HEALTH LEVEL SEVEN: Migration to objectmodelbased messaging data interchange standard

1
HEALTH LEVEL SEVEN Migration to
object-model-based messaging data interchange
standard

• W. Ed Hammond, Ph.D.
• Professor, Duke University
• President-elect, AMIA
• Convenor, ISO TC 215, WG2
• Vice-chair Technical Steering Committee, HL7

2
Presentation

• Reason for data interchange standards
• Who and what is HL7
• Version 2 overview
• Version 3 overview
• Beyond messaging standards

3
Why data interchange standards?

• Hospitals typically have many heterogeneous
  systems that need to share and exchange data
  (best-of-breed)
• Most countries moving toward connectivity between
  providers and hospitals at regional or country
  levels (enterprise systems)
• Patients visit multiple facilities for their care
  (patient-centric)

4
Who is HL7?

• 14-year-old, not-for-profit organization
• ANSI-accredited standards developer since 1994
• HL7 Working Group meets for one-week at a time,
  three times each year
• Over 500 organizational members
• About 2200 total members
• Up to 500 attend the Working Group Meetings
• International affiliates in 17 countries
• Version 2 Standards are widely used in US and
  being rapidly adopted world-wide

5
How is HL7 organized?

• Collaborative volunteer organization
• Paid staff limited to the secretariat
• Primary funding is membership dues

6
What does HL7 stand for?

• A domain-specific, common protocol for the
  exchange of health care information.

HL7
7 Application
6 Presentation
5 Session
4 Transport
3 Network
2 Data Link
1 Physical
ISO-OSI Communication Architecture Model
7
Conceptual Approach
System A
System B
8
Contents of HL7 V2.n

• Trigger events
• Actions or occurrences
• Messages
• Information content
• Segments
• Repeating structures
• Data fields, components and elements
• Data representation

9
HL7 Segment
OBXZ0092-0LN203BE0004YX12PTXltcrgt
Segment
Data Field
10
HL7 Message Message Header - MSH
Addressing the envelope
MSHSMSOR2TMRSICU199607151535passwordAD
TA03MSG1632P2.3ltcrgt
11
CE (coded element) datatype
ltidentifiergtlttextgtname of coding
systemgt ltalternate identifiergtltalternate
textgtltname of alternate coding systemgt
Identifier
Text Name
Coding System
11289-6 Body Temperature LN
12
Use Case

• Dr. John Doe orders an HIV test for a patient on
  9/ 10/ 01 at 8 15 am.
• The patients identity must be kept confidential.
• But regulations require that the patients city,
  province country be provided with the order.
• The patients weight (135 lb) and history of non-
  prescription drug use will be included as
  observations at time of order.
• The specimen was collected by Dr. Doe at the time
  of order.
• The reason for the order is a sudden decrease in
  the patients weight.

13
HL7 V2.4 Message
MSH\ 200109100815 ORM O01 777865 P
2.4 ZHD 200109100810 3993838 Y 2.3 PID
9999999999 BC PH Anonymous Patient
S 1973 U Unspecified Durham NC USA
H ORC NW 876787 DO34 200109100810
888 Doe John HealthNet L PR OBR
876787 DO34 14092- 1 HIV LN 200109100808
10 ml 888 IP Infection Precaution 888
Doe John R Sudden Decrease in
patients weight OBX 1 NM 9804- 6 Weight
LN 135 lb F OBX 2 ST 11342- 3 History
of non- medical drug use LN Yes F
14
V2.4 XML Instance Example
OBX 1 NM 9804- 6 Weight LN 135 lb
F ltOBXgt ltOBX. 1gt 1lt/ OBX. 1gt ltOBX. 2gt NMlt/ OBX.
2gt ltOBX. 3gt ltCE. 1gt 9804- 6lt/ CE. 1gt ltCE. 2gt
Weightlt/ CE. 2gt ltCE. 3gt LNlt/ CE. 3gt lt/ OBX.
3gt ltOBX. 5gt 135lt/ OBX. 5gt ltOBX. 6gtlt CE. 1gt lblt/
CE. 1gtlt/ OBX. 6gt ltOBX. 11gt Flt/ OBX. 11gt lt/ OBXgt
15
Why Version 3?

• Even as the first Version 2 standards were being
  accepted and implemented, HL7 began to seek a
  better way to develop standards
• Initial strategy was a quick-design approach to
  meet immediate needs in the health care IT
  community
• But it is an ad hoc method that is difficult to
  coordinate and control

16
Limitations of Version 2.x

• Implicit information model, not explicit
• Events not tightly coupled to profiles
• Need for controlled vocabularies
• Trigger events and data fields described only in
  natural language
• Structural relationship unclear
• No explicit support for security functions
• Optionality is ubiquitous and troublesome

17
What V3 brings

• A conceptual foundation in a single, common
  reference information model to be used across HL7
• A strong semantic foundation in explicitly
  defined concept domains drawn from the best
  terminologies
• An abstract design methodology that is
  technology-neutral able to be used with
  whatever is the technology de jour
• Maintain semantic content in a repository
  (database) to assure a single source and enable
  development of support tooling

18
Version 3 is a change to the HL7 Architecture

• The HL7 2.x specifications have
• Segments that imply information entities
• Events that indicate implied behaviors
• Descriptive content that suggests use cases
• but never formally documents these
• Version 3 seeks to formalize this by applying
  object analytic methods and style
• to improve the internal consistency of HL7
• to provide sound semantic definitions
• to enable future architectures
• to produce an evolution not a revolution
• Done by applying MODELING to the HL7 process

19
V3 process is documented in the Message
Development Framework (MDF)

• Captures healthcare requirements
• Defines scope for TSC approval

• Specifies data and its semantics
• Specifies major state transitions
• Specifies vocabulary for domains

• Defines information flows
• Defines communication roles
• Forms basis for conformance claims

• Defines message contents
• Apply constraints to the information model and
  vocabulary

20
Models developed in Phases
21
Methodology in a nutshell

• 1. Define a consensus reference information model
  (RIM) that defines the data of interest in the
  healthcare domain.
• 2. Assemble the terminologies and data types
  necessary to express the attributes of the RIM
• 3. Apply the model, vocabulary and types to
  messages, patient record DTDs, medical logic
  modules, component specifications, etc.
• 4. For any particular application, draw from the
  RIM to construct an abstract message structure -
  the Hierarchical Message Description (HMD)
• 5. For any particular implementation technology,
  define an implementation technology specification
  (ITS) for mapping the HMD to that technology.
• 6. When the message (or equivalent) is sent, the
  HMD is used to marshal the data, and the ITS is
  used to format the data for communication.

22
Version 3 is

• Message Development Framework
• Reference Information Model
• Data Types
• Integrated Vocabulary

23
Required domain submission

• Storyboard (ST)
• Storyboard Example (SX)
• Application Roles (AR)
• Refined Message Information Model (RM)
• Interactions (IN)
• Interaction Category (IC)
• Trigger Event (TE)
• Hierarchical Message Definition (HD)
• Message Type (MT)
• Common Message Element Type (CT)

24
Storyboarding

• the purpose of a message
• the players in an interaction
• the information being shared
• how it is being shared
• the preconditions for a trigger event
• the expected result of the interaction, in terms
  of any other expected interactions.

25
The Reference Information Model

• Expresses the information content for the
  collective work of the HL7 Working Group in UML
  notation.
• A coherent, shared information model that is the
  source for the data content of all HL7 messages.
  
• Maintained by a collaborative, consensus building
  process involving all Technical Committees and
  Special Interest Groups.
• RIM change proposals are debated, enhanced, and
  reconciled by technical committee representatives
  and applied to the RIM during the model
  harmonization process

26
Introduction - Reference Information Model
from November 1999
27
Reference Information Model
Version 1.1 July 2001

• Unified Service Action Model Arose in 1998 as
  result of collaboration between
  Orders/Observations and Patient Care Technical
  Committees of HL7. As name implies, sought to
  unify the HL7 view of what happens when clinical
  services are rendered and clinical actions
  undertaken

28
RIM Core Classes Attributes
Six kinds of attributes type_cd(class_cd), cd,
time, mood(determiner), status, id
29
Core concepts of USAM

• The Act class and its specializations represent
  every action of interest in health care.
• Specifically an intentional action in the
  business domain of HL7. Healthcare (and any
  profession or business) is constituted of
  intentional actions. An instance is a record of
  an act. Acts definitions (master files), orders,
  plans, and performance records (events) are all
  represented by an instance of Act.

30
Core concepts of RIM/USAM

• Every happening is an Act
• Procedures, observations, medications, supply,
  registration, etc.
• Acts are related through an Act_relationship
• composition, preconditions, revisions, support,
  etc.
• Participation defines the context for an Act
• author, performer, subject, location, etc.
• The participants are Roles
• patient, provider, practitioner, specimen, etc.
• Roles are played by Entities
• persons, organizations, material, places,
  devices, etc.

31
Is Act sufficient?

• How can a single act class represent all of the
  elements of clinical action their definition,
  request, order, report?
• Answer the Act mood code Webster's
  dictionary defines mood as a "distinction of form
  . of a verb to express whether the action or
  state it denotes is conceived as fact or in some
  other manner (as command, possibility, or wish)".
  This definition of mood can be directly applied
  to the USAM model, where the action (in natural
  language) may be conceived as an event that
  happened (fact), an ordered service (command), a
  possible service (master), and a goal (wish) of
  health care.

32
Principle Act moods

• definition (DEF) Definition of an act, formerly
  a master file
• intent (INT) an intention to plan or perform an
  act
• order (ORD) an order for a service from an
  order placer to an order filler
• event (EVN) an act that actually happens,
  includes the documentation (report) of the event
• Critical concept Mood is not a status code.
  Each instance of the Act class may have one and
  only one value for mood
• Thus, an act in order mood that orders an act
  in definition mood and results in an Act in
  event mood are three different acts, related
  through the act relationship.

33
RIM Core Classes
Entity
Participation
Act
Role
Referral Transportation Supply Procedure Condition
Node Consent Observation Medication Act
complex Financial act
Patient Employee Practitioner Assigned
PractitionerSpecimen
Organization Living Subject Material Place Health
Chart
34
Interactions

• A unique association between a specific message
  type (information transfer), a particular trigger
  event that initiates or "triggers" the transfer,
  and the application roles that send and receive
  the message type. It is a unique, one-way
  transfer of information.

35
Interaction Model Diagram
Figure Interactions for Patient subject class.b
36
Single interaction explicitly answers

• Which type of system component sends a particular
  type of message
• How a system knows when to send a particular type
  of message
• What the particular message type is
• To what type of receiving system component the
  message type is sent
• What the expectations are, if any, for the
  receiving system to be able to send other
  associated interactions.

37
Message Information Model

• The MIM is used to express the information
  content for one or more related messages. A
  Technical Committee extracts this model from the
  RIM during the Message Design stage of the
  message development process. The MIM starts out
  as a proper subset of the RIM. The Technical
  Committee may add message specific information
  constraints. No new information content is added
  at this point in the message development process
  and information constraints added at this point
  are not allowed to relax constraints specified in
  the RIM.

38
Refined Message Information Model

• The R-MIM is used to express the information
  content for a message or set of messages with
  annotations and refinements that are message
  specific. The content of the R-MIM is drawn from
  the RIM. The R-MIM may include clones of selected
  classes with alias names specific to the
  perspective of the message(s) to be derived.
  Generalization hierarchies in the RIM may be
  collapsed in the R-MIM. Essentially, the R-MIM is
  used to create a certain message-specific
  projection of the RIM for the purpose of being
  context specific while maintaining the semantic
  link to the more generic RIM.

39
Lab Order Super-R-MIM
40
Models are used to build the HMD
Reference
Information Model
Interaction
Model
Domain Specification Database
Common
Hierarchical
Message
Message
Element
Description
Types
41
Hierarchical Message Definition

• The Hierarchical Message Definition defines a
  single message structure that is used for an
  interaction without reference to the
  implementation technology.

42
Implementation Technology Specification

• The Implementation Technology Specification
  describes how to combine data with the message
  structure in order to create a message instance.
  This specification means that a message sent in
  the format of one implementation technology can
  be easily transliterated into the format of
  another.

43
Terminologies the RIM in V3

• From the outset, one goal of the Version 3
  process has been that no coded attribute should
  be included in a message design unless there is a
  specific vocabulary domain defined to constrain
  the values for that attribute to a set that is
  appropriate for the particular message
• Resulted in two, parallel efforts
• Definition of vocabulary domains to support
  messages
• Rich capability in the HL7 data types to preserve
  the semantic integrity of the terminologies used

44
Vocabulary Domains in V3

• Currently, vocabulary definitions are provided
  for
• 108 tables
• containing 5,323 concepts
• grouped into 639 values sets or domains
• Vocabulary Committee actively seeking to define
  additional domains on external terminologies of
  clinical concepts
• Vocabulary committee premise do not develop a
  code set internally where a comprehensive,
  well-maintained terminology is available
  externally at a reasonable cost

45
Initial Version 3 Ballot Package

• Five domain committees participated
• Orders/Observations
• Patient Administration/Finance
• Medical Records Management
• Control/Query
• Scheduling
• Contains
• over 275 specific message types
• supporting over 250 trigger events
• used in over 360 specified interactions
• involving 190 application roles
• using over 30 common message element types
• Supported by over 150 story-boards

46
HL7 3.0 Structure
Reference Content is harmonized during HL7
meetings or approved by the HL7 Board. It is not
subject to ballot acceptance

• V3 Backbone
• Welcome
• Introduction
• Quick Start
• Getting Started
• Glossary

Informative Content is balloted by general
membership however, it is not considered to be a
structural part of the standard, only supporting
information.
Normative Content is balloted by general
membership and is considered structural component
of HL7 standard. Negative ballots MUST be
resolved.
47
Subsection detail
48
An HL7 V2.3 Message
MSH\LABGL1DMCRES199812300100ORUR01LAB
GL1199510221838581P2.3NENE PID6910828Y
C8NewmanAlfredE19720812MW25 Centscheap
AveWhatmeworryUT85201P(555)777-6666(444)
677-7777M773789090 OBR110801LABGL38720937
3DMCRES18768-2CELL COUNTSDIFFERENTIAL TESTS
(COMPOSITE)LN19981229212835MLIN2973
SchadowGuntherMDUPINOnceCA
20837SpinosaJohnMDUPIN OBXNM4544-3HEMA
TOCRIT (AUTOMATED)LN4539-49F199812292
128CA20837 OBXNM789-8ERYTHROCYTES COUNT
(AUTOMATED)LN4.941012/mm34.30-5.90F1
99812292128CA20837
A sample results message
49
V3 XML Prototype - same data
ltLabrs3P00 T"Labrs3P00"gt ltLabrs3P00.PTP
T"PTP"gt ltPTP.primrPrsnm T"PN"gt
ltfmn T"ST"gtSamplelt/fmngt ltgvn
T"ST"gtGeorgelt/gvngt ltmdn
T"ST"gtHlt/mdngt lt/PTP.primrPrsnmgt
lt/Labrs3P00.PTPgt ltLabrs3P00.SIOO_L
T"SIOO_L"gt ltSIOO_L.item T"SIOO"gt
ltSIOO.filrOrdId T"IID"gtLABGL110801lt/SIOO.fil
rOrdIdgt ltSIOO.placrOrdId
T"IID"gtDMCRES387209373lt/SIOO.placrOrdIdgt
ltSIOO.InsncOf T"MSRV"gt
ltMSRV.unvSvcId T"CE"gt18768-2lt/MSRV.unvSvcIdgt
ltMSRV.svcDesc T"TX"gtCELL
COUNTSDIFFERENTIAL TESTS (COMPOSITE)lt/MSRV.svcDes
cgt lt/SIOO.InsncOfgt
ltSIOO.SRVE_L T"SRVE_L"gt
ltSRVE_L.item T"SRVE"gt
ltSRVE.name T"CE"gt4544-3lt/SRVE.namegt
ltSRVE.svcEvntDesc T"ST"gtHEMATOCRIT
(AUTOMATED)lt/SRVE.svcEvntDescgt
ltSRVE.CLOB T"CLOB"gt
ltCLOB.obsvnValu T"NM"gt45lt/CLOB.obsvnValugt
ltCLOB.refsRng
T"ST"gt39-49lt/CLOB.refsRnggt
ltCLOB.clnRlvnBgnDtm T"DTM"gt199812292128lt/CLOB.
clnRlvnBgnDtmgt lt/SRVE.CLOBgt
ltSRVE.spcmRcvdDtm
T"DTM"gt199812292315lt/SRVE.spcmRcvdDtmgt
lt/SRVE_L.itemgt lt/SIOO_L.itemgt
lt/Labrs3P00.SIOO_Lgt lt/Labrs3P00gt
50
Beyond Messaging
Messaging
Vocabulary
Security
CCOW
Messaging
Vocabulary
CDA
Decision Support
Clinical Templates
EHR