Introduction to HL7 Version 3

1
Introduction to HL7 Version 3

• W. Ed Hammond
• February 25, 2008

2
HL7 v3 messaging standard

• HL7 v3 is based on an object information model
  called the Reference Information Model, (RIM).
  This model is abstract, that is, it is defined
  without regard to how it is represented in a
  message on the wire or in a service
  architecture method or in a clinical document.
  In fact, each of these representations can
  contain the same instance of information.
• This object-oriented design paradigm means that
  v3 can be extended incrementally when new
  clinical information domains need to be added, in
  a way that doesnt require changing what has
  already been created.

3
HL7 Development Framework

• The HL7 Development Framework is a formal
  methodology for mapping any local,
  domain-specific system, such as a laboratory
  system in the v3 Reference model.
• The basic concept is that any system can be
  mapped into a neutral and formal UML-based
  Domain Analysis (DAM) model with the help of
  domain experts.
• The DAM can then be mapped into the equivalent
  v3-RIM model.
• This mapping is bi-directional, and highlights
  any changes needed by either the local system or
  the RIM to create a semantically complete
  mapping.
• The RIM Harmonization process supports a standard
  way to add new domain requirements to the RIM in
  a way that doesnt invalidate the previously
  created models. This again is a feature of
  object-oriented paradigms.

4
Model-based Development
HL7 Framework
HL7 Specification
RIMDatatypesData elementsVocabularyTemplatesC
linical Statements

• V3 Messaging
• CDA Specifications
• System Oriented Architecture

Core Structured Content
5
Whats different about v3?

• Conceptual foundation a single, common
  reference information model to be used across HL7
• Semantic foundation in explicitly defined
  concept domains drawn from the best terminologies
• Abstract design methodology that is
  technology-neutral able to be used with
  whatever is the technology de jour (e.g. XML,
  UML, etc.)
• Maintain a repository (database) of the semantic
  content to assure a single source, and enable
  development of support tooling

6
How is Version 3 better?

• Tools for documentation of constraints for both
  message definition and conformance specifications
• Tools to auto-generate XML schemas for messages
  once the semantic content is final (via ballot
  and conformance constraints)
• The same auto-generation process is being used
  for Java APIs for the v3 messaging models

7
Some V3 tools details

• HL7 Model Repository database holding the core
  of HL7 semantic specifications
• RIM - Storyboards
• Vocabulary domains - Interaction models
• Message designs - Message constraints
• Tool sets designed against the repository to
• Permit management of repository content
• Review and browsing of semantic specifications
• Design of abstract information structures based
  on the RIM for use in messages, templates,
  documents, etc.
• Publish HL7 specifications and standards
• Support implementation of HL7 standards

8
Drivers for v3 adoption

• Needed to support for large scale integration
• V3 has built-in support for Complex Datatypes
  supporting
• universally unique instance identifiers for
  persons, places, organizations, practitioners,
  URLs, orders, observations, etc.
• Name datatype (persons and organizations)
• Time and date-related datatype forms
• Codes (binding standard vocabularies to RIM
  attributes)
• V3s methodology of deriving its models from the
  RIM also supports semantic interoperability

9
Drivers for v3 adoption

• For implementations requiring large scale
  integration (city, region, province, nationwide,
  international), v3 has built-in support
• Structural ontology a coherent set of
  (structures) models guaranteeing semantic
  interoperability and re-use based on the RIM and
  datatypes, with integrated vocabulary support
• Identifier strategy supporting wide integration
• Model and Tools based design and implementation
• The need for decision support, and rules-based
  processing requires the v3 model-based semantic
  interoperability which is available across the
  many healthcare information domains.
• The same information is represented the same way
  everywhere using the RIM with the binding to
  structural and standard vocabularies

10
HL7 Version 3.0

• Use-case Model
• Reference Information Model
• Domain Information Model
• Message Information Model
• Message Object Diagram
• Hierarchical Message Description
• Common Message Element Definition

11
HL7 Version 3
Domain LevelElements
12
Common Domains

• Common Message Element Types (CMETS) template
  structures for complex administrative objects
  such as address or telephone number
• Shared Messages
• Clinical Statement

13
Administrative Management

• Accounting and billing
• Claims reimbursement
• Patient Administration
• Personnel Management
• Scheduling

14
Infrastructure / Messaging

• Transmission
• Message Control
• Query
• Master File / Registry

15
Health and Clinical Management

• Blood, Tissue and Organ
• Care Provision
• Clinical Decision Support
• Clinical Document Architecture
• Clinical Genomics
• Immunization
• Laboratory
• Materials Management
• Medical Records

• Medication
• Observations
• Orders
• Pharmacy
• Public Health Reporting
• Regulated Products
• Regulated Studies
• Specimen
• Therapeutic Devices

Items in yellow are Draft Standards for Trial Use
16
Version 3 Methodology
ApplicationRole
TriggerEvent
RIM
Storyboard
Information Modeling
Derive
Sender
Receiver
D - MIM
Triggers
References
Interaction
Restrict
R - MIM
Example
Serialize
Interaction Modeling
HMD
StoryboardExample
Message Design
Restrict
Content
Message Type
Use Case Modeling
17
v-3 Methodology defining abstract message
18
Message instance
lt?xml version"1.0"?gt lt!DOCTYPE Ballt SYSTEM
"Ballot_C00_RIM_0092Da_1.dtd" gt ltBalltgt
ltdttm V"1999120523570100"/gt ltvote V"A"
S"HL7001" R"3.0" PN"Abstain"/gt
ltvotesOn_PropsdItmgt ltstandrdLevlInd
V'T'/gt ltpropsdBy_OrgnztnAsCommttegt
ltnm V"Humble Task Group"/gt
ltisAsubdvsnOf_OrgnztnAsCommttegt ltnm
V"Grand Committee"/gt lt/isAsubdvsnOf_Orgn
ztnAsCommttegt ltpartcpesAsPrimryIn_Stkhldr
Affltngt lt_StkhldrAffltngt
lttype V"X" S"HL7004" R"3.0" PN"XXX"/gt
lthasSecndryPartcpnt_PrsnAsCommtteContctgt
lthas_PrsnNamegt
ltpnmgt ltG V"George"
CLAS"R"/gt ltG V"Woody"
CLAS"C"/gt ltG V"W."
CLAS"R I"/gt ltF
V"Beeler" CLAS"R"/gt
lt/pnmgt lt/has_PrsnNamegt
lt/hasSecndryPartcpnt_PrsnAsCommtteContctgt
lt/_StkhldrAffltngt
lt/partcpesAsPrimryIn_StkhldrAffltngt
lt/propsdBy_OrgnztnAsCommttegt
lt/votesOn_PropsdItmgt
ltcastBy_VotngMembr T"OrgnztnlReprsntv"gt
ltOrgnztnlReprsntvgt ltisRoleOf_PrsnAsVotrgt
lthas_PrsnNamegt ltpnmgt
ltG V"George" CLAS"R"/gt
ltG V"W." CLAS"R I"/gt
ltF V"Beeler" CLAS"R"/gt lt/pnmgt
lt/has_PrsnNamegt
lthas_PrsnNamegt ltpnmgt
ltG V"Woody" CLAS"C"/gt ltG
V"W." CLAS"R I"/gt ltF
V"Beeler" CLAS"R"/gt lt/pnmgt
lt/has_PrsnNamegt lt/isRoleOf_PrsnAsVo
trgt ltsponsrdBy_OrgnztnAsHL7Membrgt
ltnm V"Mayo Clinic"/gt
ltemailAddrssTxt vhl7_at_mayo.edu/gt
lt/sponsrdBy_OrgnztnAsHL7Membrgt
lt/OrgnztnlReprsntvgt lt/castBy_VotngMembrgt lt/Ball
tgt
Source W. Beeler
19
v3 Messaging Concerns

• Difficult to implement
• Overhead too much
• 1 of message is payload compared to v2
  (delimiters) is about 90-95
• No one understands what implementation of v3
  messaging means
• Question value of HDF
• Need stability, clarity, definition of v3
  messaging

20
What about v3 messages?

• Some implementers create their own messaging
  using the HDF process. This is tough and
  probably not necessary.
• HL7 has begun to build a library of v3 messages,
  developed by HL7 experts in different areas and
  clinical domains.
• How many v3 messages are required to support
  robust EHR, RHIO, NHIN?
• Could we meet needs with one message and
  constraints?

21
Introduction to Clinical Data Architecture

22
Document standards

• Clinical Document Architecture (CDA)
• Radiology reports
• Patient summary
• Discharge summary
• Referrals
• Claims attachments
• Infectious Disease Reports
• Continuity of Care Record (CCR)
• Continuity of Care Document (CCD)
• Common Document Types

23
What is the CDA?

• The CDA is a document markup standard for the
  structure and semantics of exchanged "clinical
  documents".
• A CDA document is a defined and complete
  information object that can exist outside of a
  message and can include text, images, sounds, and
  other multimedia content.

24
Key aspects of CDA

• CDA documents are encoded in Extensible Markup
  Language (XML).
• CDA documents derive their meaning from the HL7
  Reference Information Model (RIM).
• CDA is derived from HL7's central Reference
  Information Model, thereby enabling data
  reusability - with lab or pharmacy messages, with
  claims attachments, clinical trials, etc.
• The CDA specification is richly expressive and
  flexible. Templates, conformance profiles, and
  implementation guides can be used to constrain
  the generic CDA specification.

25
CDA Release 1
Allergies and Adverse Reactions   Penicillin -
Hives   Aspirin - Wheezing   Codeine Itching
and nausea
ANSI/HL7 CDA R1.0-2000
ltsectiongt ltcaptiongt ltcaption_cd V"11496-7"
SLOINC"/gt Allergies and Adverse
Reactions lt/captiongt ltlistgt
ltitemgtltcontent IDA1gtPenicillin -
Hiveslt/contentgtlt/itemgt ltitemgtltcontentgtAspirin
- Wheezinglt/contentgtlt/itemgt ltitemgt
ltcontentgtCodeine Itching and nausealt/contentgt
lt/itemgt lt/listgt ltcoded_entrygt
ltcoded_entry.value ORIGTXTA1
V"DF-10074" SSNOMED DNAllergy to
Penicillin/gt lt/coded_entrygt lt/sectiongt
26
ltsectiongt ltcode code"101155-0"
codeSystem"2.16.840.1.113883.6.1"
codeSystemName"LOINC"/gt lttitlegtAllergies and
Adverse Reactionslt/titlegt lttextgt ltlistgt
ltitemgtltcontent ID"A1"gtPenicillin -
Hiveslt/contentgtlt/itemgt ltitemgtAspirin -
Wheezinglt/itemgt ltitemgtCodeine - Itching and
nausealt/itemgt lt/listgt lt/textgt ltentrygt
ltobservation classCode"OBS" moodCode"EVN"gt
ltcode code"247472004" codeSystem"2.16.840.1.113
883.6.96" codeSystemName"SNOMED CT"
displayName"HIves"gt ltoriginalTextgtltrefere
nce value"A1"/gtlt/originalTextgt lt/codegt
ltentryRelationship typeCode"MFST"gt
ltobservation classCode"OBS" moodCode"EVN"gt
ltcode code"91936005" codeSystem"2.16.840.1.
113883.6.96" codeSystemName"SNOMED
CT" displayName"Allergy to
penicillin"/gt lt/observationgt
lt/entryRelationshipgt lt/observationgt
lt/entrygt lt/sectiongt
CDA Release 2
27
Continuity of Care Document (CCD)

• CCD as a catalyst
• The approach taken in the development of CCD is
  to reflect the CCR requirements in a CDA R2
  framework, and to do so in such a way that CDA is
  constrained in accordance with models being
  developed by other HL7 committees.
• This has helped accelerate convergence within HL7
  around a common clinical statement model,
  leading to closer collaboration with several
  domain committees, such as
• Results Lab committee
• Family History Genomics committee
• Allergies, Problems Patient Care committee
• Medications Pharmacy committee

28
Continuity of Care Document (CCD)

• CCD maps the CCR elements into a CDA
  representation.

ltResultsgt ltResultgt ltCCRDataObjectIDgt
2.16.840.1.113883.19.1 lt/CCRDataObjectIDgt
ltDateTimegt ltTypegt ltTextgtAssessment
Timelt/Textgt lt/Typegt ltExactDateTimegt
200004071430 lt/ExactDateTimegt
lt/DateTimegt ltTypegt ltTextgtHematologylt/Tex
tgt lt/Typegt ltDescriptiongt ltTextgtCBC
WO DIFFERENTIALlt/Textgt ltCodegt
ltValuegt43789009lt/Valuegt
ltCodingSystemgtSNOMED CTlt/CodingSystemgt
lt/Codegt lt/Descriptiongt ltStatusgtltTextgtFinal
Resultslt/Textgtlt/Statusgt
ltsectiongt ltcode code"30954-2
codeSystem"2.16.840.1.113883.6.1"
codeSystemName"LOINC"/gt lttitlegtLaboratory
resultslt/titlegt lttextgt CBC (04/07/2000)
HGB 13.2 WBC 6.7 PLT 123 lt/textgt ltentrygt
ltobservation classCode"OBS" moodCode"EVN"gt
ltid root"2.16.840.1.113883.19"
extension"1"/gt ltcode code"43789009"
codeSystem"2.16.840.1.113883.6.96"
codeSystemName"SNOMED CT"
displayName"CBC WO DIFFERENTIAL"/gt
ltstatusCode code"completed"/gt
lteffectiveTime value"200004071430"/gt