Introduction to HL7 v2+ and Add-Ons
47 sectionsContents
92Encoding
99.0HL7 v2+ - HL7 v2 refactored - Working Draft!
99.0Welcome to HL7 v2+®
99.0Complimentary Explanation on how this documentation is structured
99.1Domains
99.1.1ADT - Admission, Discharge, Transfer
99.1.2Financial Management
99.1.3Order Entry: General, Laboratory, Dietary, Supply, Blood Transfusion
99.1.4Order Entry: Pharmacy/Treatment, Vaccination
99.1.5Query
99.1.6Observation Reporting
99.1.7Master Files
99.1.8Medical Records/Information Management (Document Management)
99.1.9Scheduling
99.1.10Patient Referral
99.1.11Patient Care
99.1.12Clinical Laboratory Automation
99.1.13Application Management
99.1.14Personnel Management
99.1.15Claims and Reimbursement
99.1.16Materials Management
99.2Message Structures
99.2.1List of Message Structures
99.2.2Explanation
99.2.2Mapping and Compatibility with former v2.x standard
99.3Segments
99.3.1List of Segments
99.3.2Explanation
99.4Tables
99.5Test
99.6Transport
99.7Profile
99.10HL7 v2.x - former versions…
99.11New (v2+) Field Attributes
99.11.1Implement
99.11.2Flags
99.11.3Cardinality
99.11.4(Minimum and Maximum) Length
99.11.5Conformance Length
99.11.6Data Type
99.11.7Vocabulary
92
Encoding
TBD (92.00001): Short Introduction to Encoding
99.0
Complimentary Explanation on how this documentation is structured
This is the working draft for what is preliminary called <b>HL7v2+</b>.
It is subject to change without any notice.
Furthermore, it should be kept confidential. No distribution allowed.
Welcome to HL7 v2+®
HL7 v2+ is a standard for health care data exchange, built as a successor of HL7 v2.x, and published by HL7®.
<p style="padding: 5px; border-radius: 5px; border: 2px solid maroon; background: #ffffe6; max-width: 790px">
<b>First time here?</b><br/>See the full <a href="toc.html">Table of Contents</a>.
</p>
<div id="diagram">
<p class="level-text"><b>Introduction</b> to this standard (<a href="chapter.1.html">chapter 1</a>).</p>
<p class="content"><a href="ToC.html">Table of Contents</a>
</p>
<p class="level-text"><b>Basic framework on which the specification is built.</b></p>
control
<a style="background-image: url('foundation.png');" href="foundation-module.html">
<span>Foundation</span>
</a>
<p class="content"><span><a href="ctrl.html">Control</a> (Messaging)</span> </p>
encoding
<a style="background-image: url('workflow.png');" href="encoding.html">
<span>Encoding Notation</span>
</a>
<a href="downloads.html">Abstract Message Syntax (AMS)</a>
transport
<a style="background-image: url('linked-data.png');" href="transport.html">
<span>Transport</span>
</a>
<a href="transport01hllp.html">HLLP</a>,
<a href="transport01mllp.html">MLLP</a>,
<a href="transport02http.html">HTTP</a>
<p class="level-text"><b>Technical</b></p>
terminology
<a style="background-image: url('terminology.png');" href="tab.html">
<span>Terminology (Tables)</span>
</a>
<a href="tab.html">CodeSystem</a>,
<a href="tab.html">ValueSet</a>
<a style="background-image: url('index.png');" href="linked-data-module.html">
<span>Building Blocks</span>
</a>
<a href="dt.html">Data Types</a> ->
<a href="seg.html">Segments</a> ->
<a href="msg.html">Message Structures</a>
<p class="level-text"><b>Domains</b></p>
technical
<a style="background-image: url('secpriv.jpg');" href="dom.html">
<span>Technical</span>
</a>
<a href="dom07.html">Master Files</a>,<br/>
<a href="dom05.html">Queries</a>, <br/>
<a href="dom13.html">Appl Mngmt</a>
administrative
<a style="background-image: url('administration.jpg');" href="dom.html">
<span>Administrative</span>
</a>
<a href="dom01.html">ADT</a>,<br/>
<a href="dom10.html">Referral</a>,<br/>
<a href="dom09.html">Scheduling</a>,<br/>
<a href="dom14.html">Personnel Mngmt</a>, <br/>
<a href="dom16.html">Materials Mngmt</a>
financial
<a style="background-image: url('financial.png');" href="dom.html">
<span>Financial</span>
</a>
<a href="dom02.html">Billing</a>, <br/>
<a href="dom15.html">Claims & Reimbursement</a>
clinical
<a style="background-image: url('clinical.png');" href="dom.html">
<span>Clinical</span>
</a>
<a href="dom03.html">General Orders</a>, <br/>
<a href="dom03.html">Laboratory Orders</a>, <br/>
<a href="dom03.html">Dietary Orders</a>, <br/>
<a href="dom03.html">Supply</a>, <br/>
<a href="dom04.html">Pharmacy/Treatment</a>, <br/>
<a href="dom12.html">Lab Automation</a>
medication
<a style="background-image: url('medication.png');" href="dom.html">
<span>Medical</span>
</a>
<a href="dom11.html">Patient Care</a>, <br/>
<a href="dom08.html">Medical Record</a>
<p class="level-text"><b>Implementation</b></p>
conformance
conformance
<a style="background-image: url('conformance.jpg');" href="profile.html">
<span>Conformance</span>
</a>
<a href="profile.html">Profiling</a>
encoding
<a style="background-image: url('conformance.jpg');" href="profile.html">
<span>Encoding</span>
</a>
<a href="encoding01er7.html">Encoding Rules 7 (ER7)</a> ('vertical bar'),
<a href="encoding02xml.html">XML-Encoding (v2.x)ml</a>
datatypes
<a style="background-image: url('index.png');" href="ig.html">
<span>Data Type Flavors</span>
</a>
<p class="content">Data Type Library</p>
<a style="background-image: url('index.png');" href="ig.html">
<span>Implementation Guide Registry</span>
</a>
<p class="content">IHE Profiles, eg. Patient Administration Management, Patient Demographic Query, etc.</p>
</div >
Complimentary Explanation on how this documentation is structured
Control;Encoding;Transport;Profile;Domains;Message Structures;Segments;Vocabulary;Data Types
<p><b>Control</b></p>
<p>Basics for HL7 v2.x</p>
<p><b>Encoding</b></p>
<p>Encoding manages the transformation from the logical models to serialized data.</p>
<ul>
<li>AMS: Abstract Message Specification</li>
<li>ER7: Encoding Rules 7 = vertical bar syntax</li>
<li>v2.xml: Encoding using XML</li>
<li><font color="red">JSON: we need to think about that</font></li>
</ul>
<p><b>Transport</b></p>
<p>There are different means of transport:</p>
<ul>
<li>Files</li>
<li>MLLP</li>
<li>HTTP</li>
</ul>
<p>TBD (00025)</p>
<p><b>Profile</b></p>
<p>Text Profiles</p>
<p>Chapter 2B should go there!</p>
<p>TBD (00035)</p>
<p><b>Domain</b></p>
<p>The content (events message structures, etc.) will be organized into domains to get rid of the chapter view.</p>
<p>The tricky thing is when generating the contents peresumably in a single step, which ssections should be left out and replaced by appropriate links? How to mark then? Also, for the skipped content we need a link back to where it is used. Here, if we see the message structures, we need a list of links telling us where this specific message structure is used.</p>
<p>TBD (00045)</p>
<p><b>Message Structure</b></p>
<p>Currently there is a list of the message structures with links to the details. Do we need context information within those pages? Or do we need to group them together, eg. By message type?</p>
<p>TBD (00053)!</p>
<p><b>Segment</b></p>
<p> This is a list of segments</p>
<p>TBD (00061)</p>
<p><b>Vocabulary</b></p>
<p>Vocabulary will take care of the updated vocabulary model allowing for harmonizing with other product lines. We need to clarify</p>
<ul>
<li>Links/Names in segments and data types: what is that?</li>
<li>How to represent: Vocabulary domains, value sets and code systems? We have enhanced/updated/corrected the representation and management of tables. We should not violate the work done!</li>
</ul>
<p>TBD (00069)</p>
<p><b>Data Types</b></p>
<p>List of all Data Types</p>
<p>TBD (00077)</p>
Please be aware, that this is an intermediate version. We need to add an explanation here telling readers what has been changed and why.
The following changes were applied to improve the way the standard is written:
Message Structures: tree structure, and Must Support and cardinality
Segments: Must-Support and Cardinality instead of optionality and repetitions
Domains: restructured into contents instead of chapters
Encoding: incorporated into the standard instead of different documents
Transport
<!-- JS and analytics only. -->
<!-- Bootstrap core JavaScript
================================================== -->
<!-- Placed at the end of the document so the pages load faster -->
<script src="assets/jquery.js"> </script> <!-- note keep space here, otherwise it will be transformed to empty tag -> fails -->
<script src="bootstrap.min.js"> </script>
<script src="respond.min.js"> </script>
<script src="fhir.js"> </script>
<!-- Analytics Below
================================================== -->
<script src="jquery/jquery.js"> </script>
<script src="jquery/jquery-ui.min.js"> </script>
<script>
try {
var currentTabIndex = sessionStorage.getItem('fhir-resource-tab-index');
} catch(exception){
}
if (!currentTabIndex)
currentTabIndex = '0';
$( '#tabs-Extension' ).tabs({
active: currentTabIndex,
activate: function( event, ui ) { store(ui.newTab.index()); }
});
function store(currentTab) {
document.activeElement.blur();
try {
sessionStorage.setItem('fhir-resource-tab-index', currentTab);
} catch(exception){
}
$( '#tabs-Extension' ).tabs('option', 'active', currentTab);
}
</script>
99.1
Domains
99.1.1
ADT - Admission, Discharge, Transfer
99.1.2
Financial Management
99.1.3
Order Entry: General, Laboratory, Dietary, Supply, Blood Transfusion
99.1.4
Order Entry: Pharmacy/Treatment, Vaccination
99.1.5
Query
99.1.6
Observation Reporting
99.1.7
Master Files
99.1.8
Medical Records/Information Management (Document Management)
99.1.9
Scheduling
99.1.10
Patient Referral
99.1.11
Patient Care
99.1.12
Clinical Laboratory Automation
99.1.13
Application Management
99.1.14
Personnel Management
99.1.15
Claims and Reimbursement
99.1.16
Materials Management
99.2
Message Structures
99.2.1
List of Message Structures
99.2.2
Mapping and Compatibility with former v2.x standard
TBD (01510): Needs Verification. Up to then the information from segments is taken.
The Logical View shows the resources as a tree structure with the following columns:
Column
Content
<b>Segment</b>
The code for a segment or the name of a segment group.
<b>Cardinality</b>
The minimum and maximum Cardinality for repeating this segment or group, if constrained to less than [0..*].
<b>MustImplement</b>
The application must implement (support) an element marked as "yes".
<b>Status</b>
Additional Information about the current status of this element. <br/> The most frequent indication is "deprecated", i.e. the element is contained only for backward compatibility with the intent not to use it anymore.
<b>Comment</b>
Additional comments that the steward groups feels worth to mention.
Here is an example:
TBD (01563): Example for message structure
<a name="msgstruct"/>
<table style="font-size: 12px; font-family: verdana; vertical-align: top" cellpadding="0" cellspacing="0" align=center border=0px>
<tr style="border: 1px #F0F0F0 solid; font-size: 11px; font-family: verdana; vertical-align: top;">
<th style="vertical-align: top; text-align : left; background-color: white; padding:0px 4px 0px 4px" class="hierarchy"><A>Segment</A></th>
<th style="vertical-align: top; text-align : left; background-color: white; padding:0px 4px 0px 4px" class="hierarchy"><A>Cardinality</A></th>
<th style="vertical-align: top; text-align : left; background-color: white; padding:0px 4px 0px 4px" class="hierarchy"><A>Must Support</A></th>
<th style="vertical-align: top; text-align : left; background-color: white; padding:0px 4px 0px 4px" class="hierarchy"><A>Status</A></th>
</tr>
<tr class='even'>
<td class="hierarchy"><img src="icon_element.gif"/> <b>ADT^A03^ADT_A03</b></td><td></td><td></td><td></td>
</tr>
<tr class='odd'>
<td class="hierarchy"><img src="tbl_vjoin.png"/><img src="icon_reference.png"/> <a href="segMSH.html">MSH</a></td>
<td class="hierarchy">1..1</td>
<td class="hierarchy">Yes</td>
<td class="hierarchy"></td>
</tr>
<tr class='even'>
<td class="hierarchy"><img src="tbl_vjoin.png"/><img src="icon_element.gif"/> <b>PROCEDURE</b></td>
<td class="hierarchy"></td>
<td class="hierarchy"> </td>
<td class="hierarchy"></td>
</tr>
<tr class='odd'>
<td class="hierarchy"><img src="tbl_vline.png"/><img src="tbl_vjoin_end.png"/><img src="icon_reference.png"/> <a href="segPR1.html">PR1</a></td>
<td class="hierarchy">1..1</td>
<td class="hierarchy">Yes</td>
<td class="hierarchy"></td>
</tr>
<tr class='even'>
<td class="hierarchy"><img src="tbl_vjoin_end.png"/><img src="icon_reference.png"/> <a href="segPDA.html">PDA</a></td>
<td class="hierarchy">0..1</td>
<td class="hierarchy"> </td>
<td class="hierarchy"></td>
</tr>
</table>
<a name="explanation"></a>
<p> </p>
Key to Type Icons and Flags
<img src="icon_element.gif"/> A segment that is part of the message
<img src="icon_choice.gif"/> A choice between different lists of segments
<img src="icon_reference.png"/> A link to a segment
TBD (01675): further entries
Mapping and Compatibility with former v2.x standard
The following table helps to understand, how previous version of HL7 v2.x is converted into v2+.
<p> </p>
Optionality/usage resp. the corresponding AMS constructs are replaced by a "must-support" flag, that allows for the following values: "yes", "no" and "empty". "empty" is the default and can be constrained to either "yes" or "no", but once constrained cannot be changed any more in derived profiles /specialisations.
Some terms like "R" and "RE" are still under discussion. Therefore the following changes are intended:
</ul>
Repetitions resp. the corresponding AMS constructs are replaced by cardinality. Here the following constraints are intended: "min..max", where min starts with "0" and max="*". min is increased, max is decreased until they are equal.
<li>optionality / usage</li>
<ul>
The most important topic is to align the technical terminology that is used to write and publish the specification, namely:
<li>repetitions / cardinality</li>
99.2.2.1
for Fields
Optionality
Repetition
=>
Must Implement
Cardinality
Comment
R
yes
min = 1
RE
yes
min = 0
O
fully open
X
no
min = 0, max = 0
B
represented as a comment
W
represented as a comment
C(a/b)
that depends on the evaluation of "a" and "b", but can be translated into must-support and cardinality
n
max = n
*
max = *
Combinations are combined accordingly.
99.2.2.2
for Message Structures
AMS
=>
must Implement
Cardinality
[ { } ]
0 .. *
[ ]
0 .. 1
{ }
1 .. *
< empty >
yes
1 .. 1
marked as withdrawn
no
0 .. 0
Opening parenthesis are used to introduce groups of segments.
99.2.2.3
Must-Implement
An important point is the definition of must-support. Even if the intend is to come as close as possible to use the same technical terminology like with FHIR, some definitions cannot be provided as free as with FHIR. FHIR does not provide any base requirements. This is left for profiles that also individually declares what "must-support" mean. For v2+ the definition for must-support is equal to the previous definition of "RE".
99.3
Segments
99.3.1
List of Segments
99.3.2
Explanation
TBD (02510): Work on Explanation for Segment Attribute tables.
99.4
Tables
99.5
Test
<div id="segment-content" class="segment"> <!-- segment-content -->
<div class="container"> <!-- container -->
<div class="row">
<div class="inner-wrapper">
<div class="col-9">
</div> <!-- /inner-wrapper -->
</div> <!-- /container -->
</div> <!-- /segment-footer -->
<ul class="nav nav-tabs">
<li><a href="patient.html">Content</a></li>
<li class="active"><a href="#">Examples</a></li>
<li><a href="patient-definitions.html">Detailed Descriptions</a></li>
<li><a href="patient-mappings.html">Mappings</a></li>
<li><a href="patient-profiles.html">Profiles</a></li>
<li><a href="patient-operations.html">Operations</a></li>
</ul>
<h3>List Table</h3>
<p>Example List:</p>
<table class="list">
<tr><td><a href="patient-example.html">General Person Example</a></td><td><a href="patient-example.xml.html">XML</a></td><td><a href="patient-example.json.html">JSON</a></td><td/></tr>
<tr><td><a href="patient-example-a.html">Patient 1 for linking</a></td><td><a href="patient-example-a.xml.html">XML</a></td><td><a href="patient-example-a.json.html">JSON</a></td><td/></tr>
<tr><td><a href="patient-example-b.html">Patient 2 for linking</a></td><td><a href="patient-example-b.xml.html">XML</a></td><td><a href="patient-example-b.json.html">JSON</a></td><td/></tr>
<tr><td><a href="patient-example-c.html">Deceased patient (using time)</a></td><td><a href="patient-example-c.xml.html">XML</a></td><td><a href="patient-example-c.json.html">JSON</a></td><td/></tr>
<tr><td><a href="patient-example-c.html">Deceased patient (using time)</a></td><td><a href="patient-example-c.xml.html">XML</a></td><td><a href="patient-example-c.json.html">JSON</a></td><td/></tr>
</table>
<p>
Usage note: every effort has been made to ensure that the
examples are correct and useful, but they are not a normative part
of the specification.
</p>
</div>
<h3>Tabs</h3>
<div id="tabs">
<ul>
<li><a href="#tabs-struc">Structure</a></li>
<li><a href="#tabs-uml">UML</a></li>
<li><a href="#tabs-xml">XML</a></li>
<li><a href="#tabs-json">JSON</a></li>
<li><a href="#tabs-all">All</a></li>
</ul>
<div id="tabs-struc">
<p>structure</p>
</div>
<div id="tabs-xml">
<p>xml</p>
</div>
<div id="tabs-uml">
<p>uml</p>
</div>
<div id="tabs-json">
<p>json</p>
</div>
<div id="tabs-all">
<p>all</p>
</div>
</div>
<h3>End</h3>
<p>paragraph after end</p>
99.6
Transport
There are different means of transport
Files
MLLP
HTTP
TDB
99.7
Profile
Here we have to place chapter 2B
TBD (08000): JSON-Encoding
99.10
HL7 v2.x - former versions…
TBD (09010): The previously released versions should be available by this site as well. Following is a link the intropage.
<a href="http://www.hl7.eu/HL7v2x/hl7.html">
Perhaps direct deep links are more convenient? They must be provided later on…
99.11
New (v2+) Field Attributes
Different flags indicate different kind of behavior in combination with this element. Currently, there are three options that can be combined.
99.11.1
Implement
implement
This attribute indicates whether a developer has to take care of this data element or not. In other words, it expresses the implementation requirement, that this element must be processed in a meaningful way.
An empty entry indicates, that the developer has maximum freedom with his choice. This element may be supported (=SHALL) or not (=SHALL NOT). Therefore, the constraint machinery is changing the value from empty to either one. Once a decision has been made, there is no option to change it any more in derived profiles.
| VALUE | DESCRIPTION |
|---|---|
| SHALL | In a specification, this expresses, that an implementation has to support this element in a meaningful way that may be specified further in an implementation guide.<br/> In a conformance statement, it expresses that an implementation/application supports this element. |
| MAY (default) | An implementer has a choice whether he is going to support this element or not.<br/> This is the default value. |
| MAY NOT | In a specifiation, it expresses, that this element will not be supported soon. Therefore, it SHOULD NOT be supported any more. |
| SHALL NOT | In a specifiation, it expresses, that this element SHALL NOT be supported any more.<br/> In a conformance statement, it expresses that an implementation/application does not support this element and either is not capable of providing it (sender side) or ignores the information (receiving side). |
99.11.2
Flags
99.11.2.1
Truncation
This flags indicates, how to deal with information/data, that is too long for storage. <br/>
Possible values are "=" for "no truncation allowed" and "#" meaning "truncation is allowed".
99.11.2.2
Condition
This flag indicates that there is a predicate that defines the condition which specifies the circumstances under which this element must be handled.
99.11.2.3
Backwards/Withdrawn
This flag indicates why a certain element should not be dealt with any more.<br/>
"Backward" is a first phase indication, that this element is going to become deprecated, and that it should not be used anymore.<br/>
"Withdrawn" is an indication, that this element is deprecated.
99.11.3
Cardinality
99.11.4
(Minimum and Maximum) Length
If a value is conveyed in a field or component, its length must be within the given range including the named values.
99.11.5
Conformance Length
This information is a good starting point for a minimal maximum length.
99.11.6
Data Type
This is a reference to a dedicated Data Type specification.
99.11.7
Vocabulary
This column list the associated concept domains for a specific data element.