Wes RishelGartner Symposium last month had the finest showing of healthcare clients we have ever seen. A signature feature of Gartner symposia is 1-on-1 sessions between individual clients and Gartner analysts; several of mine were eye-opening discussions on the work required to achieve interoperability between multiple EHRs in the joint DoD-VA Virtual Lifetime Electronic Record (VLER) and to achieve interoperability among the early participants in the Nationwide Health Information Network (NwHIN). The clinical specification for exchange was the C32, a HITSP profile of the HL7 continuity of care document (CCD). There were many problems where the parties involved discovered they had each interpreted the specifications differently. In order to get the interfaces running the participants ended up creating a multilateral “harmonized” interpretation of the C32.
As is often the case, errors in interpreting the specifications often are not detected by the receiving EHR. Instead, the receiver simply omits a datum or files it in the wrong place in its database. The errors are only uncovered when someone looks at data on the screen and says “that’s not right” or “they didn’t send us the information the said they would.”
I have since talked to enough other people involved in achieving semantic interoperability based on the C32 to be sure that the problems are endemic to the C32 and not attributable to any one project. In each bilateral or multilateral project it has been necessary to use testing to discover differing interpretations and to have meetings to create harmonized versions.
It is important to emphasize that these differing interpretations of the C32 did not represent incompetent programming. The programming staffs supporting most EHRs were well-skilled with XML and understood how data was represented in their own EHRs. Difficulties arose in interpreting the C32 to decide how to place data within the complex XML used to represent the CCD. Indeed, some times each side had what appeared to be a valid interpretation of the spec. When they differed the process of deciding which was right was a bit like Talmudic disputation, with the rabbis being the analysts of each firm and the sacred documents being the four or five different documents that had to be used simultaneously in order to find interpret the C32.
In Set the Record Straight about NwHIN Experiences There may be more than two dozen EHRs exchanging C32s for semantic interoperability now. However, the process of bilateral or small-group multilateral harmonization is not scalable to cover EHRs serving thousands of health delivery organizations. Systems A and B have agreed on one harmonization spec and systems C and D have agreed on another, there is no reason to believe that A can interoperate with C or B with D.
Fortunately HL7, IHE and The Story Project http://www.healthstory.com/index.html have been working on a systematic improvement in how CDA documents are specified that. The new approach, called the Consolidated CDA (CCDA) includes a respecified CCD. It is completing ballot and will be available in time for meaningful use Stage 2. It includes numerous improvements:
- The specs are consolidated in a single document .
- The specification of X-paths for data items is more specific, reducing the possibility of alternate, valid interpretations
- There will be an appendix that maps in the specification standard business names, making it easier for a programmers that know their EHR’s database and XML to figure out the appropriate CDA X-path
- The way specific data is represented is consistent across different document types, so programmers that have developed a CCD will be able to carry their experience over to discharge summaries.
This is excellent work. I hope it works out well. (The tentative nature of this comment is because the only real proof will occur when interoperability testing occurs based on the new approach.)
Kudos also must go to Doug Fridsma at ONC for helping to cut through red tape that gave rise to the multiple documents construct in HITSP.
The CCDA is a big step forward, but it is not the whole story. One senior architect involved in the VLER effort has estimated that projects based on the CCD in the CCDA will find 50% fewer problems during interoperability testing. That is still not enough to reach large-scale interoperability, without bilateral or multilateral harmonization documents.
In future blogs I hope to suggest actions that ONC should take in the time frame of Stage 2 and actions that HL7 should take to further streamline the work of interface writers in the long term.
Category: Uncategorized Tags:
4 responses so far ↓
1 Keith Boone November 17, 2011 at 10:17 pm
One of VLER’s challenges was the loss of the organization maintaining the C32 at the time it was being deployed. That lack meant that many questions on interpretation had no place to be addressed. At least with CCDA, that problem will also be addressed.
2 Stanley Nachimson November 18, 2011 at 9:06 am
Another example of how testing before adoption is critical for standards. We need to continue to build facilities to test both clinical and administrative transactions
3 David Parker November 18, 2011 at 9:38 am
Nice post, Wes.
Having been directly in the fray of the VLER experience with C32 interoperability, as well as part of the Consolidated CDA project, I am hopeful that the Consolidated CDA will help a lot.
In our VLER experience, interoperability challenges fell roughly into two buckets:
1) Structural differences (creation side)- 2 senders have different structures for a data element (as you summarize well above, Wes)
2) Textual Representation parsing (receiving end)- differing expectations of where to find the readable textual representation of data element (e.g. the diagnosis vs. the ICD-9 code).
Consolidated CDA should help the former a whole lot. For organizations starting from scratch on the CCD, the 50% improvement you quote is probably about right.
The latter will continue to require the receivers to be sophisticated enough in their parsing to handle senders only sending a subset of the acceptable/proper ways of providing the textual representations within the structure (with different senders making different choices). In CDA, this is the “displayName” vs. “originalText” (with or without using a reference to the “narrative block”) vs. the code itself.
The next task to improve interoperability is to improve the usability and functionality of the validation tools (like the NIST validator). All the issues we found in VLER could have been readily caught earlier with an improved validator tool!
4 Robert Worden November 19, 2011 at 11:44 am
Hi Wes –
Very stimulating post. You estimate that the new consolidated C32 may reduce the costs of validation by about a factor 2; but is that enough?
There is a way to reduce validation costs further. Use a consolidated Green C32 with reliable, automatically generated transforms to the full C32. Green CDA is generally three times smaller and simpler than the corresponding full CDA, and uses the business names you mention; so there is much less room for different interpretations. Then the HL7 fixed ‘stuff’ is supplied automatically by the transform.
This is technically feasible now, and is being applied in the UK now. The sooner it is available for C32, the sooner validation costs will come down.