Introduction to HL7

Bhushan Borole.Date : 27-Sep-2012

What, Why, When HL7? Need of HL7 HL7 in Healthcare Management Systems Message Message encoding schemes V2 and V3

Agenda

What, Why, When HL7?What, Why, When HL7? Need of HL7 HL7 in Healthcare Management Systems Message Message encoding schemes V2 and V3

• Protocol for data exchange between computer systems in health care environments.

• Defines messages as they are exchanged and the procedures used for exchanging them.

• Refers to the top layer (Level 7) of OSI/ISO layer model (see next slide).

• ANSI standard since 1997 most widely used in USA, Canada, Australia, New Zealand and Japan.

What is HL7 (Health Level Seven)?What?

What is HL7 (Health Level Seven)?

HL7 contains message standards covering: •Patient Administration•Orders for Clinical Services and Observations, Pharmacy, Nutrition and Supplies order entry•Patient Accounting and Charges•Observation Reporting•Document Management Services•Appointment Scheduling•Laboratory Automation•Personnel Management•…

What is HL7 (Health Level Seven)?

Application Type of network communication(e-mail, telnet, FTP, HL7)

Data conversion, encryptionPresentation

SessionControlling dialogues (sessions). Establishing, terminating and restarting connection.

Transport

Network

Data-Link

Physical

Network adapter: Ethernet, wireless Ethernet

Physical link: Ethernet cable, RS-232, optical link

TCP/IPRouting, reliable data transport between two computers

What, Why, When HL7? Need of HL7Need of HL7 HL7 in Healthcare Management Systems Message Message encoding schemes V2 and V3

A Complete Solution Interoperability Open System

“Interoperability is the ability of two or more systems or components to exchange information and to use the information that has been exchanged.• ‘Functional’ interoperability is the capability

to reliably exchange information without error.

• ‘Semantic’ interoperability is the ability to interpret, and, therefore, to make effective use of the information so exchanged.”

• ‘Process’ Interoperability makes system Integral to (healthcare delivery) process, work flow.

Interoperability…

Interoperability Definition - (U.S. Executive Order)

“’Interoperability’ means the ability to communicateand exchange data accurately, effectively, securely,and consistently with different information technologysystems, software applications, and networks invarious settings, and exchange data such that clinicalor operational purpose and meaning of the data arepreserved and unaltered.”

- President Bush, 22 August 2006

A Very Brief History of HL7

� HL7 = Health Level 7

� 2.X

� Founded in 1987- � 2.0 was created in 1988 –

� 2.1 ->2.3 1990-1999

� versions 2.1, 2.2, 2.3, 2.3.1, 2.4, 2.5, 2.5.1 and 2.6.

� 3.0

�

EHR Interoperability Model Objectives

1. Establish a common reference for EHR Record Interoperability - Statement of requirements2.Gain industry consensus via HL7’s (ANSI accredited) open, standards development process3.Establish current and forward benchmarks to achieve persistent legal EHR Records4.Establish testable conformance criteria for validation of EHR Records.5.Specify EHR Record in context of its flow and lifecycle including Preservation of semantic meaning.6.Specify EHR Record in context as immediate record (documentation) of Health(care) delivery process7.Specify Common EHR Record Unit, sufficient to document all healthcare Acts/Actions Establish as Complementary companion to EHR-S Functional Model

Proprietary system model:

• Closed-system model is easier to design and initially costs less to implement• Greater reliability on single vendors • More reliance on specific applications and technologies

Adhering to a standard protocol is called "open system architecture". Anybody can interface with an open system using appropriate protocols, independent of its vendor. When using HL7, the interface allows for numerous systems to be added to a single HL7 feed.

What, Why, When HL7? Need of HL7 HL7 in Healthcare Management SystemsHL7 in Healthcare Management Systems Message Message encoding schemes V2 and V3

HL7 in HealthcareManagement System

Outbound Vs Inbound� Inbound – Data coming to the application� Outbound – Data being exported out of application.

� So all data being passed from MaximEyes SQL EHR to external application is called Outbound and all data being passed into MaximEyes SQL EHR is called Inbound.

ConnectEngineSpecification

Tool (e.g., nHapi)

HL7Utility

ConnectEngine Utility

HL7Messages • Profile based• Structurally correct• Validated• Varied• Descriptive• Suitable basis for conformance testing

External Application

MaximEyes SQL EHR

Inbound ...

ACK

� Every time an application accepts a message and processes the data it sends an Acknowledgement back to the sending application. The important part of an ACK is that it means the other systems has not only received but processed the message that was sent.

� NACK is a negative ACK that contains an error in that is sent back to the sending application.

What, Why, When HL7? Need of HL7 HL7 in Healthcare Management Systems MessageMessage Message encoding schemes V2 and V3

What’s the Message

� Messages are the base format used for all HL7 communication

� Data formatted with HL7 Encoding Rules and Message Construction Rules.

� A message is the atomic unit of data transferred between systems. It is comprised of a group of segments in a defined sequence.

� Each message has a message type that defines its purpose.

� “Z”

Message Type

� Type of message describes the content – What part of Message

� Defines the purpose for the message being sent � Ex. ADT Message type is used to transmit portions of a

patient's Patient Administration (ADT) data from one system to another.

� Refers HL7 Table 0076 - Message type

� Position in Message - MSH field 9.1

Trigger Event

� Type of message describes the content – Why part of message

� There is a one-to-many relationship between message types and trigger event codes.

� explicit set of conditions that initiate the transfer of information

� Refers HL7 Table 0003 - Event type

� Position in Message - MSH field 9.2� A patient is registered(A04)

� An appointment is booked (S12)

Message structure

ADT^A04 Register a patientADT^A08 Update patient informationADT^A01 Admit/visit notificationADT^A23 Delete a patient recordMFN^M02 Master file - staff practitionerMFN^M05 Patient location master fileORU^R01 Unsolicited transmission of an observation messageVXU^V04Unsolicited vaccination record update

Delimiters

Character Description

<CR> or 0x0D Segment Delimiter/Terminator

| Field(Composite) delimiter

^ Sub-field (Component) delimiter

& Sub-sub field (subcomponent) delimiter

~ Repetition delimiter

\ ESCAPE Character

Special characters that separate one composite in a segment from another, or separate one sub-composite from another.

Character Escape Sequence& \T\

^ \S\

| \F\

~ \R\

\ \E\Hexadecimal character xx \Xxx..\

Segments� Each line in a message is referred to as a Segment. � Segments are units that comprise messages. Hence each Segment

has its own semantic purpose or function� There are over 120 types of Segments that can be used.� A segment is defined as a sequence of fields� Examples of HL7 message segments:

• MSH - Message Header information about a message

• EVN - Event Type event information

• PID - Patient Identification information about a patient

• NK1 - Next of Kin information about the patient's other related parties

• OBR - Observation Request information about an order

• OBX - Observation Report information about a result

� “Z”

More on segments

•Segments and segment groups A segment is a logical grouping of data fields. •Segments of a message may be required or optional.•Each Segment provides a specific type of data to be sent.•Some segments such as OBX, NTE, NK1, or AL1 can be repeating. •An example is the NK1 segment which consists of “next of kin/associated parties" will repeat several times if a person has several next of kin relationships

Message structure

HL7 Message Example

Fields (Composites)� A field is a string of characters.� Fields for use within HL7 segments are defined by HL7.� HL7 does not care how systems actually store data within

an application. When fields are transmitted, they are sent as character strings.

� Fields are the specific fields of a segment. The fields can be either a primitive data type such as a string number, alpha or alphanumeric or it can be made up of other composites (components).

� Null. Any existing value for the corresponding data base element in the receiving application should be deleted. This is symbolically communicated as two double-quotes between the delimiters (i.e., |""|)

Fields (Continued..)� Have constraint for –

• Position - Ordinal position of the data field within the segment

• Data type - Basic building block used to construct or restrict the contents of a data.

• Optionality Whether the field is required, optional, or conditional in a segment.

Value Description

R Required

O Optional

C Conditional

X Not used with this trigger event

B Backward compatible

Repetition - Whether the field may repeat. Maximum length - Max number of characters that

one occurrence of the data field may occupy. Fields are restricted for structure by HL7 defined

Datatypes. Count is 160+ for 2.5.1

Data Exchange

•No data exchange, messaging and communication technologies are determined by HL7.

•Frequently used protocols in HL7 implementations:

MLLP (Minimal Lower Layer Protocol)

TCP/IP based

SOAP (Simple Object Access Protocol) – XML based

Batch Files – messages in text files exchanged by FTP and SMTP or offline via a tape or a diskette

What, Why, When HL7? Need of HL7 HL7 in Healthcare Management Systems Message Message encoding schemesMessage encoding schemes V2 and V3

Message encoding schemes

HL7 uses two encoding schemes:• HL7 ER, also known as 'traditional' HL7 format;

used for HL7 versions 2.x

• XML primary encoding scheme for HL7 v 3.0

can be used for HL7 v 2.x in environments where sender and receiver both understand XML

Message encoding schemes

HL7 ER

Sample message encoded in HL7 ER format

Message encoding schemes

XMLSample message encoded using XML scheme

<!DOCTYPE ACK SYSTEM "hl7_v231.dtd">

<ACK>

<MSH>

<MSH.1>|</MSH.1>

<MSH.2>^~\&amp;</MSH.2>

<MSH.3>

<HD.1>LAB</HD.1>

<HD.2>foo</HD.2>

<HD.3>bar</HD.3>

</MSH.3>

<MSH.4><HD.1>767543</HD.1></MSH.4>

<MSH.5><HD.1>ADT</HD.1></MSH.5>

<MSH.6><HD.1>767543</HD.1></MSH.6>

<MSH.7>19900314130405</MSH.7>

...

...

</MSH>

Message encoding schemes

HL7 is not Plug & Play•Basic reasons – Missing Fields, Same Data in Different Fields, Same Data in Different Formats, Different Versions, Missing Values (including mandatory fields), Invalid Segment Grammar•Not all data types may be coded using standard HL7 format. For these types vendor specific messages and fields must be used.•When deploying system utilizing HL7 interface, it still must be adapted to hospital-specific requirements.

What, Why, When HL7? Need of HL7 HL7 in Healthcare Management Systems Message Message encoding schemes V2 and V3V2 and V3

HL7 V2

• Not “Plug and Play” – it provides 80 percent of the interface and a framework to negotiate the remaining 20 percent on an interface-by-interface basis• Historically built in an ad hoc way because no other standard existed at the time• Generally provides compatibility between 2.X versions• Messaging-based standard built upon pipe and hat encoding• In the U.S., V2 is what most people think of when people say “HL7?

HL7 V3• Approaching “Plug and Play” – less of a “framework for negotiation”• Many decades of effort over ten year period reflecting “best and brightest” thinking• NOT backward compatible with V2• Model-based standard built upon Reference Information Model (RIM) provides consistency across entire standard• In the U.S., when Clinical Document Architecture (CDA) is what most people in the U.S. think of when people say “HL7 V3?

The difficulties with HL7 3.0 :

1.Despite the length of time it has been under development, the 3.0 standard has not yet been clearly defined.2.Very few health-care facilities have migrated to version 3.0, since this version is not compatible with version 2.X. Applications that support version 3.0 would also need to support version 2.X.3.Creating an interface between version 2.X and version 3.0 would be difficult and expensive.

Because of these difficulties, version 2.X remains the standard that is used by both healthcare facilities and vendors.

•HL7 interfaces need to be persistent•Configuration and change management•Licensing concerns•Database and storage issues:

HL7 interface should not be contained on a mobile device