Introduction to hl7 v2

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

July 13, 2015

Introductions and Course Overview

July 13, 2015 Page: 2 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner

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 ShakirPresident and Chief Informatics

ScientistHi3 Solutions | your healthcare standards

conformance partner3500 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

ArchitectureHL7 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 Materialshttps://drive.google.com/folderview?id=0B-

3JvLjUn5CCfk84VzNqZFY5U2NCbV95WHNNWGp0QWFIWDhZcGh1NzVnVUptZEZvNTlxYkE&usp=sharing


Questions


Hi3 Solutions 3500 W. Olive Ave, Suite

300Burbank, CA 91505

ww.hi3solutions.com +1 800 918-6520

http://www.hi3solutions.com/


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

Pharmacies

Physicians

Testing OrganizationsLab/Images

Hospitals

Payors

Employers

County/Community Entities

Patients/ConsumersGovernmentMedicare/Medicaid

Lab results

Patient Data

Orders

ResultsImages

Eligibility

Referral ProcessClaim Status

Claims/Prescriptions

Referral Process

Claim/Status

Health InformationInsurance 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

Clinical System

Images, pictures

Bedside Instruments

Billing, claimsreimbursement

Adverse Events Reporting

Immunization Database

MaterialsManagement

Agency Reporting

ProviderRepository

HL7

HL7

HL7, X12N

HL7, X12N

HL7

HL7

DICOM

IEEE MIB,ASTM

X12N / HL7 (Non-US only)

X12N

Waveforms

Retail Pharmacy Orders & Reimbursement NCPDP

Healthcare Data Interchange Standards


Leading U.S. Healthcare Data Interchange SDOs

IEEEInstitute of Electrical and

Electronic Engineers

NCPDPNational Council for

Prescription Drug Programs

X12NInsurance 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.

HL7Clinical / Administrative

X12NInsurance / Billing


An X12N Data Interchange Scenario

User InterfaceUser InterfaceProgram

Module

ProgramModuleDataset

Dataset

OutboundTransformation


InboundTransformation



Module


Dataset





B to ATransformation


A to BTransformation


Patient Billing Application

System

Claims Processing Application

System

Cl a

im

Tr a

nsa

c ti o

nPatient Billing

ApplicationSystem

Claims ProcessingApplication

System

Rem

itta

nce

T

ran

sact

ion



Module


Dataset






Module


Dataset









Order Entry Application

System

Laboratory Application

System

Lab

Ord

er

Tra

nsa

ctio

nOrder Entry Application

System


System

Lab

Res

ult

T

ran

sact

ion

An HL7 Data Interchange Scenario


Reaching the Limits of Application Interfaces

LabLab

Order EntryOrder Entry ADTADT

PharmacyPharmacy RadiologyRadiology

DecisionSupport

DecisionSupport

ElectronicHealth Record

ElectronicHealth Record

AdministrativeSystems

AdministrativeSystems

?

EnterpriseSystems

EnterpriseSystems

?ExternalSystems

ExternalSystems

?


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

10

30

50

70

90

110

Interfaces Requirements

Nodes

Inte

rfa

ce

s

With STD

W/O STD

HIE Standards: Why

Tolerable Painful Intolerable



Module


Dataset






Module


Dataset









Order Entry Application

System


System

Lab

Ord

er

Tra

nsa

ctio

nOrder Entry Application

System


System

Lab

Res

ult

T

ran

sact

ion

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 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

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 & Interoperability

31 of 55

Canada

NewZealand

Finland Germany

Netherlands

Japan

United States

United Kingdom

India

Taiwan

China

Czech Republic

Mexico

France

Argentina

Brazil

Australia

Denmark Greece

Ireland

Italy

SpainSweden

Switzerland

SouthKorea

Turkey

Uruguay

Singapore

Romania

CroatiaAustriaColombiaChile

Puerto Rico

Russia

Pakistan

Bosnia and Herzegovina

http://www.theodora.com/maps/greece_map.html

http://www.hl7.org.pk/


32

HL7 Membership•Worldwide•1800 organizations and1000+ individuals

Europe45%

Asia/Oceania15%

North America32%

Other8%

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


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® 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.

• Clinical Document ArchitectureThe 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 ModelThe 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.

• Service Oriented ArchitectureThe 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 SuiteHealth 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 2 Product SuiteHL7’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 ArchitectureThe 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.



• Context Management ArchitectureAimed 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 SuiteHealth 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 2 Product SuiteHL7’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.


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.


Context Management Architecture (CMA)

• 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.


Context Management Architecture (CMA)

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 serviceso 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 processeso 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 levelso Adaptability - Process changes with minimal complexity and effort,

saving time and moneyo 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 SOAo 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?)

toolingo 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)

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.

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.

Functions are the prime elements of the EHR Standard. There are three “groupings” of functions.



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

DefinedStructured

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







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

GT1OBR

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 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 MessageADTÂ01ÂDT_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 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.


MSH - Message Header SegmentSEQ LEN C.LEN DT OPT RP/# TBL# ITEM # ELEMENT NAME

















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


Segment Definition Table 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 12. Min 4, max 53. Defined by HD datatype4. Defined by HD datatype5. Defined by HD datatype6. Defined by HD datatype7. Defined by DTM

datatype8. Min 40, with no

truncation9. Defined by MSG

datatype10. 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ÎII^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 TypesDate/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 TypesCodeValues

CNECoded 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)>


Extended Demographics Data Types 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)


Extended Demographics Data Types

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







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 clarityTerminates a segment recordCannot 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 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 Messageshttp://www.hl7.org/implement/standards/product_brief.cfm?product_id=275


XML Representation

MSH|^~\&|LAB|767543|ADT|767543|199003141304-0500||ACK^ÂCK|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



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Â45ÂDT_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Â45ÂDT_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>



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 Schemahttp://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 MessageADT MessageA01 Admit ADTÂ01ÂDT_A01


Encoding Rules - Sender

Encode each segment in the order specified in the abstract message format

Segment ID identifies the segment

Admit MessageMSHEVNPID[ { 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.LEN 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>

Sent

OLDSent


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>OLD

Sent


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

BED 1 OFF

BED 1 OFF

BED 1 OFF

BED 1 OFF

BED 1 OFF

BED 1 OFF

BED 1 OFF

BED 1 OFF

BED 1 OFF

BED 1 OFF

POTASSIUM 3.5-5.0

BED 1 OFF

POTASSIUM 3.5-5.0

POTASSIUM 3.5-5.0

POTASSIUM 3.5-5.0

BED 1 OFF

POTASSIUM 3.5-5.0

BED 1 OFF BED 1 OFF

BED 1 OFF

BED 1 OFFBED 1 OFF

Critical Care Unit HIS/CIS

Vectra

XU

5/90C

BED 1 OFF

BED 1 OFF

BED 1 OFF

BED 1 OFF

BED 1 OFF

BED 1 OFF

BED 1 OFF

BED 1 OFF

BED 1 OFF

BED 1 OFF

POTASSIUM 3.5-5.0

BED 1 OFF

POTASSIUM 3.5-5.0

POTASSIUM 3.5-5.0

POTASSIUM 3.5-5.0

BED 1 OFF

POTASSIUM 3.5-5.0

BED 1 OFF BED 1 OFF

BED 1 OFF

BED 1 OFFBED 1 OFF

Clinical Data Repository

A/D/T System

Order Filling Application

Accept Ack

Accept + App ACK

No ACK


Sample Message


EVN|A45|200901051530<CR>



PV1||O|PT||||||||||||||||VISIT4<CR>


Messaging Framework

Sending Application


Message Type


[ ]


Messaging Framework

Sending Application


Message Type


[ ]

MSH-3 MSH-5MSH-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







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







July 13, 2015

HL7 v2 Retrospective


HL7 Version 2 Topics

Health Level Seven and the HL7 Family of

Standards



Local Extensions and inter-version

Compatibility


Health Level Seven and the HL7 Family of Standards


Electronic Health Information Exchange

Pharmacies

Physicians

Testing OrganizationsLab/Images

Hospitals

Payors

Employers

County/Community Entities

Patients/ConsumersGovernmentMedicare/Medicaid

Lab results

Patient Data

Orders

ResultsImages

Eligibility

Referral ProcessClaim Status

Claims/Prescriptions

Referral Process

Claim/Status

Health InformationInsurance 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 & Interoperability

191 of 55

Canada

NewZealand

Finland Germany

Netherlands

Japan

United States

United Kingdom

India

Taiwan

China

Czech Republic

Mexico

France

Argentina

Brazil

Australia

Denmark Greece

Ireland

Italy

SpainSweden

Switzerland

SouthKorea

Turkey

Uruguay

Singapore

Romania

CroatiaAustriaColombiaChile

Puerto Rico

Russia

Pakistan

Bosnia and Herzegovina

http://www.theodora.com/maps/greece_map.html

http://www.hl7.org.pk/




Clinical Document ArchitectureThe 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.



• Context Management ArchitectureAimed 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 SuiteHealth 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 2 Product SuiteHL7’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.




Divide and Conquer / Component Reuse

DATA

Next of Kin (NK1)

Insurance (IN1)

Patient Visit (PV1) Patient

Demographics (PID)

Guarantor(GT1)

NK1

IN1

PV1

PID

GT1OBR

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





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 OBX: Observation Result 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 Representation

MSH|^~\&|LAB|767543|ADT|767543|199003141304-0500||ACK^ÂCK|XX3657|P|2.4


Messaging Framework

Sending Application


Message Type


[ ]


Messaging Framework

Sending Application


Message Type


[ ]

MSH-3 MSH-5MSH-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



Local Extensions and inter-version

Compatibility


Q&A


Thank You!

Peace...AMS

Abdul-Malik ShakirPresident and Chief Informatics Scientist

Hi3 Solutions 3500 West Olive Ave, Suite # 300, Burbank, CA 91505

Skype: +1 9098334661 Mobile: (626) 644-4491Email: [email protected]




