08448380779 Call Girls In Civil Lines Women Seeking Men
Introduction to hl7 v2
1. July 13, 2015 Page: 1 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
July 13, 2015
Introductions and Course
Overview
2. 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
3. July 13, 2015 Page: 3 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
4. July 13, 2015 Page: 4 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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
5. July 13, 2015 Page: 5 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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
6. July 13, 2015 Page: 6 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
Course Topics
HL7 v2 Messaging HL7 v3 Messaging
HL7 Clinical
Document
Architecture
HL7 Family of
Standards
HL7 Compliance
and Conformance
7. July 13, 2015 Page: 7 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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
8. July 13, 2015 Page: 8 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
Course Materials
https://drive.google.com/folderview?id=0B-
3JvLjUn5CCfk84VzNqZFY5U2NCbV95WHNNWGp0QWFIWDhZcGh1NzVnVUptZEZvNTlxYkE&usp=sharing
9. July 13, 2015 Page: 9 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
Questions
10. July 13, 2015 Page: 10 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
Hi3 Solutions
3500 W. Olive Ave, Suite
300
Burbank, CA 91505
ww.hi3solutions.com +1 800 918-
6520
11. July 13, 2015 Page: 11 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
July 13, 2015
Health Level Seven (HL7)
and the HL7 Family of Standards
12. July 13, 2015 Page: 12 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
SESSION OVERVIEW
• HEALTH INFORMATION EXCHANGE STANDARDS
• HISTORY OF HEALTH LEVEL SEVEN
• HL7 FAMILY OF STANDARDS
• HL7 HEALTH INFORMATION EXCHANGE STANDARDS
• SESSION RETROSPECTIVE
13. July 13, 2015 Page: 13 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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
14. July 13, 2015 Page: 14 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
15. July 13, 2015 Page: 15 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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
16. July 13, 2015 Page: 16 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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
17. July 13, 2015 Page: 17 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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
18. July 13, 2015 Page: 18 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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
19. July 13, 2015 Page: 19 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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
20. July 13, 2015 Page: 20 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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
21. July 13, 2015 Page: 21 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
Reaching the Limits of Application
Interfaces
Lab
Order Entry ADT
Pharmacy
Radiology
Decision
Support
Electronic
Health Record
Administrative
Systems
?
Enterprise
Systems
?
External
Systems
?
22. July 13, 2015 Page: 22 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
24. July 13, 2015 Page: 24 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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
25. July 13, 2015 Page: 25 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
History of Health Level Seven
26. July 13, 2015 Page: 26 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
27. July 13, 2015 Page: 27 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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
28. July 13, 2015 Page: 28 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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
29. July 13, 2015 Page: 29 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
30. July 13, 2015 Page: 30 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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
31. July 13, 2015 Page: 31 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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. July 13, 2015 Page: 32 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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. July 13, 2015 Page: 33 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
33
Membership Location
2007 figures. Based on the “average 3 individuals per org rule”
34. July 13, 2015 Page: 34 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
HL7 Family of Standards
35. July 13, 2015 Page: 35 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
36. July 13, 2015 Page: 36 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
37. July 13, 2015 Page: 37 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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
38. July 13, 2015 Page: 38 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
39. July 13, 2015 Page: 39 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
40. July 13, 2015 Page: 40 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
41. July 13, 2015 Page: 41 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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
42. July 13, 2015 Page: 42 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
43. July 13, 2015 Page: 43 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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
44. July 13, 2015 Page: 44 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
45. July 13, 2015 Page: 45 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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
46. July 13, 2015 Page: 46 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
47. July 13, 2015 Page: 47 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
Building the foundation of the EHR Standard
EHR Functional Model
48. July 13, 2015 Page: 48 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
49. July 13, 2015 Page: 49 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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)
50. July 13, 2015 Page: 50 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
51. July 13, 2015 Page: 51 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
FHIR DSTU
52. July 13, 2015 Page: 52 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
DSTU Resource List
53. July 13, 2015 Page: 53 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
Resource anatomy
Resources have 3 parts
Defined
Structured
Data
Extensions
Narrative
54. July 13, 2015 Page: 54 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
Human Readable
Summary
Standard Data
Content:
MRN
Name
Gender
Date of Birth
Provider
Extension with
reference to its definition
55. July 13, 2015 Page: 55 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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
56. July 13, 2015 Page: 56 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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
57. July 13, 2015 Page: 57 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
SESSION RETROSPECTIVE
• HISTORY OF HEALTH LEVEL SEVEN
• IMPLICATIONS OF ANSI ACCREDITATION
• HL7 BOARD AND WORKGROUP COMMITTEES
• HL7 AFFILIATES
• HL7 FAMILY OF STANDARDS
58. July 13, 2015 Page: 58 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
Questions
59. July 13, 2015 Page: 59 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
Hi3 Solutions
3500 W. Olive Ave, Suite
300
Burbank, CA 91505
ww.hi3solutions.com +1 800 918-
6520
60. July 13, 2015 Page: 60 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
July 13, 2015
HL7 v2 Abstract Message
Definition
61. July 13, 2015 Page: 61 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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
62. July 13, 2015 Page: 62 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
63. July 13, 2015 Page: 63 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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)
64. July 13, 2015 Page: 64 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
65. July 13, 2015 Page: 65 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
66. July 13, 2015 Page: 66 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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
67. July 13, 2015 Page: 67 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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 “|”
68. July 13, 2015 Page: 68 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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
69. July 13, 2015 Page: 69 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
HL7 v2 Message Segments and Segment Groups
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
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.
70. July 13, 2015 Page: 70 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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)
71. July 13, 2015 Page: 71 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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]
72. July 13, 2015 Page: 72 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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
73. July 13, 2015 Page: 73 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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
[{ ARV }] Access Restrictions 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
[{ ARV }] Access Restrictions 3
74. July 13, 2015 Page: 74 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
SEGMENT DEFINITION
75. July 13, 2015 Page: 75 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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
76. July 13, 2015 Page: 76 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
HL7 v2 Fields, Data Elements and Datatypes
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
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.
77. July 13, 2015 Page: 77 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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
78. July 13, 2015 Page: 78 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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
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
79. July 13, 2015 Page: 79 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
SEGMENT FIELD SEQUENCE
80. July 13, 2015 Page: 80 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
Segment Definition Table
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.
81. July 13, 2015 Page: 81 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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
82. July 13, 2015 Page: 82 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
SEGMENT FIELD LENGTH
83. July 13, 2015 Page: 83 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
Segment Definition Table
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
84. July 13, 2015 Page: 84 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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
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
85. July 13, 2015 Page: 85 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
Example LEN and C.LEN
1. Min 1, max 1
2. Min 4, max 5
3. Defined by HD datatype
4. Defined by HD datatype
5. Defined by HD datatype
6. 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
86. July 13, 2015 Page: 86 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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
87. July 13, 2015 Page: 87 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
DATATYPES
88. July 13, 2015 Page: 88 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
Segment Definition Table
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|
89. July 13, 2015 Page: 89 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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
90. July 13, 2015 Page: 90 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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
91. July 13, 2015 Page: 91 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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
92. July 13, 2015 Page: 92 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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
93. July 13, 2015 Page: 93 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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
94. July 13, 2015 Page: 94 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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
95. July 13, 2015 Page: 95 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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
96. July 13, 2015 Page: 96 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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)>
97. July 13, 2015 Page: 97 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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)
98. July 13, 2015 Page: 98 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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)>
99. July 13, 2015 Page: 99 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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
100. July 13, 2015 Page: 100 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
OPTIONALITY AND REPETITION
101. July 13, 2015 Page: 101 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
Segment Definition Table
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
102. July 13, 2015 Page: 102 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
Segment Definition Table
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
103. July 13, 2015 Page: 103 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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
104. July 13, 2015 Page: 104 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
VALUE SET TABLES
105. July 13, 2015 Page: 105 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
Segment Definition Table
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
106. July 13, 2015 Page: 106 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
HL7 v2 Message Code Tables and Code Table Items
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
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.
107. July 13, 2015 Page: 107 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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
108. July 13, 2015 Page: 108 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
109. July 13, 2015 Page: 109 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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
110. July 13, 2015 Page: 110 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
Imported Tables
Third-party definitions published in the HL7
Standard
Example includes list of valid units of measures
imported from ISO
111. July 13, 2015 Page: 111 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
Local Tables
Local definitions in non-HL7 published table
112. July 13, 2015 Page: 112 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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
113. July 13, 2015 Page: 113 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
DATA ELEMENTS
114. July 13, 2015 Page: 114 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
Segment Definition Table
Item# - Item Number
Definition: Unique identifier of data element within HL7
Element Name
Definition: Unique name of a data element within HL7
115. July 13, 2015 Page: 115 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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
116. July 13, 2015 Page: 116 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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
117. July 13, 2015 Page: 117 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
SESSION RETROSPECTIVE
• 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
118. July 13, 2015 Page: 118 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
Q&A
119. July 13, 2015 Page: 119 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
Hi3 Solutions
3500 W. Olive Ave, Suite
300
Burbank, CA 91505
ww.hi3solutions.com +1 800 918-
6520
120. July 13, 2015 Page: 120 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
July 13, 2015
HL7 v2 Message Construction
Rules
121. July 13, 2015 Page: 121 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
SESSION OVERVIEW
• Message Delimiters
• MESSAGING FRAMEWORK
• PARTICIPATING APPLICATIONS
• MESSAGE TYPES AND VERSION
• MESSAGE ENCODING RULES
• MESSAGE PROFILES
• ACKNOWLEDGEMENTS
• COMMUNICATION ENVIRONMENT
122. July 13, 2015 Page: 122 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
MESSAGE DELIMITERS
123. July 13, 2015 Page: 123 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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
MSH-1, MSH-2: Message Delimiters
124. July 13, 2015 Page: 124 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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
125. July 13, 2015 Page: 125 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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
126. July 13, 2015 Page: 126 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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
127. July 13, 2015 Page: 127 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
128. July 13, 2015 Page: 128 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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., |""|).
130. July 13, 2015 Page: 130 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
XML Encoding Rules for Version 2 Messages
http://www.hl7.org/implement/standards/product_brief.cfm?product_id=275
131. July 13, 2015 Page: 131 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
XML Representation
MSH|^~&|LAB|767543|ADT|767543|199003141304-
0500||ACK^^ACK|XX3657|P|2.4
132. July 13, 2015 Page: 132 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
Messaging Framework
133. July 13, 2015 Page: 133 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
HL7 Conceptual Approach
Critical Care Unit
ADT System
Acknowledgement Message
Initiating Message
Clinical Data Repository
Initiating Message
134. July 13, 2015 Page: 134 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
Messaging Framework
Sending
Application
Receiving
Application
Message Type
AcknowledgementEncoding Rules Message Profile
[ ]
135. July 13, 2015 Page: 135 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
MSH – Message Header
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
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
136. July 13, 2015 Page: 136 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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
138. July 13, 2015 Page: 138 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
139. July 13, 2015 Page: 139 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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>
140. July 13, 2015 Page: 140 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
MESSAGE TYPES AND VERSION
141. July 13, 2015 Page: 141 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
142. July 13, 2015 Page: 142 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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 ( )
143. July 13, 2015 Page: 143 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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>
144. July 13, 2015 Page: 144 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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
145. July 13, 2015 Page: 145 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
Table 0354 – Message Structure
146. July 13, 2015 Page: 146 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
HL7 v2.x Messaging Schema
http://www.hl7.org/implement/standards/product_brief.cfm?product_id=185
HL7 Version 2.3.1 Messaging Schemas
147. July 13, 2015 Page: 147 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
MESSAGE ENCODING RULES
Encoding Rules
148. July 13, 2015 Page: 148 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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
149. July 13, 2015 Page: 149 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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 ]
150. July 13, 2015 Page: 150 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
Encoding Rules - Sender
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
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
151. July 13, 2015 Page: 151 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
Encoding Rules - Sender
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>
152. July 13, 2015 Page: 152 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
Encoding Rules - Sender
End each segment with the segment terminator
PID|...|Last Field<CR>
153. July 13, 2015 Page: 153 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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>
154. July 13, 2015 Page: 154 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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>
156. July 13, 2015 Page: 156 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
158. July 13, 2015 Page: 158 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
ACKNOWLEDGMENTS
Acknowledgement
159. July 13, 2015 Page: 159 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
160. July 13, 2015 Page: 160 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
General Acknowledgment Message
161. July 13, 2015 Page: 161 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
Message Acknowledgment Segment
162. July 13, 2015 Page: 162 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
Error Segment
163. July 13, 2015 Page: 163 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
168. July 13, 2015 Page: 168 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
169. July 13, 2015 Page: 169 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
Middleware Vendor Products
170. July 13, 2015 Page: 170 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
SESSION RETROSPECTIVE
• Message Delimiters
• MESSAGING FRAMEWORK
• PARTICIPATING APPLICATIONS
• MESSAGE TYPES AND VERSION
• MESSAGE ENCODING RULES
• MESSAGE PROFILES
• ACKNOWLEDGEMENTS
• COMMUNICATION ENVIRONMENT
171. July 13, 2015 Page: 171 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
Q&A
172. July 13, 2015 Page: 172 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
Hi3 Solutions
3500 W. Olive Ave, Suite
300
Burbank, CA 91505
ww.hi3solutions.com +1 800 918-
6520
173. July 13, 2015 Page: 173 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
July 13, 2015
HL7 v2 Inter-Version Compatibility
and Local Extensions
174. July 13, 2015 Page: 174 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
SESSION OVERVIEW
• Inter-version Compatibility
• Local Extensions
• MESSAGES
• TRIGGER EVENTS AND SEGMENT GROUPS
• SEGMENTS AND DATATYPES
175. July 13, 2015 Page: 175 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
INTER-VERSION COMPATIBILITY
176. July 13, 2015 Page: 176 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
177. July 13, 2015 Page: 177 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
Version compatibility
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.
178. July 13, 2015 Page: 178 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
LOCAL EXTENSIONS
179. July 13, 2015 Page: 179 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
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