Intended use vs actual use of HL7 CDA

This post originates from HL7 Structured Document working group discussions about the intended use vs. actual use of different interoperability paradigm - HL7 Document (CDA document) and Message some time ago when one member from Brazil asked whether there is an example of exchanging lab order using HL7 CDA or whether this type of transactions should be handled with HL7v3 message, the background he asked this question is that since he has already implemented sharing of lab result using CDA based on IHE lab profile whose transaction content is based on Lab Result Message RMIM, so someone out there probably is also trying to exchange lab order using CDA approach.

Back in 2007 HL7 has an elaborate e-mail exchange about the subject of 'documents versus messages', see http://www.ringholm.com/docs/04200_en.htm for the summary.

A Document a defined and complete information object that can exist outside of messaging context, it is a static snapshot of some data with a number of attributes to make it more human readable (any document or message is human readable after applying a viewer, but a document has more abilities to make it more readable) and create more context pulling varied data together.

At information modeling level, different use cases or different types of documents provide corresponding implementation guide to constrain the use of CDA, the constraints are in the form of conformance statements which are identified by "templateId" at section level (CDA R2 level 2) or entry level (CDA R2 level 3). At technical implementation level, the Document is exchanged via single XML schema - CDA schema which is serialized from HL7 CDA RMIM.

For example CCD (Continuity of Care Document) describes constraints on the HL7 Clinical Document Architecture, Release 2 (CDA) specification in accordance with requirements set forward in ASTM E2369-05 Standard Specification for Continuity of Care Record (CCR). Below screenshot shows portion of the constraints for problem act within the problem section.



and there is the corresponding templateId in the CDA XML document as shown below




On the other hand, A Message's main aim is machine processability; oriented towards the management of the status of business-objects; uses a dynamic model (trigger events) based on the status change of one or more business-objects; capable of providing real-time information, is focused on exchange the necessary data without worrying about more human readability, just get the data across to act on.

Messages contain control data to actively manage activities, thus making it clear who is supposed to do what, without confusing others who are just interested in reading that something is or has happened.

From modeling perspective, the constraints are directly applied at RMIM for the message, thus at technical implementation level, each Message has its XML schema serialized from the corresponding RMIM as payload wrapped within Trigger Event Control Act and Transmission wrapper schema.


In summary, from business perspective, yes it is needed to have separation since the obligation for the sending and receiving systems are different, However the question is whether the separation at technical implementation level is really need. In IHE lab profile it uses CDA to exchange lab result message RMIM, it also supports dynamic status of the lab result such as "final" and "final with correction" via ServiceEvent class. If that's the case, I do not see why we can not use CDA for exchanging lab order as payload. Of course this leads to the question of HL7 CDA's intended use v.s actual use debate as I mentioned in the beginning of this post.

Some of the participants responded it is because one of the concerns for IHE lab profile is for human readability. I am not fully convinced by this. If that's the case, then if 'human readability' is not concern, all exchange should use HL7 v3 message. Or let me put the question in another way, lets say currently human readability is not concern, so the participating systems happily use HL7v3 message for sharing information, next time the business users request to ensure the message can be rendered user friendly for human viewing, then the participating systems should be upgraded to use CDA document instead? Or another in case, one participating system only needs information for user friendly view, while at the same time another participating system requires dynamic status information and updates related to lab result, so in this case should the sending system implements two interface - one is using CDA and other using Message?

How many IT systems in the world really use the raw XML document for users to view? even CDA itself also needs to rely on XSL to render the document for human readability. Following that line of thinking, what matters is to ensure the XML itself contains the necessary data elements for user-friendly view and computer processable data elements for more sophisticated processing, so whether it is Message or Document paradigm, it is just naming convention to convey the business obligations.


Secondly from architecture's perspective it boils down to one key question for anyone who is working on designing the XML schema for web service implementation for the purpose of integration - whether to use tightly defined XML schema with different one for different use case (this is Message paradigm) or one generic loosely defined XML schema to cater for multiple use cases (this is the Document paradigm) within the same domain such as lab or across different domains.

My preference so far is to use one generic loosely defined XML schema, the reasons behind this are

1) For SOAP based web service implementation, the XML schema will be used for defining types in WSDL (Web Service Description Language). As a result every schema change implies changes to the SOAP web service WSDL, thus every existing service consumer invoking the web service needs to be changed at the same time when the service implementation is updated, otherwise it will break the existing service consumers which are still based on the older version of WSDL, just imagine how much coordination and cost involved in doing so. Or you can choose to create new service to use the new XML schema to avoid upfront cost, however this will incur a lot of ongoing IT cost to maintain different versions of services in application implementation and IT infrastructure maintenance such as in service authentication and authorization etc.

With tightly defined XML schema, the implementers can still achieve some level of backward compatibility without changing some of the service consumers, the approach is that newly added data elements should also be optional. But then it again defeats the whole purpose of adopting tightly defined XML schema approach.


2) With one generic XML schema in place, we can introduce change to the service consumers one by one as necessary to increase each system's level of sophistication and semantic richness. Of course the service provider internal business logic still need to be carefully managed to ensure it cater for both existing service clients and newer clients (and this cost in fact is also required even for the tightly defined XML schema approach unless you are going to implement two completely different sets of application code).

Of course just keep in mind both HL7v3 Message and CDA document are constrained from HL7 v3 RIM, the slight difference is that CDA R2 currently does not support all the RIM classes, CDA R3 is supposed to support full RIM foundation classes.

I end this post with the slide and corresponding note to further illustrate the above points.

[Thanks Wes Rishel from Gartner to allow me share this slide]



Below is the notes for the above slide

RHIOs seek to interconnect the systems of multiple stakeholders. These systems inevitably will be at differing stages of functional evolution. One measure of their evolution is the degree to which they employ clinical data to directly active decision support and aggregation for research and management vs. the degree to which they use the computer to appropriately select data to put in front of a person who will make the decision, that is passive decision support. One factor in achieving these levels of functionality is the degree to which the systems can create and store highly structured (computer processable) clinical data vs. being able to use limited structures to store and retrieve texts and images. This latter kind of data is called computer manageable.

Historically, the standards that support interoperability have been different for computer processable data than for computer manageable data. This represents a fundamental dilemma for RHIO architects. Should they choose standards for computer processable data and limit membership to those with high-end systems or set their sites on computer manageable data exchange. The latter course seems wisest, but experience has shown that it is extraordinarily difficult to upgrade a network to a categorically different standard. Not all systems will change at the same time.

The HL7 Clinical Document Architecture is a general approach to mixing computer processable and compute manageable data in the same information object. RHINS based on this approach can evolve over time, since upgrading a single stakeholder's system does not require coordinated changes in other stakeholders' systems.

Action item: RHIO architects should seek to employ standards based on the CDA wherever possible to enable evolutionary improvement over time.


### END ###