Introduction to hl7 v2

July 13, 2015 Page: 1 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
July 13, 2015
Introductions and Course
Overview

SESSION OVERVIEW
• ABOUT ME
• SCOPE AND LEARNING OBJECTIVES
• ABOUT YOU
• COURSE SYLLABUS
• COURSE MATERIALS
• Q&A

About Me
• I have been, and continue to be,
an active member of HL7 since
1991.
• I currently co-chair the HL7
Modeling and Methodology
Workgroup.
• My HL7 History:
o Chaired the HL7 Education
Workgroup from 1996 to 2010.
o Received the HL7 volunteer of
the year award in 1997
o Served on the HL7 Board of
Directors from 2000 to 2005
o Board appointed member of the
HL7 ARB since 2001and ARB
modeling facilitator since 2012
o Received the HL7 Fellowship
award in 2012
AbdulMalik Shakir
President and Chief Informatics Scientist
Hi3 Solutions | your healthcare standards conformance partner
3500 West Olive Ave, Suite # 300, Burbank, CA 91505.

Scope and Learning Objectives
• Scope - an introduction to HL7’s health information
exchange standards:
 HL7 Family of Standards
 HL7 v2 Messaging (v2)
 HL7 v3 Messaging (v3)
 HL7 v3 Clinical Document Architecture (CDA)
 HL7 Compliance and Conformance Specification
• Learning Objectives –
 To better understand the business case for HL7,
 Gain familiarity with the full suite of HL7 standards,
 Receive an in-depth overview of the HL7 information exchange standards

About You: Show of Hands Please
 Information Systems /
Information Technology
 Healthcare Information
System Data /
Databases
 Health System
Interface / Information
Exchange
 Health Level Seven
(HL7)
 Health Level Seven v2
 Health Level Seven v3
 Clinical Document
Architecture

Course Topics
HL7 v2 Messaging HL7 v3 Messaging
HL7 Clinical
Document
Architecture
HL7 Family of
Standards
HL7 Compliance
and Conformance

Course Agenda
July 13, 2015 July 14, 2015
 09:00 – 09:30 Introductions and
Course Overview
 09:30 – 10:30 Health Level Seven
and the HL7 Family of
Standards
 10:30 – 10:45 Break
 10:45 – 12:00 HL7 v2 Abstract
Message Definition
 12:00 - 12:30 Break
 12:30 – 02:00 HL7 v2 Message
Construction Rules
 02:00 - 02:15 Break
 02:15 – 03:30 Local Extensions and
inter-version
Compatibility
 03:30 – 04:00 HL7 v2 Retrospective
 09:00 – 09:30 HL7 v3 History and
Rationale
 09:30 – 10:30 HL7 v3 Development
Frameworks and
Architectures
 10:30 – 10:45 Break
 10:45 – 12:00 HL7 v3 Messaging
Artifacts
 12:00 - 12:30 Break
 12:30 – 02:00 HL7 v3 Clinical
Document Architecture
 02:00 - 02:15 Break
 02:15 – 03:30 HL7 Standards
Compliance and Profile
Conformance
 03:30 – 04:00 HL7 v3 Retrospective

Course Materials
https://drive.google.com/folderview?id=0B-
3JvLjUn5CCfk84VzNqZFY5U2NCbV95WHNNWGp0QWFIWDhZcGh1NzVnVUptZEZvNTlxYkE&usp=sharing

Questions

Hi3 Solutions
3500 W. Olive Ave, Suite
300
Burbank, CA 91505
ww.hi3solutions.com +1 800 918-
6520

July 13, 2015
Health Level Seven (HL7)
and the HL7 Family of Standards

SESSION OVERVIEW
• HEALTH INFORMATION EXCHANGE STANDARDS
• HISTORY OF HEALTH LEVEL SEVEN
• HL7 FAMILY OF STANDARDS
• HL7 HEALTH INFORMATION EXCHANGE STANDARDS
• SESSION RETROSPECTIVE

Electronic Health Information Exchange
PharmaciesPhysicians
Testing Organizations
Lab/Images
Hospitals
Payors
Employers
County/Community
Entities
Patients/Consumers
Government
Medicare/Medicaid
Lab results
Patient Data
Orders
Results
Images
Eligibility
Referral Process
Claim Status
Claims/Prescriptions
Referral Process
Claim/Status
Health Information
Insurance Updates
Eligibility
Medical Records
Enrollment
Mental Health
Family Planning
Medical Society
Public Health

Health Information Exchange
Effective, meaningful health information exchange
requires that all parties involved in information
exchange adhere to predetermined transaction
formats, usage constraints, and encoding rules.

Healthcare
Information
System
HL7
HL7
HL7, X12N
HL7, X12N
HL7
HL7
DICOM
IEEE MIB,
ASTM
X12N / HL7 (Non-US only)
X12N
NCPDP
Healthcare Data Interchange Standards

Leading U.S. Healthcare Data Interchange SDOs
IEEE
Institute of Electrical and Electronic
Engineers
NCPDP
National Council for Prescription
Drug Programs
X12N
Insurance Subcommittee of X12
ASTM
American Society for Testing and
Materials
DICOM
Digital Imaging and
Communications in Medicine
HL7
Health Level Seven

IEEE
Instrumentation communication
standards and generalized information
interchange standards
NCPDP
Standards for communication of
prescription, billing, and other pharmacy
material
X12N
Standards for exchange of healthcare
insurance and billing information
ASTM
Lab reporting standards and standard
guide for content and structure of
computer-based patient records
DICOM
Standards for exchanging digital
radiology images
HL7
Inter-application interoperability
standards for healthcare
Leading U.S. Healthcare Data Interchange SDOs

HL7 and X12N
 HL7 and X12N are standards
development organizations
accredited by the American
National Standards Institute
(ANSI).
 Each organization adheres to a
strict and well-defined set of
operating procedures that
ensures consensus, openness
and balance of interest.
 HL7 develops standards that
enable disparate healthcare
applications to exchange key
sets of clinical and
administrative data.
 X12N develops specification
that enable the electronic
interchange of healthcare
insurance and claims
processing data.
HL7
Clinical / Administrative
X12N
Insurance / Billing

An X12N Data Interchange Scenario
User Interface
Program
Module
Dataset
Outbound
Transformation
Inbound
Transformation
User Interface
Program
Module
Dataset
Outbound
Transformation
Inbound
Transformation
B to A
Transformation
A to B
Transformation
Patient Billing
Application
System
Claims Processing
Application
System
Patient Billing
Application
System
Claims Processing
Application
System

User Interface
Program
Module
Dataset
Outbound
Transformation
Inbound
Transformation
User Interface
Program
Module
Dataset
Outbound
Transformation
Inbound
Transformation
B to A
Transformation
A to B
Transformation
Order Entry
Application
System
Laboratory
Application
System
Order Entry
Application
System
Laboratory
Application
System
An HL7 Data Interchange Scenario

Reaching the Limits of Application
Interfaces
Lab
Order Entry ADT
Pharmacy
Radiology
Decision
Support
Electronic
Health Record
Administrative
Systems
?
Enterprise
Systems
?
External
Systems
?

HIE Standards: Why
• The number of interfaces between N systems is given by the formula (N2-N)/2.
• Linking 2 systems only needs 1 interface, (22 – 2) / 2 = 1;
• Linking 6 systems needs as many as 15 interfaces, (62 – 6) / 2 = 15
• The benefits of using standard increase rapidly with the number of systems involved.

2 3 4 5 6 7 8 9 10 11 12 13 14 15
W/O HL7 1 3 6 10 15 21 28 36 45 55 66 78 91 105
With HL7 2 3 4 5 6 7 8 9 10 11 12 13 14 15
0
20
40
60
80
100
120
Interfaces
Nodes
Interfaces Requirements
With STD
W/O STD
HIE Standards: Why
Tolerable Painful Intolerable

User Interface
Program
Module
Dataset
Outbound
Transformation
Inbound
Transformation
User Interface
Program
Module
Dataset
Outbound
Transformation
Inbound
Transformation
B to A
Transformation
A to B
Transformation
Order Entry
Application
System
Laboratory
Application
System
Order Entry
Application
System
Laboratory
Application
System
An HL7 Data Interchange Scenario

History of Health Level Seven

 Health Level Seven International (HL7) is a not-for-profit, ANSI-accredited
standards developing organization founded in 1987, dedicated to providing a
comprehensive framework and related standards for the exchange, integration,
sharing, and retrieval of electronic health information that supports clinical
practice and the management, delivery and evaluation of health services.
 HL7's 2,300+ members include approximately 500 corporate members who
represent more than 90% of the information systems vendors serving healthcare.

7 Application
What does “HL7” stand for?
“Level Seven” refers to the highest level of the International
Standards Organization’s (ISO) communication model for
Open Systems Interconnection (OSI) - the application level.
ISO-OSI Communication Architecture Model
1 Physical
2 Data Link
3 Network
4 Transport
Communication
5 Session
6 PresentationFunction

EARLY HISTORY OF HEALTH LEVEL SEVEN
• The HL7 Working Group has met approximately every three to four months
since March 1987.
• In the initial three meetings, a Version 1.0 draft Standard was prepared
covering the overall structure of the interfaces, ADT, order entry, and
display-oriented queries.
• HL7 v.1 was only used for a proof of concept implementation and served to
define the content and structure of the standard. This draft was presented
to a plenary meeting of the overall group in Tyson’s Corner, VA, on October
8, 1987.
• Version 2.0, included billing; it was prepared subsequent to Plenary I in
Tyson’s Corner and presented at Plenary II in Tucson, AZ in September
1988.
• Although targeted to be the first release for actual use in production, HL7
2.0 served primarily to permit the implementation of a demonstration of the
standard and was implemented in only a few settings.
• Version 2.1 was published in June 1990, and included laboratory results
reporting based on the ASTM E1238 specification.
Source: http://www.ringholm.com/docs/the_early_history_of_health_level_7_HL7.htm

Implications of ANSI Accreditation
• Health Level Seven is a Standards Development Organization
(SDO) accredited by the American National Standards Institute
(ANSI).
• Such accreditation, coupled with HL7’s own procedures, dictates
that any standard that is published by HL7 and submitted to ANSI for
approval be developed and ratified by a process that adheres to
ANSI’s procedures for open consensus (www.ANSI.org).
• Two of the most important components of these procedures are
openness and balance of interest.
• Openness means that anyone who is materially affected by the
proposed standard must be allowed to participate in its development
and/or the process by which it is ratified (voting).
• Membership within HL7 cannot be a criterion for this participation,
although ANSI allows standards developing organizations to charge
an administrative participation fee to non-members who wish to
participate.

HL7 Board
()
and Workgroup Committees
 Architectural Review Board
• Arden Syntax
• Attachments
• CCOW
• Clinical Decision Support
• Clinical Genomics
• Clinical Guidelines
 Clinical Research Outreach Committee
• Community Based Health Services
• Conformance
• Control/Query
 Education
• Electronic Health Records
• Financial Management
• Government Project
• Imaging Integration
 Implementation
 International Affiliates
• Java
• Laboratory
• Laboratory, Automated, and Testing
 Marketing
• Medical Records/Information Management
• Medication
• Modeling and Methodology
• Orders/Observations
 Organization Review Committee
• Patient Administration
• Patient Care
• Patient Safety
• Pediatric Data Standards
• Personnel Management
 Process Improvement
 Publishing
• Regulated Clinical Research Information Mgmt.
• Scheduling and Logistics
• Security and Accountability
• Structured Documents
 Technical Steering Committee
• Template
• Vocabulary
• XML

HL7 International Affiliates
April 08, 2009Informatics Standards & Interoperability31 of 55
Canada
New
Zealand
Finland Germany
Netherlands
Japan
United States
United
Kingdom
India
Taiwan
China
Czech Republic
Mexico
France
Argentina
Brazil
Australia
Denmark Greece
Ireland
Italy
Spain
Sweden
Switzerland
South
Korea
Turkey
Uruguay
Singapore
Romania
CroatiaAustriaColombia
Chile
Puerto Rico
Russia
Pakistan
Bosnia and
Herzegovina

32
HL7 Membership
•Worldwide
•1800 organizations and1000+ individuals
Europe
45%
Asia/Oceania
15%
North America
32%
Other
8%
2007 figures. Based on the “average 3 individuals per org rule”

33
Membership Location
2007 figures. Based on the “average 3 individuals per org rule”

HL7 Family of Standards

• Fast Healthcare Interoperability Resources Specification (FHIR)
FHIR is a next generation standards framework that combines the best features of HL7’s Version 2, Version 3 and CDA® productlines while leveraging the
latest web standards and applying a tight focus on implementation FHIR solutions are built from a set of modular componentscalled “Resources”. These
resources can be easily assembled into working systems that solve real world clinical and administrative problems.
• Clinical Document Architecture
The HL7 Version 3 Clinical Document Architecture (CDA) is a document markup standard that specifies the structure and semantics of "clinical documents"
for the purpose of exchange between healthcare providers and patients. A CDA can contain any type of clinical content -- typical CDA documents would be
a Discharge Summary, Imaging Report, Admission & Physical, Pathology Report and more. The most popular use is for inter-enterprise information
exchange, such as is envisioned for a US Health Information Exchange.
• Electronic Health Record System Functional Model
The HL7 International EHR System Functional Model (EHR-S FM) outlines important features and functions that should be contained in an EHR system.
Through the creation of functional profiles, this model provides a standard description and common understanding of functionsfor healthcare settings. HL7
has developed or is developing profiles for areas such as child health, emergency care, long term care, behavioral health andvital statistic reporting.
• Service Oriented Architecture
The Services Oriented Architecture supports the HL7 mission to promote and create standards by identifying common architectural "services" and their
behaviors. The SOA WG produces Service Functional Models (SFMs), implementation guides, and educational materials. Additionally, the workgroup will
explore the implications of emerging technologies (such as Cloud computing and advanced distributed systems) for health-related environments.
• Context Management Architecture
Aimed at facilitating the integration of applications at the point of use, CCOW Context Management Specification is a standard for both internal applications
programming and runtime environment infrastructure. By synchronizing and coordinating applications to automatically follow the patient, user, and other
contexts, CCOW serves as the basis for ensuring secure and consistent access to patient information from heterogeneous sources.
• HL7 Version 3 Product Suite
Health Level Seven Version 3 (V3) is a suite of specifications based on HL7’s Reference Information Model (RIM). It includesstandards for
communications that document and manage the care and treatment of patients in a wide variety of healthcare settings. Version3 represents a new
approach to clinical information exchange based on a model driven methodology that produces messages and electronic documentsexpressed in XML
syntax.
• HL7 Version 2 Product Suite
HL7’s Version 2.x (V2) messaging standard is the workhorse of electronic data exchange in the clinical domain and arguably the most widely implemented
standard for healthcare in the world. This messaging standard allows the exchange of clinical data between systems. It is designed to support a central
patient care system as well as a more distributed environment where data resides in departmental systems.

 Clinical Document Architecture
 HL7 Version 3 Product Suite
syntax.

Aimed at facilitating the integration of applications at the point of use, CCOW Context Management
Architecture is a standard for both internal applications programming and runtime environment infrastructure.
By synchronizing and coordinating applications to automatically follow the patient, user, and other contexts,
CCOW serves as the basis for ensuring secure and consistent access to patient information from heterogeneous
sources.
HL7 Context Management
Architecture

Context Management Architecture (CMA)
• The Health Level Seven Context Management Architecture (CMA)
enables multiple applications to be automatically coordinated and
synchronized in clinically meaningful ways at the point-of-use.
• The CMA establishes the basis for bringing interoperability among
healthcare applications to the point-of-use, such as the clinical
desktop.
• Clinical context is state information that a user establishes and
modifies while interacting with healthcare applications at the point-
of-use (e.g., a clinical desktop).
• The context is common because it establishes parameters that
should uniformly affect the behavior or operation of multiple
healthcare applications.
• The context needs to be managed so that the user has a way of
controlling it, and so that applications have a way of robustly
coordinating their behavior as the context changes.

• The CMA defines the interfaces between applications, known as context
participants, and a coordinating component, known as the context
manager.
• Applications that share a common context with each other, and the
context manager that mediates the applications, are collectively referred
to as a common context system.
• The data that defines the common clinical context for a common context
system resides in the context manager. The data is organized as a set
of name/value pairs that are grouped by context subject.
• When the user performs an application gesture that instructs the
application to change the common clinical context the application starts
a context change transaction.
• When the application that instigated the transaction has completed its
changes to the context data, the context manager conducts a two-phase
process to coordinate the propagation of the context changes to the
other applications.

 In the first phase, the context manager surveys the other applications to
determine which ones can apply the new context, and which ones
either cannot, or prefer not to.
 The context manager informs the instigating application of the survey
results.
 If all of the applications are willing to apply the new context, then they
are all instructed to do so.
 If at least one of the surveyed applications is blocked (“busy”) or prefers
to keep the previous context, then the user is asked by the instigating
application to decide how to proceed.
 The context manager broadcasts the decision to all of the context
participants to complete the second phase of the transaction.
 This approach ensures that the link among application is never broken
unless the user has performed an explicit gesture instructing that the
link be broken.

The Services Oriented Architecture supports the HL7 mission to promote and create standards by identifying common
architectural "services" and their behaviors. The SOA WG produces Service Functional Models (SFMs), implementation guides,
and educational materials. Additionally, the workgroup explores the implications of emerging technologies (such as Cloud
computing and advanced distributed systems) for health-related environments.
HL7 Service Oriented
Architecture

HSSP: Healthcare Services Specification Program
(HL7 SOA WG and OMG HDTF)
• Joint HL7-OMG effort to define standard healthcare
services
o HL7 does logical/functional/business model, OMG does technical
implementation through RFP process
• Current specifications:
o Entity Identification (EIS)
o Record Locate and Update (RLUS)
o Common Terminology (CTS II)
o Decision Support (DSS)
• Defined a methodology framework and specification
template.

What is Service Oriented Architecture
• SOA is an architecture that enables business agility through
the use of common services.
o Services are independent, self-contained, reusable business functions (such
as eligibility checking) or infrastructure functions (such as security)
o Services can be combined and orchestrated to automate complex business
processes
o Important aspects for SOA are:
 Semantics (models of process, service, information and relationships)
 Behavior and mindset of business and IT staff
 Clear processes, roles and responsibilities
 Explicit interaction/interface specifications and contracts
 Governance of Services

Benefits of SOA
• Business related benefits of SOA:
o Responsiveness - to meet market demands for increased service levels
o Adaptability - Process changes with minimal complexity and effort, saving time and
money
o Business-IT Alignment - Application services aligned with business activities and
business strategy.
o B2B opportunities arise and interactions are cheaper and quicker to set up.
o Shared Services - cost less to maintain and enable focus on improving quality.
o Consistency – Enables increased consistency of business-processes.
• IT benefits of SOA
o Reuse - More efficient development and delivery through reuse of shared services.
o Cost Reduction - Maintenance and integration.
o Cheaper and easier to implement - Can use standard, inexpensive (free?) tooling
o Speed of Delivery - quicker and easier than traditional mechanisms.
o Risk Reduction – Risk is reduced through modular, incremental implementation.
o Reduced Error Rates – through reuse of existing services.

The HL7 International EHR System Functional Model (EHR-S FM) outlines important features and functions that should be
contained in an EHR system. Through the creation of functional profiles, this model provides a standard description and
common understanding of functions for healthcare settings. HL7 has developed or is developing profiles for areas such as
child health, emergency care, long term care, behavioral health and vital statistic reporting.
HL7 Electronic Health
Record System Functional
Model

Electronic Health Record System (EHR-S)
• The HL7 EHR System Functional Model and Standard DSTU provides a
reference list of functions that may be present in an Electronic Health Record
System (EHR-S), from a user perspective, to enable consistent expression of
system functionality.
• This EHR-S Model, through the creation of Profiles, enables a standardized
description and common understanding of functions sought or available in a given
setting.
• The EHR-S Functional Model promotes a common understanding of individual
EHR-S functions and serves the following purposes:
o A communication link between EHR-S functions and end user defined benefits such as
patient safety, quality outcomes and cost efficiencies.
o A common understanding, and eventually, conformance measures of EHR functions
upon which developers, vendors, users and other interested parties can plan and
evaluate EHR-S functions.
o The necessary framework to drive the requirements and applications of next level
standards, such as EHR content, coding, information models, constructs and
interoperability.
o A standards-based method by which each realm can apply these EHR functions to its
individually defined care settings and priorities.

Building the foundation of the EHR Standard
EHR Functional Model

Care Settings define the environment of
care in which the functions are applied
within the EHR. (Realm Specific)
Priorities represent the requirements for
each function to be applied, in time, for the
EHR based on care setting and realm.
EHR Functional Model :: Defined
Functions are the prime elements of the
EHR Standard. There are three “groupings”
of functions.

FHIR is a next generation standards framework that combines the best features of HL7’s Version 2, Version 3 and
CDA® product lines while leveraging the latest web standards and applying a tight focus on implementation FHIR
solutions are built from a set of modular components called “Resources”. These resources can be easily assembled
into working systems that solve real world clinical and administrative problems.
Fast Healthcare
Interoperability Resources
Specification (FHIR)

Introduction
 Fast Health Interoperability Resources is HL7’s most recent
standards framework. It combines the best features of HL7’s v2,
v3, and CDA product lines. FHIR leverages web standards and
applies a tight focus on implementation concerns.
 FHIR solutions are built from a set of modular components called
“Resources”. These resources can be assembled into data objects
and services that solve clinical and administrative problems.
 FHIR leverages existing logical and theoretical models to provide a
consistent, easy to implement, and rigorous mechanism for
exchanging data between healthcare applications. FHIR has built-
in mechanisms for traceability to the HL7 RIM and other important
content models.

FHIR DSTU

DSTU Resource List

Resource anatomy
 Resources have 3 parts
Defined
Structured
Data
Extensions
Narrative

Human Readable
Summary
Standard Data
Content:
 MRN
 Name
 Gender
 Date of Birth
 Provider
Extension with
reference to its definition

Resource elements
 Resources are defined as an XML structure
 Hierarchy of elements
 Each element has
 Name
 Either a datatype or nested elements
 Cardinality
 All collections are nested in a containing element
 Definition
 RIM mapping
 But instances in XML or JSON

 HL7’s Version 2.x (V2) messaging standard is the workhorse of electronic data exchange in the clinical domain and
arguably the most widely implemented standard for healthcare in the world. This messaging standard allows the
exchange of clinical data between systems. It is designed to support a central patient care system as well as a more
distributed environment where data resides in departmental systems.
• HL7 Version 2 Messaging
 The HL7 Version 3 Clinical Document Architecture (CDA) is a document markup standard that specifies the structure
and semantics of "clinical documents" for the purpose of exchange between healthcare providers and patients. A CDA
can contain any type of clinical content -- typical CDA documents would be a Discharge Summary, Imaging Report,
Admission & Physical, Pathology Report and more. The most popular use is for inter-enterprise information exchange,
such as is envisioned for a US Health Information Exchang
• HL7 v3 Clinical Document Architecture
 Health Level Seven Version 3 (V3) is a suite of specifications based on HL7’s Reference Information Model (RIM). It
includes standards for communications that document and manage the care and treatment of patients in a wide variety of
healthcare settings. Version 3 represents a new approach to clinical information exchange based on a model driven
methodology that produces messages and electronic documents expressed in XML syntax.
• HL7 Version 3 Messaging
HL7 Health Information Exchange Standards

SESSION RETROSPECTIVE
• HISTORY OF HEALTH LEVEL SEVEN
• IMPLICATIONS OF ANSI ACCREDITATION
• HL7 BOARD AND WORKGROUP COMMITTEES
• HL7 AFFILIATES
• HL7 FAMILY OF STANDARDS

Questions

Hi3 Solutions
300
Burbank, CA 91505
6520

July 13, 2015
HL7 v2 Abstract Message
Definition

SESSION OVERVIEW
• Abstract Message Definition
• Message Elements
• Abstract Message Syntax
• MESSAGE SEGMENT DEFINITION
• SEGMENT FIELD SEQUENCE
• SEGMENT FIELD LENGTH
• HL7 V2 DATATYPES
• OPTIONALITY AND REPETITION
• VALUE SET TABLES
• DATA ELEMENTS

HL7 Messaging Standard: What
 HL7 v2 messaging standards - the Application Protocol for
Electronic Data Exchange in Healthcare Environments - enable
disparate healthcare applications to exchange clinical and
administrative data.
 The standard defines the data content and provides the layout
of messages that are exchanged between applications based
upon a particular trigger event.
 A message is comprised of an ordered collection of segments.
A segment is an ordered collection of data elements (Fields,
Datatype Components, and Datatype Subcomponents).
 The HL7 v2 standard specifies which data elements are to be
sent, the data type and suggested length of each, and
indicates whether the data element is required or optional and
whether it may repeat.

Divide and Conquer / Component Reuse
DATA
Next of Kin
(NK1)
Insurance
(IN1)
Patient Visit
(PV1) Patient
Demographics
(PID)
Guarantor
(GT1)
NK1
IN1
PV1
PID
GT1
OBR
OBX
Next of KIN
(NK1)
Patient Visit
(PV1)
Patient
Demographics
(PID)

HL7 Message Elements
 An HL7 message specification is an ordered collection of one or more segment
groups where each segment group is an ordered collection of one or more
segments. A segment may be part of more than one segment group; it can also
appear more than once within the same segment group.
 A segment is an ordered collection of fields. Each segment field is an instance
of a data element. A data element may appear as a field in more than one
segment or as more than one field within the same segment. Each data element
is assigned a data type.
 A datatype may be simple or composite. A composite datatype is an ordered
collection of one or more data type components; a simple datatype has no
components. A data type component is an instance of a data element. A data
element may appear as a component of more than one composite data type or
as more than one component of the same composite data type.
 Segment fields and datatype components may be associated with a code table.
A code table is a collection of code table items. Each code table item is a code
system term from some code system. A code system may be HL7 defined, user
defined, or defined by a third party. A code system term may be used as a code
table item in more than one code table but may appear only once within the
same code table.

HL7 Message Elements
 An HL7 message specification is an ordered collection of one or more segment
groups where each segment group is an ordered collection of one or more
segments. A segment may be part of more than one segment group; it can also
appear more than once within the same segment group.
 A segment is an ordered collection of fields. Each segment field is an instance
of a data element. A data element may appear as a field in more than one
segment or as more than one field within the same segment. Each data element
is assigned a data type.
 A datatype may be simple or composite. A composite datatype is an ordered
collection of one or more data type components; a simple datatype has no
components. A data type component is an instance of a data element. A data
element may appear as a component of more than one composite data type or
as more than one component of the same composite data type.
 Segment fields and datatype components may be associated with a code table.
A code table is a collection of code table items. Each code table item is an
instance of a code system term from some code system. A code system may be
HL7 defined, user defined, or defined by a third party. A code system term may
be used as a code table item in more than one code table but may appear only
once within the same code table.

HL7 v2 Message Elements
Message Specification
Segment Group
Message Segment
Segment Segment Field
Data Element
Data Type Composite Data Type
Data Type Component
Code Table Code Table Item
Code System Term
Code System

Abstract Message Definition - Syntax
Annotation sets cardinality:
• XYZ means 1 to 1
• [XYZ] means 0 to 1
• {XYZ} means 1 to many
• [{XYZ}] means 0 to many
3-character code identifies the segment
[ ] means the segment or group is optional
{ } means the segment or group may repeat
<OBR|RQD|RQ1> < > choice of segments separated by “|”

Exercise – Abstract Message Definitions
 Given the following definition –
 MSH, EVN, PID, [{NK1}], PV1, [PV2], [AL1]
 How many PV2 segments are allowed?
 Is a message which does not contain an AL1 segment compliant?
 How many NK1 segments are allowed?
 Are the following message instances compliant?
 MSH, EVN, PID, PV1
 MSH, EVN, PD1, PV2, AL1
 EVN, MSH, PID, PV1, PV2
 MSH, EVN, NK1, PV1, AL1
 Missing non-optional segments PID and PVI
 Includes all non-optional segments, but in the wrong order
 Missing non-optional PID segment

HL7 v2 Message Segments and Segment Groups
Segment Group
Message Segment
Data Element
Data Type Component
Code System Term
Code System
 An HL7 v2 message specification is an
ordered collection of one or more
segment groups where each segment
group is an ordered collection of one or
more segments. A segment may be
part of more than one segment group; it
can also appear more than once within
the same segment group.

Segment Groups
 Logical grouping of segments containing more than
one type of segment. A segment group might be
required or optional and might be repeating or non-
repeating.
 The first segment in a segment group is always
required; this helps ensure that message instances
can be unambiguously parsed. This required first
segment is known as the anchor segment.
 Which of the following segment groups are valid:
 MSH, {PID, [NK1]}, OBX…
 MSH, [PID, [NK1]], OBX…
 MSH, {[PID],NK1}, OBX…
 Valid Required Repeating Group
 Valid Optional Non-Repeating Group
 Invalid, Optional Anchor Segment (PID)

Exercise – Abstract Message Definitions
 Create an abstract message definition for which all
of the following are valid:
 MSH, EVN, PID, PV1, PV2
 MSH, EVN, PID, PV1, PV2, AL1
 MSH, EVN, PID, PD1, NK1, NK1, PV1, PV2, AL1
 MSH, EVN, PID, AL1
 MSH, EVN, PID, PD1, NK1
 MSH, EVN, PID, [PD1], [{NK1}], [PV1], [PV2], [AL1]
 MSH, EVN, PID, [PD1], [{NK1}], [PV1, PV2], [AL1]
 MSH, EVN, PID, [PD1, {NK1}], [PV1, PV2], [AL1]

Segment Groups
 Segment Groups may be nested
 Groups of groups...
 How many segment groups are there in the following?
 {OBR, [NTE], [{OBX, [{NTE}]}]}
 {OBR, [NTE], [{OBX, [{NTE}]}]}
 Repeating Group 1 = OBR (1..1), NTE (0..1), Group 2 (0..*)
 Nested Optional Repeating Group 2 = OBX (1..1), NTE (0..*)
 A segment group is assigned a name that is used as an
identifier.
 { --- Group 1
 OBR
 [NTE]
 [{ --- Group 2
 OBX
 [{NTE}]
 }] --- End Group 2
 } --- End Group 1

Example Abstract Message
ADT^A01^ADT_A01: ADT Message
Segments Description Status Chapter
MSH Message Header 2
[{ SFT }] Software Segment 2
[ UAC ] User Authentication Credential 2
EVN Event Type 3
PID Patient Identification 3
[ PD1 ] Additional Demographics 3
[{ ARV }] Access Restrictions 3
[{ ROL }] Role 15
[{ NK1 }] Next of Kin / Associated Parties 3
PV1 Patient Visit 3
[ PV2 ] Patient Visit - Additional Info. 3
[{ ROL }] Role 15
[{ DB1 }] Disability Information 3
[{ OBX }] Observation/Result 7
[{ AL1 }] Allergy Information 3
[{ DG1 }] Diagnosis Information 6
[ DRG ] Diagnosis Related Group 6
[{ --- PROCEDURE begin
PR1 Procedures 6
[{ ROL }] Role 15
}] --- PROCEDURE end
[{ GT1 }] Guarantor 6
[{ --- INSURANCE begin
IN1 Insurance 6
[ IN2 ] Insurance Additional Info. 6
[{ IN3 }] Insurance Additional Info - Cert. 6
[{ ROL }] Role 15
}] --- INSURANCE end
[ ACC ] Accident Information 6
[ UB1 ] Universal Bill Information 6
[ UB2 ] Universal Bill 92 Information 6
[ PDA ] Patient Death and Autopsy 3
Segments Description Status Chapter
MSH Message Header 2
[{ SFT }] Software Segment 2
[ UAC ] User Authentication Credential 2
EVN Event Type 3
PID Patient Identification 3
[ PD1 ] Additional Demographics 3

SEGMENT DEFINITION

HL7 Message - Segment
 An HL7 message segment is an ordered collection
of data fields.
 Segments in a message:
 are identified by a unique three character code known as the Segment
ID.
 may be required or optional
 may be repeating or non-repeating
 may occur in multiple positions in the same message

HL7 v2 Fields, Data Elements and Datatypes
Segment Group
Message Segment
Data Element
Data Type Component
Code System Term
Code System
 A segment is an ordered collection of fields. Each
segment field is an instance of a data element. A
data element may appear as a field in more than one
segment or as more than one field within the same
segment. Each data element is assigned a data type.
A datatype may be primitive or composite. A composite
datatype is an ordered collection of one or more data type
components; a primitive datatype has no components. A data
type component is an instance of a data element. A data
element may appear as a component of more than one
composite data type or as more than one component of the
same composite data type.

MSH - Message Header Segment
SEQ LEN C.LEN DT OPT RP/# TBL# ITEM # ELEMENT NAME
1 1..1 ST R 00001 Field Separator
2 4..5 ST R 00002 Encoding Characters
3 HD O 0361 00003 Sending Application
4 HD O 0362 00004 Sending Facility
5 HD O 0361 00005 Receiving Application
6 HD O 0362 00006 Receiving Facility
7 DTM R 00007 Date/Time of Message
8 40= ST O 00008 Security
9 MSG R 00009 Message Type
10 1..199 = ST R 00010 Message Control ID
11 PT R 00011 Processing ID
12 VID R 00012 Version ID
13 NM O 00013 Sequence Number
14 180= ST O 00014 Continuation Pointer
15 2..2 ID O 0155 00015 Accept Acknowledgment Type
16 2..2 ID O 0155 00016 Application Acknowledgment Type
17 3..3 ID O 0399 00017 Country Code
18 5..15 ID O Y 0211 00692 Character Set

17 3..3 ID O 0399 00017 Country Code
SEQ - position within segment
LEN - length of field
C.LEN – conformance length
DT - data type for field
OPT - optionality for field
RP/# - repeatability
TBL# - table number for codes
ITEM# - HL7 element number
ELEMENT NAME - name
Segment Definition Table

SEGMENT FIELD SEQUENCE

 SEQ – Sequence
 Definition: Ordinal position of the data field within the segment.
 Sequence one follows the field separator following the segment identifier
 Sequence one in the MSH segment is also the field separator.

17 3..3 ID O 0399 00017 Country Code

SEGMENT FIELD LENGTH

 LEN – Normative Length
 Established boundaries for minimum and/or maximum length of a single
field occurrence. Does not include repetitions
 The minimum and the maximum length separated by two dots, e.g. m..n;
or the list of possible values for length separated by commas, e.g. x,y,z.
 When a normative length is asserted, compliant messages must have a
length that lies within the boundaries specified. The boundaries are
inclusive, so a length of 1..3 means the length of the item may be either
1, 2, or 3.
 Normative lengths are only specified for fields with primitive data types.
 “65536” is a conventional value used to express a very large field
 “99999” indicates that the length may vary
 The lengths specified for primitive datatypes may vary across the
different fields
 E.g. an ST in one field may be 20, in another it may be 199

 C.LEN – Conformance Length
 Minimum length that applications must be able to store
 Applications SHALL NOT truncate a value that is shorter than the length
specified
 Truncation Pattern (‘=‘ or ‘#’)
 = - value may never be truncated
 # - value truncation behavior defined by data type

Example LEN and C.LEN
1. Min 1, max 1
2. Min 4, max 5
3. Defined by HD datatype
7. Defined by DTM datatype
8. Min 40, with no truncation
9. Defined by MSG datatype
10. Min 1, max 199, with no
truncation

17 3..3 ID O 0399 00017 Country Code

DATATYPES

 DT – Data Type
 Restrictions on the contents of the data field.
 If the data type of the field is variable, the notation “varies” is used.
 HL7 defines 89 different data types.
 Each field is assigned a data type.
 Some data types are primitive (singular value, e.g. string).
 Some data types are complex (contain discernible parts or components).
For example, the patient’s name is recorded as last name, first name,
middle name or initial, suffix, prefix, and professional suffix.
 Each component is a distinct data element separated by the component
delimiter, e.g. “^”
|Smith^John^J^III^Dr.^MD|

Text/String Data Types
ST String 999
TX Text data 65536
FT Formatted
text
65536
SRT Sort order <sort-by field/parameter (varies)> ^
<sequencing (ID)>
Name
Note: Normative lengths are only specified for primitive data types.
LenAlphanumeric

FT: Formatted Text
 .sp <number> End current
output line and skip
<number> vertical spaces.
If <number> is absent, skip
one space. For
compatibility with previous
versions of HL7, “^.sp” is
equivalent to “.br.”
 .br Begin new output line.
 .fi Begin word wrap or fill
mode. This is the default
state.
 .nf Begin no-wrap mode.
 .in <number> Indent
<number> of spaces,
where <number> is a
positive or negative
integer.
 .ti <number> Temporarily
indent <number> of
spaces where number is a
positive or negative
integer.
 .sk <number> Skip
<number> spaces to the
right.
 .ce End current output line
and center the next line

Numerical Data Types
Numerical
CQ Composite
quantity
with units
<quantity (NM)> ^ <units (CWE)>
MO Money <quantity (NM)> ^ <denomination (ID)>
NM Numeric
SI Sequence
ID
SN Structured
numeric
<comparator (ST)> ^ <num1 (NM)> ^ <separator/suffix
(ST)> ^ <num2 (NM)>
Name Len

Code & Identifier Data Types
Identifier
ID Coded values
in HL7 table
IS Coded values
for user-
defined table
VID Version
identifier
<version ID (ID)> ^ <internationalization code (CWE)> ^
<international version ID (CWE)
HD Hierarchic
designator
<namespace ID (IS)> ^ <universal ID (ST)> ^ <universal
ID type (ID)>
Name Len

Code & Identifier Data Types
Identifier Name
EI Entity
identifier
<entity identifier (ST)> ^ <namespace ID (IS)> ^
<universal ID (ST)> ^ <universal ID type (ID)>
RP Reference
pointer
<pointer (ST) > ^ < application ID (HD)> ^ <type of
data (ID)> ^ <subtype (ID)>
PL Person
location
<point of care (IS )> ^ <room (IS )> ^ <bed (IS)> ^ <facility
(HD)> ^ < location status (IS )> ^ <person location type (IS)>
^ <building (IS )> ^ <floor (IS )> ^ <location description (ST)>
^ <comprehensive location identifier (EI)> ^ <assigning
authority for location (HD)>
PT Processing
type
<processing ID (ID)> ^ <processing mode (ID)>
Len

Date/Time Data Types
Date/time
DT Date 8 YYYY[MM[DD]]
TM Time 16 HH[MM[SS[.S[S[S[S]]]]]][+/-ZZZZ]
DTM Date/time 24 YYYY[MM[DD[HHMM[SS[.S[S[S[S]]]]]]]][+/-
ZZZZ]
[ ] Optional elements

Coded Data Types
Code
Values
CNE
Coded with
no
exceptions
These data types supersede CE, which has been
withdrawn.
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(ID)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)> ^ <coding system
version ID (ST)> ^ <alternate coding system version ID (ST)>
^ <original text (ST)> ^ <second alternate identifier (ST)> ^
<second alternate text (ST)> ^ <name of second alternate
coding system (ST)> ^ <second alternate coding system
version ID (ST)> ^ <coding system version OID (ST)> ^
<value set OID (ST)> ^ <value set version ID (DTM)> ^
<alternate coding system OID (ST)> ^ <alternate value set OID
(ST)> ^ <alternate value set version ID (DTM)>^ <second
alternate coding system OID (ST)> ^ <second alternate value
set OID (ST)> ^ <second alternate value set version ID
(DTM)>
CWE
Coded with
exceptions

Extended Demographics Data Types
XCN Extended
composite
ID
number
and name
<ID number (ST)> ^ <family name (FN)> ^ <given name
(ST)> ^ <second and further given names or initials thereof
(ST)> ^ <suffix (e.g., JR or III) (ST)> ^ <prefix (e.g., DR)
(ST)> ^ <degree (e.g., MD) (IS)> ^ <source table (IS)> ^
<assigning authority (HD)> ^ <name type code (ID)> ^
<identifier check digit (ST)> ^ <check digit scheme (ID)> ^
<identifier type code (ID)> ^ <assigning facility (HD)> ^
<name representation code (ID)> ^ <name context (CWE)> ^
<name validity range (DR)> ^ < name assembly order (ID)> ^
<effective date (DTM)> ^ <expiration date (DTM)> ^
<professional suffix (ST)> ^ <assigning jurisdiction (CWE)>
^ <assigning agency or department (CWE)>

XAD Extended
address
<street address (SAD)> ^ <other designation (ST)> ^
<city (ST)> ^ <state or province (ST)> ^ …
XPN Extended
person
name
<family name (FN)> ^ <given name (ST)> ^ <second and
further given names or initials thereof (ST)> ^ …
XON Extended
composite
name and
ID number
for
organiza-
tions
<organization name (ST)> ^ <organization name type
code (IS)> ^ <ID number (NM)> ^ <identifier check digit
(NM)> ^ <check digit scheme (ID)> ^ <assigning
authority (HD)> ^ <identifier type code (ID)> ^
<assigning facility ID (HD)> ^ <name representation code
(ID)> ^ <organization identifier (ST)

XTN Extended
telecommunications
number
<telephone number> ^ <telecommunication use
code (ID)> ^ <telecommunication equipment type
(ID)> ^ <communication address (ST)> ^ <country
code (NM)> ^ <area/city code (NM)> ^ <local
number (NM)> ^ <extension (NM)> ^ …
SAD Street address <street or mailing address (ST)> ^ <street name
(ST)> ^ <dwelling number (ST)>

17 3..3 ID O 0399 00017 Country Code

OPTIONALITY AND REPETITION

 OPT – Optionality
 Definition: Whether the field is required, optional, or conditional in a
segment.
 The designations for optionality are:
 R - required
 RE - required but may be empty
 O - optional
 C - conditional on trigger event or other field(s)
 X - not used with this trigger event
 B - left in for backward compatibility with previous versions
 W - withdrawn

 REP – Repetition
 Indicates whether the field may repeat.
 The designations for Repetition are:
 N or blank - no repetition
 Y - the field may repeat an indefinite number of times
 (integer) - the field may repeat up to the number of times specified by integer
 Each occurrence may contain the number of characters specified by the
field’s maximum length

17 3..3 ID O 0399 00017 Country Code

VALUE SET TABLES

 TBL# - Value Table
 Definition: The table attribute of the data field definition specifies the
HL7 identifier for a set of coded values.
 An entry in the table number column means that the table name and
the element name are equivalent.
 If this attribute is not valued or blank, there is not a table of values
defined for the field.
 Specifies the sets of allowable code values for
coded fields and datatype components
 HL7-Defined Table
 User-Defined Table
 External Table
 Imported Table
 Local Table

HL7 v2 Message Code Tables and Code Table Items
Segment Group
Message Segment
Data Element
Data Type Component
Code System Term
Code System
 Segment fields and datatype components may be associated with a
code table. A code table is a collection of code table items. Each code
table item is an instance of a code system term from some code
system. A code system may be HL7 defined, user defined, or defined
by a third party. A code system term may be used as a code table item
in more than one code table but may appear only once within the same
code table.

HL7 Defined Tables
 Normative
 Set of values maintained and published by HL7.
 They affect the interpretation of the messages that contain them
 May not be redefined locally
 The table itself may be extended with locally defined values
 The ID data type is most often used for elements
that are populated with value from HL7 tables

User-defined Tables
 A user-defined table is a set of values that are
locally or site defined
 E.g. PV1-3 Assigned patient location, will vary from institution to
institution
 HL7 sometimes publishes suggested values that
a site may use as a starter set (e.g., table 0001-
Sex)
 The IS data type is most often used for elements
that are populated with values from user-defined
tables.

External Tables
 A set of coded values defined and published by
another standards organization (e.g., ISO, WHO,
etc.)
 FT1-19 Diagnosis Code – FT1
 Clinical Observations using LOINC codes
 CF/CNE/CWE data type is used for elements that
can be populated with values from external tables

Imported Tables
 Third-party definitions published in the HL7
Standard
 Example includes list of valid units of measures
imported from ISO

Local Tables
 Local definitions in non-HL7 published table

17 3..3 ID O 0399 00017 Country Code

DATA ELEMENTS

 Item# - Item Number
 Definition: Unique identifier of data element within HL7
 Element Name
 Definition: Unique name of a data element within HL7

17 3..3 ID O 0399 00017 Country Code

Segment Group
Message Segment
Data Element
Data Type Component
Code System Term
Code System

• Abstract Message Definition
• Message Elements
• Abstract Message Syntax
• MESSAGE SEGMENT DEFINITION
• SEGMENT FIELD SEQUENCE
• SEGMENT FIELD LENGTH
• HL7 V2 DATATYPES
• OPTIONALITY AND REPETITION
• VALUE SET TABLES
• DATA ELEMENTS

Q&A

Hi3 Solutions
300
Burbank, CA 91505
6520

July 13, 2015
HL7 v2 Message Construction
Rules

SESSION OVERVIEW
• Message Delimiters
• MESSAGING FRAMEWORK
• PARTICIPATING APPLICATIONS
• MESSAGE TYPES AND VERSION
• MESSAGE ENCODING RULES
• MESSAGE PROFILES
• ACKNOWLEDGEMENTS
• COMMUNICATION ENVIRONMENT

MESSAGE DELIMITERS

17 3..3 ID O 0399 00017 Country Code
MSH-1, MSH-2: Message Delimiters

Message Delimiters (MSH-1, MSH-2)
Delimiter Suggested Value Encoding
Character Position
Segment Terminator <CR>
(Hex: 0D)
Field Separator |
Component Separator ^ 1
SubComponent
Separator
& 4
Repetition Character ~ 2
Escape Character 3
Truncation Character # 5

Message Delimiters
 Segment Terminator <CR>
 Non-printing character – the four characters “<CR>”
are shown in documentation for clarity
 Terminates a segment record
 Cannot be changed by implementers

Message Delimiters
 Field Separator (MSH-1)
 Suggested: |
 Identifies the start of a data field within a segment.
Will be the first character following the Segment ID as
established by the MSH segment
 It may be changed by implementers

Message Delimiters
 Encoding Characters (MSH-2)
 Component Separator (^)
Separates adjacent components of data fields.
 Subcomponent Separator (&)
Separates adjacent subcomponents of data fields.
 Repetition Separator (~)
Separates multiple occurrences of a field.
 Escape Character ()
Used to signal certain special characteristics of portions of the text
field.
 Truncation Character (#)
Used to indicate that a value has been truncated.

Field or Component Status
 HL7 does not care how systems actually store data within an application.
When fields are transmitted, they are sent as character strings
 A field may exist in one of three population states in an HL7 message:
Populated. (Synonyms: valued, non-blank, not blank, not empty.)
 The sending system sends a value in the field. For example, if a sending
system includes medical record number, that would be communicated as
|1234567^^^MR^KP-CA|.
Not populated. (Synonyms: unpopulated, not valued, empty, not present, missing.)
 The sending system does not supply a value for the field. The Sender
might or might not have a value for the field. unless there is a
conformance profile governing the implementation, the receiving system
can make no inference regarding the absence of an element value.
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., |""|).

Sample HL7 v2.x Message
Segments
 MSH: Message Header
 PID: Patient Identification
 OBR: Observation Request
 OBX: Observation Result
MSH|^~&|LABGL1||DMCRES||199812300100||ORU^R01|LABGL1199510221838581|P|2.3
|||NE|NE
PID|||6910828^Y^C8||NewmanÂlfredÊ||19720812|M||W|25 Centscheap Ave^^
WhatmeworryÛT^85201^^P||(555)777-6666|(444)677-7777||M||773789090
OBR||110801^LABGL|387209373^DMCRES|18768-2^CELL COUNTS+DIFFERENTIAL TESTS
(COMPOSITE)^LN|||199812292128||35^ML|||||||IN2973^Schadow^Gunther^^^^MDÛPIN
||||||||||Ônce||||||CA20837^Spinosa^John^^^^MDÛPIN
OBX||NM|4544-3^HEMATOCRIT (AUTOMATED)^LN||45||39-49
||||F|||199812292128||CA20837
OBX||NM|789-8ÊRYTHROCYTES COUNT (AUTOMATED)^LN||4.94|10*12/mm3
|4.30-5.90||||F|||199812292128||CA20837
Delimiters
| Field
^ Component
& Subcomponent
~ Repetition
Escape Character

XML Encoding Rules for Version 2 Messages
http://www.hl7.org/implement/standards/product_brief.cfm?product_id=275

XML Representation
MSH|^~&|LAB|767543|ADT|767543|199003141304-
0500||ACK^^ACK|XX3657|P|2.4

Messaging Framework

HL7 Conceptual Approach
Critical Care Unit
ADT System
Acknowledgement Message
Initiating Message
Clinical Data Repository
Initiating Message

Messaging Framework
Sending
Application
Receiving
Application
Message Type
AcknowledgementEncoding Rules Message Profile
[ ]

MSH – Message Header
17 3..3 ID O 0399 00017 Country Code
19 CWE O 00693 Principal Language Of Message
20 3..13 ID O 0356 01317 Alternate Character Set Handling Scheme
21 EI O Y 01598 Message Profile Identifier
22 XON O 01823 Sending Responsible Organization
23 XON O 01824 Receiving Responsible Organization
24 HD O 01825 Sending Network Address
25 HD O 01826 Receiving Network Address
The MSH segment defines the intent, source, destination, and some
specifics of the syntax of a message.
3
5
9
12
16
21
15

Message Header
 MSH-3: Sending Application
 MSH-5: Receiving Application
 MSH-9: Message Type
• MSH-9.1: Message Code
• MSH-9.2: Event Type
• MSH-9.3: Message Structure
 MSH-12: Version ID
 MSH-15: Accept Acknowledgement
 MSH-16: Application Acknowledgement
 MSH-21: Message Profile Identifier

PARTICIPATING APPLICATIONS
Sending
Application
Receiving
Application

PARTICIPATING APPLICATIONS
 MSH-3 Sending Application (HD)
 Components: <Namespace ID (IS)> ^ <Universal ID (ST)> ^ <Universal ID Type (ID)>
 This field uniquely identifies the sending application among all other
applications within the network enterprise. The network enterprise
consists of all those applications that participate in the exchange of HL7
messages within the enterprise. Entirely site-defined. User-defined Table
0361- Application is used as the user-defined table of values for the first
component.
 MSH-5 Receiving Application (HD)
 Components: <Namespace ID (IS)> ^ <Universal ID (ST)> ^ <Universal ID Type (ID)>
 This field uniquely identifies the receiving application among all other
applications within the network enterprise. The network enterprise
consists of all those applications that participate in the exchange of HL7
messages within the enterprise. Entirely site-defined. User-defined Table
0361- Application is used as the HL7 identifier for the user-defined table of
values for the first component.

Sample Message
MSH|^~&#|REGADT|MCM|RSP1P8|MCM|200901051530
||ADT^A45^ADT_A45|0000005|P|2.7|||AL|NE<CR>
EVN|A45|200901051530<CR>
PID|||MR1^^^XYZ^MR||JONES^MARY||19601010|F|||123
NORTH STREET^^NY^NY^10021||
(212)111-3333|||S||X1<CR>
MRG|MR1^^^XYZ^MR||ACCT1||VISIT2<CR>
PV1||O|PT||||||||||||||||VISIT4<CR>

MESSAGE TYPES AND VERSION

Message Type and Version
 MSH-9 Message Type (MSG)
 Components: <Message Code (ID)> ^ <Trigger Event (ID)> ^ <Message Structure (ID)>
 This field contains the message type, trigger event, and the message
structure ID for the message. The receiving system uses this field to
recognize the data segments, and possibly, the application to which to
route this message.
 MSH-12 Version ID (VID)
 Components: <Version ID (ID)> ^ <Internationalization Code (CWE)> ^ <International Version ID (CWE)>
 This field is matched by the receiving system to its own version to be sure
the message will be interpreted correctly. Beginning with Version 2.3.1, it
has two additional "internationalization" components, for use by HL7
international affiliates. The <internationalization code> is CE data type
(using the ISO country codes where appropriate) which represents the
HL7 affiliate. The <internal version ID> is used if the HL7 Affiliate has
more than a single 'local' version associated with a single US version. The
<international version ID> has a CE data type, since the table values vary
for each HL7 Affiliate.

Message Type and Version
HL7 Table 0104 - Version ID
Value Description Comment (Date)
2.0 Release 2.0 September 1988
2.0D Demo 2.0 October 1988
2.1 Release 2.1 March 1990
2.2 Release 2.2 December 1994
2.3 Release 2.3 March 1997
2.3.1 Release 2.3.1 May 1999
2.4 Release 2.4 November 2000
2.5 Release 2.5 May 2003
2.5.1 Release 2.5.1 January 2007
2.6 Release 2.6 July 2007
2.7 Release 2.7 November 2010
 Message Type |ADT^A45^ADT_A45|
 MSH-9.1: Message Code (ADT)
 MSH-9.2: Trigger Event (A45)
 MSH-9.3: Message Structure (ADT_A45)
 Version ID |2.7|
 MSH-12.1 Version ID (2.7)
 MSH-12.2 International Code ( )
 MSH-12.3 International Version ID ( )

Sample Message
EVN|A45|200901051530<CR>
(212)111-3333|||S||X1<CR>
PV1||O|PT||||||||||||||||VISIT4<CR>

Message Structure
 Specifies the abstract message structure code. Refer to
HL7 Table 0354 – Message Structure for valid values.
 Predefined abstract message definition
 Message Type + Trigger Event => Message Structure
 A message structure may be shared by more than one
message type/event combination

Table 0354 – Message Structure

HL7 v2.x Messaging Schema
http://www.hl7.org/implement/standards/product_brief.cfm?product_id=185
HL7 Version 2.3.1 Messaging Schemas

MESSAGE ENCODING RULES
Encoding Rules

Chapter 3
Encoding Rules
 To determine the exact representation of an
abstract message, one applies the HL7 encoding
rules to the abstract definition from the relevant
transaction definition chapter.
HL7 Message
ADT Message
A01 Admit
ADT^A01^ADT_A01

Encoding Rules - Sender
 Encode each segment in the order specified in the
abstract message format
Segment ID identifies the segment
Admit Message
MSH
EVN
PID
[ { NK1 } ]
PV1
[ PV2 ]
[ HL1 ]
[ { AL1 } ]
[ { DG1 } ]
[ { PR1 } ]
[ { GT1 } ]
[ { IN1
[ IN2 ]
[ IN3 ] } ]
[ ACC ]
[ UB1 ]

 Encode the data fields in the order specified in the
segment definition table
 Precede each data field with the data field separator
 PID|||2-68708-5|253763|COX^JAMES...
 Data fields ‘present, but null’ are encoded with “”
 PID|||2-68708-5|253763|COX^JAMES|“”|...
Data fields that are ‘not
present’ require no
characters
SEQ LEN
C.LE
N
DT OPT RP/#
ITEM #
TBL#
ELEMENT NAME

 If components, subcomponents, or repetitions at
the end of a data field are ‘not present’, their
separators may be omitted
 If no more fields are present in a segment, the data
field separators may be omitted
|Marotta^David^John^^^| |Marotta^David^John|
PID|...|Last Field||||||||<CR> PID|...|Last Field<CR>

 End each segment with the segment terminator
PID|...|Last Field<CR>

Decoding Rules - Receiver
 If a data segment that is expected is not found,
treat it as if all the data fields were ‘not present’
 If a data segment is included that is not expected,
ignore it; this is not an error
PV1<CR>
NEW|A|B|C<CR>

Decoding Rules - Receiver
• If unexpected data fields are found at the end of a
data segment, ignore them; this is not an error
SEG|A|B|C|New1|New2|New3<CR>
SEG|A|B|C<CR>

MESSAGE PROFILES
Message Profile
[ ]Encoding Rules

Message Profile Identifier
 MSH-21 Message Profile Identifier (EI)
 Components: <Entity Identifier (ST)> ^ <Namespace ID (IS)> ^ <Universal ID (ST)> ^ <Universal ID Type (ID)>
 Sites may use this field to assert adherence to, or reference, a message
profile.
 Message profiles contain detailed explanations of grammar, syntax, and
usage for a particular message or set of messages.
 Repetition of this field allows more flexibility in creating and naming
message profiles.
 Using repetition, this field can identify a set of message profiles that the
message conforms to.

Message Profile Example
...
...
...
NK1
MSH
EVN
PID
NK1 NK1 NK1 NK1
PV1
PV2
OBX
AL1
HL7 Message Structure
...
NK1
MSH
EVN
PID
NK1 NK1 NK1 NK1
PV1
PV2
OBX
AL1
Message Profile
Segments/Segment Groups:
•Usage (Optionality)
•Cardinality (min, max)
Fields/Components:
- Usage (Optionality)
- Cardinality (min, max)
- Value Sets/Coding system
- Descriptions

ACKNOWLEDGMENTS
Acknowledgement

Acknowledgments
 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, an application acknowledgment may be used to
return the resultant status to the sending system.
 For example,
 If a patient care system has processed the trigger event a lab
test is ordered for a patient, it may send an unsolicited
update to a lab application identifying the patient, the test
ordered, and various other information about the order.
 The ancillary system will acknowledge the order when it has
processed it successfully.
 For some pairings of patient care and ancillary department
systems the acknowledgment may also include the order
identification number that was assigned by the ancillary
system.

General Acknowledgment Message

Message Acknowledgment Segment

Error Segment

Acknowledgments
 MSH-15 Accept Acknowledgment Type (ID)
 This field identifies the conditions under which accept acknowledgments
are required to be returned in response to this message.
 MSH-16 Application Acknowledgment Type (ID)
 This field contains the conditions under which application
acknowledgments are required to be returned in response to this
message.

Acknowledgments
Vectra
XU
5/90C
BED1OFF
BED1OFF
BED1OFF
BED1OFF
BED1OFF
BED1OFF
BED1OFF
BED1OFF
BED1OFF
BED1OFF
POTASSIUM3.5-5.0
BED1OFF
POTASSIUM3.5-5.0
POTASSIUM3.5-5.0
POTASSIUM3.5-5.0
BED1OFF
POTASSIUM3.5-5.0
BED1OFF BED1OFF
BED1OFF
BED1OFFBED1OFF
Critical Care Unit
HIS/CIS
Vectra
XU
5/90C
BED1OFF
BED1OFF
BED1OFF
BED1OFF
BED1OFF
BED1OFF
BED1OFF
BED1OFF
BED1OFF
BED1OFF
POTASSIUM3.5-5.0
BED1OFF
POTASSIUM3.5-5.0
POTASSIUM3.5-5.0
POTASSIUM3.5-5.0
BED1OFF
POTASSIUM3.5-5.0
BED1OFF BED1OFF
BED1OFF
BED1OFFBED1OFF
Clinical Data
Repository
A/D/T System
Order Filling Application
Accept Ack
Accept + App ACK
No ACK

Sample Message
EVN|A45|200901051530<CR>
(212)111-3333|||S||X1<CR>
PV1||O|PT||||||||||||||||VISIT4<CR>

Messaging Framework
Sending
Application
Receiving
Application
Message Type
[ ]

Messaging Framework
Sending
Application
Receiving
Application
Message Type
[ ]
MSH-3 MSH-5
MSH-9, MSH-12
MSH-21 MSH-15, MSH-16MSH-9.3

Communication Environment
 Error Free Transmission. Applications can assume that they
correctly received all of the transmitted bytes in the order in which
they were sent. However, sending applications may not assume
that the message was actually received without receiving an
acknowledgment message.
 Character Conversion. If the two machines exchanging data use
different representations of the same character set, the
communications environment will convert the data from one
representation to the other.
 Message Length. HL7 sets no limits on the maximum size of HL7
messages. The Standard assumes that the communications
environment can transport messages of any length that might be
necessary. In practice, sites may agree to place some upper bound
on the size of messages and may use the message continuation
protocol for messages that exceed the upper limit.

Middleware Vendor Products

• Message Delimiters
• MESSAGING FRAMEWORK
• PARTICIPATING APPLICATIONS
• MESSAGE TYPES AND VERSION
• MESSAGE ENCODING RULES
• MESSAGE PROFILES
• ACKNOWLEDGEMENTS
• COMMUNICATION ENVIRONMENT

Q&A

Hi3 Solutions
300
Burbank, CA 91505
6520

July 13, 2015
HL7 v2 Inter-Version Compatibility
and Local Extensions

SESSION OVERVIEW
• Inter-version Compatibility
• Local Extensions
• MESSAGES
• TRIGGER EVENTS AND SEGMENT GROUPS
• SEGMENTS AND DATATYPES

INTER-VERSION COMPATIBILITY

Version compatibility
 The keys to understanding version compatibility are the following 2
axioms:
 • Old receivers receiving new messages should be able to
continue receiving messages without error.
 • New receivers should be able to understand old messages.
 A new message or a new message element of an HL7 message may be
introduced.
 A sending system should be able to send a new message or new
message element.
 The receiver, regardless of its version level, must ignore any message
or message element it is not expecting without generating an application
failure.
 This does not preclude a receiver notifying the sender that an additional
element was ignored, but the receiving application should not fail just
from the existence of additional element.

 HL7 versions are backwards compatible when:
 New message types and structures are added
 New segments are added to an existing message
 New fields are added at the end of a segment
 New components are added at the end of data types
 Optional elements are re-designated conditional or required
 Deprecated and withdrawn fields are retained as place holders
 Deprecating messages or message constituents
 Any required, optional or conditional constituent of an HL7 message, including the message
itself, may be deprecated.
 Language will be inserted stating the fact of deprecation, the version in which the deprecation
occurred, and what message or message constituent, if any, replaces it.
 Removing messages or message constituents
 A message or message constituent may be removed from the standard immediately, only if is
not referenced elsewhere in the standard or all references to it are also removed.
 A message constituent, will be withdrawn and removed, no sooner than, after 2 versions in a
deprecated state. For example, if a message was originally deprecated in v 2.3.1, its
definition can be removed when v 2.6 is published.

LOCAL EXTENSIONS

Local Extensions
 Local extensions are permitted to aid in meeting unique information or
message processing needs particular to a suite of applications, community
of users, or realm.
 A realm is a localization group defined by geographic boundaries or
jurisdiction, medical specialty area, time period, or any combination of the
three. HL7 Affiliate organizations are typically designated as realms for the
purpose of localization.
 Localization methods exist for:
 Messages
 Trigger Events
 Segment Groups
 Segments
 Data Types

Messages
 Users may develop local Z messages to cover areas not already covered
by existing HL7 messages. The messages should be composed of HL7
segments where possible.
 A local Z message may consist entirely of Z segments except that it must
begin with a MSH segment.
 A local Z Acknowledgment message must begin with an MSH segment
followed by an MSA segment, an optional SFT segment, and a conditional
ERR segment.
 Users may develop Z segments and add them to Z messages.
 Users may develop Z segments an add them to HL7 messages. The
trigger event may remain the same if the intent of the message has
remained unchanged.
 The practice of adding additional HL7 segments to existing HL7 messages
locally is ill-advised.

Trigger Events and Segment Groups
 Trigger Events
 Users may develop local Z trigger events for messages.
 Segment Groups
 The practice of turning a single segment or segments into a segment group
locally is not allowed within an HL7 event.
 An HL7 segment group may not be ungrouped locally.
 A segment group can repeat locally. The 1st occurrence needs to mean what it
does in HL7.
 The practice of incorporating a Z segment into a segment group locally is allowed.

Segments and Data types
 Segments
 Locally defined fields may be defined for use in locally defined
segments, although HL7 defined fields are a better choice when
available.
 The process of extending an HL7 segment with locally defined
fields, while not prohibited , is ill-advised.
 Data types
 Locally defined data types may be defined for use in locally defined
segment fields, although HL7 defined data types are a better choice
when available.
 Locally redefining existing data type components is prohibited.
 Data types may be locally extended by adding new components at
the end. This action creates a Z data type.

• Inter-version Compatibility
• Local Extensions
• MESSAGES
• TRIGGER EVENTS AND SEGMENT GROUPS
• SEGMENTS AND DATATYPES

Q&A

Hi3 Solutions
300
Burbank, CA 91505
6520

July 13, 2015
HL7 v2 Retrospective

HL7 Version 2 Topics
 Health Level Seven and the HL7 Family of Standards
 HL7 v2 Abstract Message Definition
 HL7 v2 Message Construction Rules
 Local Extensions and inter-version Compatibility

Health Level Seven and
the HL7 Family of Standards

Electronic Health Information Exchange
PharmaciesPhysicians
Testing Organizations
Lab/Images
Hospitals
Payors
Employers
County/Community
Entities
Patients/Consumers
Government
Medicare/Medicaid
Lab results
Patient Data
Orders
Results
Images
Eligibility
Referral Process
Claim Status
Claims/Prescriptions
Referral Process
Claim/Status
Health Information
Insurance Updates
Eligibility
Medical Records
Enrollment
Mental Health
Family Planning
Medical Society
Public Health

HIE Standards: Why
• The number of interfaces between N systems is given by the formula (N2-N)/2.
• Linking 2 systems only needs 1 interface, (22 – 2) / 2 = 1;
• Linking 6 systems needs as many as 15 interfaces, (62 – 6) / 2 = 15
• The benefits of using standard increase rapidly with the number of systems involved.

HL7 International Affiliates
April 08, 2009Informatics Standards & Interoperability191 of 55
Canada
New
Zealand
Finland Germany
Netherlands
Japan
United States
United
Kingdom
India
Taiwan
China
Czech Republic
Mexico
France
Argentina
Brazil
Australia
Denmark Greece
Ireland
Italy
Spain
Sweden
Switzerland
South
Korea
Turkey
Uruguay
Singapore
Romania
CroatiaAustriaColombia
Chile
Puerto Rico
Russia
Pakistan
Bosnia and
Herzegovina

 Clinical Document Architecture
syntax.

HL7 v2 Abstract Message
Definition

Divide and Conquer / Component Reuse
DATA
Next of Kin
(NK1)
Insurance
(IN1)
Patient Visit
(PV1) Patient
Demographics
(PID)
Guarantor
(GT1)
NK1
IN1
PV1
PID
GT1
OBR
OBX
Next of KIN
(NK1)
Patient Visit
(PV1)
Patient
Demographics
(PID)

Segment Group
Message Segment
Data Element
Data Type Component
Code System Term
Code System

Abstract Message Definition - Syntax
Annotation sets cardinality:
• XYZ means 1 to 1
• [XYZ] means 0 to 1
• {XYZ} means 1 to many
• [{XYZ}] means 0 to many
3-character code identifies the segment
[ ] means the segment or group is optional
{ } means the segment or group may repeat
<OBR|RQD|RQ1> < > choice of segments separated by “|”

17 3..3 ID O 0399 00017 Country Code
SEQ - position within segment
LEN - length of field
C.LEN – conformance length
DT - data type for field
OPT - optionality for field
RP/# - repeatability
TBL# - table number for codes
ITEM# - HL7 element number
ELEMENT NAME - name

HL7 v2 Message Construction
Rules

Message Delimiters (MSH-1, MSH-2)
Delimiter Suggested Value Encoding
Character Position
Segment Terminator <CR>
(Hex: 0D)
Field Separator |
Component Separator ^ 1
SubComponent
Separator
& 4
Repetition Character ~ 2
Escape Character 3
Truncation Character # 5

Sample HL7 v2.x Message
Segments
 MSH: Message Header
 PID: Patient Identification
 OBR: Observation Request
MSH|^~&|LABGL1||DMCRES||199812300100||ORU^R01|LABGL1199510221838581|P|2.3
|||NE|NE
PID|||6910828^Y^C8||NewmanÂlfredÊ||19720812|M||W|25 Centscheap Ave^^
WhatmeworryÛT^85201^^P||(555)777-6666|(444)677-7777||M||773789090
OBR||110801^LABGL|387209373^DMCRES|18768-2^CELL COUNTS+DIFFERENTIAL TESTS
(COMPOSITE)^LN|||199812292128||35^ML|||||||IN2973^Schadow^Gunther^^^^MDÛPIN
||||||||||Ônce||||||CA20837^Spinosa^John^^^^MDÛPIN
OBX||NM|4544-3^HEMATOCRIT (AUTOMATED)^LN||45||39-49
||||F|||199812292128||CA20837
OBX||NM|789-8ÊRYTHROCYTES COUNT (AUTOMATED)^LN||4.94|10*12/mm3
|4.30-5.90||||F|||199812292128||CA20837
Delimiters
| Field
^ Component
& Subcomponent
~ Repetition
Escape Character

XML Representation
MSH|^~&|LAB|767543|ADT|767543|199003141304-
0500||ACK^^ACK|XX3657|P|2.4

Messaging Framework
Sending
Application
Receiving
Application
Message Type
[ ]

Messaging Framework
Sending
Application
Receiving
Application
Message Type
[ ]
MSH-3 MSH-5
MSH-9, MSH-12
MSH-21 MSH-15, MSH-16MSH-9.3

Middleware Vendor Products

Local Extensions and
inter-version Compatibility

 The keys to understanding version compatibility are the following 2
axioms:
 • Old receivers receiving new messages should be able to
continue receiving messages without error.
 • New receivers should be able to understand old messages.
 A new message or a new message element of an HL7 message may be
introduced.
 A sending system should be able to send a new message or new
message element.
 The receiver, regardless of its version level, must ignore any message
or message element it is not expecting without generating an application
failure.
 This does not preclude a receiver notifying the sender that an additional
element was ignored, but the receiving application should not fail just
from the existence of additional element.

Local Extensions
 Local extensions are permitted to aid in meeting unique information or
message processing needs particular to a suite of applications, community
of users, or realm.
 A realm is a localization group defined by geographic boundaries or
jurisdiction, medical specialty area, time period, or any combination of the
three. HL7 Affiliate organizations are typically designated as realms for the
purpose of localization.
 Localization methods exist for:
 Messages
 Trigger Events
 Segment Groups
 Segments
 Data Types

HL7 Version 2 Topics
 Health Level Seven and the HL7 Family of Standards
 HL7 v2 Abstract Message Definition
 HL7 v2 Message Construction Rules
 Local Extensions and inter-version Compatibility

Q&A

Thank You!
Peace...AMS
Abdul-Malik Shakir
President and Chief Informatics Scientist
Hi3 Solutions
3500 West Olive Ave, Suite # 300, Burbank, CA 91505
Skype: +1 9098334661  Mobile: (626) 644-4491
Email: abdulmalik.shakir@hi3Solutions.com

Hi3 Solutions
300
Burbank, CA 91505
6520

Introduction to hl7 v2

More Related Content

What's hot (20)

Viewers also liked (19)

Similar to Introduction to hl7 v2 (20)

More from Abdul-Malik Shakir (13)

Recently uploaded (20)

Introduction to hl7 v2