|
|
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 |
|
First draft for
comment |
|
1.0 |
|
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
2.2. Support for Non Browser Interfaces
2.3. Requirement for well-formed XHTML
2.4. Use of Namespace attribute.
2.5. Permitted tags and attributes
1. Purpose
This document specifies how to use the ED data type to convey textual information within HL7 messages. Many media types can be catered for within an ED data types but only two are considered here.
- Text/plain is a required media type which is always supported.
- Text/html which is used where formatting is a business requirement.
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 :-
- Inclusion
of external hyperlinks that invoke or reference material not within the
message.
- This
is considered necessary to ensure all material relevant is communicated
and to avoid risks from linking to material that is not constrained by
the message specification and may thus include viruses or other rogue
software.
- Inclusion
of complex formatting which may not be supported by a receiving system
- Representation
of structured computer parsable semantics in a document that is intended
only for presentation to a human reader.
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:
- The
document must be well-formed according to XML rules.
- All
opening tags must either be balanced by closing tags or must be marked
empty
- The
following is correct ...
- <body><h1>A
heading</h1><p>A paragraph broken here<br/>and
ended here</p><p>Another paragraph</p></body> - The
following would produce the same results in most HTML browsers but is not
well-formed according to the rules of XHTML and thus generates an XML
parser error ...
- <body><h1>A
heading</h1>A paragraph broken here<br>and
ended here<p>Another paragraph</body> - All
attribute values must be enclosed in quotations
- For
example the following is correct ...
- <table
border="1">
- But
the line below generates a parser error ...
- <table border=1>
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> |
Heading levels. Restriction:
These are not permitted to contain any sub-elements. |
|
|
|
<p> |
Paragraph |
|
paragraph |
|
<ol> |
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.
|
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
& E</value>
More information can be found at http://www.w3schools.com/html/html_entitiesref.asp