Should you require any more information or have encountered a problem, please call the support helpdesk on (07) 5456 6000.

Overview

A standards based Mechanism for using HTML as display segments in HL7V2 messages

The use of HL7V2 for transmitting clinical data occurs on a massive scale worldwide. This has been the case for many years and it works well as a basic level, but the richness and control of the display of this data has not kept pace with what users expect. This can create resistance to the adoption of HL7V2 by new players and is a barrier to more widespread adoption. Over that last 15 years the availability of high quality components for the display of html encoded documents is become ubiquitous and quite standards compliant and represents a good choice for a display format for clinical documents where a higher fidelity display is desired. This document represents a constraint on the html features that can be used for this purpose and specification of conventions to access embedded binary data such as clinical images.

The current Australia Diagnostics standard (AS4700.2) specifies html as a possible display segment for use by senders to transmit a display version of the data in the ORU message. The html display segment should be the last OBX segment and is identified by a OBX-3 Observation Identifier of "HTML^Display Segment as Html^AUSPDI". It is possible to send a single OBX segment of this type however it is recommended that the same data is also sent in an atomic format. Currently no guidance is given as to what features the html can use and this technical report aims to provide this guidance. The message types such as the Referral Message detailed in AS4700.6 defer to the Diagnostics standard for guidance in this area and the guidance specified in this document is also relevant to these messages on this basis.

The advantages of using html as a display segment include:

  1. The ability to use proportional fonts and have control of font sizes and weights/colours to enable appropriate emphasis to be given to critical abnormalities in the report. Currently only highlight is supported in HL7 Free Text (FT).
  2. Reliable representation of tabular data which otherwise requires the use of spaces with a non proportional font. The character width is usually assumed to be around 78 characters, but this is not specified or reliably supported and word wrapping of tabular formatted data impacts severely on its readability.
  3. The ability to represent a container ship hierarchy for highly nested data with appropriate headings
  4. The ability to embed images into the report where the image data is in the HL7 messages
  5. The ability to include hyperlinks to internal and external information
  6. A means of identifying header and footer data such as letterhead information and allowing this to be optionally displayed.
  7. Existing standard that is widely supported across operating systems.
  8. Good tolerance for displays of variable size and resolution with mechanisms for users to alter display size.
  9. The availability of screen readers for disabled users.
  10. Freely available validation services
  11. Wide availability of tools for authoring content and formatting of display.
  12. Text based format that remains searchable and human readable and is small in size.

The disadvantages of html include:

  1. Limited support in current applications despite being a specified display format for many years.
  2. The potential for exploits on the common viewers to be exploited to compromise security.
  3. The potential for external links to become obsolete.


Constraints on html Profile for display segments

In order to reduce the potential for exploits and reduce the overhead, reliability and longevity of the display segments the following constraints must be followed.

1. No Javascript

The html display must not use any javascript whatsoever in the document either as directly embedded javascript or script tags in the header. It is suggested that javascript processing be turned off in the display.

2. Embedded CSS only

It is recommended that CSS be used for styling the document but that CSS must be directly included in the header of the document and not linked to an external URL. This is important for both longevity and the ability of the document to be styled off line. CSS level 2 [[1]] should be used at this time. Any selectors should work on all the major browsers. (Currently Internet Explorer 6+, Firefox, Chrome and Webkit)

3. HTML 4

While support for html 5 is appearing its support is far from universal and content should be compliant with the W3c XHTML 1.0 specification [[2]] XHTML is preferred as it can be parsed with an xml parser.

To improve security and reduce the requirement for end users to have browser extensions installed the only embedded content allowed are images. No applet or object tags are allowed. Multimedia presentations can be included as HL7 ED type OBX segments and the media type used to optionally display content in external viewers. The html display segments must be viewable without browser extensions or plugins installed. No <form> or <iframe> tags are allowed.

4. HTML structure

Many display segments include letterhead information and while this is permitted it should be encapsulated in a html
and be located outside the scope of the core report data. The core display of the report should be encapsulated in a
of html class "reportDisplay"
It should be possible for a user to selectively hide everything apart from the div with class of reportDisplay without loosing any clinical information. In that fashion it will be possible for users to toggle the display of the letterhead components of the display segment.

External links to images are permitted in the non "reportDisplay" divs to permit the display of logos but the user or system may refuse to download these images and the display formatting should not be dependant on the image downloading. The core report html should display in a readable way with the CSS removed and information in the core report data should not be hidden by CSS formatting directives.

An example skeltal structure of the html body is below:

<body>
<div>
<div class="sendingAuthorityHeader">Letterhead here</div>
<div class="reportDisplay">Clinical content here</div>
<div class="sendingAuthorityFooter>Letterhead footer here</div>
</div>
</body>


5. Internal linking to images

The use of a html display segment allows rich formatting of both text and images, but the images are not embedded in the html and need to be linked back to the binary image data in the message. The images can be in either ED or RP OBX value type segments. The convention for the url format is "hl7v2://OBX.<setID>" eg if the OBX with a SetID of 4 contains an image the url would be "hl7v2://OBX.4". This will need to be handled on the display control or the URL converted to a file based URL and the OBX data extracted to a file. Images, other than in the letterhead divs, should not be linked to external URLs. It is permissible to provide links to external images in the report body but this should be done with a click-able link that the user has to manually select. These external links may well become invalid with time and their external links should be an adjunct to the report and not the entire report contents.

6. Use ASCII Character Set

To ensure interoperability the html text should use the HL7V2 subset of the ASCII character set. Unicode characters should be escaped using the standard html escape characters and the resulting html file then placed in the OBX segment. If a free text (FT) OBX value type is used then any reserved HL7 delimiters will need to be escaped using HL7 escape conventions and this will include cursor return/Line feed sequences. If a Encapsulated data (ED) OBX value type is used then the html file should be Base 64 encoded and placed in the appropriate ED field. After extraction from the Base 64 encoding a ASCII encoded html file should be the result.

  • No labels