Sending Text Documents or Reports via an HL7 Interface
February 11th, 2008 by Dave Shaver
(2 votes, average: 4.5 out of 5)
Loading ...Posted in HL7 Messaging
HL7 does not provide a real world standard for controlling the display of text documents on the receiving system. While there are some rarely-implemented formatting codes provided in the Formatted Text (FT) section of HL7, often senders must deliver “plain, vanilla text” in order for a receiver to accept a text document via HL7 messaging. The receiver will then display the lines of text in whatever manner is appropriate for that application.
Typically this question comes up when someone is trying to ensure that text documents they send (such as a radiology report) will be displayed a specific way on a remote application. Asked another way, the sending HL7 user want to know if the receiving (remote) application will display the report in a given size font or a fixed-width font. The question revolves around the desire to put “low tech text formatting” in place to build things like tables, indented paragraphs, or even nicely word-wrapped paragraphs.
The reality is that HL7 messaging does not imply or demand that an application display a text report in any specific manner. If there is a need to ensure that the receiving application displays data in a specific way, the interface analyst must review the display mechanisms in the receiving application to see what is possible. The analyst must then change the message (text) format to work within those provided by the receiver’s display mechanisms. Typically the sender can not force the receiver to take a “pretty text document.”
The problems most frequently encountered when moving text reports are related to the size of the text, how long the lines can be, indenting text, the desire to make headers “stand out”, and how word wrapping is accomplished. All of these items are under the control the receiving application. In the real world, HL7 has no opinion on these issues.
Often applications support moving rich text documents via either an ED or RP data type. This means that the sender can deliver a PDF, Word document, RTF document, HTML document, etc — but only if the receiver supports the format. More details on rich documents are provided in this blog posting.
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
Dave,
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 fontsize. CDA is usually displayed using a stylesheet - 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 stylesheet. 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 would’n 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…
-René
[…] 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 […]
Hope you don’t mind a newbie question - I am just starting to learn about this area and came across your posts, which have been very helpful. I have an example of how to embed binary info in an HL7 2.3 ADT message. If using the CDA instead, is the use of the ED datatype still possible? The reference seems to indicate that the ED data type is a 2.x feature - is it still available using the CDA. Thanks in advance for any light you can shed on this.