Comments on Advice to ONC on PCAST

Wes Rishel recently gave some advice to ONC on what they should do with respect to the PCAST report.   In it, he largely agrees with me, or I with him.  There are a few points of departure, which I'd like to address:

• Documents vs. Molecules
• The arcanity of CDA.
• The dreaded OID.
• The unwillingness of HL7 to do more than experiment.
• Getting agreement on important molecules vs. documents.

More than 200 products have been ONC-ATCB certified.  Based on reports from others, I would estimate that at least 80% of those support generating a CCD (and therefore CDA).  Viewing IHE Connectathon results, more than 50 companies around the world have demonstrated the ability to generate a CDA, and as evidenced by IHE Conformance statements, nearly 40 of those companies are shipping product that does so (and many have more than one product). 

Arcane?  Maybe, BUT also doable and shipping.

Should we go back to the drawing board and do it better?  My answer to this question depends on what your time frame is.  If it for stage 2, the answer is pretty clear.  NO.  If you want to get it right, and take in the experiences of others, you need to take the time to figure this out and to build consensus.  If you want this to get started, great.  Just don't tie it to an arbitrarily tight deadline.

Documents vs. Molecules
Actually, I don't disagree with Wes at all on this topic.  I just wanted to point out a few things from my own experiences creating a system envisioned in a former job that is similar to what PCAST envisioned.  The importance of context is one we built into that system.  It extracted problems, medications, allergies and procedures from dictated text, coded the problems, and saved the links back to the documentation with the data stored in the database.  That database was successfully used to identify patients taking Vioxx when that recall was announced.

The IHE Query for Existing Data profile envisions just such an extraction.  In fact, it uses very similar XML as found in CDA, and when data is extracted from documents, requires that references to the source documents be provided with the data.  Does IHE support the PCAST vision?  Yes, it does.

The Arcanity of CDA
Any critique of arcanity should start by addressing the specific issues, not just an essential claim of difficulty.  So, to add to Wes's point, what contributes to the arcanity:

• The lack of readily available educational materials and instruction (which is why I wrote The CDA Book).
• An insistence upon rigor in modeling information correctly, and the complexity reporting information rigorous models in a generalized XML implementation technology. 
• Counterintuitive uses of XML, including he use of attributes (moodCode and classCode) to define semantics in the model, rather than element names [brought about by the parsing limitations of XML].
• The onion peeling problem, which is really a question of publication format rather than a problem directly related to the standard.
• The use of the dreaded OID.

Lack of Educational Materials and Instruction
One of the problems in healthcare IT is that it is a "small" vertical market when compared to the much larger IT market.  While it didn't take me long to find a publisher for The CDA Book, what I heard from traditional publishers in the IT space was that it was "small potatoes" compared to things like HTML, XSL, XSLT, et cetera.  I'm not going to get rich off that title, nor did I expect to, but neither is my publisher (although I expect we will both do better than he projects).

It's also not the kind of thing that used to show up frequently in informatics classes, although I do see that changing (and have taught a few classes on the topic).  I expect by this time next year that there will be a few classes that spend at least a few weeks, and maybe an entire semester on the topic.

Rigor in Modeling
I don't want to see the perpetuation of the abuse of OBX and ORU that we've seen in HL7 Version 2.  This is after all possibly my mother you are caring for.  That being said, a rigorous model that creates difficult XML presents other opportunities for things to get messed up in implementation, and makes it hard to see what is being said.  There should be a way to have both.  That is what the standards experts need to do.  GreenCDA is a way forward that supports both, and other ways might also be developed.

Counterintuitive XML
In the HL7 XML ITS, the XML element names don't carry semantics.  The moodCode and classCode attributes do.  Once you learn to get over that obstacle, much of the "complexity" is readily understood.  There are two different projects in HL7 to make that easier to comprehend.  The first of these is the RIM ITS, which uses semantically meaningful names, but still puts some information into classCode and moodCode.  The other is greenCDA which goes for "molecular" names of things.  I'm not convinced that either has the XML right yet, but both are headed in the right direction, making the XML more readily accessible to engineers. 

Onion Peeling
This is really a problem of how the standard is published.  There is a push from ONC to use model based development tools and to publish not just the standard, but also the data used to create the models.  One of the important challenges here is addressing how to manage the various intellectual property issues across all of the organizations that want to use this data.  That's no longer a problem I can claim to be beyond my ability to address (it is an issue that the HL7 Board is focused on).  The CDA Conslidation Project being worked on by HL7, IHE and ONC is making substantial progress in this direction.

The Deaded OID
I am reminded of the opening of "The Prisoner".  Q: Who is number one?  A: You are number six.  The ambiguity of indentification requires some mechanism to uniquely and perpetually provide the context that ensures identifiers and codes are correctly interpreted.  HL7 chose to use OIDs, which are remarkably simple to generate, distribute and manage.  What is hard about them is remembering them, but the same can also be said about codes.  But, we don't talk about the "dreaded code".  There seems to be a disconnect here.  OIDs solve a problem that needs to be solved, just like codes do.

One need only recall that several large national programs have been shut down because identifers were not correctly dealt with.  Criticising without proposing a solution is not constructive.  If you have a better solution to this problem, I'd love to hear it.  I can personally think of a few, but they add complexity through indirection, and I'm not sure that helps either.

The Unwillingness of HL7 to do more than experiment.
Progress starts with experimentation, moving beyond the theoretical with the recognition that more information may be needed.  The concept of a "Draft Standard for Trial Use" embodies this principle.  We say try it out and tell us what you think.  That's not an unwillingness to do more than experiment, it's simply a recognition that attempts to theorize the right way to do something are futile beyond a certain point.  Experience is needed, so go ahead, get some and tell us what you learned.  If you'd like some approval beyond that, you might try describing your experiment, but um, do me a favor.  Make sure that you realize that you are experimenting, and that you do have consenting patients participating in your study.

Getting Agreement on Important Molecules vs. Documents
Getting agreement on the molecules is a required step when one creates a document specification.  Having done this more than two dozen times in three different organization, what I can tell you is that we already have a considerable collection (nearly 500) molecules, that have already been agreed upon by multiple organizations, standards experts, clinicians, et cetera.

In developing the HL7 CCD Specification, the IHE PCC Technical Framework, various other HL7 implementation guides, and the HITSP C83 specfication, we used the principle of creating the library of building blocks (molecules).  Documents are composed of sections, which are composed of various entries.  The entries are the same across documents (In HITSP, a problem entry in a C32 is the same as a problem entry in a C84 or C48, and that same principle applies across other specficiations).  In fact, the proliferation of the IHE PCC Technical Framework across Europe and Asia has not been through the documents, but rather the sections and entries that appear within it.

Getting agreement on what the molecules are is NOT the problem.  What is the problem is making that information readily available.  I get just a bit tired of rebuilding the wheel.  It this century, it is round, filled with air and made of rubber.  I'd like to move on to build the next race car.