hl7

E-LEARNING COURSE HL7 2X

INTRODUCTION TO HL7 VERSION 2.X, DATA TYPES, ACK

HL7 E-LEARNING COURSE MODULE V.1 - HL7 V2.X INTRO: CONTROL

HL7ELC_V_EN_U01_V01.2 Asociacin HL7 Argentina HL7 Inc. - All rights reserved 2

HL7 E-LEARNING COURSE MODULE I - INTRODUCTION UNIT I.1 INTRODUCTION TO HEALTHCARE INTEROPERABILITY UNIT I.2 INTRODUCTION TO VOCABULARIES IN HEALTHCARE UNIT I.3 INTRODUCTION TO UNIFIED MODELING LANGUAGE (UML) UNIT I.4 INTRODUCTION TO EXTENSIBLE MARKUP LANGUAGE (XML) MODULE V HL7 V2.x UNIT V.1 INTRODUCTION TO HL7 VERSION 2.X, DATA TYPES, ACK UNIT V.2 HL7 V2.X: PATIENT ADMINISTRATION, ORDERS AND RESULTS UNIT V.3 HL7 V2.X: Z-SEGMENTS / IMPLEMENTATION / PROFILES UNIT V.4 HL7 V2X.XML: XML IMPLEMENTATION OF V2.X MESSAGING MODULE T HL7 V3 UNIT T.1 INTRODUCTION TO HL7 V3 UNIT T.2 REFERENCE INFORMATION MODEL RIM / DERIVED MODELS UNIT T.3 HL7 V3 DATA TYPES AND THEIR XML REPRESENTATION UNIT T.4 HL7 V3: FROM THE MODEL TO THE MESSAGE MODULE C HL7 CDA R2 UNIT C.1 INTRODUCTION TO HL7 CDA R2 UNIT C.2 CDA R2 ARCHITECTURE: HEADER, BODY AND ENTRIES UNIT C.3 CDA R2 IMPLEMENTATION GUIDES UNIT C.4 CDA R2 ENTRIES: CLINICAL STATEMENT Language: EN (ENGLISH) Version: 1.2 Year: 2009



Table of Contents Introduction to HL7 v2 ...................................................................................................4 Health Level 7 (HL7) .......................................................................................................5

HL7 Mission (as an organization)..............................................................................5 HL7 version 2 ...................................................................................................................8

What is HL7 V2.x?........................................................................................................8 How is the HL7 V2.x standard organized? ..............................................................8 How do we read the HL7 V2.x standard? ............................................................10

Communication environment ...................................................................................12 Message ........................................................................................................................12

Segments ...................................................................................................................13 Fields...........................................................................................................................17 Components .............................................................................................................17 Subcomponents .......................................................................................................18 Message delimiters...................................................................................................18 Summary....................................................................................................................19 Summary....................................................................................................................19

Data types.....................................................................................................................20 Categories.................................................................................................................20

Alphanumeric Data Types ..................................................................................21 Data Types for Numbers and Quantities...........................................................22 Data Types for Times and Dates.........................................................................24 Data Types for Identifiers .....................................................................................25 Data Types for Coded Values ............................................................................29 Data types for Addresses, Persons, Organizations, and Phone Numbers ...31 Data Types for Multimedia Objects ...................................................................32

Message Processing Rules ..........................................................................................34 Sending Rules............................................................................................................34 THE TEN OUTBOUND HL7 COMMANDMENTS ........................................................34 Receiving Rules.........................................................................................................35 THE TWO INBOUND HL7 COMMANDMENTS ..........................................................35 Acknowledgement of Message Reception (ACK).............................................35

Original mode .......................................................................................................35 Enhanced mode ..................................................................................................36



INTRODUCTION TO HL7 V2

Goals of this unit:

Understand the mechanics of message exchange. Write a simple V2.x message header (and some other message fragments). Read and understand an HL7 v2.x message.

To help define the scope of HL7 V2.x were going to review some basic information; much of which you may be familiar with. Please take a moment to review this information so we can avioid any misconceptions.



HEALTH LEVEL 7 (HL7)

Founded in 1987, HL7 is the only standards development organization (SDO) committed solely to the helthcare domain. HL7 V2.x is an implementation of healthcare information exchange at layer 7 of the OSI (Open Systems Interconnection) network model, hence its name: Health [Information at] Level 7 [of the OSI model].

For more information on the ISO/OSI network model, we recommend: http://en.wikipedia.org/wiki/OSI_model

HL7 Mission (as an organization)

HL7 defines its mission as providing standards for interoperability that improve care delivery, optimize workflow, reduce ambiguity and enhance knowledge transfer among all of our stakeholders, including healthcare providers, government agencies, the vendor community, fellow SDOs and patients. [http://www.hl7.org/about] HL7 standards define messages and message exchange protocols that support clinical practice and management. Remember that in the first part of UNIT 1, you saw that clinical management is a broad concept that tries to analyze the cost and effectiveness of medical acts in order to define healthcare policies that will achieve and maintain high quality outcomes. Data exchange between health care applications is essential to achieving that goal.

1 Physical2 Data Link3 Network

4 TransportCommunication

Function

5 Session 6 Presentation 7 Application HL7



HL7 has accepted responsibility for creating flexible, cost-effective standards, guidelines and methodologies that provide interoperability between healthcare systems and the exchange of meaningful electronic health information.

Since 1994 the organization has been accredited by the American National Standards Institute (ANSI) as a Standards Developing Organization (SDO). As an SDO, HL7 has adopted a structure and formal procedures to achieve consensus and a balance of interest among its various stakeholders: systems and application vendors, health insurance companies, governmental jurisdictions, universities, hospitals, health care providers, consultants, etc.

The use of HL7 standards worldwide has been made possible in large part by the more than 500 companies that have organizational membership, representing more than 2000 members, and more than 30 international affiliate organizations. About a quarter of the worldwide membership meets periodically in Working Group Meetings.

Table 1 lists some of the nations represented by HL7 Affiliate organizaitons.

Table 1 - International affiliates

Argentina Australia Brazil

Canada China Croatia

Czech Rep. Denmark Finland

Germany Greece India

Ireland Italy Japan

Korea Lithuania Mexico

New Zealand Poland Spain

South Africa Switzerland Taiwan

Netherlands United Kingdom Uruguay

Recently, affiliates representing Chile, Colombia, and Singapore joined HL7, as the organization continues its trend of steady growth. All these countries have their own independent affiliate organizations and are represented on an Affiliate Council for international harmonization and adapting standards in different parts of the world.

The first HL7 messaging standards, Version 1.0 and Version 2.0, were approved in 1987 and 1988 respectively. Since then various release updates of V2 have been published:



1990 1994 1997 1999 2000 2003 2007 2008

2.1 2.2 2.3 2.3.1 2.4 2.5 2.5.1 2.6

This course is ased on v2.6, which is widely supported by existing applications. Usually applications encode HL7 messages using pure ASCII text with a flat file format. HL7 V2.x has fewer semantic restrictions that is to say, it does not specify the underlying model and the vocabulary as strictly as HL7 Version 3. Efforts have been initiated to align the HL7 V2.x standards with the Version 3 Reference Information Model (RIM) HL7 has also developed a specification for encoding V2.x messages in XML (V2.XML). Our initial focus will be on HL7 V2.x, a messaging standard for the exchange of administrative, financial or clinical data, HL7 also provides other standards including the following:

HL7 Clinical Document Architecture (CDA) is a very important initiative within HL7, defining a standard for the exchange of clinical documents, such as discharge or consultation notes and summaries, imaging and laboratory reports, etc. This model is typically encoded in XML. CDA Release 2.0 is closely aligned with the Version 3 Reference Information Model and uses V3 data types. The CDA specifications are flexible and allow for the use of templates according to different scenarios and settings. In a later unit, we shall discuss CDA and examine several examples of CDA implementations.

Arden Syntax is a grammar for expressing and sharing rules of clinical

knowledge, which generally are well developed in clinical practice guidelines. For example, a rule can be formulated in Arden Syntax such that if a patient is to be administered digoxin but his potassium is less than 3 mEq/L, an alarm may be generated to suspend the medication.

CCOW (a standard developed by the Clinical Context Object Workgroup) is a

framework for sharing context (user, patient, study) between applications and allowing single sign-on and desktop sharing among applications.



HL7 VERSION 2 What is HL7 V2.x? Development of incremental releases of HL7 V2, which have come to be referred to collectively as HL7 V2.x, began in 1988. HL7 V2.x is a protocol for the exchange of clinical data through messages. What HL7 V2.x is not includes the following:

It is not an application It is not a data structure or a database specification. It is not an architecture to design applications for hospitals. It is not a specification for a message router.

Typically, HL7 V2.x messages are encoded as ASCII text strings with delimiters. HL7 V2.x has few inherent semantic restrictions; the vocabulary to include in the codified elements of the messages is usually subject to negotiation between the parties.

The standard does not define how the messages are sent (directly over TCP/IP, through file transfers, via a serial port, through a Web service, etc.) These are called `low level' or `transport' protocols; while HL7 V2.x sometimes offers guidance in this regard, none of these lower-level protocols is mandatory or normative in the HL7 standard.

How is the HL7 V2.x standard organized? HL7 v2.x is organized into chapters, each of which has a specific purpose or domain.

Chapter 2 defines how to encode and decode messages, whereas the rest of the chapters concentrate on an area or domain of healthcare information addressed by a specific Work Group. The combined output of these Work Groups must be approved by a consensus group with broad representation of the HL7 membership before a version of the standard may be published.

HL7 V2.x defines the context of each field for example, diagnosis - but may leave the decision of whether field contents should be free text or use a standard terminology up to the implementers. That decision is typically agreed upon between the issuer and the recipient of the message.



Membership in a Work Gorup is open to any HL7 member or other party interested in that specific area. Work Groups are responsible for incorporating additions or changes to their respective areas of the Standard.

The final product of the Working Group is a version of the HL7 V2.x standard, of which the most recent version as of this writing is V2.6. Each chapter contains the necessary information to create messages relevant to that chapters domain, as well as appropriate references to the content (such as element definitions) of other chapters.

Table 2 describes the chapters that make up HL7 V2.6

Table 2 - Chapters of Version 2.6

CAP. SCOPE / DOMAIN

01 Introduction

02 Control (Structure of the messages/Conformance)

03 Patient Administration (admission , discharge, transfer)

04 Order Entry (laboratory, pharmacy, etc.)

05 Query

06 Financial Management (Billing / Patient Accounts)

07 Observation Reporting (results sent as identifiable elements - laboratory, imaging, etc.)

08 Master Files

09 Medical Records/Information Management (document management

10 Scheduling

11 Patient Referral

12 Patient Care

13 Clinical Laboratory Automation

14 Application Management

For example, Chapter 10, Scheduling, makes reference to the PID segment, which conveys information about the patient. The PID segment is not defined in Chapter 10; instead the reader is referred to Chapter 3 which defines the PID segment.



15 Personnel Management

16 Claims & Reimbursement

17 Materials Management

How do we read the HL7 V2.x standard? In order to be able to use the standard it is essential to know Chapter 2, Control. Mastery of this chapter will enable you to apply the rest of the standard, which is why a Control Specialist Certification program has been developed for HL7 V2.x.

As mentioned in previous paragraphs, the chapters following Chapter 2 define the elements (message types, trigger events, segments, and fields) required to build messages appropriate to a specific domain of the information system.

Each of these domain chapters typically includes the following parts:

introduction/scope trigger events message definition examples outstanding issues

Figure 1 shows a basic model of an HL7 transaction.

NETWORK

SEND A MESSAGE

System A

System B

RECEIVE A MESSAGE

Trigger event

RECEIVE AN ANSWER

SEND AN ANSWER



Figure 1 - Basic model of transaction The model is quite basic: a trigger event (something that ocurred in the real world) causes System A to send a message. This message is received by System B, which sends a response back to System A.

As a real-life example; when a patient is admitted into the hospital, the patient registration system sends a message to the billing system to inform it of the new patient and request than an account be opened for this episode. This message is received by the billing system, which sends a response message to the patient registration system confirming that the original message has been processed.



COMMUNICATION ENVIRONMENT The HL7 Standard assumes that the communication environment will provide the following capabilities:

Error-free transmission. Applications can assume that they will correctly receive all of the transmitted bytes in the order in which they were sent. This implies that error checking is done at a lower level.

Character conversion. In a case where different machines use different representations (e.g., ASCII-EBCDIC) the communication environment will be expected to convert the data from one representation to the other.

Message Length. HL7 sets no limits on the length of a message. The standard assumes that the communication environment can transport messages of any length necessary.

MESSAGE A message is the atomic unit of data transferred between systems. Figure 2 shows a typical HL7 message.

MSH|^~\&|NSI||LAB||20090627120759||ADTÂ01ÂDT_A01|NSI1|P|2.6 EVN|A01|20090627120759 PID|1|||444-22-2222^^^HC^MR|EVERYWOMANÊVEÊ||19780113000000|F|||2222

HOME STREET^ÂNN ARBOR^^99999 NK1|1|EVERYMANÂDAM|SPO|2222 HOME STREET|555-555-2004 PV1|1|I|301|R|||1436^PRIMARY^PATRICIA^P|1026ÂDMITÂLAN|998ÂTTENDÂA

RON|M|||A|4|A0|N|1026^SENDER^SAM|OB|H0100240|||||||||||||||||ALV||||||||20080123095130|20080123102455

IN1|1|INT|HCPAYOR|HC PAYOR INC Figure 2 - A01 Sample Message

Each message contains: 1. segments 2. fields 3. delimiter characters 4. components

Lets look at these elements of the message in a little more detail.



Segments A HL7 segment is a logical grouping of data fields. Segments of a message may be

required or optional. They may occur only once or they may be allowed to repeat. Each segment is identified by a three character code, known as the Segment ID, and a name. For example, the ADT message may contain, among others, the following segments: Message Header (MSH), Event Type (EVN), Patient ID (PID), and Patient Visit (PV1).

The following table shows the segments that might be transmitted in a typical patient registration message (message type ADT). This is commonly referred to as an abstrat message syntax.

MSH Message Header

EVN Event Information

PID Patient Identifiers and Demographic Data

[PD1] Additional Demographic Data

[{ NK1 }] Patient Next of Kin/Associated Parties

PV1 Patient Visit/Encounter Information

[PV2] Patient Visit Additional Information

[{ DB1 }] Disability Information

[{ AL1 }] Allergy Information

[{ DG1 }] Diagnosis Information

[DRG] Diagnosis Related Group

Segment ID codes beginning with the letter Z are reserved for locally defined segments. Such constructs are useful for the exchange of information not defined by the standard. However, caution must be exercised when using Z segments and other locally defined structures. Well see more about that later.



PLEASE REMEMBER THESE RULES a) If the segment ID appears between square brackets [...] then the segment is optional. b) If the segment ID appears between curly braces {} then the segment may repeat. c) If the segment ID appears between both curly braces and square brackets [{}] then it is both optional and repeating.

Each segment is composed of a number of fields which well discuss later in this unit. The first segment (MSH) identifies the type of message and the trigger event that caused the message to be sent. A real-world event that triggers a message exchange is called a trigger event.

The message types are logical aggregators that assign the same category to a group of events. For example, messages of type ADT will be used to transmit information about all patient registrations and updates. Within the ADT message type we find over 60 different trigger events, such as the admission of the patient, a change in location of the patient, or discharge of a patient. Thus, a message for trigger event A01 indicates that a new patient has been admitted. The A02 trigger event indicates that the patient has changed location, while trigger event A03 indicates that the patient was discharged.

[{ PR1}] Procedures

[{ROL}] Role

[{ GT1 }] Guarantor

[{IN1}] Insurance

[IN2] Insurance Additional Information

[IN3] Insurance Additional Information cert.

[ACC] Accident Information

The relationship between message type and trigger event is one to many. Each message type may be associated with more than one trigger event. However, each trigger event is associated with one and only one message type (and its associated application acknowledgment).



Figure 3 shows an example of transactions between two systems using Chapter 3 messages and trigger events.

Figure 3 V2.x Chapter 3 Transactions

When a patient admission is recorded, a message of type ADT event A01 is sent. Likewise, to report a change of patient location, a message of type ADT event A02 is sent.

In both cases the receiving system returns a message of type ACK (general acknowledgment).

Usually the information in an ADT message type has been entered into the patient administration system and is then transmitted to other systems throughout the organization.

If the patient is subsequently transferred to a new permanent location, an A02 trigger event is used to notify the laboratory of the new location, so the lab will be able to locate the patient when needing to perform a phlebotomy.

System A

ADT^A01

Accept ACK

System B

Trigger Event A01

Trigger Event A02

ADT^A02

Accept ACK

For example, an A01 event can be used to notify the laboratory system that a patient has been admitted and that studies can be requested for the patient. It also contains the patients location, sex, and age.



An abstract message syntax, such as that shown for the ADT message above, defines which segments make up the message, as well as their order, grouping, and optionality. However, the abstract message syntax does not describe the segment content. Two or more segments may be organized as a logical unit called a segment group. As with individual segments, a segment group may be required or optional. A segment group is assigned a name that represents a permanent identifier that may not be changed; unlike an individual segment ID, the name of a segment group generally does not appear in the HL7 message.

Table 4 shows the attributes of the first 18 fields of the PV1 segment, as defined in V2.6: SEQ LEN DT OPT RP/# TBL# ITEM# ELEMENT NAME

1 4 SI O 00131 Set ID - PV1

2 1 IS R 0004 00132 Patient Class

3 80 PL O 00133 Assigned Patient Location

4 2 IS O 0007 00134 Admission Type

5 250 CX O 00135 Preadmit Number

6 80 PL O 00136 Prior Patient Location

7 250 XCN O Y 0010 00137 Attending Doctor

8 250 XCN O Y 0010 00138 Referring Doctor

9 250 XCN B Y 0010 00139 Consulting Doctor

10 3 IS O 0069 00140 Hospital Service

11 80 PL O 00141 Temporary Location

12 2 IS O 0087 00142 Preadmit Test Indicator

13 2 IS O 0092 00143 Re-admission Indicator

14 6 IS O 0023 00144 Admit Source

15 2 IS O Y 0009 00145 Ambulatory Status

16 2 IS O 0099 00146 VIP Indicator

17 250 XCN O Y 0010 00147 Admitting Doctor

18 2 IS O 0018 00148 Patient Type

19 250 CX O 00149 Visit Number

20 50 FC O Y 0064 00150 Financial Class

21 2 IS O 0032 00151 Charge Price Indicator

22 2 IS O 0045 00152 Courtesy Code

23 2 IS O 0046 00153 Credit Rating

24 2 IS O Y 0044 00154 Contract Code

25 8 DT O Y 00155 Contract Effective Date

26 12 NM O Y 00156 Contract Amount

27 3 NM O Y 00157 Contract Period

28 2 IS O 0073 00158 Interest Code

29 4 IS O 0110 00159 Transfer to Bad Debt Code

30 8 DT O 00160 Transfer to Bad Debt Date

31 10 IS O 0021 00161 Bad Debt Agency Code

32 12 NM O 00162 Bad Debt Transfer Amount



33 12 NM O 00163 Bad Debt Recovery Amount

34 1 IS O 0111 00164 Delete Account Indicator

35 8 DT O 00165 Delete Account Date

36 3 IS O 0112 00166 Discharge Disposition

37 47 DLD O 0113 00167 Discharged to Location

38 705 CWE O 0114 00168 Diet Type

39 2 IS O 0115 00169 Servicing Facility

40 1 IS B 0116 00170 Bed Status

41 2 IS O 0117 00171 Account Status

42 80 PL O 00172 Pending Location

43 80 PL O 00173 Prior Temporary Location

44 24 DTM O 00174 Admit Date/Time

45 24 DTM O 00175 Discharge Date/Time

46 12 NM O 00176 Current Patient Balance

47 12 NM O 00177 Total Charges

48 12 NM O 00178 Total Adjustments

49 12 NM O 00179 Total Payments

50 250 CX O 0203 00180 Alternate Visit ID

51 1 IS O 0326 01226 Visit Indicator

52 250 XCN B Y 0010 01274 Other Healthcare Provider

Table 4 PV1 segment definition

Each column in the table defines a specific attribute of the segment: SEQ: Ordinal position of the field within the segment. LEN: Maximum number of characters that the field may contain. DT: Data type defined by HL7. OPT: Field Optionality (R-required, O-optional, C-conditional, X-discontinued, B- maintained for backward compatibility with previous versions) RP #: Repetition, maximum number of occurrences allowed TBL #:Domain of possible values ITEM: an integer number that uniquely identifies the field ELEMENT NAME: the field name Fields A field is a string of characters defined by an HL7 data type. Appendix A of the HL7 V2.x standard provides an alphabetical list of all fields.

Components Depending on its data type, a field can have one or more components. A model of the components of each field in a segment is contained in the chapter of the HL7



standard in which the segment is defined. Figure 4 below, shows the eight components of patient name (data type XPN) as defined in HL7 V2.3.1.

Figure 4

Subcomponents Note that when a field (as defined by its data type) is made up of multiple components, each component itself is assigned a data type. When the data type specifying a component is itself made up of multiple components, each of its parts is called a subcomponent. In the example above none of the components contains subcomponents.

Message delimiters In constructing a message, certain special characters are used. The recommended delimiters are:

Segment Terminator (ASCII 13) Field separator | (ASCII 124) Component Separator ^ (ASCII 94) Subcomponent Separator & (ASCII 38) Repetition Separator ~ (ASCII 126) Escape Character \ (ASCII 92)

With the exception of the Segment Terminator any of these delimiters can be modified by negotiation during the implementation.

3.3.2.5 Patient name (XPN) 00108 Components: ^ ^ ^ ^ ^ ^ ^



Summary A message consists of segments separated from each other by the segment terminator (always ). Each segment consists of fields separated by the field separator (usually |). Each field is composed of one or more components separated by the component separator (usually ^) and each component corresponds to a specific data type. Depending on its data type, a component can contain one or more subcomponents separated by the subcomponent separator (usually &).

The next section will address the data types that define components and subcomponents within fields.

MESSAGE

SEGMENTS

FIELDS

DATA TYPES

COMPONENTS



DATA TYPES Each HL7 element is defined as having a data type; the HL7 V2.x standard defines over 80 different data types. A data type may have a single component or may be defined as a set of components. The purpose of a data type is to constrain the contents of a field. Starting in HL7 Version 2.5, each data type has a defined maximum length. In the segment attribute table (table 4 of part 1) the data type defining the structure of each field is indicated in the DT column. Categories Data types tend to fall into logical categories:

Alphanumeric (ST TX FT SRT) Numerical (CQ MO NM SI SN) Identifiers (ID IS HD EI RP PL PT VID) Date / Time (DT TM TS) Coded values (CE CF CK CX XCN CNE CWE) Generic (CM) Demographic (AD PN TN XAD XPN XON XTN SAD FN) Waveforms (CD MA NA ED) Price (CP) Finance (FC) Master File tables (DLN JCC VH) Medical records(PPN) Temporary series (DR RI SCV TQ)

We wont review all V2.x data types in this unit, only some of the more common ones.



Alphanumeric Data Types Alphanumeric data types may contain any ASCII printable character. Table 5 shows these data types and their characteristics.

Table 5 - Alphanumeric data types

Data type Characteristic

ST - String Left justified, trailing spaces optional. Used for short strings of



The output displayed by the receiving system would look something like this:

Observation:Observation:1.1. The cardio The cardio mediastinalmediastinal

silhouette is now within silhouette is now within normal limits.normal limits.

2.2. Lung fields show minimal Lung fields show minimal ground glass appearance.ground glass appearance.

Data Types for Numbers and Quantities The data types in the following table are used to express numbers and quantities.

Table 6 - Numeric and quantity data types

Data type Characteristic

CQ - Composite Quantity with units

This data type has two components, the first for the amount and the second for the units of measure. ^ For example, to express that a person weighs 123.7 Kilograms: |123.7^kg|

MO - Money (Money)

This data type is specifically for fields expressing currency amounts and has two components. The first one is the amount and the second is the denomination of currency. ^ For example, to specify that a medicine cost is $ 99,50 ($=U.S. dollars) : |99.50^USD|



Data type Description

SI - Sequence Identifier

This data type is a positive whole number. It is used to identify the ordinal position of a repeating segment within a message.

SN - Structured Numeric

This data type is used to express clinical results with some type of qualifier. Sets of values are indicated with a comparator and a separator/suffix (Comparators can be =, >, =, ^10000| (greater than 10000) Ex |^128^-^256| (equal to a range between 128 and 256) Ex |^1^:^256| (titration of 1:256 - serology) Ex |^3^+| (occult blood positivity)



Data Types for Times and Dates


DT (Date) This data type is specifically for expressing dates. The format is YYYY[MM[DD]]. The portions in square brackets are optional. Thus, the group month-day is optional and the day is optional if the month is specified. For example, to express October15, 2006: 20061015; to express May 2007: 200705.

TM (Time)

This data type is used to express time, without date, in the following format: HH[MM[SS[.S[S[S[S]]]]]][+/-ZZZZ] The digits symbolized by HH indicate hours, MM indicate minutes and SS.SSSS indicate seconds and optional fractions of seconds. +ZZZZ or ZZZZ optionally designates the time zone offset from UTC (formerly Greenwich Mean Time). Lets see some examples: |235959+1100| 1 second before midnight in the time zone located at GMT+11 hours. |0800| eight AM, local time. |093544.2312| 44.2312 seconds after 9:35 AM, local time. |13| 1 PM, local time.

TS - Time Stamp (Time/date)

This data type combines date and time. Its structure is as follows: YYYY[MM[HH[MM[SS[.S[S[S[S]]]]]][+/-ZZZZ]]^

Example: |19760704010159| indicates 1:01: 59 A.M. on July 4, 1976



Data Types for Identifiers


ID - value from HL7 defined table

This data type indicates that the value is from a HL7 defined table. When we encounter a field with this data type we must defer to the specified table (TBL#) for allowable values and their definition. For example, there is a table with the values: Yes or No. These values are specified in the table 0136 yes/no and the possible values include Y (YES) and N (NO).

The table may be extended, but the values published by HL7 are normative and may not be redefined. They are expected to be recognized by communicating systems.

IS - value from user defined tables

This data type indicates that the value is from a USER defined table. For example, Sex table VALUE Description

F Female M Male O Other U Unknown

These tables are defined in each implementation. HL7 may suggest values, but communicating systems may use any set of values they deem appropriate.




HD - Hierarchic Designator

This type of identifier is usually for applications and assigning authorities. Its structure is: ^^

It consists of three components where the first is an entry from a user-defined table, and the second is a string formatted according to the rules of the ID type indicated in the third component.

If the designated entity is a locally defined organization, only will be included. Example GHH_CLINIC. If the organization identifier is public, the last two components are used. Universal ID type (ID) is the type of domain Identifier for the universal ID. Examples of Universal ID type are: DNS, GUID, etc. Example: ^HL7.org^DNS Universal ID (ST) is an identifier that is unique within the domain of the Universal ID Type.

EI - Entity Identifier

This data type expresses identifiers assigned by an application. It consists of 4 components; the first one is the identifier for the entity, and the remaining components identify the authority assigning the identifier.

Here is its structure: ^^ ^ Examples: Accession Number (lab), Order Number, Inpatient Encounter Number, Authorization Number, Facility Identifier, etc. Example: |125658^HIS_HIBA| designates ID 125658 assigned by the hospital information system of the Italian Hospital of Buenos Aires




PL - Patient Location

This data type is used to specify the location of a patient within an institution. It can also have other uses; for example, the location of a doctor's office or a nursing station. The components, as of HL7 V2.3.1, are as follows: ^^^^^^^^

Note that this data type does not present the information in the logical order one might expect (from the most generic to the most specific component) which would be: person location type, facility, building, floor, point of care, room, bed. This is due to the HL7 rules for extending data types. Over time additional components were added this data type; based on the rules each addition occurred to the end of the data type.

Person location type and location description are intended to describe the kind of location.

Location status can be used to express the state of a bed or room for example in a room census (occupied, reserved, free).

Example: |2101 IM^210^2101^GHH^^^GHH^2^GHH BED- BUILDING 10| This indicates that the patient is in the department of Internal Medicine (IM) in room 210, bed 2101 of the second floor of Building 10 of Good Health Hospital




PT - Processing Type

Indicates if the message is to be processed in debugging, production, or training mode and whether regular processing or special processing (restoring from archive, initial load, etc.) is being used

This data type is used in MSH-11-Processing ID. Its structure is: ^ The first component has three possible values - D: Debugging, P: Production, T: Training. The second component has four possible values - A: Archive; R: Restore from archive; I: Initial load; not present/blank: default, regular processing) Example |P| indicates that the sending interface is in production mode and that the data is intended to be processed normally



Data Types for Coded Values HL7 establishes these data types for those elements that need to be codified. Among them we find:


CE - coded element

This data type transmits codes with a text or description associated to the code. Contains 6 components. The first three components specify the concept in one coding system. The second three components allow the same concept to be expressed using an alternate coding system. Its structure is:^^^^^ Within the first triplet, the first component contains the code, the second component contains a description of that code and the last component identifies the coding system. The structure of the second triplet is the same. Example: |F-11380^CREATININE^I9^2148-^CREATININE^LN|

RECOMMENDATION: USE CNE or CWE data type. CE is retained for backward compatibility

CNE - coded with no exceptions

This data type indicates that the values in this field must be selected from the coding system designated in the HL7 element definition without exception. The designated coding system may not be locally extended and its codes may not be redefined.

Similar to CE but with versioning and original text (original text is meant for including the text that the physician actually entered into the system).

Its structure is: ^^^^^^



with check digit patient or a person identifier. It has the following format: ^ ^ ^ ^ ^ ^ ^ ^ For example, the patient with medical record number W1234 assigned by Good Health Hospital would have the following information in field PID-3, which is of data type CX: |W1234^^^GHH^MR|



Data types for Addresses, Persons, Organizations, and Phone Numbers


XAD - extended address

This data types is used to express addresses; its structure is as follows: ^< other designation (ST)>^ ^ ^^ ^^^ ^^ ^^ ^ For example to indicate building number 1058 on Healthcare Drive in Ann Arbor, Michigan, USA, with zip code 99999: |1058 Healthcare Drive^^ANN ARBOR^MICHIGAN^ 99999^USA|

XPN - extended person name

This data type is used to identify patients and persons. The format is: ^^ ^^^ ^^ ^^ ^^ ^^ The following example refers to Charlie C. Chopper, MD: |Chopper^Charlie^C^^MD|

XON - extended composite name and ID for organizations

This data type is used to identify an organization and its associated ID. Its format is: ^ ^ ^ ^ ^ ^ ^ ^ ^ This data type is similar to XCN but for organizations. Note that it includes an ID number in the third component. See also data type XCN, used for staff and practitioners.



XTN - extended telephone number

This data type is used to express contact information such as telephone numbers; its format is:

[NN] [(999)]999-9999[X99999][B99999][C any text] (ST) ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^

Data Types for Multimedia Objects


ED - encapsulated dates

This data type is used to transmit encapsulated data. Instead of sending a pointer to the data, you can send the actual data encoded as MIME (BASE 64). Format: ^^ ^^

RP - Reference Pointer

This data type is used to transmit information on multimedia objects stored in another systems repositories. Its structure is: ^^ ^ The first component indicates the resource location. The second identifies the application responsible for the information. The third and fourth components define the type of information (type and subtype). For example: Image / JPEG

Uses: To let the receiving applications know the address for accessing objects stored by the sender application: DICOM objects, PDF, JPG, HTML, etc. | http://www.hl7.org/image/about2.gif ^HL7^image^GIF|

We have seen the most commonly used HL7 data types, including several examples. Numerous other examples will be provided throughout the course.



Lets examine a few more important concepts before we conclude this introduction to HL7 Version 2.x.



MESSAGE PROCESSING RULES Sending Rules THE TEN OUTBOUND HL7 COMMANDMENTS 1. Encode each segment in the order specified in the abstract message format 2. The segment ID is required to identify EACH segment 3. Precede each data field with the field separator 4. Encode the data fields in the order specified in the segment definition table 5. Data fields not present require no characters. 6. Data fields present but null are encoded with (double quotes) 7. If components, subcomponents, or repetitions at the end of a data field are not present, their separators may be omitted 8. If no more fields are present in a segment, the data field separators may be omitted 9. Padding doesnt violate the rules, but its not good practice and leads to unnecessary processing and message length. 10. End each segment with the REQUIRED segment terminator (1) Abstract Message Format

(4) Segment Definition Table

(5) - (6) PID|||222-666-7777||CHOPPER^CHARLIE^C||...

(7) Nightingale^Nancy^^^^^ = Nightingale^Nancy

(8) PID|||222-666-7777||CHOPPER||||| = PID|||222-666-7777||CHOPPER

(10) MSH PID



Receiving Rules THE TWO INBOUND HL7 COMMANDMENTS 1. IGNORE THE UNEXPECTED: segments, fields, components, subcomponents, and repetitions of a field that are present but not expected. THEY ARE NOT YOUR PROBLEM 2. IF ITS NOT THERE, ASSUME ITS NOT PRESENT: Treat segments, fields, components, subcomponents, and repetitions that are expected but not sent as not present take no action.

If the message contains something you werent expecting: ignore it. If something is not there and you were expecting it: assume its not present, and respond accordingly. Required fields (fields required and not present) should be identified in the ERR segment of an acknowledgment message. Acknowledgment messages are discussed briefly below. Acknowledgement of Message Reception (ACK) In figure 1 we saw that in a basic HL7 transaction, a trigger event causes System A to send a message. This message is received by System B, which sends a response to System A. The response from System B is an acknowledgment message. One of two modes of acknowledgment may be in use:

1. Original processing mode 2. Enhanced processing mode

Original mode In the Original processing mode, the reception, storage, and processing of messages are all acknowledged by a single acknowledgment message at the application level. The rationale is that it is not enough to know that the underlying communications system guaranteed delivery of the message. It is also necessary to know that the receiving application processed the data successfully.



The acknowledgment may contain data that are of interest to the system that initiated the exchange. For example, if a patient care provider wants to order a lab test, it may send a message of type ORM to a lab application identifying the patient, the test ordered, and other information about the order. The lab application will acknowledge the order when it has processed it successfully. It will do so by means of an application acknowledgment message of type ORR that includes an order status and filler order number in the ORC segment. The receiving system may also acknowledge the order after placing it in an input queue, expecting to fully process the order into its database at a future time. The only assumption is that the input queue is maintained at the same level of the integrity as the database.

Enhanced mode In Version 2.2 HL7 extended the standard to include Enhanced Mode acknowledgment. Here a distinction is made between accept and application acknowledgment, as well the conditions under which each is required. With a positive accept acknowledgment, the receiving system commits the message to safe storage in a manner that releases the sending system from the need to resend the message.



After the message has been processed by the receiving system at the application level, an application acknowledgment may be used to return the new status to the sending system. This ACK may be of three types:

1. OK Answer: (AA): the message was processed successfully

2. Reject ANSWER : failed to process (REJECT) the message for reasons unrelated to its content or format (AR)

3. ERROR Message: Message of error (AE). You are now ready to perform the practice exercises.

hl7

Documents

hl7 version

asociacin hl7 argentina

hl7 mission

x unit

introduction unit

elearning course hl7

hl7 v3 data types

entries unit