NeoTool — Singular Focus, Healthcare Integrated

Posted in CDA

Yesterday I wrote an article about formatted documents and HL7 2.X. The focus of that posting was to suggest that in the real world HL7 does not control the formatting of a document on a receiving system.

René Spronk wrote an interesting reply that I did not want to get lost:

From the blog it isn’t clear whether you’d like HL7 to address the formatting of documents or not. The fact that the FT datatype is rarely implemented seems to suggest that there is no underlying requirement. Otherwise, implementers would use it and request enhancement of those features (maybe even to make them mandatory) as part of the development standard of the v2.x standard.

The CDA standard (HL7 v3) contains markup with a functionality akin to FT. It focuses on medical content, not on font-size. CDA is usually displayed using a style-sheet - albeit one that the receiver chooses, which may be a different one than was used by the document creator.

In case of CDA HL7 leaves it up to the communicating parties to “contractually” agree to use a specific style-sheet. Whether or not such agreements are in place depends on the jurisdiction where CDA is used.

Are there uses cases and jurisdictions where it makes sense to give more control to the sender of how the receiver should view the data? Yes.

One of the enhancement requests for the next release of CDA (CDA R3) is to support a much larger set of XHTML tags for formatting. This is however a balancing act - I wouldn’t want to support all of XHTML (including scripting stuff) in a CDA. The more formatting we introduce in a CDA, the more we’ll be moving away from the actual content, and the more things will be focused on formatting. I’m not sure if we should go there…

As always, René made some great points; thanks for your comments. I think that users of HL7 (either 2.X or 3.0 family) wish for many things — mostly they wish that the standard will make their lives easier. Often they look to HL7 to “force” an application to do something that “seems obvious” to them and their world. In terms of document formats from the perspective of a sending application, they wish that their “pretty report” would be displayed correctly by the receiver.

Once a week I hear someone wish they could force that mainframe or mumps application (which was coded in the early 1980s) to take an HTML or PDF document.

“Why can’t it display bold text? Our paragraphs are not wrapping correctly! The reason people use our service is that we produce these great reports. It is one of our key selling features! We just hate to fax or email them. Can’t HL7 deliver the same thing? Can’t I force that receiving HIS/CDR/EMR at my customer site to take this document via an interface? What does HL7 say about that? Can’t HL7 make the receiver display this correctly? I wish this was easier!”

To answer the questions above, read my posting. In short, HL7 does not force a receiver to format a document in a particular manner.

As noted in René’s comment, HL7’s CDA standard is mostly focused on the content and coding of the information — the display or rendering was, IMO, a secondary aspect. In fact, one of the key points of CDA is that the same document can be rendered on many devices — cell phone, printer, HTML, thick client, thin client, PDF, etc. As noted by René, the receiver’s style-sheet controls the final display.

IMO, the major display advantage of CDA is that it provides a much more structured starting point. In theory, we no longer have to worry about boring stuff like word wrapping or section headers — these display features “come for free” with the style-sheet used by the receiver.

Hopefully as a community we will not lose track of the fact that what CDA is really about is coded documents — the “easier display” is just a bonus.

It is interesting, however, to note that often what real world users of either HL7 2.X or CDA want is a mechanism to get a document “nicely displayed” on the receiving system. Sure, the informatics geeks can talk about the coding/format of the document and how many places we have clever OIDS, but ultimately it seems that much of healthcare is still about paper documents. Kudos to the CDA visionaries who seemed to get this up front — allow for lots of coding but also allow for simple blobs of text split into sections.

Last 5 posts by Dave Shaver

• RHIOs vs. Peer-to-Peer Communications - July 11th, 2008
• Hospitals Allowed to Pay for EMR Interfaces and Not Violate Stark - June 3rd, 2008
• May 2008 HL7 Working Group Meeting - May 5th, 2008
• Formatted Documents: HL7 2.X vs. HL7 CDA vs. Wishes - February 12th, 2008
• Sending Text Documents or Reports via an HL7 Interface - February 11th, 2008