Software vendors in the healthcare space likely have interfaces in their systems that are capable of receiving HL7 2.x messages and processing that data through an application. In Part 1 of this series, I explained how a section in the xml allows developers to write applications to make use of the coded elements. (A patient’s immunization history, for example.) As a result of these applications, the following is an example of an application that may construct the text portion of an immunization section.
For example, an application may construct the text portion of an immunization section as shown in the example below:
The text element is meant to be displayed, not processed. Software applications are currently unable to reliably parse out the discrete pieces of data which may be present in this format.
An alternative option as an application is to extract the entire text element, and display this data in a browser as HTML:
Of course you always have the option to display the entire document using a style sheet as mentioned above.
If your application is going to support Level 3 CDA documents, it will need to understand entries. Entries are meant to be processed by a machine and not intended to be displayed to users. Entries have a standardized structure based on the Reference Information Model (RIM) and an HL7 pattern called a Clinical Statement.
Latest posts by Mike Stockemer (see all)
- Supporting CDA in Clinical Applications, Part 2: XML and HTML Rendering - March 8, 2011
- Supporting CDA in Clinical Applications, Part 1: Introduction - March 1, 2011
- Comparing HL7 Messages to HL7 Documents - January 25, 2008