HL7 version 3: Message or CDA Document?

3. Other factors influencing the choice

The above recommendation applies to those situations where one (as a solutions architect or analyst) has absolute freedom in choosing either a messaging or a document approach to support a given use case. There tend to be other factors that influence this choice.

• Familiarity with the current solution: The choice tends to be influenced by that which is customary in a particular country, even if one explicitly provides them with the recommendation as presented in this whitepaper. Ask someone from the Netherlands, a country with a long history in the exchange of electronic messaging, whether a prescription is best supported by means of a message or a document and 9 times out of 10 the response will be that a prescription is a message. The rationalization is that a prescription is a business object that undergoes state changes, it can be updated, it may be cancelled. Ask someone in Germany, and the response will mostly be that a prescription is a document. The rationalization is that the current German prescription is a well-structured paper form which can be easily emulated in the form of an electronic document. If one looks really hard at the underlying use cases it turns out that prescriptions fulfil a slightly different role in each country, resulting in a better match with either messages (the Netherlands) or documents (Germany).
• Sophistication of the IT infrastructure: Another factor is the level of advancement of the IT infrastructure involved in the workflow. Messages require a higher level of sophistication of the IT infrastructure when it comes to processing and storing them. If one only uses messages to support a workflow, all parties concerned must have the capability to process and generate the data structures as provided by the messages. The v3 CDA documents can be used in an environment where the only thing a healthcare provider has access to is a web browser: it can be used to render the contents of the documents. Even though one can opt not to process certain parts of a message, v3 CDA documents offers a lowest-common denominator (human readability) for use in less IT sophisticated environments. Those parties involved in the workflow that do use software that is sophisticated enough to process the software-processable parts of the document will be able to use that data, whilst other may choose only to render the document.
  CDA provides several �levels� of conformance, beginning with support for a simple header structure and standardized markup (CDA level 1), migrating to the formal encoding of a subset of the data (CDA level 2), through to full encoding of the complete set of data (CDA level 3 � still in development). This series of levels provides a migration path for applications not yet ready for full discrete data capture. Messages on the other hand are designed for a particular use-case with an expected level of discrete data capture. The level of discreteness may vary by message, but there is no concept of a migration path.
• Impact on workflow: Much of the work in non-electronicized healthcare is document-focused. Migrating from paper documents to electronic documents and leveraging such paradigms as libraries and file systems as enabled by standards such as [IHE XDS] means that existing data management systems can be maintained. Migration to messaging allows the introduction of new paradigms such as real-time decision support, application of configurable real-time access controls and sophisticated electronic workflow management. While the introduction of these capabilities promises considerably greater benefit to the healthcare system, introducing the workflow changes needed is more difficult, particularly in environments where there is resistance to or lack of familiarity with computers in the healthcare environment.
• The presence of legacy systems: CDA occupies a solution space not covered by any existing standard and as such is an attractive add-on to existing solutions. The cost of legacy HL7 2.x displacement with HL7 v3 messaging infrastructure may be a factor in deciding to use v3 CDA Documents and to transport them using a HL7 Version 2.x Message. This cost of displacement, makes CDA an attractive alternative given tight budgets and a need to show ROI for projects. Even when not a cost issue, the perception of CDA as �different� rather than a duplication or replacement can make CDA more attractive than messaging.
• Learning curve: CDA is easier to come to grasp with than v3 messaging. All CDA documents are based on one single RIM-based model, v3 messaging is based on a multitude of RIM-based models.
• Flexibility vs. Richness of software processable models: CDA is attractive to some implementers because it allows significant flexibility in what data can be sent while still remaining �compliant�. Messaging, on the other hand tends to apply more rigorous constraints specific to narrower use-cases. The flip side of this is that the chances of semantic interoperability beyond the �human-readable level� between two independent systems is significantly higher for messages than for documents. Because CDA is based on a constrained portion of the RIM, there are some concepts it is not able to express or that it is not able to express in the same way as message models which may take full advantage of all parts of the RIM. For example, maintenance of location, patient and provider registries, as well as management of financial information is not supported by the CDA model. In current CDA projects this is rarely an issue because documents tend to contain summary information (requiring less detail).
• Requirement for sender asserted presentation of the content: Documents like CDA convey a sender asserted or predetermined presentation or look for the authenticated content in the document. The CDA's human readable markup supports this and enables what the Legal Authenticator viewed, when they signed a document, to be conveyed with the document. This may be of importance in some jurisdictions.

If one has opted for an infrastructure which allows either exclusively for the use of documents, or of messages, then this may lead to the consequence that one has to model absolutely everything as being a document or a message � even when by its very nature the particular use-case could more suitably be covered by the other paradigm. If all you have is a hammer, everything looks like a nail. For example: this issue occurs in projects that use [IHE XDS] (an architecture that is exclusively based on documents): all data has to be exchanged in the form of a document, regardless of its nature. Laboratory orders, and the status management thereof, were modelled as documents. Each update of the order results in a new document.

4. Factors that should have no impact on the choice

The use of digital signatures should have no impact on the choice. Digital signatures can be used to either sign (parts of) a message, or to sign a document. Documents are persistent by nature; messages can be persisted in audit logs and the data within messages is typically stored in the receiver�s database. The persistent nature of documents may be a factor influencing the choice, however the use of digital signatures should not. In the context of messaging the messages are most likely signed by the sending software application, however the explicit act by a human being of (legally) signing a collection of data is supported both by messaging as well as documents.

The requirement to convey textual (human readable) descriptions should have no impact on the choice. In documents, all information has to be sent in the form of human readable text. In messages, all information can be sent in the form of human readable text (by populating the Act.text attribute in Act-based classes). In itself a requirement to sent human readable text should have no impact on the choice.

5. Examples

Example use cases with a recommendation as to whether a message or document based approach may be more applicable are described below.

• If one wants a rough list of patient drugs as part of a referral, documents will work (referral from B to C). If one wants a prescription that will be manipulated as a patient gets it dispensed, is admitted and then discharged from hospital, messages are the best solution (messages exchanged between A and B).
• If one wants to have a list of patient medications "as known at admission", a document may work (B to C). If one wants to know "what medications are they on right now, not 5 hours ago", messages are the best solution (A to B). The order / promise negotiation phase of a business process is generally best supported using messages (messages exchanged between A and B).
• If one intends to send clinical summary documents or referral letters documents are mostly the best option. A physician makes a selection out of all of the data available and generated during the process (which was supported by messages) and sends that subset to another healthcare provider (B to C). The use of documents is often associated with a transfer of responsibility. The creation of a general clinical summary (as is done in some countries) which is stored on a centralized server for long term use is also a kind of transfer of responsibility; in this case a transfer to an as-yet unknown colleague who may be treating the patient in another part of the country or on an emergency ward.
• If one wishes to generate a real-time summary based on information stored across a variety of systems in an environment where the data may be maintained by multiple providers and change over time, messaging is a more natural approach. (messages exchanged between A and B and other applications).
• If one queries for a patient summary, a responding system could respond with a (Patient care) message, or with an CDA document (potentially created on the fly upon receipt of the query). The latter is done (although in the form of a PDF) in a region in Sweden. Whether or not documents are the most suitable approach probably depends on what the party that receives the response intends to do with the information. If it is just a snapshot of information which is consulted by a human reader then a document is the best solution. If the information is within workflow processes that are started upon the receipt of the response then a message will be the best solution.

6. Recommendations

Allow for both paradigms to coexist � use a use case driven approach to determine what paradigm forms the better solution for the use case.

Be aware that there is no clean white line that neatly divides the world between documents and messages. It all depends on what one is trying to achieve. Any time you're trying to drive workflow you either want messages or you'll need documents transmitted via messages with an additional non-standardized workflow layer built on top. Note the importance of conveying the document metadata next to the persistent document itself. The metadata (e.g. document status, links between the document and other documents, digital signatures) changes and is managed by the exchange of messages; the document itself doesn't change. If one chooses to support a use-case with documents, one has to deal with document metadata, be it (for example) in the form of [IHE XDS] or ebXML metadata or the metadata in HL7 v2/v3 medical records messages.

7. Acknowledgements

We'd like to thank Dan Russler, Calvin Beebe, Diego Kaminker, Kathleen Connor, Lloyd Mckenzie and Keith Boone for their feedback on this document.

8. References

[IHE XDS], see the ITI Technical Framework available at http://www.ihe.net
[HL7Wiki] HL7 Wiki,http://wiki.hl7.org (antispam: username= wiki , password= wikiwiki)

---

About Ringholm bv

Ringholm bv is a group of European experts in the field of messaging standards and systems integration in healthcare IT. We provide the industry's most advanced training courses and consulting on healthcare information exchange standards.