The hitchhiker's guide to health level seven

© 2015 Health Level Seven ® International. All Rights Reserved. HL7 and Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.© 2018 Healthcare Information Integration Infrastructure Solutions. All Rights Reserved
The Hitchhiker's guide to
Health Level Seven
HL7, the ‘Babel Fish’ of
Health Information Systems
Communication

Introduction
 Presentation Title: The hitchhiker’s guide to Health Level Seven
 Summary: This presentation provides a concise overview of the history,
operational framework, and standards of Health Level Seven (HL7). It is
intended to be a guide to those seeking to engage in the HL7 standards
development effort or to be consumers of HL7 products and services.
 Target Audience: The primary intended audience for this presentation are
individuals curious about but not yet engaged in HL7 activities or the use of
HL7 standards. Those already familiar with or engaged in the use or
development of HL7 standards may also find the distillation of the various
aspects of HL7 useful to their work.

AbdulMalik Shakir - President and Chief Informatics Scientist, Hi3 Solutions
 I am an experienced healthcare informatics
standards expert.
 I specialize in the application of health
information technology standards for use in:
 health information exchange,
 clinical decision support, and
 semantic interoperability.
 My primary area of interest is facilitating the
discovery and application of evidence
based best practices in health care.

My HL7 history and experience
 I have been, and continue to be, an active
member of HL7 since September 1991.
 I currently co-chair the HL7 Modeling and
Methodology Workgroup.
 My HL7 History:
 Chaired the HL7 Education Workgroup from 1996
to 2010.
 Received the HL7 volunteer of the year award in
1997
 Served on the HL7 Board of Directors from 2000
to 2005
 Received the HL7 Fellowship award in 2012
“The Hitchhiker's Guide to the Galaxy is
an indispensable companion to all
those who are keen to make sense of
life in an infinitely complex and
confusing Universe, for though it cannot
hope to be useful or informative on all
matters, it does at least make the
reassuring claim, that where it is
inaccurate it is at least definitively
inaccurate. In cases of major
discrepancy it's always reality that's got
it wrong.” ~ Douglas Adams, The Hitchhiker's Guide to the Galaxy

Companion Guide
The broad narrative of Hitchhiker follows the misadventures of the last
surviving man, Arthur Dent, following the demolition of the planet Earth by a
Vogon constructor fleet to make way for a hyperspace bypass.
Dent is rescued from Earth's destruction by Ford Prefect, a human-like alien
writer for the eccentric, electronic travel guide “The Hitchhiker's Guide to the
Galaxy”, by hitchhiking onto a passing Vogon spacecraft.
Following his rescue, Dent explores the galaxy with Prefect and encounters
Trillian, another human who had been taken from Earth prior to its
destruction by the President of the Galaxy, the two-headed Zaphod
Beeblebrox, and the depressed Marvin, the Paranoid Android.

Presentation Topics
HL7 Specification Domains
HL7 Cross Paradigm Specifications
HL7 Information Exchange Standards
HL7 Operational Framework
Introduction to Health Level Seven

The Hitchhiker's guide to Health Level Seven
Early History
Product
Families
ANSI / ISO
Accreditation
International
Affiliates
Business
Architecture
HL7
Development
Framework
Governance
and
Operations
Service-Aware
Interoperability
Framework
Version 2
Messaging
Fast
Healthcare
Interoperability
Resources
Version 3
Messaging
Clinical
Document
Architecture
Domain
Analysis
Conformance
Datatypes
Vocabulary
Health Care
Delivery and
Finance
Knowledge
Representation
and Decision
Support
Public and
Population
Health
Biomedical
Research and
Regulation

Introduction to Health Level Seven
International
Affiliates
ANSI / ISO
Accreditation
Product
FamiliesEarly History

The Babel Fish
“The Babel fish is small, yellow, leech-like,
and probably the oddest thing in the universe.
It feeds on brain wave energy, absorbing all
unconscious frequencies and then excreting
telepathically a matrix formed from the
conscious frequencies and nerve signals
picked up from the speech centers of the
brain, the practical upshot of which is that if
you stick one in your ear, you can instantly
understand anything said to you in any form
of language.” ~ Douglas Adams, “The Hitchhiker's Guide to the Galaxy”

Health Level Seven
Health Level Seven International (HL7)
is a not-for-profit, ANSI-accredited
standards developing organization
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.

Early History of Health Level Seven
• The HL7 Working Group meets and has met three times a year ever 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 v1.0 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.

HL7 Board, August 1992.
Front row (Left to right): Phil Bartleson, Ed Hammond, Sue Campbell, Dave Carlson, John Quinn.
Back row: Philip Caillouet, Wes Rishel, Mike Glickman, David Kates, Mark McDougall.

ANSI Accreditation
• June 12, 1994 – HL7 becomes an American National Standards Institute (ANSI)
accredited Standards Developing Organization
• ANSI 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.
• 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, however, ANSI allows
standards developing organizations to charge an administrative participation fee to non-
members who wish to participate.
• Balance of interest is a principle ingrained in decision making practices that ensures that no
single interest category constitutes a majority in a consensus pool. HL7 defines an interest
category as either membership category (Affiliate) or membership classification
(vendor/manufacturer, consultant, healthcare provider/user, associations/government agencies,
payer/third party administrator, pharmaceutical, or general interest)

International Affiliates
1. The HL7 Standard should be a single entity including
those elements that support the needs of different
realms.
2. Individual HL7 International Affiliates have the right to
determine the requirements of their realm and to
develop elements of the HL7 Standard that meet those
requirements.
3. Individual HL7 International Affiliates have
a responsibility to ensure that they do not develop
elements of the HL7 standard in a way that duplicates
or conflicts with other elements of the HL7 standard.
4. HL7 determines appropriate points within the Standard
at which localization is appropriate, useful and
manageable.
5. Where localization to meet the needs of a realm
represented by an International Affiliate appears to
require a change to foundational artifacts or to any
aspect of methodology or infrastructure, the suggested
change shall be resolved through a harmonization
process.
Principles of Approach
to Localization

The HL7 International Council
 Mission
The HL7 International Council supports the HL7 mission to create and promote its standards by helping to assure that the needs, issues and other input of the
HL7 International Affiliates are recognized and effectively acted on by the HL7 organization.
 Charter
The International Council provides a forum for the HL7 International Affiliates and other interested HL7 members to communicate and exchange views as well
as discuss issues regarding the international development, adoption, application and implementation of the HL7 standard.
The International Council collates, evaluates and actions - for processing by other entities within HL7 - any needs, issues and other input expressed and
agreed to by the HL7 International Affiliates.
The International Council recommends to the Board of Directors actions and policies on behalf of the International Affiliates.
The International Council advises the Technical Steering Committee and Board of Directors on matters relating to areas of standardization that are relevant to
the International Affiliates.
 Formal Relationships With Other HL7 Groups
The International Council may establish, with Board approval, formal liaisons to other HL7 groups.
The International Council shares with the Board the responsibility to consult with each other on issues affecting the International Affiliates and their members.
 Formal Relationship With Groups Outside of HL7
The International Council evaluates and recommends formal relations with other international and regional standards bodies (e.g., CEN, ISO, etc.)

Product Families
• Fast Healthcare Interoperability Resources Specification (FHIR)
FHIR is a next generation standards framework that combines the best features of HL7’s Version 2, Version 3 and CDA® product lines while leveraging the latest web standards and applying a tight focus on
implementation FHIR solutions are built from a set of modular components called “Resources”. These resources can be easily assembled into working systems that solve real world clinical and administrative
problems.
• Clinical Document 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 functions for healthcare settings. HL7 has developed or is developing profiles for areas such as child health, emergency care, long term care,
behavioral health and vital statistic reporting.
• Service Oriented 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 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’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.

Product Family Groups
• Information Exchange Standards
• Fast Healthcare Interoperability Resources Specification (FHIR)
FHIR is a next generation standards framework that combines the best features of HL7’s Version 2, Version 3 and CDA® product lines while leveraging the latest web standards and applying a tight focus on
implementation FHIR solutions are built from a set of modular components called “Resources”. These resources can be easily assembled into working systems that solve real world clinical and administrative
problems.
• Clinical Document 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.
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’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.
• System Functional Standards
• 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 functions for healthcare settings. HL7 has developed or is developing profiles for areas such as child health, emergency care, long term care, behavioral health
and vital statistic reporting.
• Service Oriented 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 Operational Framework
Service-Aware
Interoperability
Framework
Governance
and
Operations
HL7
Development
Framework
Business
Architecture

Business Architecture
Board of
Directors
Technical
Steering
Committee
Steering
Divisions
Working
Groups

Technical
Steering
Committee
Steering
Divisions
Working
Groups
Board of
Directors
2018

Board of
Directors
Technical
Steering
Committee
Steering
Divisions
Working
Groups
 The HL7 Technical Steering Committee (TSC) is responsible for overseeing the execution of
standards development within HL7 by assuring that the efforts of the WG are in line with the
product and services strategy set forth by the Board.
 The TSC provides a coherent architecture and development process by refining the HL7-
adopted Services-Aware Interoperability Framework Canonical Definition (SAIF-CD) and
specializes the SAIF-CD to develop an Implementation Guide as the HL7 Technical
Architecture, development methodologies, and work processes to be used by the WG in
developing HL7 consensus-based standards specifications.
 The TSC oversees the management function of the WGs and will delegate the governance
needs of the WGs as needed, assuring that the WGs work smoothly together and cover the
work scope in a consistent manner..
 The TSC serves as the primary communication vehicle for the technical operations of HL7
and serves as the technical authority of HL7, communicating status and guidelines regarding
standards and operations.
 The composition of the TSC is described in section 09.01 of the GOM, and additional ex
officio membership as described in sections 07.02 (Chair), 07.03 (Chair-elect).

Board of
Directors
Technical
Steering
Committee
Steering
Divisions
Working
Groups
Administrative Steering Division Infrastructure Steering Division
Clinical Steering Division Organizational Support Steering Division
The Administrative Steering Division (ASD) focuses
on the creation of basic patterns and common
messages, including knowledge representation and
access, that are used to convey domain specific
content.
The Infrastructure Steering Division (ISD) focuses on
providing the fundamental tools and building blocks
that other Work Groups should use to build the
standards, and upon the technology infrastructure
that implementers of HL7 standards must manage.
The mission of the Organizational Support Services
Steering Division (OSSD) (formerly Technical &
Support Services Steering Division) is to develop
projects and products providing direct support to
the work groups, thereby enabling them to function
efficiently.
The Clinical Steering Division (CSD) mission is to
define the requirements and solutions to support
the needs for communicating information related to
the creation, management, execution and quality of
messages, services, resources and documents.

Board of
Directors
Technical
Steering
Committee
Steering
Divisions
Working
Groups
Administrative Steering Division Infrastructure Steering Division
Attachments Arden Syntax
Electronic Health Records Clinical Information Modeling Initiative (CIMI)
Financial Management Conformance
Imaging Integration FHIR Infrastructure (FHIR-I)
Orders & Observations Implementable Technology Specifications (ITS)
Patient Administration Infrastructure & Messaging (InM)
Mobile Health
Clinical Steering Division Modeling & Methodology (MnM)
Security
Anesthesia Service Oriented Architecture (SOA)
Biomedical Research and Regulation Structured Documents
Clinical Decision Support Templates
Clinical Genomics Vocabulary
Clinical Interoperability Council
Clinical Quality Information Organizational Support Steering Division
Community-Based Care and Privacy
Emergency Care Electronic Services and Tools
Health Care Devices Process Improvement
Learning Health Systems Project Services
Patient Care Publishing
Pharmacy
Public Health (formerly PHER)

Governance and Operations
 The Governance and Operations Manual (GOM) defines standard
operating procedures and various policies created to clarify,
support, and/or implement the tenets of the HL7 Bylaws.
 The GOM is established to assure the uniformity, equity, quality,
efficiency, and compliance of administrative and organizational
activities through standard methods and guidelines.
 The Governance and Operations Manual (GOM) is a dynamic
document with proactive, iterative, and participatory maintenance
designed to keep the manual current with HL7 operational
requirements.
 An updated GOM is posted to the HL7 Web site within ten working
days of the closing date of each WGM.
 Revisions or additions to the GOM are effective on the date
stipulated upon adoption by the Executive Committee.

The current version of the GOM was adopted in its entirety
February 5, 2016.
(http://bit.ly/HL7_GOM)
“There’s no point in acting surprised about it.
All the planning charts and demolition orders
have been on display at your local planning
department in Alpha Centauri for 50 of your
Earth years, so you’ve had plenty of time to
lodge any formal complaint and it’s far too late
to start making a fuss about it now. … What do
you mean you’ve never been to Alpha
Centauri? Oh, for heaven’s sake, mankind, it’s
only four light years away, you know. I’m sorry,
but if you can’t be bothered to take an interest
in local affairs, that’s your own lookout.
Energize the demolition beams.”
~ Douglas Adams, The Hitchhiker's Guide to the Galaxy
 “But the plans were on display…”
 “On display? I eventually had to go down to
the cellar to find them.”
 “That’s the display department.”
 “With a flashlight.”
 “Ah, well, the lights had probably gone.”
 “So had the stairs.”
 “But look, you found the notice, didn’t you?”
 “Yes,” said Arthur, “yes I did. It was on
display in the bottom of a locked filing
cabinet stuck in a disused lavatory with a
sign on the door saying ‘Beware of the
Leopard.”
27

Membership
 HL7 membership offers valuable resources and services for
healthcare providers, government stakeholders, payers,
pharmaceutical companies, vendors/suppliers, and consulting
firms.
 HL7 membership benefits include:
 Influence the technical and policy environment of the
future by voting on standards
 Show the industry that you are a leader who is helping to
make interoperability a reality
 Manage your implementation costs and speed time to
market
 Access industry information to help make more informed
business decisions
 Learn best practices from industry leaders
 Discounts on meetings and educational opportunities
 Gain immediate access to HL7 FHIR and other HL7
standards
 To learn more about the benefits of HL7
Membership, download the HL7 Membership Brochure
(http://bit.ly/2Q9NDDz).
28

Membership Categories and Benefits
29
The HL7 individual
membership
category is intended
for those with a
personal interest in
the standards,
including people
who are retired, self-
employed and/or are
employed by an
organization with
revenues less than
$5 million per year.

Service-Aware Interoperability Framework
(SAIF)
 SAIF is a specification stack the identifies, defines, organizes, and relates a set of
artifacts that collectively specify the relevant semantics of a software component
specification or other system-of-interest.
 Enterprise Conformance and Compliance Framework (ECCF) is a framework for enabling
Working Interoperability between different users, organizations, and systems. The ECCF
is manifest in the SAIF specification stack.
 The ECCF specification stack provides an organizational framework in which inter-related
artifacts are sorted by content – for example, business rules, information constructors,
behavioral contracts, and level-of-abstraction.

ECCF Organizing Paradigm
 The ECCF is an organizing paradigm for the
models, specifications, and other work products
produced as part of a systems development
project.
 The ECCF provides a foundation for assessing
the conformance and compliance of system
analysis, design, and construction artifacts.
 The ECCF also provides the basis for
organization of project teams and the assignment
of project team functional boundaries,
interrelationships.

What is a Model?
 mod·el – /mɒdl/ noun, adjective, verb, -eled, -el·ing or ( especially British ) -elled, -el·ling.
1. a standard or example for imitation or comparison.
2. a representation, generally in miniature, to show the construction
or appearance of something.
3. an image in clay, wax, or the like, to be reproduced in more
durable material.

The Purpose of Data Modeling
 To aid in understanding data in a particular domain
 To communicate the modeler’s understanding of data and allow that
understanding to be assessed by others
 To aid in reconciling multiple perspective of data by harmonizing the
perspectives into a single specification
 To document a design an existing or planned data structure so that the
design may be evaluated
 To serve as a communication aid between subject matter experts and
informatics professionals

Revealing assumptions is an essential component of effective communication.
Data models are an effective means of documenting our assumptions
about a domain
Yes, I do
play
football.
Do you
play
football?
Reveal Assumptions

Modeling provides a language that allows us to unambiguously express
our understanding and assumptions about the actions and information of
interest in a particular domain
Reduce Ambiguity
A
C
B
0..*
0..*
0..* 1

Sharing models provides an opportunity to identify and reconcile
conflicts in our understanding and to validate our assumptions.
Reconcile Conflicts
A
C
B
0..*
0..*
0..* 1 X
C
B
0..*
0..*
0..* 1

Sharing models also provides an opportunity to identify gaps in
our understanding. No one of individual has the complete view of
domain of interest.
Expand Understanding
A
C
B
0..*
0..*
0..* 1
D
A B0..* 0..*
0..*
1

Consolidate Ideas
B
X F
E
C A D
G
1
0..*
0..* 1 0..* 1
0..* 0..1 0..*1
Model I Model II Model III
A
C
B
0..*
0..*
0..* 1 X
C
B
0..*
0..*
0..* 1
D
A B0..* 0..*
0..*
1

The Value of Modeling
 Reveal Assumptions
 Reduce Ambiguity
 Reconcile Conflicts
 Expand Understanding
 Consolidate Ideas

The Value of Modeling
 Note that there are multiple modeling
notations to choose from.
 Crows-foot notation, IDEF, and UML are
alternative notations widely used in
information modeling.
 Each notation has a unique set of symbols,
semantics, and rules of construction.
 The Unified Modeling Language (UML) is
HL7’s preferred modeling notation.

UML Diagram Types Used in HL7 Models
Diagram Description Classification
Activity Diagram Depicts high-level business processes, including data flow, or to model the logic of complex
logic within a system.
Behavior
Class Diagram Shows a collection of static model elements such as classes and types, their contents, and
their relationships.
Structure
Communication Diagram Shows instances of classes, their interrelationships, and the message flow between them.
Communication diagrams typically focus on the structural organization of objects that send and
receive messages.
Interaction
Component Diagram Depicts the components that compose an application, system, or enterprise. The components,
their interrelationships, interactions, and their public interfaces are depicted.
Structure
Composite Structure Diagram Depicts the internal structure of a classifier (such as a class, component, or use case),
including the interaction points of the classifier to other parts of the system.
Structure
Deployment Diagram Shows the execution architecture of systems. This includes nodes, either hardware or
software execution environments, as well as the middleware connecting them.
Structure
Interaction Overview Diagram A variant of an activity diagram which overviews the control flow within a system or business
process. Each node/activity within the diagram can represent another interaction diagram.
Interaction
Object Diagram Depicts objects and their relationships at a point in time, typically a special case of either a
class diagram or a communication diagram.
Structure
Package Diagram Shows how model elements are organized into packages as well as the dependencies
between packages.
Structure
Sequence Diagram Models the sequential logic, in effect the time ordering of messages between classifiers. Interaction
State Machine Diagram Describes the states an object or interaction may be in, as well as the transitions between
states.
Behavior
Timing Diagram Depicts the change in state or condition of a classifier instance or role over time. Typically
used to show the change in state of an object over time in response to external events.
Interaction
Use Case Diagram Shows use cases, actors, and their interrelationships. Behavior
Activity
Class
Package
Sequence
State
Use Case
0..*
1
.
1..*

UML Modeling Diagrams and their Artifacts
UseCaseDiagram
UseCaseActor
ActivityDiagram
Activity
SwimLane
ObjectInformationFlow ObjectDiagram
Class
Attribute
ClassDiagram
«Class»
Datatype
Enumeration EnumeratedValue
ValueSetReference
{XOR}
«ClassDiagram»
DatatypeDiagram «ClassDiagram»
EnumerationDiagram
Relationship
«trace»
1..*
1..*
includes
1
0..*1..*
+source
1 0..*
+target
1 0..*
1
1
instantiates
0..1
0..*
0..1
boundTo
1..* 0..*
0..1
1..*
1..*
assigned
0..1
1..*
0..*
+source 1
0..*

ECCF Specification Stack

ECCF Influence on Model Artifacts
 The viewpoints of the ECCF provide a framework for organizing UML model elements, diagrams, and specifications.
 The Enterprise viewpoint includes the UML concept of actor and the business perspectives of requirements and
reference materials.
 The Information, Computation, and Engineering viewpoints correspond to the UML diagram categories of Structure,
Behavior, and Interaction.
 The four viewpoints taken collectively across one layer of abstraction is a single internally consistent model and is used
along with expository text to form a single model specification.

ECCF Influence on Project Teams
 Domain experts are the providers of system
requirements and the deployment team is the provider
of the solution systems.
 Sandwiched between the domain experts and the
deployment team are the Analyst, Architecture, and
Development teams.
 The Analyst team is responsible for the transformation
of system requirements into a CIM.
 The Architecture team is responsible for the
transformation of a CIM into a PIM.
 The Development team is responsible for
transformation of a PIM into a PSM.
 The quality assurance team is responsible for ensuring
traceability and compliance from deployment to
requirements.

Seven Phases of the HDF Methodology
1. Project initiation
2. Requirements Documentation
3. Specification Modeling
4. Specification Documentation
5. Specification Approval
6. Specification Publication
7. Specification Profiling
Initiate
Project
Project
Charter
Specify
Requirements
Reference
Models
Requirement
Specification
Prepare Specification
Design Models
Specification
Design Models
Prepare
Specification
Approve
Specification
Approved
Specification
Publish
Approved
Specification
Published
Specification
Prepare Specification
Profiles
Specification
Profile
Conformance
Statement
Proposed
Specification

Project initiation
During project initiation the project is defined, a project plan is produced, and
project approval is obtained. The primary deliverable produced during project
initiation is the project charter.
Project
Initiation
Project
Charter
1. Define project scope, objectives, and intended deliverables
2. Identify project stakeholders, participants, and required resources
3. Document project assumptions, constraints, and risk
4. Prepare preliminary project plan and document inter-project dependencies
5. Obtain project approval and launch the project

Requirements Documentation
During requirements documentation the problem domain is defined, a model of the
domain is produced, and the problem domain model is harmonized with HL7
reference models. The primary deliverable produced during requirements
documentation is the requirements specification.
Requirements
Documentation
Requirements
Specification
1. Document Business Process: Dynamic Behavior and Static Structure
2. Capture Process Flow: UML Activity Diagram
3. Capture Structure: Domain Information Model and Glossary
4. Capture Business Rules: Relationships, Triggers, and Constraints
5. Harmonize the Domain Analysis Model with HL7 Reference Models
Project
Charter

Specification Modeling
During specification modeling reference models are constrained into design models
through an iterative process of requirements driven refinements following specification
design rules, conventions, and guidelines. The primary deliverable produced during
specification modeling is a set of specification design models.
Specification
Modeling
Specification
Design Models
1. Build design models of static information views
2. Construct design models of behavioral views
3. Define reusable design model components
4. Construct design models of collaboration and interaction
5. Harmonize design models with HL7 Reference Models
Requirements
Specification

Specification Documentation
During specification Documentation the specification design models are packaged into
logical units, supplemented with explanatory text, and prepared for approval. The
primary deliverable produced during specification documentation is a proposed
specification.
Specification
Documentation
Proposed
Specification
1. Organize design model elements into logical packages
2. Compose explanatory text, examples, and design rationale
3. Update design models and requirement specifications
4. Assemble a proposed specification package
5. Submit specification for approval
Specification
Design Models

Specification Approval
During specification approval the pre-approval specification is subjected to a series of
approvals steps. The specific approval steps vary by kind of specification, level of
approval, and realm of interest. The primary deliverable produced during specification
approval is an approved specification.
Specification
Approval
Approved
Specification
1. Obtain TSC and Board approval to ballot specification
2. Form a ballot pool and conduct specification ballot
3. Assess negative ballots and affirmative comments
4. Modify specification in response to ballot comments
5. Resolve negative ballot responses and if necessary re-ballot
Proposed
Specification

Specification Publication
During specification publication the approved specification is prepared for
prepared for publication and distribution. The primary deliverable produced during
specification publication is a published specification.
Specification
Publication
Published
Specification
1. Obtain TSC and Board approval to publish specification
2. Prepare specification for publication
3. Submit publication to standards authorities (ANSI/ISO)
4. Render the specification in various forms of publication media
5. Post and distribute approved specifications
Approved
Specification

Specification Profiling
During specification profiling specification models and published specifications are
further refined to produce a specification profile for use in a particular environment by
a defined community of users. The primary deliverable produced during specification
profiling is a set of specification constraints and conformance statements.
Specification
Profiling
Specification
Constraints and
Conformance
Statements
1. Identify community of user for the published specification
2. Further refine and constrain specification design models
3. Document exceptions, extensions, and annotations to specifications
4. Prepare and publish specification profile
5. Prepare and publish conformance statements
Published
Specification

Version 2
Messaging
Version 3
Messaging
Clinical
Document
Architecture
Fast Healthcare
Interoperability
Resources

© 2015 Health Level Seven ® International. All Rights Reserved. HL7 and Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
7 Application
What does the name “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

Version 2 Messaging

HL7: Why
User Interface
Program
Module
Dataset
User Interface
Program
Module
Dataset
Message
Creation
Message
Parsing
A to B
Transformation
Message
Parsing
Message
Creation
B to A
Transformation
Order Entry
Application
System
Laboratory
Application
System
Order Entry
Application
System
Laboratory
Application
System
LabResult
Transaction

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

Health Level Seven: Why
• The number of interfaces between N systems is given by the formula
I = (N2-N)/2.
• Linking systems needs ?? Interfaces:
• Linking 6 systems needs as many as 15 interfaces, (62 – 6) / 2 = 15
• The benefits of using the HL7 standard increase rapidly with the
number of systems involved. I = N
3 (32 - 3) / 2 = 32 (22 - 2) / 2 = 14 (42 - 4) / 2 = 6

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

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)

Abstract Message Specification
MSH Message Header
EVN Event Type
PID Patient Identification
[PD1] Additional Demographics
[ { NK1 } ] Next of Kin /Associated Parties
PV1 Patient Visit
[ PV2 ] Patient Visit - Additional Info.
…
[ { GT1 } ] Guarantor
[
{ IN1 Insurance
[ IN2 ] Insurance Additional Info.
[ IN3 ] Insurance Add'l Info - Cert.
}
]
…
[ ] optional
{ } may repeat
Segment ID Segment Name

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

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

Version 2 Messaging Version 3 Messaging

International
National
Inter-Enterprise
Enterprise
Institution
Standards Moving in Ever Increasing Circles
Source: Gartner

HL7 v3 Back Room Zealots
 Wes Rishel - vision
 Ted Klein - vocabulary
 Woody Beeler - tooling
 AbdulMalik Shakir - modeling
 Mead Walker - methodology
71

 HL7 Version 3 (V3) introduced a common Reference Information Model
(RIM), data type model, a set of vocabulary and a formal standards
development methodology.
 In addition, it introduced the use of "documents" as an alternative
architecture for sharing healthcare information. However, the term "V3" is
typically used to refer to "V3 messaging".
 The HL7 RIM and data types used as a basis for V3 have also been
adopted as ISO standards. ISO 21731:2014 and ISO 21090:2011
respectively.
HL7 v3 Messaging

HL7 V3 Message Design Information Models
 RIM: Reference Information Model
 D-MIM: Domain Message Information Model
 R-MIM: Refined Message Information Model
 HMD: Hierarchical Message Definition
RIM
Restrict
R-MIM
Serialize
HMD
D-MIM
Derive

HL7 V3 Message Development Framework
Use Case Modeling
Interaction Modeling
Message Design
Information Modeling
RIM
Restrict
R-MIM
Serialize
HMD
Restrict
Message
Type
Example
Storyboard
Storyboard
Example
D-MIM
Derive
Application
Role
Sender Receiver
Trigger
Event
Triggers
Content
Interaction
References

RIM History
 Development of the HL7 Reference Information Model began in April 1996.
 The first draft of the RIM was created by consolidating data models developed by HL7
Technical Committees, contributed by HL7 Member Organizations, and published by national
and international standards organizations and government bodies.
 The first release of the RIM (v0.80) was adopted by the HL7 Technical Steering Committee at
the January 1997 working group meeting.
 The next two working group meetings focused on gaining familiarity with the draft RIM and
implementing a process for obtaining and reconciling proposed enhancements to the model.
 The RIM maintenance process became known as "RIM harmonization.” The first RIM
harmonization meeting was held July 1997 in Indianapolis, Indiana.

RIM Development Process
B
X F
E
C A D
G
1
0..*
0..* 1 0..* 1
0..* 0..1 0..*1
Model I Model II Model III
A
C
B
0..*
0..*
0..* 1 X
C
B
0..*
0..*
0..* 1
D
A B0..* 0..*
0..*
1

Contributing Data Models
 HL7 Technical Committees
 Admission/Discharge/Transfer
 Finance
 Medical Records
 Orders/Results
 Patient Care
 Standards Development Organizations
 CEN TC251
 DICOM
 HL7 Member Organizations
 Eli Lilly and Company
 HBO and Company
 Health Data Sciences
 IBM Worldwide
 Kaiser Permanente
 Mayo Foundation
 Hewlett Packard
 National Health Programs
 United Kingdom
 Australia
Abdul-Malik Shakir
Manager, Information Administration
Kaiser Foundation Health Plan, Inc.
One Kaiser Plaza, Oakland, CA 94612
v: (510) 271-6856 f: (510) 271-6859
Email: 74353.1431@Compuserve.com
April 1996

The RIM Prior to USAM

The Unified Service Action Model

Entity and Act
 Entity
a physical thing or an
organization/group of physical things
capable of participating in Acts. This
includes living subjects, organizations,
material, and places.
 Act
a discernible action of interest in the
healthcare domain. An instance of Act
is a record of that action. Acts
definitions (master files), orders,
plans, and performance records
(events)
are all represented by an
instance of Act.
Entity Act

Entity
classCode : CS
determinerCode: CS
code: CE
statusCode : CS
id : II
Act
classCode : CS
moodCode: CS
code: CD
statusCode : CS
effectiveTime : GTS
id : II
RIM Core Classes
 Entity - a physical thing or an organization/group of physical things
capable of participating in Acts. This includes living subjects,
organizations, material, and places.
 Act – a discernible action of interest in the healthcare domain. An
instance of Act is a record of that action. Acts definitions (master files),
orders, plans, and performance records (events) are all represented by an
instance of Act.
0..* 0..*

Entity
classCode : CS
determinerCode: CS
code: CE
statusCode : CS
id : II
Role
classCode : CS
code: CE
effectiveTime : IVL<TS>
statusCode : CS
id : II
Act
classCode : CS
moodCode: CS
code: CD
statusCode : CS
effectiveTime : GTS
id : II
RIM Core Classes
0..* 0..*1 0..*plays

0..1
0..*
0..1
0..*
plays
scopes
Entity
classCode : CS
determinerCode: CS
code: CE
statusCode : CS
id : II
Role
classCode : CS
code: CE
statusCode : CS
id : II
Act
classCode : CS
moodCode: CS
code: CD
statusCode : CS
effectiveTime : GTS
id : II
RIM Core Classes
 Role – a classification/specialization of an Entity defined by the
relationship of the playing Entity to a scoping Entity. An example of Role
is “Employee”. An employee is a classification attributed to a person which
has an employment relationship with an organization (Employer).
0..* 0..*

Entity
classCode : CS
determinerCode: CS
code: CE
statusCode : CS
id : II
Role
classCode : CS
code: CE
statusCode : CS
id : II
Participation
typeCode : CS
time : IVL<TS>
statusCode : CS
Act
classCode : CS
moodCode: CS
code: CD
statusCode : CS
effectiveTime : GTS
id : II
0..1
0..* 1
0..*
1
0..*
RIM Core Classes
 Participation – an association between a Role and an Act representing
the function assumed by the Role within the context of the Act. A single
Role may participate in multiple Acts and a single Act may have multiple
participating Roles. A single Participation is always an association between a
particular Role and a particular Act.
0..1
0..*
plays
scopes

Entity
classCode : CS
determinerCode: CS
code: CE
statusCode : CS
id : II
Role
classCode : CS
code: CE
statusCode : CS
id : II
Participation
typeCode : CS
time : IVL<TS>
statusCode : CS
Act
classCode : CS
moodCode: CS
code: CD
statusCode : CS
effectiveTime : GTS
id : II
0..1
0..*
1
0..*
1
0..*
Act Relationship
typeCode : CS
1 1
0..* 0..*
RIM Core Classes
 Act relationship – an association between two Acts.
This includes Act to Act associations such as
collector/component, predecessor/successor, and
cause/outcome. The semantics of the association is
captured by the Act Relationship attributes.
0..1
0..*
plays
scopes

Entity
classCode : CS
determinerCode: CS
code: CE
statusCode : CS
id : II
Role
classCode : CS
code: CE
statusCode : CS
id : II
Participation
typeCode : CS
time : IVL<TS>
statusCode : CS
Act
classCode : CS
moodCode: CS
code: CD
statusCode : CS
effectiveTime : GTS
id : II
0..1
0..*
1
0..*
1
0..*
Role Link
typeCode : CS
Act Relationship
typeCode : CS
RIM Core Classes
0..1
0..*
plays
scopes
1 1
0..* 0..*
1 1
0..* 0..*
Role Link – An association
between two Roles. It is
used to capture relationships
that exists between Entities
other than the scoping
relationships.

Definition of RIM Core Classes
 Act – a discernible action of interest in the healthcare domain. An instance of Act is a record of
that action. Acts definitions (master files), orders, plans, and performance records (events) are all
represented by an instance of Act.
 Act relationship – an association between two Acts. This includes Act to Act associations such
as collector/component, predecessor/successor, and cause/outcome. The semantics of the
association is captured by the Act Relationship attributes.
 Entity - a physical thing or an organization/group of physical things capable of participating in
Acts. This includes living subjects, organizations, material, and places.
 Participation – an association between a Role and an Act representing the function assumed
by the Role within the context of the Act. A single Role may participate in multiple Acts and a single
Act may have multiple participating Roles. A single Participation is always an association between a
particular Role and a particular Act.
 Role – a classification/specialization of an Entity defined by the relationship of the playing
Entity to a scoping Entity. An example of Role is “Employee”. An employee is a classification
attributed to a person which has an employment relationship with an organization (Employer).
 Role Link – An association between two Roles. It is used to capture relationships that exists
between Entities other than the scoping relationships. A single Role may have a Role Link
with multiple other Roles. A single Role Link is always between two distinct instances of Role.

Observation
value : ANY
interpretationCode : SET<CE>
methodCode : SET<CE>
targetSiteCode : SET<CD>
SubstanceAdministration
routeCode : CE
approachSiteCode : SET<CD>
doseQuantity : IVL<PQ>
rateQuantity : IVL<PQ>
doseCheckQuantity : SET<RTO>
maxDoseQuantity : SET<RTO>
Procedure
methodCode : SET<CE>
approachSiteCode : SET<CD>
targetSiteCode : SET<CD>
Supply
quantity : PQ
expectedUseTime : IVL<TS>
Diet
energyQuantity : PQ
carbohydrateQuantity : PQ
Document
setId : II
versionNumber : INT
completionCode : CE
storageCode : CE
copyTime : TS
Container
capacityQuantity : PQ
heightQuantity : PQ
diameterQuantity : PQ
capTypeCode : CE
separatorTypeCode : CE
barrierDeltaQuantity : PQ
bottomDeltaQuantity : PQ
Access
approachSiteCode : CD
targetSiteCode : CD
gaugeQuantity : PQ
Device
manufacturerModelName : SC
softwareName : SC
localRemoteControlStateCode : CE
alertLevelCode : CE
lastCalibrationTime : TS
Employee
jobCode : CE
jobTitleName : SC
jobClassCode : CE
salaryTypeCode : CE
salaryQuantity : MO
hazardExposureText : ED
protectiveEquipmentText : ED
LivingSubject
administrativeGenderCode : CE
birthTime : TS
deceasedInd : BL
deceasedTime : TS
multipleBirthInd : BL
multipleBirthOrderNumber : INT
organDonorInd : BL
Material
formCode : CE
LicensedEntity
recertificationTime : TS
Place
mobileInd : BL
addr : AD
directionsText : ED
positionText : ED
gpsText : ST
ManufacturedMaterial
lotNumberText : ST
expirationTime : IVL<TS>
stabilityTime : IVL<TS>
NonPersonLivingSubject
strainText : ED
genderStatusCode : CE
Patient
confidentialityCode : CE
veryImportantPersonCode : CE
Organization
addr : BAG<AD>
standardIndustryClassCode : CE
Account
name : ST
balanceAmt : MO
currencyCode : CE
interestRateQuantity : RTO<MO,PQ>
allowedBalanceQuantity : IVL<MO>
Person
addr : BAG<AD>
maritalStatusCode : CE
educationLevelCode : CE
raceCode : SET<CE>
disabilityCode : SET<CE>
livingArrangementCode : CE
religiousAffiliationCode : CE
ethnicGroupCode : SET<CE>
WorkingList
ownershipLevelCode : CE
PublicHealthCase
detectionMethodCode : CE
transmissionModeCode : CE
diseaseImportedCode : CE
PatientEncounter
preAdmitTestInd : BL
admissionReferralSourceCode : CE
lengthOfStayQuantity : PQ
dischargeDispositionCode : CE
specialCourtesiesCode : SET<CE>
specialAccommodationCode : SET<CE>
acuityLevelCode : CE
Other
Acts
Infrastructure (Structured documents)
HEALTH LEVEL 7
REFERENCE INFORMATION MODEL
VERSION 1.25 (RIM_0125)
Reflects changes to RIM in RIM Harmonization Through 06/30/2003.
Billboard produced by:
Rochester Outdoor Advertising
Roles
DiagnosticImage
subjectOrientationCode : CE
QueryAck
queryResponseCode : CS
resultTotalQuantity : INT
resultCurrentQuantity : INT
resultRemainingQuantity : INT
QueryContinuation
startResultNumber : INT
continuationQuantity : INT
Table
summary : ST
width : ST
rules : CS
cellspacing : ST
cellpadding : ST
border : INT
frame : CS
TableStructure
char : ST
charoff : ST
halign : CS
valign : CS
TableColumnStructure
span : INT
width : ST
TableCell
scope : CS
abbr : ST
axis : ST
colspan : INT
headers : SET<ED>
rowspan : INT
LocalAttr
name : ST
value : ST
LocalMarkup
descriptor : ST
render : ST
ignoreCode : CS
LinkHtml
href : ED
name : ST
rel : SET<CE>
rev : SET<CE>
title : ST
ContextStructure
localId : ST
Infrastructure (Structured
documents)
Infrastructure
(Communications)
Enitites
Message Control
FinancialTransaction
amt : MO
creditExchangeRateQuantity : REAL
debitExchangeRateQuantity : REAL
InvoiceElement
modifierCode : SET<CE>
unitQuantity : RTO<PQ,PQ>
unitPriceAmt : RTO<MO,PQ>
netAmt : MO
factorNumber : REAL
pointsNumber : REAL
FinancialContract
paymentTermsCode : CE
RoleHeir
EntityHeir
SortControl
sequenceNumber : INT
elementName : SC
directionCode : CS
QuerySpec
modifyCode : CS
responseElementGroupId : SET<II>
responseModalityCode : CS
responsePriorityCode : CS
initialQuantity : INT
initialQuantityCode : CE
executionAndDeliveryTime : TS
0..n
1
0..n
1
RelationalExpression
elementName : SC
relationalOperatorCode : CS
value : ST
QueryBySelection
SelectionExpression
0..n
1
0..n
1
LogicalExpression
relationalConjunctionCode : CS
0..n
0..1
userAsRight
0..n
rightSide 0..1
0..n
0..1
userAsLeft0..n
leftSide0..1
QueryByParameter
ParameterList
Parameter
id : II 0..n 0..10..n 0..1
0..1
0..n
0..1
0..n
ParameterItem
value : ANY
semanticsText : ST
DeviceTask
parameterValue : LIST<ANY>
ManagedParticipation
id : SET<II>
statusCode : SET<CS>
ActHeir
ActRelationship
typeCode : CS
inversionInd : BL
contextControlCode : CS
contextConductionInd : BL
priorityNumber : INT
pauseQuantity : PQ
checkpointCode : CS
splitCode : CS
joinCode : CS
negationInd : BL
conjunctionCode : CS
localVariableName : ST
seperatableInd : BL
Act
classCode : CS
moodCode : CS
id : SET<II>
code : CD
negationInd : BL
derivationExpr : ST
text : ED
effectiveTime : GTS
activityTime : GTS
availabilityTime : TS
priorityCode : SET<CE>
confidentialityCode : SET<CE>
repeatNumber : IVL<INT>
interruptibleInd : BL
levelCode : CE
independentInd : BL
uncertaintyCode : CE
reasonCode : SET<CE>
languageCode : CE
0..n
1
inboundRelationship
0..n
target
1
0..n1
outboundRelationship
0..n
source
1
Participation
typeCode : CS
functionCode : CD
contextControlCode : CS
negationInd : BL
noteText : ED
time : IVL<TS>
modeCode : CE
awarenessCode : CE
signatureCode : CE
signatureText : ED
performInd : BL
substitutionConditionCode : CE
0..n
1
0..n
1
RoleLink
typeCode : CS
Role
classCode : CS
id : SET<II>
code : CE
negationInd : BL
addr : BAG<AD>
telecom : BAG<TEL>
certificateText : ED
quantity : RTO
positionNumber : LIST<INT>
0..n
1
0..n
1
0..n1
outboundLink
0..n
source
1 0..n1
inboundLink
0..n
target
1
LanguageCommunication
languageCode : CE
modeCode : CE
proficiencyLevelCode : CE
preferenceInd : BL
AttentionLine
keyWordText : SC
value : ST
Entity
classCode : CS
determinerCode : CS
id : SET<II>
code : CE
quantity : SET<PQ>
name : BAG<EN>
desc : ED
existenceTime : IVL<TS>
telecom : BAG<TEL>
riskCode : CE
handlingCode : CE
0..n0..1
playedRole
0..n
player
0..1
0..n0..1
scopedRole
0..n
scoper
0..1
10..n 10..n
Transmission
id : II
creationTime : TS
securityText : ST
0..n
1
0..n
1
CommunicationFunction
typeCode : CS
telecom : TEL
1..n
0..*
1..n
0..*
1..*
0..*
1..*
0..*
InfrastructureRoot
templateId : SET<OID>
realmCode : SET<CS>
typeID : SET<OID>
nullFlavor : CS
QueryEvent
queryId : II
statusCode : CS
ControlAct
0..1
1
0..1
1
Message
versionCode : CS
interactionId : II
profileId : SET<II>
processingCode : CS
processingModeCode : CS
acceptAckCode : CS
attachmentText : SET<ED>
responseCode : CS
0..1
0..n
0..1
payload
0..n
Acknowledgement
typeCode : CS
messageWaitingNumber : INT
messageWaitingPriorityCode : CE
expectedSequenceNumber : INT
0..n
1
acknowledgedBy
0..n
acknowledges
1
0..1
1
conveyedAcknowledgement
0..1
conveyingMessage
1
AcknowledgementDetail
typeCode : CS
code : CE
text : ED
location : SET<ST>
1
0..n
1
0..n
Batch
referenceControlId : II
name : SC
batchComment : SET<ST>
transmissionQuantity : INT
batchTotalNumber : SET<INT>
0..1
0..n
0..1
0..n
RoleEntity
Participation
Acts
The RIM After USAM
Version 1.25 06/30/2003
Infrastructure

Normative R6 RIM
Version 2.44 11/22/2013

RIM From Draft to Normative
 Apr 96 – Dec 96: Initial development
 Jan 97 – Jan 00: Pre-USAM Harmonization
 Jan 00 – Jul 03: Post-USAM and Pre-Normative
 Normative Releases:
– V1.25 Release 1.0: 2003
– V2.07 Release 1.0: 2005
– V2.14 Release 1.0: 2007
– V2.29 Release 2.0: 2009
– V2.33 Release 3.0: 2010
– V2.36 Release 4.0: 2011
– V2.40 Release 5.0: 2012
– V2.44 Release 6.0: 2013
– V2.47 Release 7.0: 2016

HL7 V3 Message Design Information Models
 RIM: Reference Information Model
 D-MIM: Domain Message Information Model
 R-MIM: Refined Message Information Model
 HMD: Hierarchical Message Definition
RIM
Restrict
R-MIM
Serialize
HMD
D-MIM
Derive
PatientIncident
classCode*: <= ENC
moodCode*: <= EVN
id: [1..*] (RegistNum)
code: CV CNE [0..1] <= ExternallyDefinedActCodes (PatientType)
statusCode: LIST<CS> CNE <= ActStatus (IDPHStatus)
activityTime: TS (EDDate)
Injury
classCode*: <= ACT
moodCode*: <= EVN
activityTime: TS (InjuryDate)
0..1 pertinentInjury
typeCode*: <= PERT
pertinentInformation1
TraumaRegistryExport
(IDPH_RM00001)
Data content of HL7
messages used to export
data from the IDPH Trauma
Registry.
PatientPerson
classCode*: <= PSN
determinerCode*: <= INSTANCE
name: PN [0..1] (*Name)
existenceTime: (Age)
administrativeGenderCode: CV CWE <= AdministrativeGender
(GenderID)
birthTime: (DateOfBirth)
addr: AD [0..1] (AddressHome)
raceCode: CV CWE [0..1] <= Race (RaceID)
ethnicGroupCode: CV CWE [0..1] <= Ethnicity (EthnicID)
1..1 patientPatientPerson
1..1 providerTraumaParticipant
Patient
classCode*: <= PAT
id: II [0..1] (MedicaRecordNum)
TraumaParticipant
classCode*: <= ORG
id: [1..1] (HospitNum)
code: CV CWE [0..1] <= EntityCode
name: ON [0..1] (HospitName)
statusCode: CS CNE [0..1] <= EntityStatus (ActiveFacili)
addr: AD [0..1] (HospitCity)
1..1 patient
typeCode*: <= SBJ
subject
InjuryLocation
classCode*: <= PLC
code: CV CWE [0..1] <= EntityCode (InjuryPlaceID)
addr: AD [0..1] (AddressScene)
0..1 playingInjuryLocation
Role
classCode*: <= ROL
1..1 participant
typeCode*: <= LOC
location
InjuryRelatedObservation
classCode*: <= OBS
moodCode*: <= EVN
code: <= ExternallyDefinedActCodes
priorityCode: CV CWE [0..1] <= ActPriority
value: [0..1]
0..* pertinentInjuryRelatedObservation
typeCode*: <= PERT
sequenceNumber: INT [0..1] (InjurySequen)
pertinentInformation
Procedure
classCode*: <= PROC
moodCode*: <= EVN
code: CV CWE <= ActCode (ICDCodeID)
activityTime: TS (ProcedDate)
0..* pertinentProcedure
typeCode*: <= PERT
0..1 medicalStaff
typeCode*: <= PRF
performer
MedicalStaff
classCode*: <= PROV
id: II [0..1] (MedicalStaffID)
0..1 procedureLocation
typeCode*: <= LOC
location
ProcedureLocation
classCode*: <= SDLOC
code: <= RoleCode (ProcedLocateID)
PatientIncidentRelatedObservation
classCode*: <= OBS
moodCode*: <= EVN
code: <= ActCode
reasonCode: CV CWE [0..1] <= ActReason
value: ANY [0..1]
0..* pertinentPatientIncidentRelatedObservation
typeCode*: <= PERT
PatientTransfer
classCode*: <= TRNS
moodCode*: <= EVN
activityTime: IVL<TS> (DischaDate to ArriveDate)
reasonCode: CV CWE [0..1] <= TransferActReason (REASONTRANSFID)
1..1 arrivalPatientTransfer
typeCode*: <= ARR
arrivedBy
0..* aRole
typeCode*: <= ORG
origin
0..1 playingTraumaParticipant
aRole
classCode*: <= ROL
TransferRelatedObservation
classCode*: <= OBS
moodCode*: <= EVN
code: CV CWE <= ExternallyDefinedActCodes
value: PQ [0..1]
methodCode: CV CWE [0..1] <= ObservationMethod
1..* pertinentTransferRelatedObservation
typeCode*: <= PERT
1..1 transferVehicle
typeCode*: <= VIA
via
1..1 owningVehicleProvider
TransferVehicle
classCode*: <= OWN
id: II [0..1] (VehiclNum)
code: <= RoleCode (VehiclLevelID)
VehicleProvider
classCode*: <= ORG
id: II [0..1] (VehiclProvide)
code: <= EntityCode (MaxVehiclLevelID)
name: ON [0..1] (VehiclProvidName)
HospitalVisit
classCode*: <= ENC
moodCode*: <= EVN
code: CV CWE <= ActCode (AdmitServicID)
activityTime: TS (DischaDate)
dischargeDispositionCode: CV CWE [0..1]
<= EncounterDischargeDisposition
1..1 pertinentHospitalVisit
typeCode*: <= PERT
HospitalVisitRelatedObservation
classCode*: <= OBS
moodCode*: <= EVN
value: [0..1]
0..* pertinentHospitalVisitRelatedObservation
typeCode*: <= PERT
1..1 admittingProvider
typeCode*: <= ADM
admitter
0..1 healthCareMedicalStaffPerson
AdmittingProvider
classCode*: <= PROV
id: II [0..1] (ADMITMEDICASTAFFID)
code: CV CWE <= RoleCode (StaffTypeID)
0..* hospitalVisitPhysician
typeCode*: <= RESP
time: TS
responsibleParty
HospitalVisitPhysician
classCode*: <= PROV
id: II [0..1]
MedicalStaffPerson
classCode*: <= PSN
name: PN [0..1] (MedicaStaffName)
0..1 licensedEntity
typeCode*: <= DST
destination
0..1 subjectChoice
LicensedEntity
classCode*: <= LIC
id: II [0..1]
Choice
Facility
classCode*: <= ORG
id:
code*: CS CNE <= EntityCode "FAC"
name:
Hospital
classCode*: <= ORG
id:
code*: CS CNE <= EntityCode "HOSP"
name:
EmergencyDepartmentEncounter
classCode*: <= ENC
moodCode*: <= EVN
activityTime: IVL<TS>
dischargeDispositionCode: CV CWE <= EncounterDischargeDisposition
0..1 pertinentEmergencyDepartmentEncounter
typeCode*: <= PERT
EmergencyDepartmentRelatedObservation
classCode*: <= OBS
moodCode*: <= EVN
text:
activityTime: TS
reasonCode: <= ActReason
value: [0..1]
targetSiteCode: CV CWE [0..1] <= HumanActSite
0..* pertinentEmergencyDepartmentRelatedObservation
typeCode*: <= PERT
0..* emergencyDepartmentPhysician
typeCode*: <= PRF
performer
0..1 healthCareMedicalStaffPerson EmergencyDepartmentPhysician
classCode*: <= PROV
id: II [0..1]
code: CE CWE [0..1] <= RoleCode (StaffTypeID)
PreHospitalEncounter
classCode*: <= ENC
moodCode*: <= EVN
id: II [0..1] (crashNum)
0..1 priorPreHospitalEncounter
typeCode*: <= PREV
predecessor
PreHosptialRelatedObservation
classCode*: <= OBS
moodCode*: <= EVN
value: ANY [0..1]
0..* pertinentPreHosptialRelatedObservation
typeCode*: <= PERT
1..1 preHospitalVehicle
typeCode*: <= ParticipationType
participant
PreHospitalVehicle
classCode*: <= OWN
0..* emergencyDepartmentPhysicianAct
typeCode*: <= COMP
component
EmergencyDepartmentPhysicianAct
classCode*: <= ACT
moodCode*: <= EVN
code: CS CNE [0..1] <= ExternallyDefinedActCodes
activityTime*: TS [0..1]
component
0..* patientIncidentRelatedObservation
typeCode*: <= COMP
VehicleProvider
MedicalStaffPerson
TraumaParticipant
A_AbnormalityAssessment
(COCT_RM420000UV)
Description: assessment of clinical findings, including lab test results,
for indications of the presence and severity of abnormal conditions
AbnormalityAssessment
classCode*: = "OBS"
moodCode*: = "EVN"
code*: CD CWE [1..1] <= V:ObservationType ("ADVERSE_REACTION")
statusCode*: CS CNE [1..1] <= V:ActStatusAbortedCancelledCompleted
activityTime*: TS.DATETIME [1..1]
value: CD CWE [0..1] <= V:AbnormalityAssessmentValue
methodCode: SET<CE> CWE [0..*] <= V:AbnormalityAssessmentMethod
1..* assessmentOutcome *
typeCode*: = "OUTC"
contextConductionInd*: BL [1..1] ="true"
outcome
AssessmentException
classCode*: = "OBS"
moodCode*: = "EVN"
code*: CD CWE [1..1] <= V:ObservationType ("ASSERTION")
value*: SC CWE [1..1] <= V:AssessmentExceptionValue
AbnormalityGrade
classCode*: = "OBS"
moodCode*: = "EVN"
code*: CD CWE [1..1] <= V:ObservationType ("SEV")
uncertaintyCode: CE CNE [0..1] <= V:ActUncertainty
value*: CD CWE [1..1] <= V:AbnormalityGradeValue
AssessmentOutcome
0..* assessmentOutcomeAnnotation
typeCode*: = "APND"
contextConductionInd*: BL [1..1] ="true"
appendageOf
AssessmentOutcomeAnnotation
classCode*: = "OBS"
moodCode*: = "EVN"
code*: CD CWE [1..1] <= V:ObservationType ("ASSERTION")
value*: SC CWE [1..1] <= V:AssessmentOutcomeAnnotationValue

Domain Information Model
PatientIncident
classCode*: <= ENC
moodCode*: <= EVN
id: [1..*] (RegistNum)
code: CV CNE [0..1] <= ExternallyDefinedActCodes (PatientType)
statusCode: LIST<CS> CNE <= ActStatus (IDPHStatus)
activityTime: TS (EDDate)
Injury
classCode*: <= ACT
moodCode*: <= EVN
activityTime: TS (InjuryDate)
0..1 pertinentInjury
typeCode*: <= PERT
TraumaRegistryExport
(IDPH_RM00001)
Data content of HL7
messages used to export
data from the IDPH Trauma
Registry.
PatientPerson
classCode*: <= PSN
name: PN [0..1] (*Name)
existenceTime: (Age)
administrativeGenderCode: CV CWE <= AdministrativeGender
(GenderID)
birthTime: (DateOfBirth)
addr: AD [0..1] (AddressHome)
raceCode: CV CWE [0..1] <= Race (RaceID)
ethnicGroupCode: CV CWE [0..1] <= Ethnicity (EthnicID)
1..1 patientPatientPerson
1..1 providerTraumaParticipant
Patient
classCode*: <= PAT
id: II [0..1] (MedicaRecordNum)
TraumaParticipant
classCode*: <= ORG
id: [1..1] (HospitNum)
code: CV CWE [0..1] <= EntityCode
name: ON [0..1] (HospitName)
statusCode: CS CNE [0..1] <= EntityStatus (ActiveFacili)
addr: AD [0..1] (HospitCity)
1..1 patient
typeCode*: <= SBJ
subject
InjuryLocation
classCode*: <= PLC
code: CV CWE [0..1] <= EntityCode (InjuryPlaceID)
addr: AD [0..1] (AddressScene)
0..1 playingInjuryLocation
Role
classCode*: <= ROL
1..1 participant
typeCode*: <= LOC
location
InjuryRelatedObservation
classCode*: <= OBS
moodCode*: <= EVN
priorityCode: CV CWE [0..1] <= ActPriority
value: [0..1]
0..* pertinentInjuryRelatedObservation
typeCode*: <= PERT
sequenceNumber: INT [0..1] (InjurySequen)
Procedure
classCode*: <= PROC
moodCode*: <= EVN
code: CV CWE <= ActCode (ICDCodeID)
activityTime: TS (ProcedDate)
0..* pertinentProcedure
typeCode*: <= PERT
0..1 medicalStaff
typeCode*: <= PRF
performer
MedicalStaff
classCode*: <= PROV
id: II [0..1] (MedicalStaffID)
0..1 procedureLocation
typeCode*: <= LOC
location
ProcedureLocation
classCode*: <= SDLOC
code: <= RoleCode (ProcedLocateID)
PatientIncidentRelatedObservation
classCode*: <= OBS
moodCode*: <= EVN
code: <= ActCode
reasonCode: CV CWE [0..1] <= ActReason
value: ANY [0..1]
0..* pertinentPatientIncidentRelatedObservation
typeCode*: <= PERT
PatientTransfer
classCode*: <= TRNS
moodCode*: <= EVN
activityTime: IVL<TS> (DischaDate to ArriveDate)
reasonCode: CV CWE [0..1] <= TransferActReason (REASONTRANSFID)
1..1 arrivalPatientTransfer
typeCode*: <= ARR
arrivedBy
0..* aRole
typeCode*: <= ORG
origin
0..1 playingTraumaParticipant
aRole
classCode*: <= ROL
TransferRelatedObservation
classCode*: <= OBS
moodCode*: <= EVN
value: PQ [0..1]
1..* pertinentTransferRelatedObservation
typeCode*: <= PERT
1..1 transferVehicle
typeCode*: <= VIA
via
TransferVehicle
classCode*: <= OWN
VehicleProvider
classCode*: <= ORG
id: II [0..1] (VehiclProvide)
code: <= EntityCode (MaxVehiclLevelID)
name: ON [0..1] (VehiclProvidName)
HospitalVisit
classCode*: <= ENC
moodCode*: <= EVN
code: CV CWE <= ActCode (AdmitServicID)
activityTime: TS (DischaDate)
dischargeDispositionCode: CV CWE [0..1]
<= EncounterDischargeDisposition
1..1 pertinentHospitalVisit
typeCode*: <= PERT
HospitalVisitRelatedObservation
classCode*: <= OBS
moodCode*: <= EVN
value: [0..1]
0..* pertinentHospitalVisitRelatedObservation
typeCode*: <= PERT
1..1 admittingProvider
typeCode*: <= ADM
admitter
AdmittingProvider
classCode*: <= PROV
id: II [0..1] (ADMITMEDICASTAFFID)
0..* hospitalVisitPhysician
typeCode*: <= RESP
time: TS
responsibleParty
HospitalVisitPhysician
classCode*: <= PROV
id: II [0..1]
MedicalStaffPerson
classCode*: <= PSN
name: PN [0..1] (MedicaStaffName)
0..1 licensedEntity
typeCode*: <= DST
destination
0..1 subjectChoice
LicensedEntity
classCode*: <= LIC
id: II [0..1]
Choice
Facility
classCode*: <= ORG
id:
code*: CS CNE <= EntityCode "FAC"
name:
Hospital
classCode*: <= ORG
id:
code*: CS CNE <= EntityCode "HOSP"
name:
EmergencyDepartmentEncounter
classCode*: <= ENC
moodCode*: <= EVN
dischargeDispositionCode: CV CWE <= EncounterDischargeDisposition
0..1 pertinentEmergencyDepartmentEncounter
typeCode*: <= PERT
EmergencyDepartmentRelatedObservation
classCode*: <= OBS
moodCode*: <= EVN
text:
activityTime: TS
reasonCode: <= ActReason
value: [0..1]
targetSiteCode: CV CWE [0..1] <= HumanActSite
0..* pertinentEmergencyDepartmentRelatedObservation
typeCode*: <= PERT
0..* emergencyDepartmentPhysician
typeCode*: <= PRF
performer
0..1 healthCareMedicalStaffPerson EmergencyDepartmentPhysician
classCode*: <= PROV
id: II [0..1]
code: CE CWE [0..1] <= RoleCode (StaffTypeID)
PreHospitalEncounter
classCode*: <= ENC
moodCode*: <= EVN
id: II [0..1] (crashNum)
0..1 priorPreHospitalEncounter
typeCode*: <= PREV
predecessor
PreHosptialRelatedObservation
classCode*: <= OBS
moodCode*: <= EVN
value: ANY [0..1]
0..* pertinentPreHosptialRelatedObservation
typeCode*: <= PERT
1..1 preHospitalVehicle
typeCode*: <= ParticipationType
participant
PreHospitalVehicle
classCode*: <= OWN
0..* emergencyDepartmentPhysicianAct
typeCode*: <= COMP
component
EmergencyDepartmentPhysicianAct
classCode*: <= ACT
moodCode*: <= EVN
code: CS CNE [0..1] <= ExternallyDefinedActCodes
activityTime*: TS [0..1]
component
0..* patientIncidentRelatedObservation
typeCode*: <= COMP
VehicleProvider
MedicalStaffPerson
TraumaParticipant

The hitchhiker's guide to health level seven

The hitchhiker's guide to health level seven

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to The hitchhiker's guide to health level seven

Similar to The hitchhiker's guide to health level seven (20)

More from Abdul-Malik Shakir

More from Abdul-Malik Shakir (12)

Recently uploaded

Recently uploaded (20)

The hitchhiker's guide to health level seven