HL7 Review

HL7 – stands for Health Level 7 – level seven refers to the top layer of the OSI object
model (application layer).

HL7 was originally an adhoc group to help standardize the communication between
incompatible healthcare applications. Most were interface programmers.

Started as v2.0. Current ANSI accepted version is v2.5. Very backward compatible.

The HL7 Version 2 Messaging Standard — Application Protocol for Electronic Data
Exchange in Healthcare Environments — is considered to be the workhorse of data
exchange in healthcare and is the most widely implemented standard for healthcare
information in the world.

HL7 also responsible for :

1. CCOW - Clinical Context Object Workgroup
a. The context is primarily comprised of the identity of real-world things,
such as patients, and real-world concepts, such as encounters, that
establish the common basis for a consistent set of user interactions with a
set of healthcare applications
2. Arden Syntax
a. knowledge bases that are represented as a set of discrete modules.
Referred to as a Medical Logic Module (MLM), each contains sufficient
knowledge to make a single decision. Contraindication alerts,
management suggestions, data interpretations, treatment protocols, and
diagnosis scores are examples of the health knowledge that can be
represented using MLMs.
b. Simplified programming language. Allows non professional programmers
to create a module.
3. Clinical Document Architecture
a. an exchange model for clinical documents, such as discharge summaries
and progress notes. Leverages the use of XML, the HL7 Reference
Information Model (RIM) and coded vocabularies, the CDA makes
documents both machine-readable, are easily parsed and processed
electronically, human-readable.
4. Reference Information Model
a. Vocabulary Domains
b. Jim Cimino is Vocabulary co-chair.

Other standards include DICOM (X-rays), X12 (billing), ACPDP (pharmacy) ASTM
(clinical).

Each standard is published like a book with chapters. Chapter 2 is the chapter on
Control, the section that covers how to encode a message.

HL7 designed around the assumption that there is a real world event that triggers the
exchange of messages. Examples of trigger event is patient admission and ER visit..

When messages are sent, the recipient application returns an “ACK” message. Say to
sender, “I got the message”. The ACK means that the recipient accepts responsibility
for the message. Currently standard is recipient sends a “commit/accept” message.
Can be in two stages. Need both to assume responsibility. Not implemented.

ACK message contain one of 3 codes

1. AA – application accept - “Got it”
2. AE – application error - “it will never work”
3. AR – Application reject – “I can’t handle it now”

Message format
1. <SB> = start block (0x0B)
2. <dddd = message
3. <EB> = end Block (0x1C)
4. <CR> = carriage return (0x0D)

Message defined as atomic unit of data transferred.

Information sent in segments, each segment separated with “<cr>”
Messages have message type, a 3 letter code (MSH, EVN, ADT)
Messages have a trigger event
Messages are encoded as ER7 (pipes, bars, carat, ampersand) or as XML
(<patname></patname>)

Message Definition rules (how a message is structured)

1. MSH is always first
2. Order is important
3. “[…]” is optional segment
4. “{…}” is repeat segment

Receiving rules
1. Ignore extra stuff that is present in the message but is not expected.
2. If something is missing, assume it is not present. NOT THE SAME A NULL
VALUE

Trigger events in-patient Management

1. A01 admit (bed assigned)
2. A04 visit (no bed assigned)
3. A03

HL7 v3 is under development that is big departure from v2.x. The flexibility of v2.x also
makes it impossible to do conformity testing between vendor products. Version 3
addresses these and other issues by using a well-defined methodology based on a
reference information (i.e., data) model. It will be the most definitive standard to date.
Using rigorous analytic and message building techniques and incorporating more trigger
events and message formats with very little optionality, HL7's primary goal for Version 3
is to offer a standard that is definite and testable, and provide the ability to certify
vendors' conformance. Version 3 uses an object-oriented development methodology and
a Reference Information Model (RIM) to create messages. The RIM is an essential part
of the HL7 Version 3 development methodology, as it provides an explicit representation
of the semantic and lexical connections that exist between the information carried in the
fields of HL7 messages
A little more about HL7 based on my observations -- ongoing work, activities, opinions,
projects, etc.

o Introduction to HL7 tutorial session (taught by David John Marotta from

DT7Software) clarified some common misunderstandings. HL7 is as an
application protocol for electronic data exchange in health care environments.
However, many people consider HL7 as a standard just for messaging in the
medical domain. The HL7 tutorial explained that the topics covered by HL7
actually go far beyond messaging. For example, Arden Syntax, CCOW, and
CDA are all considered as non-messaging HL7 activities. Moreover, HL7 is not
just another standard in the medical domain; rather, it acts like a big umbrella
that brings together many other healthcare standards such as DICOM, IEEE
P1157 Medix, ASTM E31, etc, to facilitate ordering, and ADT (Admission,
Discharge and Transfer) scheduling. Regarding messaging, although HL7
version 2.x has more than ten chapters, the tutorial focused on four of them for
general audience: Control and query (Chapter 2), Patient administration (Chapter
3), Orders (Chapter 4), and Observation reporting (Chapter 7).

o In CDS TC (Clinical Decision Support Technical Committee) and CPG SIG

(Clinical Practice Guideline Special Interest Group) Working Group Meetings,
Bob Greenes (Harvard U.) gave a presentation on updates of Guideline
Expression Language (GELLO) in CDS TC Working Group Meeting. GELLO is
an object-oriented guidelines procedural language that includes prototypes of
expression and query languages. It is designed to be able to record decision
logic of existing MLM in Arden Syntax and facilitate the knowledge modeling.
GELLO is incomplete yet, and several issues such as the incorporation of some
commands, infix operators, and development of IDE (Integrated Development
Environment) for writing expressions, statements and queries still need more
work.

o The joint meeting between CDS TC with EHR (Electronic Health Records)
focused on the topic of VMR (Virtual Medical Record). VMR aims to find the
minimal set of record types and attributes required to achieve semantic
interoperability. On the one hand, the benefits of VMR are: first, it makes it
possible to reuse the most expensive parts of DSS (Decision Support Systems)
such as Guideline Interpreter software component and knowledge base. Second,
it decouples these from terminology or schema changes. Third, it facilitates rapid
deployment on new clinical systems. On the other hand, appropriate
terminology-mapping knowledge and software components are needed and
system vendor might have problems with it when mapping their system into VMR
format. The discussion about VMR will keep going on and a possible direction is
to develop VMR as a subset of platform-neutral EHR model in future HL7 work.

o In Vocabulary session, topics reviewed include the historical origins of clinical

terminology, the strengths and weaknesses of the present terminology
alternatives, and basic characteristics that terminologies need if they are to
support sophisticated use and re-use of clinical data. In my opinion, the primary
lesson is that terminologies, if they are to be really useful, need to be in the form
of ontologies, and that this is the direction that newer terminologies are moving.
In terms of RIM (Reference Information Model), the current model of HL7
message content, an important concept “realms” is introduced as an
 administrative jurisdiction (country, agency, state). To promote interoperability,
HL7 Messages in a particular realm prescribe one terminology code set per one
type of message usage.

o In Clinical Guidelines Special Interest Group meeting, SAGE Project presented

their goal “to develop a standards based sharable active guidelines
environment”. Funded by the U.S. Department of Commerce's National Institute
of Technology's (NIST) Advance Technology Program, the three-year, $9.2
million grant will support SAGE to create and distribute electronic clinical
guidelines-also known as "best medical practices". The project is led by IDX
Systems (Nasdaq: IDXC), with Apelon, Intermountain Health Care, Mayo Clinic,
Stanford University, and University of Nebraska as research partners. Stanford,
Mayo, IHC and the University of Nebraska will provide clinical and academic
expertise in the development of guideline models and knowledge representation.
Apelon, which specializes in the application of structured medical vocabularies to
clinical information systems, will provide software and terminology services to
assist in the development and deployment of the guideline knowledge. The core
reference terminologies will be SNOMED, LOINC and RxNORM. Deliverables of
SAGE include an interoperable guideline model, an interoperable guideline
workbench, and a guideline deployment system.

HL7 Technical Committees:

Architectural Review Board

This group supports the HL7 mission to create and promote its standards by
helping to assure that the body of HL7 standards and recommendations is
internally congruent, consistent with appropriate measures of quality and has
been prepared according to the appropriate HL7 methodology.

Clinical Context Object Workgroup

With an emphasis on the point-of-use of applications, this group supports the HL7
mission to create and promote its standards by developing specifications that enable the
visual integration of healthcare applications. Applications are visually integrated when
they work together in ways that the user can see in order to enhance the user’s ability to
incorporate information technology as part of the care delivery process.

Clinical Decision Support

Co-chairs: Robert Greenes MD PhD

Partners Healthcare/Brigham & Women's Hospital
Phone: 617-732-6281
Email: [email protected]

Robert Jenders M.D.

Cedars-Sinai Medical Center
Phone: 310-423-2105
Fax: 310-423-0112
 Email: [email protected]

Ian Purves
Sowerby Centre for Health Informatics at Newcastle
Phone: +44 (0) 191 256 3100
Fax: +44 (0) 191 256 3099
Email: [email protected]

R. Matthew Sailors
University of Texas-Houston, Dept. of Surgery
Phone: 713.500.6192
Email: [email protected]

The Technical Committee will focus on issues related to single-patient-focused health

care decision support messaging. The committee will focus on the development of
messages independent of any implementation of clinical logic. The TC will also be
responsible for the support and development of Arden Syntax for Medical Logic
Systems. The Arden Syntax will serve as a test case in the development of general
messaging schemes.

The role of this TC is to (a) identify the scope and range of data elements required for
the functionality of DS applications, (b) work with other SIGs, TCs, or outside
organizations to identify appropriate controlled vocabulary for encoding those data
elements, (c) identify or define messages (and objects) required to support the specific
information exchange needs of DS applications, both as feeders to DS applications and
as output from DS applications.

Control/Query

The Control/Query Committee is responsible for defining the details of the message
transport services including encoding rules and auxiliary protocols, maintenance of
common datatypes, definition of the query framework, and definition of the framework for
master files support.

Vocabulary

Co-Chairs

Chris Chute Paul Frosdick

Mayo Clinic/Foundation NHS Information Authority
Phone: 507-284-5506 Phone: 44-121-3330331
Fax: 507-284-0360 Fax: 44-121-3330334
Email: [email protected] Email: [email protected]

Stan Huff Ted Klein

Intermountain Health Care Klein Consulting, Inc.
Phone: 801-442-4885 Phone: 631-924-6922
Fax: 801-442-6996 Fax: 631-924-8718
Email: [email protected] Email: [email protected]

Objective

To identify, organize and maintain coded vocabulary terms used in

HL7 messages.

Goal

Provide an organization and repository for maintaining a coded

vocabulary that, when used in conjunction with HL7 and related
standards, will enable the exchange of clinical data and information
so that sending and receiving systems have a shared, well defined,
and unambiguous knowledge of the meaning of the data
transferred. The purpose of the exchange of clinical data includes,
but is not limited to: provision of clinical care, support of clinical and
administrative research, execution of automated transaction
oriented decision logic (medical logic modules), support of
outcomes research, support of clinical trials, and to support data
reporting to government and other authorized third parties. To
achieve this goal, we will work cooperatively with all other groups
that have an interest in coded vocabularies used in clinical
computing. Some of the groups that we will seek to work closely
with include: standards development organizations, creators and
maintainers of vocabularies, government agencies and regulatory
bodies, clinical professional specialty groups, vocabulary content
providers, and vocabulary tool vendors.

Definitions

Data element
Any data field, component, or subcomponent of HL7.
Domain
The set of all appropriate values for a data element. For a coded data
element, the coded domain is the set of all coded vocabulary items that
are appropriate values of the coded data element.
Coded Value
A coded vocabulary item that is a member of a coded domain. This
corresponds to a table entry in existing HL7 tables.

Background

A. There are at least five types of coded domains referenced by the

HL7 standard:
1. Domains whose content is entirely controlled by HL7
committees. This category includes tables that enumerate
 trigger events, message types, segment identifiers, format
types, event types, etc.
2. Domains where HL7 committees have included incomplete
lists of terms or "starter sets" for a given domain. This
category includes tables that enumerate sex, marital
status, race, ethnicity, order priorities, etc.
3. Domains that have a specific use, but no data elements
are defined, and it is assumed that the coded values used
would come from one or more available coding systems
such as SNOMED International, CPT, ICD-9CM, ICD-10,
UMLS Metathesaurus, LOINC, Read codes, NDC codes,
etc. This category includes tables that define Universal
Service IDs, Observation IDs, Drug ID, Component Drug
ID, etc.
4. Domains that fill the value field in an OBX message for a
specific Observation ID. It is assumed that the coded terms
used would come from one or more available coding
systems. For example, if the Observation ID were set to
"Red Cell Antibody" the possible values would be Kell,
Duffy A, Duffy B, etc.
5. Domains that are referenced in the HL7 standard, but the
structure and contents of the tables are assumed to be
locally defined. This category includes, user identifiers,
codes that represent clinics or facilities, and identifiers for
nursing divisions, rooms, beds, etc.
B. The same meaning can often be expressed by a single code, or
by a combination of codes. For instance, the description of how a
laboratory specimen was collected might be indicated by a single
term Midstream-clean-catch, or by two terms urine and clean
catch. The ability to know how atomic terms are related to
molecular terms is critical to the transformation of data in
interfaces. This situation is also known as pre vs. post
coordination of terms, or as composition-decomposition.
C. HL7 tables do not currently exist to support hierarchical
inferencing. Hierarchical inferencing would allow a user or process
to send an HL7 query message that asked, "Is the patient taking
any penicillin type drugs?" Having a common set of hierarchies
that can be referenced by decision support modules is a critical
need as the work of the decision support SIG progresses. It is
proposed that tables be added to HL7 that support this kind of
inferencing. These tables would be specifically focused on
capabilities needed by HL7 and there would be no attempt to
make these tables a comprehensive knowledge base of medicine.
D. HL7 messages exist to update "Master Files" across
communicating systems. The vocabulary SIG should investigate
suitability of using these messages to update coded domains
between systems.

HL7 Special Interest Groups:

Arden Syntax

Co-Chairs: Robert Jenders M.D.

Cedars-Sinai Medical Center
Phone: 310-423-2105
Fax: 310-423-0112
Email: [email protected]

R. Matthew Sailors
University of Texas-Houston, Dept. of Surgery
Phone: 713-500-6192
Email: [email protected]

This group supports the HL7 mission to create and promote its standards by
maintenance and further development of the Arden Syntax for Medical Logic Systems, a
standard for representing and sharing clinical knowledge in procedural format.

Attachments

This group supports the HL7 mission to create and promote its standards. The
Attachment Special Interest Group standardizes the supplemental information needed to
support health care insurance, and other e-commerce transactions. Our purpose is to
encourage the use of HL7 for uniform implementation of this supplemental information.
An important effort as guided by the Board of HL7 is to work jointly with ASC X12N
(Insurance), to assist in the implementation of the Administrative Simplification
provisions of HIPAA mandates, to provide on-going support, and to represent HL7 in the
HIPAA Designated Standards Maintenance Organization (DSMO) efforts.

This SIG coordinates industry input to produce and maintain guides for HL7 messages
that can stand alone or be embedded within ASC X12N transactions.

Clinical Guidelines

Co-chairs: Robert Greenes MD PhD

Partners Healthcare/Brigham & Women's Hospital
Phone: 617-732-6281
Email: [email protected]

Samson Tu
Stanford Medical Informatics
Stanford University
Phone: 650-723-6979
Email: [email protected]

The HL7 GLIF initiative is a special interest group of HL7 formed to create the standard
for the specification of clinical practice guidelines to facilitate their integration into health
care systems, electronic medical records, and a variety of applications. Participation is
open to all parties.

Community Based Health Services

The Community Based Health Services (CBHS) is a special interest group of HL7 . The
mission of the CBHS-SIG is to support the message development effort for Community
Based Health Services within the framework of HL7 Standards, in order to promote
adequate information exchange between Community Based and Acute Care service
domains. The scope of the CBHS-SIG includes but is not limited to home health,
hospice, long term care, mental health and other community based providers.

Conformance

This group supports the HL7 mission to create and promote its standards by providing a
consistent mechanism to specify conformance via HL7 V2.x message profiles. The
Conformance SIG will also act in an advisory role to the HL7 Modeling & Methodology
Technical Committee regarding conformance topics.

Clinical Genomics

This group supports the HL7 mission to create and promote its standards by enabling
the communication between interested parties of the clinical and personalized genomic
data. The focus of clinical genomics work is the personalization (differences in
individual's genome) of the genomic data and the linking to relevant clinical information.

Electronic Health Records

This group supports the HL7 mission to create and promote its standards by defining a
high-level architecture to support a variety of interoperability requirements for electronic
health records.

Government Projects

The goal of the Government Projects SIG is to coordinate the integration of government
health informatics requirements into the HL7 standards. The SIG will address Federal,
State and local government requirements.

Imaging Integration

Imaging Integration collects, reviews, develops and documents use cases, information
structures and message content related to ordering and reporting of non-textual data
and associated information, including images themselves. Imaging Integration promotes
the interoperation of imaging systems, PACS and associated radiological oriented
systems with information systems that use HL7.

Java

This group will define application programming interfaces (APIs) to HL7 version 3
artifacts for the Java platform. While the group's focus will be the definition of APIs, it will
also promote the development of implementations to validate the API, to serve as
reference implementations, and as tools. By providing these APIs and promoting
implementations, this group will hasten the adoption of HL7 version 3 by healthcare
application providers, many of whom want to develop for the Java platform. By doing this
work for the Java platform, the group will also incidentally provide a model for HL7
implementations that assure interoperability in other popular programming languages,
further encouraging development of HL7 Version 3-compliant applications.

Laboratory, Automated and Point of Care Testing

The goal of the "Laboratory, Automated, and Point of Care Testing SIG" is to meet the
needs for communication among automated clinical lab systems, instruments, devices,
and information systems in various implementations of clinical lab, point of care, and
automated testing by developing interoperable messaging.

Medication Information

This group helps to assure that the HL7 messages and models concerning medication
related information - including prescribing, dispensing, and administering medication -
address all of the requirements of the many stakeholders and variations in different
countries.

Security and Accountability

This Secure Transactions SIG will focus on the use of HL7 in communications
environments where there is a need for authentication, encryption, non-repudiation, and
digital signature. This group will focus on the mechanisms for secure HL7 transactions
and not on standardizing security policies. It will, however, ensure that the mechanisms
are present to implement security policies. It will report to HL7 on available options and
recommend actions that the organization may take to address these needs. The early
activities of the group will include reviewing the work of other standards groups in this
area including, but not necessarily limited to, ANSI X3, ASTM, CEN, CPRI, X12, HL7
Germany, U.N. Edifact, and the general Internet community.

Templates

This group supports the HL7 mission to create and promote its standards by
creating the procedures for creation and management of HL7 Templates. An
HL7 template is a data structure, based on the HL7 Reference Information
Model, that expresses the data content needed in a specific clinical or
administrative context.

XML

This group supports the HL7 mission through recommendations on use of Extensible
Markup Language (XML) standards for all of HL7 's platform- and vendor-independent
healthcare specifications.
Question 1.

Hospital A has added Information Systems ad hoc. When a department saw a need for
a computer app, they made the purchase decision without thought to any other
department. As a result they have a hodge-podge of systems. Hospital B also operated
the same way. Mega Health Care has decided to buy both hospitals. You have been
assigned the job of leading the integration of both hospitals into MegaHealth care.
Consider your options on how to accomplish this. Pick your favorite and defend your
position.

Question 2.

You are an Informatics consultant who is brought into a large medical group in order to
advise on the group’s IT system. The group has an integrated system from a single
vendor that handles all the administrative duties and some clinical information but it is far
from a total EMR. The group would like to implement a full EMR. The vendor of the
current system cannot give a time frame for when a full EMR implementation will be
available. However, they will provide you access to their business object so that you can
do a custom add-on. What would you recommend to the group?

Question 3.

HL7 v2.x is highly backward compatible. This allows great flexibility in messaging
between old legacy applications and newer applications. HL7 v3 is a different animal. It
is much less flexible based on adherence to a reference model. Describe a scenario in
which adherence to v2.x is the preferred answer and why this is the preferred solution.
Do the same for v3.