HL7 Message Encoding
In the first chapter you were introduced to the HL7 standards. You were also introduced to the following:
In this chapter, you will be concentrating on the message encoding for HL7 Version 2.x. Let’s start off by looking at the HL7 V2.x message and the encoding types.
Tip If you are already experienced with HL7 and are knowledgeable about HL7 message encoding, you can skip ahead to the next chapter.
The HL7 Message
An HL7 message is used to transfer patient information from one system to another healthcare system. There are various types of HL7 messages defined to carry different types of patient information; for example, the ADT message type is used for patient’s patient administration information. The HL7 message structure defined by HL7 organization is also referred to as HL7 message encoding, which we will talk about in this chapter.
Message Encoding Types
Message encoding types describe how an HL7 message is formatted to carry information from one system to another. There are two different types of encoding for the HL7 2.x version:
Delimiter-based encoding, as the name suggests, defines data fields of variable lengths and separates them using a delimiter. In this encoding, five different delimiters are used to lay out the message structure; for example, a carriage return delimiter is used to group message into different segments, a pipe (|) is used to group each segment into fields, and so on. Listing 2-1 shows an HL7 message with delimiter-based encoding.
Listing 2-1. HL7 Message with Delimiter-based Encoding
MSH|^~&|ADM|HUN|||201302260415||ADT^A01|125|P|2.2|||AL|NE
EVN||201302260250|||REG.RN^Name^Name^^^^|201302260250
PID|1||M123123123^^^^MR^HUN||Name^Name^^^^^L||19891203|F||W|126 LK^^HU
NK1|1|B^K^^^^|MO|2 Street^^City^State^Zip^Country^^^DES|Number CELL
PV1|1|P|F.ECC^^||||||YTU.FR^Y^F^R^^^MD|EDS||||||||ER||MCD||||||||||||||||
ZBC|1
ZCS|N|N^^UNKNOWN^UN^00000|N|||01371
You will learn more about the message structure and its details in the next sections.
Message Structure
The HL7 delimiter-based encoded message structure contains all the information within different components. There are five components that make up the message structure.
Delimiters are the key components of the HL7 message. Delimiters allow you to identify these key components within the HL7 message. Table 2-1 provides descriptions of the default delimiters.
Table 2-1. The Default Delimiters of an HL7 2.X Message
Delimiter |
Description |
---|---|
0D 0A hex ( ) |
Group message into segments |
| |
Fields: Group data into different fields within segments |
^ |
Subfields: Group field data into subfields |
& |
Sub-subfields: Group subfields into sub-subfields |
~ |
Indicates if a field is a repeatable field |
These delimiters are found at the start of MSH segment, as shown in Listing 2-2.
Listing 2-2. Delimters in the MSH Segement
MSH|^~&|ADM|HUN|||201302260415||ADT^A01|125|P|2.2|||AL|NE
These delimiters can be customized. For example, if you want # to be a field delimiter, then the code in Listing 2-2 will look like the code in Listing 2-3.
Listing 2-3. Customized Field Delimter
MSH#^~&#ADM#HUN###201302260415##ADT^A01#125#P#2.2###AL#NE
Note In Listing 2-3, the character (backslash) before the & character is used as escape character to escape special characters in the message.
Segments
In Chapter 1, you were introduced to the key segments (components) of an HL7 V.2.x message. As previously mentioned, the HL7 message contains different segments; each segment represents specific information such as patient information, patient visit, patient insurance, lab results, etc., and groups the information into different data fields.
There are hundreds of predefined segments as part of HL7 2.X specification. Each segment indicates the kind of information it contains; for example, a patient admit HL7 message may contain segments as shown in Table 2-2.
Table 2-2. Sample List of Segments
Segment |
Name |
Description |
---|---|---|
MSH |
Message Header Segment |
Contains metadata about the message |
PID |
Patient Identification |
Patient identification information such as name, patient id, etc. |
PV1 |
Patient Visit |
Patient visit information |
IN1 |
Insurance |
Patient insurance information |
Tip A complete list of these segments and their definitions can be found as part of HL7 Standard documentation on the HL7 web site at www.hl7.org/implement/standards/product_brief.cfm?product_id=185. Download a specific version of HL7 2.x and refer to the Appendix.
An HL7 2.X message is all about one or more segments. These segments divide the HL7 message into three different parts, as shown in Figure 2-1:
Figure 2-1. HL7 message parts
Let’s see what these segments contain.
Fields
Fields in an HL7 message contain message information; in the OOPS world, we would consider them as properties of a class where the class is the segment. In this section, you will learn about following:
Field Identification
As you learned in the delimiter section, fields in an HL7 segment are identified using a delimiter, which is a pipe (|) by default. Listing 2-4 shows how the delimiter is used.
Listing 2-4. Field Delimiter Sample
PID|1|123456|M123123123^^^^MR^HUN||Name^Name^^^^^L||19891203|F||W|126
Each field in the segment is referred to by its ordinal position in the segment; in Listing 2-3, the highlighted field is referred to as PID1, PID2, and PID3, and the values are 1, 123456, and M123123123^^^^MR^HUN, respectively.
Tip There is one exception to this. In the MSH, the field is still referred to by its ordinal position. However, the ordinal position value is one more than the ordinal position of the other segments. In the following example, the first field is referred to as MSH2 rather than MSH1. So where is MSH1? MSH1 is always a field separator, which in this case is a pipe (|).
MSH|^~&|ADM|HUN|||201302260415||ADT^A01|125|P|2.2|||AL|NE
In a HL7 message, if you want to make sure that the receiving application deletes the data in their data store corresponding to the field, then the message should have the field value as “” e.g. |“”|. If the field is sent like ||, it will indicate that no change is required to the data store.
Subfields are referred as components in the HL7 message specification. Throughout this book we will refer to them as subfields to make it easier to understand the relationship between fields and subfields.
A field can have subfields. You can find subfields within fields using the subfield delimiter, which is a caret (^) by default. In the following example, PID3 has six subfields highlighted; these fields are referred as PID3.1, PID3.2, and so on.
PID|1|123456|M123123123^^^^MR^HUN||Name^Name^^^^^L||19891203|F||W|126
A subfield can also have subfields; they are referred as subcomponents in the HL7 specification. We will refer to them as sub-subfields.
Sub-subfields are separated by ampersand (&) within the subfield. In following example, SFT segment field 1, subfield 6th has three sub-subfields referred to as SFT1.6.1, SFT1.6.2, and SFT1.6.3.
SFT|MEDITECH, Inc. ^L^^^^MEDITECH&1.3.6.1.4.1.24310&ISO^XX^^^MEDITECH|5.6.6
Repeatable Fields
The repeatable field is like an array of a field and is identified by repeat delimiter (~) in the field. In following example, there are three PID3 fields:
PID|1||0266432^^^Test&Test^MR^.~151-22-5907^^^^SS^.~104475^^^^PI^.||
Each PID3 will have its defined subfields and so on.
Tip Repeatable fields are not applicable for subfields or sub-subfields. They are only defined at field level. Defining them at subfield or sub-subfield level will break the message structure.
Data Types
All fields (PID1, PID2, etc.) have data types defined as part of HL7 2.x standard. The data type definition includes following key information:
Tip Appendix 3 contains the definitions of the data types currently supported in BizTalk.
Use of Escape Sequences
The escape sequence allows you to have special characters in the HL7 message text that are not allowed normally; for example, delimiter characters can be included in the message field by using an escape sequence. An escape sequence as defined by HL7 organization (www.hl7.org/implement/standards/index.cfm?ref=nav) consists of an escape character which is defined in MSH.2, normally ‘’, followed by an escape code ID of one character then zero or more data characters, and another occurrence of the escape character, according to the spec. Table 2-3 shows the escape sequences that are defined for delimiters and other characters.
Table 2-3. The HL7 Specification Provides the Escape Sequence for These Characters (Source: www.hl7.org/implement/standards/index.cfm?ref=nav)
Escape Sequence |
Description/Characters to Escape |
---|---|
F |
Pipe “|” |
S |
Caret “^” |
T |
Ampersand “&” |
R |
Tilda “~” |
E |
Escape character “” |
H |
Highlighting text start |
N |
Normal text (end highlighting) |
Xdddd. . . |
Hexadecimal data |
dddd. . . |
Locally defined escape sequence |
Some examples of escape sequences are shown in the following sections.
Highlight Text
The escape sequence of H can be used to format the text in many ways; for example, a receiving application can display the highlighted text in bold or in red color. The message fragment "OBX| TOTAL H240*N [90 - 200]" can be used by receiving application to display the text as "TOTAL 240* [90 - 200]" or show the 240* in red.
Delimiter Escape Sequences
The HL7 messaging standard delimiters can be included in the message text by using the escape sequence of “F, S, R, T, and E”. For example, the message fragment
OBX|25|TX||| FAF. PROCEDURE - WIDE RESECTION.||||||F|
OBX|26|TX||| B. TUMOR T SITE - LEFT LOWER BACK.||||||F|
will be displayed as
|A|. PROCEDURE - WIDE RESECTION
B. TUMOR & SITE - LEFT LOWER BACK.
Usage and Examples of Formatted Text
Apart from the normal escape sequence, there are different commands that can be used alone or together with an escape sequence to format the text especially for fields with the FT data type. Formatted text commands start with a dot ‘ . ’ Table 2-4 shows different formatting commands available.
Table 2-4. Commands for Formatted Text and Description
Command |
Description |
---|---|
.sp <n> |
Indicates the end of the current line and skips n number of spaces, where n is the number of spaces to skip. |
.br |
Indicates the beginning of a new line. |
.fi |
Indicates the beginning of word wrap or fill mode. |
.nf |
Indicates the beginning of no-wrap mode. |
.in <n> |
Indicates that the text should be indented by n number of spaces. |
.ti <n> |
Indents temporarily n number of spaces. |
.sk <n> |
Skips <n> spaces to the right. |
.ce |
Indicates the end of the current line and the center of the next line. |
Message Types
Message types (MSH9.1) in the HL7 2.x specification correspond to a group of real world events. For example, Patient Administration has number of real world events, such as patient admit, patient registration, and many more. All such patient administration messages are grouped into one message type, which is referred to as ADT. There are more than 100 message types defined within HL7 specification. Some of the most common message types are listed in Table 2-5.
Table 2-5. Most Common Message Types
Message Type |
Description |
---|---|
ADT |
Admit Discharge Transfer; used for patient administration |
ORM |
Order Message; Order can be defined as a request of service, such as a lab service request |
ORU |
Observation Results, such as clinical lab results or imaging study results |
DFT |
Detail Financial Transaction; used for patient account purposes |
MDM |
Tip A complete list of these message types and their definitions can be found as part of the HL7 standard’s documentation at on ay www.hl7.org/implement/standards/product_brief.cfm?product_id=185. Download a specific version of HL72.x and refer to Appendix A.
Message Trigger Event
Each message contains one or more trigger events (MSH9.2), which correspond to real-world events in the healthcare system. Some of the real world examples are the following.
These real world events initiated the need for the HL7 2.x messaging standard to transfer information from one system to another. These events are bundled into specific message types; for example, Patient Administration-related events are bundled into message type ADT.
MSH|^~&|ADM|HUN|||201302260415||ADT^A01|125|P|2.2|||AL|NE
The message type and trigger event has a one-to-many relationship, so one message type can have more than one trigger event; however, one trigger event can only be part of one message type. The combination of message type and trigger event governs the layout of the message, so which segments are required or optional all depends on this combination. Table 2-6 is a partial list of message types and their events.
Table 2-6. Partial List of Message Types and Their Events
Message Type^Event |
Description |
---|---|
ADT^A01 |
Patient admit |
ADT^A02 |
Transfer a patient |
ADT^A04 |
Register a patient |
ORM^O01 |
Order message |
ORU^R01 |
Observation message |
SIU^S12 |
Notification of new appointment booking |
For each message type, a complete list of triggered events can be found in specific HL7 standard documents. If you need to find all events for ADT messages, then look for the CH03_PatientAdmin document of the HL7 message standard, which can be downloaded from: www.hl7.org/implement/standards/product_brief.cfm?product_id=185.
Message Version
A message also carries its HL7 2.x version to which it conforms within in message header MSH12 field. In the following sample, the version of the message is 2.4:
MSH|^~&|ADT1|MCM|LABADT|MCM|198808181126|SECURITY|ADT^A01|MSG00001|P|2.4
The message control id (MSH10) field in the message header represents an identity for the message, which the sending application should generate so that it is unique and can be used to correlate the message acknowledgment sent by receiving application. In an enterprise, the message control id field should be used to track messages. The following example shows how to create the message control id:
MSH|^~&||COCFH|||201304210056||ADT^A08|FHGTADM.1.7230428|P|2.1
Tip The format in a message control id can be anything as long it is unique for each message.
Message Acknowledgment
In an HL7 message exchange between two systems, the receiving application sends an acknowledgment of the message received to the sending application. This way message delivery is guaranteed between two systems. Also, the sending application does not send the next message until the acknowledgment is received from the receiving application. Figure 2-2 shows an example of the acknowledgment message.
Figure 2-2. Message acknowledgment sample
Key Elements of the Acknowledgement Message
There are few key elements of an acknowledgment message.
Acknowledgement Modes
There are two modes that determine how an acknowledgment should be returned. They are the original and enhanced modes.
Original Mode
In original mode, an application acknowledgment is returned, which means that before returning an acknowledgment to sending application not only is the message received by the receiving application but also it is processed successfully.
Tip For original mode, both MSH15 (Accept Acknowledgment Type) and MSH16 (Application Acknowledgement Type) in the MSH segment need to be null or not present.
The message processing by the receiving application may vary depending on the functional requirements of a system; for example, a system can return the acknowledgment after storing the message in an input queue for later processing.
Note HL7 does not have any requirements for the design and architecture of a receiving application for processing of the message.
Enhanced Mode
The enhancement mode breaks the acknowledgment into two parts:
Note For enhanced mode, at least MSH15 (Accept Acknowledgment Type) and MSH16 (Application Acknowledgement Type) in the MSH segment need to be present.
Acknowledgment Types
There are four acknowledgment types that can be used by the sending application in enhanced mode to request an acknowledgment from the receiving application. Table 2-7 lists them.
Table 2-7. List of Acknowledgement Types
Code |
Description |
---|---|
AL |
Always send the acknowledgment. |
ER |
Send the acknowledgment only if there is any error or rejection. |
NE |
Never send an acknowledgment. |
SU |
Send acknowledgment only after successful completion. |
These same acknowledgment type can be used for both MSH15 and MSH16 and accordingly the receiving application sends the acknowledgment back.
Tip MSH15 and MSH16 should only be used for enhanced mode acknowledgment and should not be used for original mode.
Acknowledgment Code
The Acknowledgment code (MSA1) in the acknowledgment message returns the acknowledgment code that indicates the message status returned by the receiving application. Table 2-8 lists the acknowledgment codes.
Table 2-8. Acknowledgement Codes
ERR Segment
The error segment (ERR) is used to return error information in the acknowledgment message when the returned acknowledgment code is not AA or CA. One example of an acknowledgment with ERR segment is shown below:
MSH|^~&|TEST2|MCM|TEST|MCM|20131226132358||ACK|10000GSM|P|2.5.1|||NE
MSA|AA|MSG00001
ERR||PID^1^5|102^Data type error^HL79999|E||||||||^^^^^^^^^^^
ERR||NK1^1^2|102^Data type error^HL79999|E||||||||^^^^^^^^^^^
As you can see, the ERR segment include details about the errors the receiving application sends in acknowledgment. Some of the key fields of ERR segment are defined in Table 2-9.
Table 2-9. Key fields for ERR Segment
Field |
Name |
Description |
---|---|---|
ERR2 |
Error Location |
This field contains details about the location of error in HL7 message. |
ERR 2.1 |
Segment ID |
Segment Name where error occurred, such as PID. |
ERR2.2 |
Segment Sequence |
This indicate which segment has the error; this is useful when one segment is present multiple times in an HL7 message. If the segment is present only once, then it will be 1. |
ERR2.3 |
Field Position |
The field position where the error occurred. |
ERR3 |
HL7 Error Code |
Identifies HL7 error code for the error. The HL7 standard defines standard error codes for specific issues; for example, a Data Type Error relates to an issue where a field data type does not match. These standard error code can be found in Table 357 at www.hl7.org. |
ERR 3.1 |
Identifier |
Identifier of the error code; for example, 102 represents data type error. |
ERR 3.2 |
Text |
Error description. |
ERR4 |
Severity |
Severity of error: W - Warning I - Information E - Error |
Using XML is an alternate encoding for an HL7 message that can be used where both the sender and receiver can understand XML. The XML representation of HL7 Version 2.x messages is algorithmically derived directly from the HL7 database. This is done to prevent work has to be done by hand, which often is susceptible to errors. Furthermore, deriving the XML representation algorithmically allows generating schemas for future HL7 v2.x versions easily.
Message Structure
In XML encoding, message segment fields are represented as XML elements. Listing 2-2 shows an example of an HL7 acknowledgment message in both delimiter and XML encoding.
Listing 2-2. Sample Delimiter and XML Encoding
MSH|^~&|TEST2|MCM|TEST|MCM|20131226132358||ACK|10000GSM|P|2.5.1|||NE
MSA|AA|MSG00001
ERR||PID^1^5|102^Data type error^HL79999|E||||||||^^^^^^^^^^^
ERR||NK1^1^2|102^Data type error^HL79999|E||||||||^^^^^^^^^^^
<?xml version="1.0" encoding="UTF-8"?>
<ACK>
<MSH>
<MSH.1>|</MSH.1><MSH.2>^~&</MSH.2><MSH.3><HD.1>TEST2</HD.1></MSH.3>
<MSH.4><HD.1>MCM</HD.1></MSH.4><MSH.5><HD.1>TEST</HD.1></MSH.5>
<MSH.6><HD.1>MCM</HD.1></MSH.6><MSH.7><TS.1>20131226132358</TS.1>
</MSH.7><MSH.9><MSG.1>ACK</MSG.1></MSH.9><MSH.10>10000GSM</MSH.10>
<MSH.11><PT.1>P</PT.1></MSH.11><MSH.12><VID.1>2.5.1</VID.1></MSH.12>
<MSH.15>NE</MSH.15>
</MSH>
<MSA>
<MSA.1>AE</MSA.1><MSA.2>MSG00001</MSA.2>
</MSA>
<ERR>
<ERR.2><ERL.1>PID</ERL.1><ERL.2>1</ERL.2><ERL.3>5</ERL.3></ERR.2>
<ERR.3><CWE.1>102</CWE.1><CWE.2>Data type error</CWE.2><CWE.3>HL79999</CWE.3>
</ERR.3><ERR.4>E</ERR.4><ERR.12><XTN.12> </XTN.12></ERR.12>
</ERR>
<ERR>
<ERR.2><ERL.1>NK1</ERL.1><ERL.2>1</ERL.2><ERL.3>2</ERL.3></ERR.2>
<ERR.3><CWE.1>102</CWE.1><CWE.2>Data type error</CWE.2><CWE.3>HL79999</CWE.3>
</ERR.3><ERR.4>E</ERR.4><ERR.12><XTN.12> </XTN.12></ERR.12>
</ERR>
</ACK>
Root Element—Message Structure IDs
In the HL7 Version 2.x standard, several trigger events share the same abstract message syntax. An example of this could be an ADT message that is triggered by event A04, which the same message structure as ADT A01. In addition to A04, other events like A05, A08, A13, A14, A28, and A31 share the same A01 message structure. Until Version 2.3.1, there was no way to represent this in an HL7 message; however, with version 2.3.1, this fact became standardized and represented as Message Structure ID in an HL7 message by adding a new field called MSH9.3 to the message type MSH9 field. The following is an example of the ADT_A01 delimited message structure used by ADT A04 message event:
MSH|^~&|ADT2||LAB||198808181121|SECURITY|ADT^A04^ADT_A01|MSG00001|P|2.4
The message structure ID is relevant for XML encoding since this is used as a root element in an XML instance document, as shown:
<?xml version="1.0" encoding="UTF-8"?>
<ADT_A01>
...(Segment Elements)
</ADT_A01>
Segments
Message structures contain segments also represented as XML elements. Each segment name is three characters long, similar to HL7 V2.x encoding; these names are used as an XML element. The following example shows a few segments as an XML element:
<?xml version="1.0" encoding="UTF-8"?>
<ADT_A04>
<MSH>
...(MSH Field Elements)
</MSH>
<PID>
...(PID Field Elements)
</PID>
<PV1>
...(PV1 Field Elements)
</PV1>
...(Other Segment Elements)
</ADT_A04>
Segment Groups
One benefit of XML encoding is the ability to represent segment grouping easily. In a group, whether a segment is optional or repeatable is represented using brackets [ ... ] or braces { ... } in the standard. So segments [{ IN1, [ IN2 ], [{ IN3 }], [{ ROL }] } ] represent the INSURANCE group, where each group itself is optional or may repeat, and within the group segment, IN1 is required, IN2 is optional, IN3 is optional or may repeat, and ROL is optional and may repeat as well.
The explicit grouping is one major difference between delimiter and XML encoding as there is no grouping in traditional delimiter encoding.
Segment group naming includes upper case names. So ADT_A01.INSURANCE and the name itself represents the purpose of the segment group. In other words, the “INSURANCE” group bundles all INx segments, and the “VISIT” group bundles PV1 and PV2 segments, as shown in following example:
<?xml version="1.0" encoding="UTF-8"?>
<ADT_A04>
<MSH>
...(MSH Field Elements)
</MSH>
<EVN>
...(EVN Field Elements)
</EVN>
<PID>
...(PID Field Elements)
</PID>
<ADT_A04.INSURANCE>
<IN1>
...
</IN1>
<IN2>
...
</IN2>
<ROL>
...
</ROL>
</ADT_A04.INSURANCE>
</ADT_A04>
Note Segment group naming includes the message structure id as a prefix, as shown in the above example, to differentiate between different message structures, so the INSURANCE group can be found in ADT_A01 with different cardinality.
Another way of grouping segments is by a choice; here a decision has to be made as to which set of segments should be conveyed in a message: This is indicated in the HL7 standard documents by angle brackets: < and >. The different options for a choice are then separated by a vertical bar. In the XML schema, the choice is represented using the xsd: choice element.
Note This vertical bar is independent from the vertical bar in the conventional encoding reflecting the standard field delimiter.
Fields
In XML encoding, XML elements representing fields and their naming conventions are based on segment names and the field positions in the segment. So the first field in PID segment is named PID.1, the second is PID.2, etc., like so:
...
<PID>
<PID.1>1</PID.1>
<PID.2>
...
</PID.2>
</PID>
In delimiter-based encoding, empty fields are also required to be separated by a pipe; however, in XML encoding, an element with no contents simply can be omitted (unless explicit use of the “” is required to force a data delete action by the receiving application).
The data types for the fields are defined similarly to that of delimiter-based encoding for each field. Please refer to the “Data Types” section of the “Delimiter-based Encoding” section for more details.
Use of Escape Sequence
There are some basic differences in the escape sequence between delimiter- and XML-based encoding. These differences are as follows:
Table 2-10. Escape Characters in XML Encoding
Escape Characters as Defined Earlier |
Replacement for XML Encoding |
Description |
---|---|---|
H |
<escape V=“H”/> |
Start highlighting text. |
N |
<escape V=“N”/> |
Normal text (stop highlighting). |
Similarly, the command also indicates using XML elements, as shown in Table 2-11.
Table 2-11. Formatting Comments in V2.x and Their Replacements in V2.xml
Escape Characters as Defined in the v2.x Standard |
v2.xml Encoding |
---|---|
.br |
<escape V=“.br”/> |
.spn |
<escape V=“.spn”/> |
.in±n |
<escape V=“.in±n”/> |
.ti±n |
<escape V=“.ti±n”/> |
Message Header Segment
As mentioned before, with XML encoding there is no change to message semantics. All header properties and their definitions remain as in delimiter-based encoding.
Message Acknowledgment
Both message acknowledgment modes, original and enhanced processing, remain the same in XML encoding, except that validation of messages now includes well-formed and valid XML by the receiving system. This means sender system must ensure that the HL7 message’s XML is well-formed and valid as per its schema.
XML Schemas
HL7 provides XML schemas for each version supported by HL7 Version 2.x.XML specification, as shown in Table 2-12.
Table 2-12. XML Schema (Source: www.hl7.org/implement/standards/index.cfm?ref=nav)
Schema File |
Description |
---|---|
MessageStructureID.html |
A set of many files in HTML format containing a short description of the message and links to the corresponding schemas. |
<MessageStructureID>.xsd |
A set of many schemas each containing the schema definitions for a specific message structure specified by MessageStructureID. For example, ADT_A01.xsd contains the definitions for the ADT A01 message structure, ADT_A02.xsd for ADT A02, and so forth. |
Segments.xsd |
Schema for all segment definitions, imports fields definitions. |
fields.xsd |
Schema for all field definitions, imports data type definitions. |
datatypes.xsd |
Schema for all data type definitions for v2. |
batch.xsd |
Schema containing definition of batch. |
Messages.xsd |
Schema containing all message definitions together. |
An XML instance of a specific message should refer to the corresponding schema. The following code shows a schema reference within a v2.XML XML message instance fragment:
<ADT_A04
xmlns="urn:hl7-org:v2xml"
xmlns:xsi="http://www.w3.org/2001/XmlSchema-instance"
xsi:schemaLocation="urn:hl7-org:v2xml ADT_A04.xsd">
<MSH>...
<ADT_A04>
Note When you install the BizTalk 2013 R2 HL7 Accelerator (BTAHL7), the setup wizard creates the <drive>: Program FilesMicrosoft BizTalk 2013 R2 Accelerator for HL7TemplatesSchemas folder structure that contains templates to support the events for HL7. Beneath this folder, a V2.X folder includes a subfolder for each of the HL7 2.X versions: 2.1, 2.2, 2.3, 2.3.1, 2.4, 2.5, 2.5.1, and 2.6.
Summary
In this chapter, you took an in-depth tour of the HL7 message structure, encoding, and acknowledgment model. Understanding these concepts is key to any implementation of healthcare-based system. In Chapter 3, you will learn about the Microsoft BizTalk HL7 Accelerator and its capabilities for HL7 2.x message processing.
3.16.51.157