XHTML for CDA Release 3

CDA Release 2 uses an HTML-like markup language to support narrative text.  The table below shows the coorespondence between the two:

CDA	HTML
‹content›	‹SPAN›
‹linkHTML› (attributes are identical)	‹A› ‹LINK›
‹sub›	‹SUB›
‹sup›	‹SUP›
‹br›	‹BR›
‹footnote›‹footnoteRef›	(not available)
‹renderMultimedia›	‹IMG›
‹paragraph›	‹P›
‹list listType="ordered"›	‹OL›
‹list listType="unordered"›	‹UL›
styleCode="className"	class="className"
ID="value"	ID="value"

For CDA Release 3 there's been a formal proposal to use XHTML to support the narrative text. I'm very much in support of this for several reasons. You can take a class on XHTML, buy a book on it, and hire engineers with experience in this markup language. From a technical perspective, this also eliminates the need for a "default" stylesheet, since the XHTML is already there.

There are a couple of places where I suspect we will want to "Profile" XHTML to limit some of the capabilities.  The W3C developed Modular XHTML for this sort of purpose.

What are the challenges and their implications?  The biggest issue has to deal with where and how the document structure is stored. 

The structure of the CDA Document today is as a list of sections representing using a RIM class called an Organizer.  These sections can possibly contain recursive subsections.  All of these are intermingled into the RIM structure of the CDA.  Using XHTML would likely separate the organization of the text from the structured entries describing it.  The current document structure organizes content in a certain way, and that organization carries semantic meaning (not all aspects of presentation are fluff!).  This change would require some thought to determine whether: 

1. The XHTML structure is used to organize the content, with sections attached to XHTML organizing elements such as ‹div›.
2. A parallel organization structure is incorporated into the structured entries.

There are strengths and weaknesses to either of these.  The biggest weakness of using the XHTML representation for organizational structure of the content is the loss of the organization structure in the RIM classes.  One reason this is an issue is because of something called context conduction.  Context conduction allows certain pieces of context (i.e., the subject, author or performer of an act in a clinical statement) to be conveyed from larger structural components.  Loss of the organization structure in the structured entries would make it more difficult for systems to determine who was the author, subject or performer associated with a given act using fairly simple programatic constructs.

Duplicating the organizational structure in the structured entries has other problems.  Any time you duplicate information in two different places, you have an associated risk that the duplication process was not carried out correctly.  The question then becomes how to determine which structure is correct.

Fortunately, I think there is a solution to both of these problems.  The organizational structural of the document is implicitly represented by block elements in the content.  That structure can be made explicit through an algorithmic transform of the content.  Specifying the algorithm by which the structure is duplicated enables use of that structure to convey context information.  The remaining question is whether it would be better to convey the structured entries in the CDA Release 3 document using that algorithmically developed structure (which could require a validation step), or letting the application use the algorithm when it needed to make inferences about context.

I think at this point, I'm in favor of duplicating the organizational structure in the entries, but could be readily convinced that it isn't necessary.  An advantage to not carrying the implicit structure is that you can have other parallel structures in the structured entries.  This gives you another "view" of the data that is separated from the presentation view.  An example of where this could be valuable is in developing treatment plans.  A component of a treatment plan is the particular condition or conditions which it treats.  That could be the context for that portion of the treatment plan, which could simplify the transmission of the treatment plan content.

An additional benefit of using XHTML to convey document structure is that it allows lists and tables to also be used to convey structure.  Tables and lists are organizers of information even more so than document sections.  Why should they not be treated in the same fashion in CDA?

I expect the discussion and development of this formal proposal will take quite a bit of time over the coming months.  It will certainly result in some challenging problems that need to be solved if we are to move forward in this direction.  I look forward to those challenges.

Virtual Medical Records, HL7 Models and Simplification

As I've previously reported, there are a number of different activities in HL7 regarding simplification.  One of these activities is around the development of a model for the virtual medical record (VMR) to use in the Domain Analisys Model.  The VMR concept has been around for more than a decade, but has yet to really be standardized.

The HL7 Clinical Decision Support workgroup is currently exploring the US Federal Health Information Model.

I have (as usual), a somewhat different view of what the VMR should be.  The VMR to me is to the medical record as the Document Object Model is to XML and HTML.  It is described by a UML model with a set of classes, interfaces and the relationships between them, and then has bindings to various programming languages and formats (Java, JavaScript, PERL, C++, PHP, XML, et cetera). 

All HL7 Version 3 models derive from the HL7 V3 Reference Information Model, Data types and vocabulary.  I don't see this changing in the VMR, but I do forsee changes to how we would develop a model for it.  As I've been exploring this area, I see some things missing from the current HL7 methodology.  The first of these is interfaces.  Interfaces represent an excellent way to capture common design capabilities.  There are two examples of "interfaces" that should be used in the VMR.  The first of these is the "Annotatable" interface.  A class that implements this interface supports the ability to add annotations to an information item (a class in the model) that has an author, data enterer, date of authorship, and free text.  This interface represents a way to access annotations described in the A_Annotation (Universal) COCT_RM590000UV CMET that is used in several places in HL7 Version 3. 

Here's a bit of pseudo-code defining Annotation and the Annotatable interface.

class Annotation extends Act {
    String readwrite Text;
    List readonly Authors;
    List readonly DataEnterer;
    Act readonly Subject;
}

interface Annotatable  {
    List readonly Annotations;
}

The Annotatable interface can be implemented by any Act.  It provides access to the list of annotations on that act.  Each annotation provides access to the text, authors, data enterer, and the act that is the subject of the annotation.

The Severity interface is similar, except that it provides access to a single Severity class that represents the severity of a concern, allergy, or reaction.

I'm using about ten sources for modeling content.  The most important is probably the clinical statement pattern.  Other important sources are the standards and draft standards in the Care Record domain, and domain specific content in the Clinical Genomics pedigree topic, Orders and Observations, Pharmacy and Medications, and Immunization.  Another important modelling sources is of course the HL7 Continutity of Care Document.  This latter document helps to define the major categories of information that I would expect to appear in the Patient class.  I think the US Federal Healthcare Information Model will help identify some of the neccessary relationships, but it's just at much to detailed a level.

Below is a list of just some of the classes that I've found thus far (and my work is nowhere near complete):

Class	RIM Class Type	Specialization
Allergy Intollerance Concern	Act	CONC
Allergy Intollerance List	Act	LIST
Annotation	Act	OBS
AssessmentComponent	Act	OBS
AssessmentScore	Act	OBS
Author	Participation	AUT
CarePlan	Act	PCPR
Causes	Participation	CAGNT
Consumable	Participation	CSM
Custodian	Participation	CST
Document	Act	DOC
Fullfills	ActRelationship	FLFS
Goal	Act	OBS
Guideline	Act	PCPR
Healthcare Facility	Role	SDLOC
Informant	Participation	INF
Legal Authenticator	Participation	LA
Medication	Role	ADMM
Organization	Entity	ORG
Patient	Role	PAT
Place	Entity	PLC
Precondition	ActRelationship	PRCN
Procedure	Act	PROC
Reaction	Act	OBS
Reason	ActRelationship	RSON
Record Target	Participation	RCT
ReferenceRange	ActRelationship	REFV
Related Party	Role	ROL
Substance Administration	Act	SBADM

Some of these will wind up being split (e.g., Substance Administration will eventually show up as Immunization and Medication) in the model), others will be renamed (e.g., Record Target to MedicalRecord or some such).

Once I get the list to a point where I think it is complete, I'll begin developing a set of UML diagrams.  There'll be some interesting effects as I go through this work.  The use of packages and interfaces is not something that's not often been done in the HL7 Version 3 models.  Using the W3C DOM as a model has gotten me thinking about what I know (UML modeling) and the V3 RIM, and applying it.  I've gone from someone who has an outsider's view of HL7 to having a detailed insider's view, and gotten lost in the woods in the process (as I suspect many of us in HL7 have).  Using another standard that I know well like the DOM has given me a new map to work with.

There are quite a number of techniques that the DOM uses in its models that could vastly simplify HL7 Version 3.  The idea that there could be a standard way to interact with the medical record that is consistent across not just serialization, but also dealing with dynamic behaviors is getting to be pretty interesting.  I'm already imagining that there will be a base class that supports XML and Text representations, and other features that support declarations of conformance (templates) and validations, and ...

Packaging will make it easier to separate and scope these different concerns (e.g., conformance and validation).  Having identified the appropriate package for a class or interface will enable use to determine whether different parts of the VMR are in or out of scope for a particular project.

An Alternative Approach for how to use the NIEM

In Adopting the NIEM for Health Information Exchange Joel Massou talks about replacing the current set of standards that many of us have been working on over the last decade years with new XML content.  While he makes many key points (e.g., concept naming and software development requirements), I disagree with the overall approach.

The key approach that I think is important from the NIEM is not the current set of data models, but rather the approaches used in harmonization.  I'm told that the key here in the NIEM is to engage committed stakeholders and in the processes used to obtain consensus.  Having seen how some of these processes played out in NHIN Direct, I think that NIEM may be on to something, but more work is clearly needed.

If you've read this blog before, you've seen me reference Glen Marshall's excellent article on the Standards Value Chain.  The point is that it takes time (sometimes as longer than five years) to go from the development of a standard to release in a product.  It all depends upon market demand.  ONC has already created a demand for the CCD and CDA standards in the Interim Final Rule.  Changing that would be a disaster at this stage of the game.  Too many have already headed down the path because providers need products using these standards yesterday.

Changing standards in the middle of this process will take even more time.  There should be an evolution in the standards along the lines that Joel suggests, rather than a revolution.  In fact, this is an ideal time in HL7 to address this needed change.  The Structured Documents Workgroup is presently working on the next release of CDA and on Green CDA, the ITS workgroup is reviewing several simpler ITS forms including hData and MicroITS, Clinical Decision Support is searching for models, and everybody is trying to simplify.  An evolutionary path will be sustainable.

My father's imparted wisdom comes to mind again, this time, about trying to change horses in midstream, and the effects that it has on both schedules and quality of work.

Are we lost?

For the last four years, the healthcare standards imperatives in the US have largely been driven by AHIC, ONC, CCHIT and use cases delivered to ANSI/HITSP.  Now that the HITSP and CCHIT contracts have ended, and meaningful use is in the process of being enacted those drivers no longer exist.  This has to some degree caused a shift in what we are working on in healthcare standards.

So what is happening in the meantime?

HL7 is working on an overall model of healthcare in at least five different initiatives:

• hData
• Micro-ITS
• VMR
• A framework based on the EHR Functional Model
• Green CDA

There's progress on some of these, yet not a lot convergence, and quite a good deal of overlap.  I'd say we are still in the "Research" phase of this R&D effort on standardization.  When we get there, I think this will be a pretty disruptive innovation (see my previous post reviewing the Innovator's Dilemma where this term is described).

IHE is focusing on refining HIE oriented profiles in the IT Infrastructure Committee, Patient Care Coordination is focused on meaningful use in perinatal and post-natal care, and Cardiology is working on the Image enabled office.  IHE Radiology is examining Web services.  There are few breakthrough activities going on here; most of what I see is sustaining innovation.

NHIN Direct is the one US government initiative that is getting some attention, although it is behind by about a month after delays in obtaining consensus (now nearly achieved). 

The HITSP Harmonization process is due to be replaced by an NIEM oriented process, but while submissions were due back in March, nothing has been announced.

The industry is still waiting for various details of the "Meaningful Use" regulations to be completed, some of which are expected "REAL SOON NOW".

The abscense of a strong "requirements" driver in the US is clearly having an impact on standards initiatives here.  Collaboration among the various standards bodies is reduced due to the lack of deadline driven projects.  Most of us are waiting for the other shoe to drop, mostly on several regulatory fronts, including standards, meaningful use incentives, and long term certification, but also on standards and harmonization contracts due to be announced by ONC.

Does that mean the standards community is lost?  I don't think so.  But I do welcome the opportunity to "catch my breath".  The last four years have been very intense.  While I would do it all over again in a heartbeat, I'm glad I'm not at that level of intensity right now.  I expect that to change any day now.

I appreciate the struggle that HL7 is going through right now.  They've latched onto an old problem (models of healthcare information) and are seeing it in a very new light (simplicity in use and access) and at a higher level of abstraction that the RIM.  Given that many workgroups are currently struggling with the same issues, I expect that there will be some divergence for a few more months, followed by a convergence and reinvigoration of HL7 Version 3 activities focused on making it more readily used.  My hope is that a reemergence of a strong driver in US government activities will not distract HL7 from engaging in this work.

IHE PCC has started some work in a new paradigm in Patient Care Coordination that addresses workflows crossing various healthcare settings.  That space will probably produce a profile a year for the next three or four years.  This too is sustaining work, and I believe will continue regardless of what happens here in the US.

The Search for Use in HL7

Yesterday I met with 5 developers at MITRE in their Burlington, MA office.  In addition to giving the CDA and CCD ambassador talk, we spent some time reviewing and discussing the hData Implementation Technology Specification.  Gerald Buechelt is leading this effort in the HL7 ITS Workgroup.

During the review, several interesting ideas cropped up (as they usually do when brainstorming).  One of the interesting questions is how to organize the "resource space" of the healthcare information systems using the hData ITS.  Since hData is a RESTful approach, access to services is governed by resources identified using a URL.  In the HTTP world, URLs have a hostname, zero or more path components, and then a resource name component.  Each of the path components in the URL further refines what kind of content could appear in the resource.  There are a number of common ways to represent these paths.  One example is:
http://www.examplehealthrecord.org/patients/patientId/problems.xml.  In this example, the "patients" path component describes a particular kind object (a patient) that is being referenced.  The patientId component identifies (by a key) which of the patients is being referenced, and finally, the problems.xml resource identifies which of the resources associated with the given patient are being accessed.  The URL is effectively a "search" criteria or pattern matching criteria that is being accessed.  Another URL that could have been used to produce the same information might be: http://examplehealthrecord.org/problems/patients/patientId.xml. 

This "structured search pattern" is something that is familiar to users of XSLT, XPath and XQuery.  In fact, the structure and organization of the XPath searches has been extensively analysed.  The math is even quite pretty (perhaps I'll write a post on in someday).  I'd be interested in seeing a similar representation for REST based URLs be developed to deal with patient records.  But before we can get there, we need to have a better understanding of what it is we are organizing using these URLs.

"Water, water, everywhere, nor any drop to drink"
- Samuel Taylor Coleridge; The Rime of the Ancient Mariner

This leads into the main theme of this posting, which is the search for a model of how health information is used.  HL7 has done great work on developing the Reference Information Model which provides the model of meaning, and the various HL7 Version 3 standards which have computationally well defined exchange semantics.  Part of what makes it difficult to find the model of use is that while meaning is in general static, use is part of the dynamic model.  Several different workgroups in HL7 are starting projects that are focused on how information is used.  The Services Aware Interoperability Framework (SAIF) includes a Behavioral Framework currently being developed by the HL7 Architecture Review Board.  The HL7 Clinical Decision Support Workgroup is working on the Virtual Medical Record, which is a data model that can be used for clinical decision support.  The Micro-ITS and hData project is exploring how to deal with domain specific languages more oriented towards the model of use in an exchange.  The EHR Workgroup has proposed a project called the EHR System Computationally-Independent Information-Model (EHR-S CI-IM) to develop constrained information models or "data profiles" that can be associated with an EHR-S Functional profile.  The superset of these data profiles would effectively become an overarching Computationally-Independent Information-Model supporting the HL7 development process.  Many other workgroups are now deep into development of Domain Analysis Models, which are again, models of work processes and information oriented around how it is used.

With everyone now searching for generalized models, two questions arise.  What is objective evidence that something belongs in a model of use? Related to that is how will the process of developing an overall model will be governed?  We've already seen the need to coordinate the VMR and micro-ITS/hData work, and I also suspect that we'll need to coordinate with the EHR workgroup as well.  At the same time, we need to be certain that it all fits within the SAIF and Behavioral Framework activities.  Given that everyone is now headed towards the same stuff, what is the next step? 

From a business perspective, there needs to be internal coordination (governance) within HL7 on much of this work that is so similar in scope.  The TSC needs to step in and help organize these overlapping activities.

From an information viewpoint, we need take a look at existing models to see which may be have something to contribute.  As the quote above alludes, there is no lack for models in HL7.  We have the Clinical Statement model, the CCR data set that is the underlying model of the CCD, the Care Provision Model, the Pharmacy and Medications Model, et cetera.  We also have external work like that of the US Federal Health Architecture initiative. 

There is also a hidden resource we discovered yesterday that contains within in it the collective wisdom of the HL7 Community as expressed in how different information systems collaborate using V3 standards. The HL7 development process includes identification of Application Roles which participate in Interactions with other Application Roles.  These Interactions involve the communication of V3 messages.  The high level entry points of these V3 messages represent the key objects that make up a model of healthcare information use, at least as defined by HL7 Version 3 standards efforts.  The application roles define a set of service roles.  Let's look at a couple of examples embodied in HL7 V3 Standards:

The HL7 Version 3 Patient Administration Domain includes about 13 different topic areas including: Persons, Identity Documents, Patients, Service Locations, and Encounters of various types.  Each of these belong in a model of use.  The HL7 Care Provision Domain includes about 10 different topic areas including: Care Records, Care Plans, Transfers of Care, Allergies and Intolerances, Adverse Reactions, Professional Services, Encounters and Episodes of Care, Health Concerns (Problem Lists), and Assessments.  The CCD contains all the elements of the CCR data set, which includes: Payers, Advance Directives, Support (Persons), Functional Status, Problems, Family History, Social History, Alerts, Medications, Medical Equipment, Immunizations, Vital Signs, Results, Procedures, Encounters, Plan of Care, Healthcare Providers.  And so on.

We need to figure out how to expose this underlying model of healthcare information that is embedded in the HL7 Version 3 standards. 

After that, we need to makes this information simple and easy for implementors to find and understand. The engineers implementing the HL7 standards are probably our largest audience of these standards.  They need simplicity.  Simplicity is a theme that I've been persuing for a number of years (actually, it was the central theme of my comments on the HL7 CDA Release 2.0 standard six years ago), and one that I will continue to persue more agressively in the coming years.

Attacks on HL7 Version 3 as being too complicated are certainly based on the experiences of many of these implementers.  They didn't appear just because one SDO doesn't like another, or one vendor or another didn't like HL7.  My own learning curve is pretty steep, and yet my understanding of how to use HL7 Version 3 came very slowly.  But you shouldn't need to understand how something is built in order to use it.  What you need to understand is how to "operate" it.  I don't fully understand how a motorcycle, a microwave or a computer works.  I certainly understand the controls and the general maintainance procedures, but I don't have to know how to manufacture these objects in order to use them.  The same should be true of HL7 Version 3 standards.

P.S.  After the meeting was over, and I was headed out, I picked up the phone and called a former collegue who is now also working on uses of NLP in healthcare at MITRE and connected her up to the group working on hData.  Score another connection for the O3C.

Simplification

My how times change.  In 2005, the largest problem facing healthcare IT interoperability in the US was the harmonization of standards.  ANSI/HITSP was formed in October of 2005 with the goal of addressing this particular issue.  It is now four years (and a month) since HITSP was created, and we no longer talk about the "Harmonization" problem.  The problem facing us now is the "Simplification" of standards.  I'm glad to see that we are moving onto the next problem, but hope that in so doing, we don't "unsolve" the previous one.

HITSP's great success in achieving its contract objectives goes largely unnoticed in this new phase because its objectives no longer address the most pressing issue.  I've heard several complaints about how the HITSP specifications are too complex, long and not directive enough for implementors.  These are valid complaints if you are trying to use these specifications as "implementation guides".  They were designed to specify enough to address the harmonized use of standards.  Iimplementation guides are much more than that.  Many of us involved in HITSP have argued that we need to find a better way to communicate.  However, the development of implementation guides requires a great deal more resources that were made available to HITSP under the ONC contract for harmonization, and the scope of the harmonization contract did not include that requirement.

To put this all into perspective, I did a little bit of research into what we (US taxpayers) are paying for with respect to implementation guides for healthcare standards.  See http://www.fedspending.org/ for one place where you can dig up some of this data for yourself. My own survey was anything but scientific, but based on my findings, I will assert that a 50-100 page implementation guide seems to cover from 2 - 4 transactions, and costs anywhere from $175,000 to $350,000 dollars to develop.  It is usally done in anywhere from 6 - 15 months.  The costs don't seem to scale up linearly with complexity either, twice as much complexity results in more than twice the cost.

So, how do we move forward from here?  The next step needs to be forward, towards simplification and education, yet not reject the harmonization that we just spend four+ years and spent tens of millions of dollars of both public and private funds addressing.

There are some concrete actions that we can take:

1. Make simplification of standards an important topic for SDOs and profiling organizations to address.
   The ebXML Reference information model and the HL7 RIM are great information models (of meaning), but what we are hearing from the "Internet" crowd is that we need to be closer to how the information modeled for use (see my ramblings on Synthensis). So, how can we simply go from meaning to use and back again?
   
   
2. Develop tools to make simplification easier (tool development is cheaper in the long run than just throwing more labor at the problem).
   The HL7 Templates workgroup is in the process of starting a project to build a templates registry.  Imaging having an information resource that would pull together all the templates that you need to implement a HITSP construct in one place.  One could readily use that resource to more quicky develop complete implementation guides that wouldn't have some of the challenges that our current HITSP specifications face.
   
3. Move away from linear documents for specifications. 
   We are dealing with the information age, it's about time we moved away from linear documents, and the constraints that they place upon us.  Developers want richly linked media to help them find what they are looking for.  The HL7 V3 Ballot site is an overdone example of what I'm talking about, but it is surely better than a 100 page document to deliver the necessary content.  One of the biggest challenges that HITSP faces is how to take the content that we have now in documents and make it something that would allow us to put together a real implementation guide.
   
4. Figure out how to move away from single-SDO based interchange and vocabulary models
   One thing that the world wide web and XML have taught us is the power of structured information that can be easily transformed.  We have 5-6 different key standards for communication in healthcare, only two of which are in XML.  We have some 7-9 different key vocabularies, with very similar high level models, yet no common terminilogy interchange format.  Can we provide common model across the space of healthcare for both interchange and terminilogy standards. 
   

These are real and concrete steps that will move us in the right direction. Let's not revisit discussions we had 4 years ago, they were far from simple then, and they would be even more complicated now.

Synthesis

‘When I use a word,’ Humpty Dumpty said, in a rather scornful tone, ‘it means just what I choose it to mean, neither more nor less.’

‘The question is,’ said Alice, ‘whether you can make words mean so many different things.’
‘The question is,’ said Humpty Dumpty, ‘which is to be master – that’s all.’
-- Lewis Carol, Alice in Wonderland

It's been interesting reading the shift in discussions around REST vs. SOAP in the blogosphere this week now moving towards HTTP and HTML , or device-based connectivity.  See blog posts from John Halamka, Sean Nolan, and Wes Rishel.  My head exploded with insight -- and the sleep that I promised myself is gone by the wayside.

I'm a web, HTML and XML geek from way back.  In 2001 I claimed 7 years of experience with XML (a test my employer passed).  I've got dog-eared copies of the HTTP specifications (as well as HTML and XML specs) sitting on my shelf that are rather aged.  In the thirty years since the development of the OSI seven layer model, we've now seen a shift in how we view HTTP.  Most mappings of the web stack refer to HTTP as an "application layer" protocol, but SOAP, REST, Web Services and Web 2.0 seem to have driven it down the stack to "transport" by layering yet more on top of it.

The complexity of what has been identified as "SOAP" in all these discussions is not SOAP at all, but rather the information models in SOAP.  There's an important difference between the information models that SOAP and RESTful implementations offer that needs to be considered.  These models by the way, are not demanded of SOAP and REST, they just happen to be broadly adopted models that are often associated with these different protocols.

What REST implementations typicall offer that SOAP typically does not is something that HL7 geeks will recognize as a "model of use".  Models of use offer up business friendly names and representations for sometimes fairly complex semantic constructs (and they do it compactly).  The business concepts map closely to the Business Viewpoint of the HL7 SAEAF model.

What ebXML, HL7 Version 3, and similar protocol specifications offer up through SOAP that REST does not is a model of meaning.  The model of meaning maps closely to the Information Viewpoint represented in the HL7 SAEAF model.  Models of meaning are more complex, and contain a lot more explicit information, but they are bigger and harder to understand.  They become a language in which one must express the meaning of "simple" business concepts (although I note those concepts are not really all that simple).

Models of use are easy for people to understand and to perform simple and often very useful computations with (e.g., pretty UI).  Models of meaning are easy to perform complex and often revealing computations with (e.g., clinical decision support).  Geeks like me who've been immersed in various models of meaning don't have large problems speaking those languages and crossing between them, but trying to teach people new languages is rather hard after a certain age.  I seem to have a knack for computer languages that I just wish applied to spoken ones.

The benefits of models of use are conciseness and direct applicability to business processes, but to cross "models of use" boundaries often requires a great deal more translation (e.g., from clinical to financial).  That's because the concepts communicated in a model of meaning assume a great deal of implicit domain knowledge.  The hidden domain knowledge into the model of use makes translations hard.

The benefits of models of meaning are explicit representations of domain knowledge using a controlled information model.  All the possible sematic relationships are explicitly stated and controlled.  This simplifies translation between different models of meaning because one can work at the more atomic level of the controlled information model.  This is why (computer or human) language translators build "parse trees" first, and translate from those "models of meaning".  Models of meaning are more readily marshalled into data storage systems.

The importance of models of meaning in healthcare IT comes into play when we start talking about clinical decision support.  I illustrated one of these examples in Gozinta and Gosouta back in August.  In short, the "model of use" described in the guideline needs to be translated into a "model of meaning" representation in order to compute the guideline through a decision support rule.

So, I think I've successfully convinced myself that we need both model of use and model of meaning in the HIT standards space.  The simple business oriented representations are needed to make implementations easier for engineers.  The more complex information models are needed to compute with.

I think I see a way through the muddle, but it will take some time.  The right solution will not just adopt the first model of use that comes to us.  We will need to put some thought into it.  I believe that we can provide some motion towards an answer that could begin to use in 2013 (or earlier), would be easily adapatable with solutions deployed for 2011.

But if we move towards a model of use in communication patterns, we run into a translation problem that someone has to address.


In a nutshell, WE need to fully specify (in a normative way) translations from model of use to model of meaning and back.  The former is easy (with a common model of meaning), the latter more difficult.  Compilers are easy (use to meaning), but decompilers are hard (meaning to use).  When I say WE, I've got all my big hats on: HL7, IHE and HITSP.  And, we need to agree on a common model of meaning (and this we is the SCO, for which I have no hat).  The HL7 RIM is a really good start for a reference information model in healthcare (Wes and I both know that you can say almost anything in HL7 V3, and I have the V3 model to prove it.)

Having a common reference model provides the interlingua that will truly allow for interoperable healthcare standards.  If all models of use can be expressed in one (and nearly only one) model of meaning based on a common reference model, then translation between the models of use becomes a real possibility.  I know I can translate the "transports" that we've all been talking about into a model of use that would make a number of nay-sayers really happy.

There's also a way to use the same WSDL to enable either SOAP or RESTful transports which makes interfacing a lot easier and more negotiable.  The last problem is how to secure all of this RESTfully, which I'm somewhat unsure of.  I'm not sure it's safe to leave in the hands of the giants that gave us SOAP and WS-* (and insisted on XDS.b) but maybe they've learned their lesson

There's a lot more engineering that is needed to really make this work, and this blog posting is already too long to go into all the details.  The solution isn't simple (making hard problems easy never is) and it needs to address a lot of different business considerations.  There's also a need to address the migration issues for the current installed base (not just one, but at least 10 different HIE's in the US are using the HITSP protocols, many in production, and that doesn't count the Federal agencies, and a heck of a lot more internationally have been using the IHE specifications upon which the HITSP protocols are built for even longer).

My main concerns about all of this discussion is CHURN and disenfrancisement.  Over the past five years we've taken huge steps forward, and this seems like a big step backwards.  It may be a step backwards that prepares for a huge leap ahead, and because of that, I'm willing to engage.  I get what REST can do (this blog and my whole standards communications campaign are built on RESTful protocols).  The concern about disenfranchisement is the suggestion that a group of uber architects could do this quickly and outside the bounds of a governance model that organizations like IHE, HITSP and HL7 impose.  If this is to work, it needs the buy-in of those organizations, and their constituencies.  It needs to have two key goals:  simplicy and compatibility with the industry investments of the last five years.  XML was a three year long project that replaced SGML and changed the world.  It had those same two key goals.

If we can synthesizes models of meaning and models of use together, we will truly have a model of meaningful use.

I'll probably get a heap of flack for this post tomorrow (or at least the pun), but what can I say?