Message Constraints for the ED datatype

 

Programme

NPFIT

DOCUMENT RECORD ID KEY

Sub-Prog /

Project

Comms & Messaging

NPfIT-FNT-TO-DPM-0314.01

Prog. Director

Tim Jones

Owner

Margaret Baldock

Version

1.0

Author

Core Technical Team

Version Date

7/1/2005

Status

Issued

 

 

  

Message Constraints for the ED datatype

 


Amendment History:

Version

Date

Amendment History

0.1

23/12/2004

First draft for comment

1.0

7/1/2005

Issued Version

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Forecast Changes:

Anticipated Change

When

 

 

 

 

 

 


Document Status:

This is a controlled document.

This document version is only valid at the time it is retrieved from controlled filestore, after which a new approved version will replace it.

On receipt of a new issue, please destroy all previous issues (unless a specified earlier issue is baselined for use throughout the programme).

 


Contents

1.†††† Purpose. 5

2.†††† Specification. 5

2.1.†††††† Mapping to HL7 CDA. 5

2.2.†††††† Support for Non Browser Interfaces. 5

2.3.†††††† Requirement for well-formed XHTML. 5

2.4.†††††† Use of Namespace attribute. 6

2.5.†††††† Permitted tags and attributes. 6

2.6.†††††† Common Attributes. 7

2.7.†††††† Schema. 7

3.†††† Reserved Characters. 7

 


1.                Purpose

This document specifies how to use the ED data type to convey textual information within HL7 messages. This document does not apply to the use of ED data type for use with Presentation Text. This is documented here

Many media types can be catered for within an ED data types but only two are considered here. 

Text/html in an unconstrained form would cause problems so below is a table containing a restricted set of XHTML tags that may be used where simple formatting is a business requirement.

Theses restrictions are specifically designed to prevent :-

2.                Specification

2.1.           Mapping to HL7 CDA

There is a mapping provided in the table below which indicates how this constrained xHTML maps to the HL7 CDA body structures. The structures defined here are more constrained than CDA, but will map to a true subset of that document definition.

2.2.           Support for Non Browser Interfaces

It is assumed that some applications will want to display the received text within an existing user interface, rather than directly in a browser.  Were the narrative text always going to be viewed with a browser (or browser component), then we need only constrain to the point of a reasonable baseline browser conformance.  However if this data may be displayed within non-browser user interfaces, then style and layout markup should be kept to a minimum.  

This specification defines a minimum set of markup that all receivers must be able to process, and allows further markup that the receiver can ignore if they wish to display the data within an existing user interface template.  

2.3.           Requirement for well-formed XHTML

If formatted text is a requirement then XHTML rather than HTML shall always be used. 

The main implications of this are:

2.4.           Use of Namespace attribute.

Within the <html> tag you should declare a namespace using the xmlns attribute as follows:

    <html xmlns="http://www.w3.org/1999/xhtml" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"     xsi:schemaLocation="http://www.w3.org/1999/xhtml     ..\dt\xhtmlNPfIT.xsd">

2.5.           Permitted tags and attributes

 

Tag

Description

Permitted attributes

Mapping to HL7 CDA

<html>

Top level element containing an instance of <head> and an instance of <body>.

 xlmns, xsi:schemaLocation

 

<head>

One instance only in the <html> element.

Restriction: This may only contain two sub-elements <title> and <style>.

 

 

<style>

One instance only in the <head> element.  This element may be ignored by receiving systems that do not use a browser component to display the narrative text.  It is the senderís responsibility to ensure that this does not alter the semantic meaning.  

 

 

<title>

One instance only in <head> element.

This provides a document title.

 

caption

<body>

One instance only in the <html> element following the <head> and containing the remainder of the document.

 

 

<h1>
<h2>
<h3>
<h4>
<h5>
<h6>

Heading levels.

Restriction: These are not permitted to contain any sub-elements.

 

 

<p>

Paragraph

 

paragraph

<ol>
<ul>

Outline list numbered and unnumbered.

 

list

<li>

List item

 

item

<table>

Table

width, cellpadding, cellspacing, border

table

<thead>

Table header

valign

thead

<tfoot>

Table footer

valign

tfoot

<tr>

Table row

valign

tr

<td>

Table cell

rowspan, colspan, nowrap, width, height

td

<pre>

Preformatted text -- this has been included to represent fixed width fonts where layout is controlled by whitespace, as for the pathology result messages.

Restriction: The sending system should convert any tabs to spaces when sending a message to avoid misaligned text.

 

 

<a>

Internal links

Restriction: The href URL for an internal link must start with #, indicating that it is a pointer into the current document. 

name, href="#...."

link_html

 

2.6.           Common Attributes

Class and style are permitted attributes but maybe ignored by receiving applications.  It is the senderís responsibility to ensure information is represented safely and appropriately whether or not these additional attributes are processed.  

2.7.           Schema

Click here to see a schema that will validate restricted Xhtml fragments used within messages.

 

3.                Reserved Characters

Certain ASCII characters should not be used within XML/XHTML or even plain text fragments as they have a special meaning.  Whereas this applies to all data types problems are most likely to arise within Encapsulated Data or Strings.  Therefore the following characters must only be used via the appropriate entity name.

 

Character

Description

Entity Name

"

quotation mark

&quot;

'

apostrophe 

&apos;

&

ampersand

&amp;

<

less-than

&lt;

>

greater-than

&gt;

 

 

 

 

e.g. The following will cause syntactical errors in a message due to the presence of a ampersand character:

<value>Patient was sent to A & E</value>

 

It should be expressed as:

<value>Patient was sent to A &amp; E</value>

More information can be found at http://www.w3.org/TR/xhtml1