Implementation Technology Specifications

I met today with the Implementation Technology Specification (ITS) Workgroup to discuss ITS issues related to the HL7 CDA Standard, both for the current CDA Release 2.0 and also CDA R3 currently being developed by the HL7 Structured Documents Workgroup.

One Schema to Rule them All and Bind them
In the first meeting, we discussed Grahame Grieve's proposal for a RIM-based ITS.  This ITS is, I think, rather important for the representation of HL7 Version 3 messages and documents.  The RIM-based ITS uses the HL7 RIM semantics to produce a single schema that describes a RIM-based artifact (message or document).  The beauty of the RIM-based ITS is that it contains something on the order of 50 or so classes. This is a volume that can be readily taught to engineers, rather than the current collection of 50 domains, 1000+ interactions, and I'm certain an order of magnitude more "clones"¹. It also associates the RIM class names with the XML element names so that element names are meaningful.   This eliminates much of the cognitive dissonance caused by the current XML ITS.


The ITS workgroup agreed to develop a scope statement for a project that would develop this as an HL7 standard.


The μ ITS 
The idea of the μ ITS is spawned by two other initiatives, as I stated in a previous post:  hData and the Green CDA work of Alschuler and Associates and Bob Dolin.  Taking the ideas of these two projects a step further, I came up with the concept of the μ ITS.  We discussed this idea in the ITS meeting along with the other two ideas, and came to the conclusion that they address three areas of concern that have some overlap and some differences.  The ITS work group agreed to develop a scope statement to be reviewed an sent up the chain.  I'm writing the first draft with collaborators from MITRE (developers of hData).  Structured Documents agreed to write a scope statement for development of a proof of concept for the Green CDA using the CCD templates, and to work with the ITS and Implementation and Conformance work groups on it.

Now, here's how I think this all breaks down:
The μ ITS is a collection of principles describing a micro-ITS, its required properties, artifacts and deliverables.  hData is a transport mechanism that uses one or more micro-ITS implementations to exchange information.  Green CDA is an instance of a micro-ITS.  A fourth project is a μ-Processor.  The μ-Processor takes as input a collection of business rules governing an exchange described in a controlled fashion, some business names, and an algorithm for unifying them.  As output it produces a micro-ITS.  The specification of the μ ITS will be informed by the development of a prototype μ-Processor.


The RQ-ITS

Finally, there is one last ITS I'd like to mention in passing.  It is derived from the work of the HL7 Clinical Decision Support work group on the URL-based implementation guide for the Context Aware Information Retrieval (Infobutton).  That specification is a RESTful query for information pertinent to a clinical act in a particular context.  It occurs to me that several HL7 interactions, some of which are queries, and others of which are retrieval operations, could benefit from a similar specification.  The RESTful Query ITS presents a set of rules by which an HL7 message that retrieves a resource is converted from the HL7 Model presentation (an R-MIM) into an HTTP GET request.  Interactions which are appropriately designed can readily and quickly implemented using these rules.  I believe that the URL-based Infobutton Specification is an implementation that could very much inform this sort of ITS.  One of the things that would likely go into an RQ ITS is the application of business names to an HL7 model artifact.  The business names would then become the parameters of the query.  

Summary
Today was a very productive day.  I was able to help coordinate the efforts of two different committees trying to reach similar goals.  Throughout there was a spirit of collaboration and even more importantly, the willingness to look at innovation in HL7.   Not everyone feels comfortable with these directions.  There are some slippery slopes that we could slide down with no way back up.  A few pitons have been driven in to rope us off, and even those don't seem all that substantial.  However, we do have to listen to our customers, and these initiatives are certainly attempts to meet their needs.

I'm not sure that Green CDA is something that HL7 would have considered a few years ago, nor do I believe that we would have had the necessary experience to approach it as we are today.  The same is true of the μ ITS.  I'm hopeful that we'll see significant progress on both of these initiatives in Rio in May, and look forward to playing with some of the ideas that we've been exploring this week.  Tomorrow I'll tell you about another toy that I plan on playing with in the coming months ... Template Registries.



     Keith


P.S. I hadn't realized that I had created a triple pun with the name μ ITS. 

1. The Greek letter MU is one character before the Greek letter NU, and the the MU ITS is a step back  from the New ITS.  
2. When translated to its English pronunciation MU is an acronym for Meaningful Use.  
3. Finally, the μ symbol is used for the metric prefix micro, also meaning small, and a μ ITS is intended to create smaller and simpler messages (this is the one I missed)
   

---

¹ A clone is a renamed copy of a RIM class that has been restricted by a working group to a subset of the full RIM semantics. The name of the clone in an HL7 message or document appears as the XML Element name but it "carries" no semantics.

Hot topics at the HL7 Working Group Meeting

There were a number of topics that came up today and the HL7 Working Group Meeting, but two of them seem to deserve attention here.  Both of these are related to meaningful use, but in completely different ways.

CCR and CCD Translations
The first topic that was heavily debated in the Structured Documents working group meeting was whether or not HL7 should publish transforms between the HL7 CCD format and the ASTM E2369 CCR format and back, and document the limitations of such a transform.  Most of the debate was between cochairs, with me on the side of publication, two others adamantly against it, and a third being realtively neutral.

Conceptually, we all agree that the only meaningful way forward (e.g., for 2013) is to communicate clincial information is through the CDA standard and HL7, IHE and HITSP implementation guides based on those.  Where we differ is in tactics.   Some would have HL7 do nothing to make it easier to use CCR with EHR systems, and others would make it easier to transition between use of CCR and use of CDA.  I'm in the second camp.  We voted on whether to develop a project to do this and the outcome is that the committee agreed to do so, though not unanimously given the divisions.

Even though I'm not fond of the CCR XML, I must acknowledge that A) It's been regulated as a requirement that applications be able to view them at a very minimum, and B) that regulation is extremely unlikely to change as a result of ANY industry feedback.  Having acknowledged that, there are a couple of ways forward.  1) Penalize those who have gone down one path or another, or 2) make it easier to cross between the two.  My own thoughts are to take the latter road, because this will make it easier for others to come to HL7 and use CDA.  That includes both vendors and healthcare providers.  Most of the latter are simply caught in the middle of this debate. 

This has the danger that it also enables implementors to go the other direction.  I have the same attitude about this concern as I do about the concern that sharing healthcare data could cause a healthcare facility to lose customers.  If you believe that providing better service to your customers will enable them to leave you to go elsewhere, you need to look at what you are doing much more closely.  However, if you really believe in what you are doing, this can only be to your own advantage.

The industry needs this, and it will be done whether or not HL7 does it.  I would prefer to see HL7 take the lead and do it right because it is the appropriate thing to do to serve our constituents.  Some feel that this will simply perpetuate the problem of two standards, and those concerns are indeed reasonable.  However, HL7 cannot ignore the lessons that CCR had to teach us.  Furthermore, we must not ignore the needs of our constituents just because their requirements (imposed from an external body), seem not to be in HL7's best interests tactically.  The strategic move is to serve the industry, and by so doing, gain the trust and confidence that will allow that industry to adopt the HL7 CDA standard.

This is the high road, or path less travelled by.  It may be more difficult, but to me it seems to be the right direction to go.  I may not like having to choose this path, but it will be a better result for patients.  I am here not for any one company or organization.  I develop healthcare standards for  my wife, my children, my mother and anyone else who needs healthcare.  If there is something I can do to make sure that they get the right care, I will, and this seems to be it.

Green CDA

Green CDA is good for the environment because it uses fewer electrons.  The idea behind Green CDA is that there is a simpler way to exchange CDA documents that meets 80% of the capabilities of CDA, but has a much simpler to understand XML.  This is another of the lessons learned from CCR.  I can see the point of pain that Green CDA is going after.  As someone who has taught CDA to more developers than I can count, and having implemented CDA using numerous implementation guides, I very clearly see the point of pain it is addressing.  I agree wholeheartedly that it needs to be addressed.  Green CDA is very similar to the hData format developed by MITRE.

There are some limitations in Green CDA as currently proposed that I have some concerns about, and so I propose something just a litte bit different.  I'll just introduce this concept below, as it needs more fleshing out.

The μ ITS
Green CDA is simply another Implementation Technology Specification or ITS for use with the CDA standard.  The same techniques could readily be applied to any other HL7 Version 3 message or document with similar benefits.  I believe that we should approach this as an alternate ITS for HL7 Version 3.  I call this the μ ITS because it is close to the New ITS proposes a few years ago in HL7, but takes a slight step backwards.  Also the μ ITS takes its name from the synthesis of model of meaning and model of use that I discussed earlier this year.  When I told the cochair of the TSC and a past supporter of the New ITS that we needed something like this he was floored because I adamantly and successfully opposed that ITS.  I still think the idea is a little bit wonky because I understand the value of communicating meaning vs. use, but I don't see a way around it.  I guess it goes to show that I can indeed be educated even though I turn 45 in two days.

It's getting late, and the details of the μ ITS are still rolling around in the back of my head.  I'm going to sleep on it and write more about it tomorrow.

     Keith