Introduction to HL7 Version 3

1
Introduction to HL7 Version 3

• Jane Curry
• Sierra Systems
• HL7 Canada Halifax
• October 18th, 2001

2
Todays Objectives

• Discuss the rationale for Version 3.
• Introduce the Version 3 methodology
• Describe the RIM its core components and relate
  to Vocabulary Domains and Data Types.
• Briefly discuss the use of XML (eXtensible Markup
  Language) in Version 3.
• Version 3 and the EHR new opportunities

3
Acknowledgements

• Abdul-Malik Shakir
• Woody Beeler
• Stan Huff
• Ted Klien
• Lloyd McKenzie
• Dan Russler
• Gunther Schadow
• Helen Stevens
• Mead Walker
• And others too numerous to mention
• (The named individuals are those I directly
  swiped slides from)

4
Outline of this Session

• Version 3 and the drive for Interoperability
• A new paradigm for HL7 Messages - methodology
  introduction
• Introduction to the HL7 Reference Information
  Model (RIM) to HL7 vocabularies
• Key Ballot Components
• Message Basics
• XML HL7s chosen message transport mechanism
• Discussion on HL7 V3 and the EHR

5
Note Our Focus is on Standards Development

• The Version 3 methodology provides
• processes for building HL7 message
• discussion of the models that support that
  process
• tools to aid in message creation
• Standards implementers should understand the
  basis for the messages they implement.
• Standards implementers do not need to master the
  mechanics of using the methodology simply to
  implement V3 interfaces.

6
Interoperability Innovation

• Main Entry interoperabilityFunction
  nounDate 1977 ability of a system (as a
  weapons system) to use the parts or equipment of
  another system Source Merriam-Webster web site
• interoperability ability of two or more
  systems or components to exchange information and
  to use the information that has been
  exchanged. Source IEEE Standard Computer
  Dictionary A Compilation of IEEE Standard
  Computer Glossaries, IEEE, 1990

7
Interoperability Innovation

• Main Entry innovationFunction nounDate
  15th century1 the introduction of something
  new2 a new idea, method, or device
  novelty Source Merriam-Webster web site

8
Interoperability Innovation

• HL7s mission is clinical interoperability
• To provide standards for the exchange,
  management and integration of data that supports
  clinical patient care and the management,
  delivery and evaluation of healthcare
  services. Source HL7 Mission statement (1997)
• HL7s strategy is innovation both by ourselves
  and by our users

9
Another Perspective on New Requirements

• Drawn from The eHealth Landscape - a paper
  prepared for the Robert Wood Johnson Foundation
  to discuss emerging information and communication
  technologies (available online at www.rwjf.org.)

Many observers believe that a vision of
convergent or at least interoperable clinical,
laboratory, and public health information systems
appropriately linked to personal health
information, will provide unprecedented
opportunities for improving individual and
population health services and knowledge.
Outside of the approximately 3 billion health
care claims processed annually, an estimated
additional 25 to 30 billion clinical, financial,
and administrative health care transactions take
place, with only a small fraction of these
transactions transmitted electronically.
Extensible Markup Language (XML) is enabling the
development of innovative eHealth tools that are
considerably more powerful and user friendly than
what we currently have.
10
What must be specified for communication?
HL7 specifications
Nouns .
Adjectives
Verbs

• The semantics of the communication
• The semantics convey the actual "meaning" of the
  message. The semantics is conveyed via a set of
  symbols contained within the communication. An
  external "dictionary", thesaurus, or terminology
  explains the meaning of the symbols as they
  occur.

A syntax for communication The syntax defines the
structure and layout of the communication. Common
syntax representations include ASN.1, XML, X.12,
HL7, IDL, etc.
Services to accomplish the communication Examples
include the post office, a telephone
switchboard, SMTP, FTP, Telnet, RPC, ORB
services, etc.
11
HL7 Version 3.0

• HL7 version 3.0 will be the most definitive HL7
  standard to date, incorporating more trigger
  events and message formats with very little
  optionality.
• Version 3.0 uses an object-oriented development
  methodology and a Reference Information Model
  (RIM) to create message specifications.
• The RIM is an essential part of the HL7 Version
  3.0 development methodology, as it provides an
  explicit representation of the semantic and
  lexical connections that exist between the
  information carried in the fields of HL7
  messages.
• As part of version 3.0, the HL7 Vocabulary
  Technical Committee is developing methods that
  will allow HL7 messages to draw upon codes and
  vocabularies from a variety of sources.
• The V3.0 vocabulary work will assure that the
  systems sending and receiving V3.0 HL7 messages
  have an unambiguous understanding of the code
  sources and code value domains they are using.
• HL7s primary goal for version 3.0 is to offer a
  standard that is definite and testable, and to
  provide certification of vendors conformance.

12
Limitations of Version 2.x

• Implicit information model, not explicit.
• Events not tightly coupled to profiles.
• Need for controlled vocabularies.
• Limited to a single encoding syntax.
• No explicit support for object technologies.
• No explicit support for security functions.
• Optionality is ubiquitous and troublesome.

13
HL7 Version 3 Characteristics

• Design based on consensus Reference Information
  Model - ties message elements to explicit
  semantic definitions
• Adaptable to current and future technology bases
  - requires abstract expression of standard data
  structure
• Vocabulary-level interoperability - requires
  robust data type(s) for coded data
• Explicit conformance model - means that optional
  elements in the specification must be eliminated
  where ever possible

14
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

15
V3 has a Focus on Quality

• We often criticize the quality of standard
  interfaces
• each implementation is different,
• install time is no less then a custom interface,
• little support for specialized needs.
• Version 3 provides a platform for quality
  improvement
• the methodology defines the process for creating
  the standard - this is subject to incremental
  improvement,
• models such as the RIM explicitly declare the
  functional assumptions of the standards
  developers.
• The drive to create more rigorous specification
  of interface leads to greater effort in standards
  development.

16

• Outline of a Method for building Messagesa
  Methodology

17
Version 3 Messaging Goals

• Provide a framework for coupling events, data
  elements and messages.
• Improve clarity and precision of specification.
• Improve adaptability of standards to change.
• Begin to approach plug and play.

18
History of HL7 V3 Messaging Activities

• 2000
• V3 data types out to ballot
• First vocabulary harmonization
• V3 Acceleration Project started
• 2001
• RIM and Vocabulary stabilized
• Version 3 Publication Strategy
• Publish initial message ballot
• Datatype ballots expected complete
• XML ITS ballot completed

• 1996
• Introduce modeling to TC Chairs
• First V3 Tutorial to general membership
• Vocabulary SIG established
• 1997
• Roll-out of first RIM, version 0.80
• First Message Development Framework
• First RIM Harmonization meetings
• 1998
• Adopted Rational Rose for modeling
• Work begins on V3 XML ITS
• First RoseTree tools appear
• 1999
• V3 Data type proposal reviewed
• Notion of R-MIM added to MDF
• Vocabulary enters the V3 MDF

19
HL7 Modeling
Abstractions
Version 2.x focused its energies at the
communication level and covered the other
abstractions only loosely in the specifications.
Activities(Use Case Model)
Objects (Information Model)
Communication (Interaction and Message Models)
20
Messaging Methodology Mission

• To bring modern software engineering practices,
  such as Object Oriented Analysis and Design and
  formal modeling, to the standards development
  process.
• To bring the highest level of quality,
  understandability, and flexibility to a messaging
  standard.
• Incorporate concept abstractions and behavior
  modeling using roles in a rigorous set of work
  products.
• Express the standard in widely accepted UML
  notation.

21
In fact, Version 3 Is Mostly Modeling

• The deliverables are expressed as models.
• Each model leads to greater understanding of
  areas that influence content, structure, and
  behavior of messages.
• Messages are defined when the models are
  integrated.
• The HL7 standard message specification will be
  derived from the models.

22
HL7 Version 3 Models and Specifications

• 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

23
HL7 V3 Messaging Deliverables

• Use case model
• Hierarchy of tasks and actors
• Interaction model
• Trigger events, abstract messages application
  profiles
• Information model
• Classes, relationships, states, and lifecycles

• Message design model
• Refined Message Information Model (R-MIM)
• Abstract message definitions (HMDs)
• Vocabulary
• Domain definitions
• Representations and mappings
• Implementation Specification
• Implementation Technology Specification (ITS)

24
HL7 V3 Message Development Lifecycle
Analysis
Design
Application
Messaging Message Types for use with
XML, ER7, etc (MET)
Requirements Analysis Use
Case Model (UCM)
Domain Analysis Information Model
Vocabulary (RIM)
Interaction Design Interaction Model (IM
)
Message Design HierarchicalMessageDescr
iptions (HMD)
Documents Document Types forHL7
PRA (DTD)
Medical logic Variable definition for
Arden syntax (AVD)
TYPE MPSLOC CONTAINS idid.TYPE
IID nmname.TYPE ST adaddr.TYPE
XAD phphon.TYPE XTN email_address
emlAdr.TYPE XTN
2-nd Order 1 choice of 0-n Drug
0-1 Nursing
lt!ENTITY DT_MPSLOCMPSLOC.id, MPSLOC.name?,
MPSLOC.addr?, MPSLOC.phon?, MPSLOC.emlAdr?"gt
datalocation_of_action READ LAST
MPSLOC patient location
Reference Model Repository
25
Message Development Phases
26
An HL7 Version 2.x Message Spec
Common Specs
27
An HL7 Version 3.x Message Spec
HL7 Reference Model
Common Specs
Future Consideration
Implementable Message Specification XML/ER7/
Implementable Message Specification OLE/CORBA
Implementable Message Specification EDIFACT
28
HL7 Version 3 Methodology in words

• 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,
  HL7 will 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.

29
Defining Conformance within V3

• Reducing the cost, and increasing the
  predictability of a new interface is a key driver
  for Version 3.
• At the same time, the standards organization
  cannot, and should not, determine how application
  functions should be organized and bundled
  together.
• For example
• Should an application that manages patient
  encounters also manage patient accounts?
• Does a system that captures (outpatient) visits
  also have to record inpatients?
• Does a system that receives lab orders also have
  to receive pharmacy orders.
• The solution is conformance claims based on
  application roles.

30
V3 Conformance Claims

• HL7 defines, within the Interaction Model,
  application roles that are played by message
  senders and receivers.
• A vendor or system creator issues conformance
  claims that declare which application role or
  roles their system can support.
• This implies the system can send and/or receive
  all the messages defined for that application
  role.
• Conformance claims also indicate how a vendor or
  system creator supports V3 messages.
• They declare the message encoding to be used.
• They indicate, of the attributes in a message
  that are neither mandatory nor forbidden, which
  are supported.

31
How do you get an encoded message?
32

• Building an HL7 Reference Information Model

33
HL7 core requirement - Common semantic models
34
The Information Model

• A detailed and precise definition for the
  information from which the data content of HL7
  messages are drawn.
• Follows object-oriented modeling and diagramming
  techniques, and is centered on a depiction of the
  classes that form the basis for the objects in
  HL7 messages.
• Provides a means for expressing and reconciling
  differences in data definition independent of
  message structure.
• Forms a shared view of the information domain
  used across HL7

35
The Reference Information Model (RIM)

• Used to express the information content for the
  collective work of the HL7 Working Group.
• 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

36
The Reference Information Model

• is a consensus view on our universe
• nothing exists outside, isolated from the RIM
• provides flexible structures
• rather than isolated detail data elements
• melts the vertical silos into a coherent whole
• is work in progress
• wants you to get involved
• wants you to wrestle with it,
• wants you to understand it,
• wants you to help improving it
• wants to work for you!

37
Committee Models Vs. HL7 Model

• What is the RIM?
• A HL7-wide common reference model that integrates
  all Technical Committees domain views
• Why do we need a common model?
• To ensure consistency of concepts
• To ensure consistent vocabulary

• How will we coordinate these efforts?
• Iterative reviews
• Harmonization meetings
• Who controls RIM?
• The MM committee
• Format, syntax, style
• Revision histories
• The Technical Steering Committee
• Dispute resolution
• Overseer

38
HL7 RIM Harmonization Process
Review RIM Change Proposal w/ Stewards
Prepare RIM Change Proposal
39
Reference Information Model
40
RIM Core Classes
Entity
Participation
Act
Role
Encounter Referral Supply Procedure Observation Su
bstance Administration Financial act
Patient Employee Certified Practitioner Assigne
d PractitionerSpecimen Healthcare Facility
Organization Living Subject Material Place
41
Definitions

• Act - 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.
• Entity - physical thing or organization and
  grouping of physical things. A physical thing is
  anything that has extent in space, mass. Excludes
  information structures, electronic medical
  records, messages, data structures, etc.
• Role For people, role is usually positions,
  jobs, or hats and for places and things are
  what these places or things are normally used
  for.
• Each role is played by one Entity and is
  usually scoped by another. Thus the role of
  Patient is played by (usually) a person and
  scoped by the provider from whom the patient will
  receive services. Similarly, an Employee role is
  scoped by the employer.

42
Definitions (continued)

• Participation -- exists only within the scope of
  one act. Acts have multiple participants, each of
  which is an entity in a role. Role signifies
  competence while participation signifies
  performance.
• Relationship Link Is similar to an Act
  relationship in that it binds together two roles.
  Thus Dr. Smith of the OB section (an Assigned
  Practitioner) has primary responsibility for Mrs.
  Smith (a Patient of Mercy Hospital).

43
RIM Core Attributes
Relationship Link
Act Relationship
type_cd CS effective_time IVLltTSgt
type_cd CS
Entity
Role
Participation
Act
class_cd CC cd CE determiner_cd CS status_cd
CS id II
class_cd CS cd CE effective_time
IVLltTSgt status_cd CS id II
type_cd CS time IVLltTSgt status_cd CS
class_cd CC cd CD mood_cd CS status_cd
CS effective_time GTS id II
1
plays
0..
1
scopes
0..
Six attributes Class_cdcd/type_cd, time, mood,
determiner, status, id
44
RIM Core Attribute Value Sets
Entity
Role
Participation
Act
class_cd CC determiner_cd CS status_cd
CS cd CE
class_cd CS effective_time IVLltTSgt cd CE
type_cd CS time IVLltTSgt status_cd CS
class_cd CC mood_cd CS status_cd CS Cd
CD effective_time GTS
1
plays
0..
1
scopes
0..
45
Act State Model
46
Master Act(definition)
Care plan for a patient
Define plans and guidelines
Act
Ordering(order)
Business Cycle
Scheduling
Performing
Reviewing
Documenting reporting(event)
47
Why Does the RIM look the way it does?

• Highly generic class structure promotes stability
  and extensibility.
• Provides a simple construct that can easily be
  grasped.
• The richness and complexity of the real world is
  captured in individual domain and message
  information models.
• Note, for some, the RIM is too abstract. HL7 is
  working on a way to link together the subset
  models to address this issue.

48

• A RIM is not enough what about Vocabularies.
  and Data Types?

49
Constraining Coded Attributes

• Coded attributes in the RIM must be associated
  with one and only one Vocabulary Domain prior to
  being used in a message specification.
• A vocabulary domain is The set of all concepts
  that can be taken as valid values in an instance
  of a coded field or attribute.
• Each concept in the vocabulary domain is
  represented using a code from a specific
  vocabulary.

Coded attributes Over 40 of RIM attributes are
coded!
50
Attributes, domains, and value sets
51
Vocabulary Domains

• A vocabulary domain is a defined set of coded
  concepts.
• A vocabulary may be specified as an enumerated
  list of coded concepts (HL7 defined) or as a
  reference to an externally maintained list of
  coded concepts (e.g., SNOMED, LOINC, CPT,).

52
Vocabulary Domain Specification
53
Vocabulary Codes Definitions
54
HL7 Vocabulary Development Strategy

• Reference existing vocabularies.
• Collaborate with other Standards Development
  Organizations (SDO)
• DICOM,
• ASTM,
• X12.
• Add value by creating a formal linkage between
  HL7 messages and existing vocabularies.
• Only add items that do not already exist.
• Collaborate with vocabulary developers.

55
Each coded attribute has a domain specification

• administrative_gender_cd CE ltAdministrativeGende
  rgt CWE
• A code depicting the gender (sex) of a person
  (e.g., female, male).
• living_arrangement_cd CV ltLivingArrangementgt
  CWE
• A code depicting the living arrangements of a
  person (e.g.,
• independent household, nursing home, extended
  care facility,
• retirement community, etc.).
• marital_status_cd CV ltMaritalStatusgt CWE
• A code indicating the married or similar
  partnership status of a person,
• e.g., married, separated, divorced, widowed,
  common-law marriage.

56
Codes and Print names in the Vocabulary Tables

• AdministrativeGender
• M Male
• F Female
• LivingArrangement
• H Independent Household
• I Institution
• N Nursing Home
• X Extendedcare facility
• R Retirement Community
• G Group Home
• T Transient
• M Nomadic
• MaritalStatus
• S Single
• M Married
• D Divorced
• SP Separated

57
Vocabulary domain

• The set of all concepts that can be taken as
  valid values in an instance of a coded field or
  attribute.
• Concept - A unit of thought constituted through
  abstraction on the basis of characteristics
  common to a set of objects. ISO 1087
• Each concept in the domain can be represented
  using a specific vocabulary/terminology

58
Specialization of Domains

• Used in specifying message
• R-MIM, CMET, HMD, Templates
• Constrain an attribute to a subset of the global
  domain
• Constrain an attribute to an exact code value
• For HL7 maintained domains
• Create new sub-domains in the HL7 tables
• For domains defined by external vocabularies
• Create an expression that selects the set of
  codes desired
• Allowed set operators
• Union (?)
• - Difference (sometimes represented as \)
• Intersection (?)
• Value set name
• Domain nameRealmTerminology
• Examples GenderRootHL7, DiagnosisUSASMI

59
Vocabulary Domain Specification

• General form
• One and only one domain for each coded RIM
  attribute
• ltdomain name, list of domain qualifiersgt
• ltGender, ExtCWEgt
• Currently two types of domain qualifiers
• Extensibility (Extensibility)
• CNE - Coded No Extensions
• CWE - Coded With Extensions
• Realm (RealmOfUse)
• Root (universal HL7 domain)
• USA?
• Europe?
• Others

60
Domain Constraint Notation

• To specify the relationship between type_cd and
  cd in Act
• invariant(Act x) where x.nonNull
• x.cd.implies(x.class_cd)
•  To specialize Act to be a LOINC observation
• invariant(Observation x) where x.nonNull
• x.class_cd.implies(ActTypeObservation)
• x.cd.implies(x.class_cd) (same for all Acts)
• x.cd.codeSystem.equals(
• 2.16.840.1.113883.6.1ltLOINCgt)
  

61
V3 Coded Data Types
62
CodedSimpleValue (CS)
type CodedSimpleValue alias CS restricts CD ST
code ST displayName XML ltmood_cd TCS
CINT/gt ltmood_cd TCS CINT
DIntent/gt Structural type attribute or CNE
field. Code must come from the specified HL7
domain
63
Hierarchical Relationships
Race
64
You can use the Rosetree tools to view Vocabulary
domains
65
What is a value set?

• A named set of valid values for a specific
  vocabulary domain
• Usually organized with a specific format or
  coding system (sometimes called code scheme)
• Valid values may be explicitly listed, or be
  referenced by referring to another value set with
  a constraint expression
• Concepts can be described and organized but only
  values that are represented in a format that can
  be interpreted can be sent in a message

66
Data types and attribute types

• Data types
• Are specifications for the value domain of an
  attribute
• Are balloted formally by HL7
• Initial, committee-level V3 data type ballot
  concluded September 2000
• Once assigned to an attribute, may not be changed
• May be defined as late as when the attribute is
  used in an HMD (late binding)
• Attribute types
• Provide a general characterization of an
  attribute
• Are defined in information model section of MDF
• Control the naming of attributes
• Indicate the set of applicable data types
• Must be assigned when an attribute is defined
  (early binding)

67
Data type basics - an analogy

• Classes have attributes
• Each attribute is assigned a data type
• Classes have hierarchies
• Classes have explicit associations
• Classes can have aliases

• Data types have components
• Each component is assigned a data type
• Data types have hierarchies
• Data types have implicit associations (at best)
• Some data types are aliases

68
Representation of data types in the RIM

• Data types are defined within categories assigned
  the Data_type_category stereotype (Causes a D
  to appear on the category icon in the Rose
  Browser)
• Data types are defined in Rose classes that have
  the Data_type stereotype (Causes a D to
  appear on the class icon in the Rose Browser)
• Data type components are the attributes of the
  stereotype classes
• Generic data types are modeled as parameterized
  classes
• Special properties for the data type classes

69
Data type specialization

• HL7 uses two stereotypes of the
  generalization/specialization (super-type/sub-type
  ) hierarchy in defining data types
• extends stereotype means that the subtype
  inherits the properties and components of the
  parents. In most cases, the parent super-type
  represents a value component of the sub-type,
  where the data type of the value is the parent
  data type
• constrains stereotype means that the sub-type
  has a similar structure as the parent, but
  imposes constraints on the components of the
  parent.

70
Selected flavors of null
Name Meaning not present Value is not present in
a given message. This concept exists only in
messages. As soon as a message is processed by a
receiver it is resolved into a default value,
which may be another null value. no
information This is the default null value. It
simply says that there is no information
whatsoever in the particular message where the no
information value occurs. The information may or
may not be available at the senders system, it
may or may not be applicable or known. The
receiver can not interpret the no information
value any further. not applicable The attribute
does not apply at all. unknown A value is
applicable but is unknown to the sending
system. other A value exists and is known but is
not an element of the domain. Note that other is
a specific flavor of a null value, it is not a
not otherwise specified null value.
71

• Understanding Basic Ballot Components

72
HL7 3.0 Core Publication 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
• V3 Principles
• 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.
Implementable Technology Specifications
XML
Data Types
Data Types
Part I
Part II
Section Infrastructure Management
Sub-sections
Legend
Section Health Clinical Management
Reference
Sub-sections
Informative
Section Administrative Management
Normative
Sub-sections
73
HL7 3.0 Section Publication Structure
CMET
R-MIM
HMD
Message Type
Sub-sections
Domain
Application Roles
R-MIM
HMD
Message Type
Storyboard
Interaction Category
Storyboard Examples
Legend
Reference
Trigger Event
Informative
Normative
Interaction
74
Message Development Phases
75
Storyboard A story to illustrate the domain

• A partial overall Lab Order Storyboard is as
  follows
• Anthony Chaves has been experiencing lower back
  pain on his right side. Lately he has also
  experienced discomfort during urination and the
  frequency of urination has increased. These
  symptoms have been going ongoing for the past few
  weeks, so Anthony decides to visit his family
  doctor, Doctor Adams.
• Doctor Adams examines Anthony, he takes his
  temperature to determine if Anthony has a fever,
  and Anthony doesn't. Doctor Adams taps Anthony,
  on the lower right section of his back. Anthony
  states that when Doctor Adams does this, the pain
  increases slightly.
• Anthony also has a history of Diabetes in his
  family, so Doctor Adams decides that he will need
  to have a Urinalysis test performed, to determine
  if there is a kidney infection, and a Fasting
  Glucose Level to rule out Diabetes. Frequent
  urination is a symptom of Diabetes.
• The urine and blood samples are taken from
  Anthony. The blood sample is put in a red top
  vacutainer this is used for the serum
  separation. The blood is spun down to separate
  the serum from the blood cells and the urine is
  placed in a urine cup and prepared for transport.
  Doctor Adams has his nurse place the orders
  through his Physician Order System (POS).
• The lab receives the request for the Urinalysis
  and Fasting Glucose Level tests through their Lab
  Information System (LIS). The two specimens,
  urine in the urine cup, and a spun-down vial of
  blood, in a red top vacutainer are sent to the
  lab, via courier for testing.

76
Application Roles Whos responsible for What?

• Application Roles are simply the name for an
  application interface that is responsible for
  sending and receiving an explicit set of messages
• A particular system may have many application
  roles
• Application roles can be hierarchical or nested
  so that the most general are responsible for more
  messages than the more specific
• Application Roles are discovered by inspecting
  the set of interactions between systems that are
  required to do real work
• Application roles may be deemed to be loosely
  or tightly coupled, depending on whether there
  is an expectation that they share key identifier
  and Master File information. This often
  differentiates whether or not the messages need
  to contain more or less information.
• Application roles may be named as manager,
  tracker, archivist to identify their expected
  function

77
Trigger Events What makes information flow?

• Trigger events are some real world event that
  initiates a message set
• Usually a readily identifiable business event
• A system has to be able to recognize that such an
  event occurred
• A person can interact with a system to invoke a
  trigger event
• A trigger may be invoked by a pre-defined rule
  that monitors the condition of selected data (eg.
  Alerts)
• A trigger may be a certain time interval or point
  in time
• A trigger event may cause a transition from one
  state to another for the focal class usually
  an Act or Act Clone

78
Interactions A message in a particular context

• An Interaction is made up of
• 1. A specific Trigger Event
• 2. A sending Application Role
• 3. A specific Message Type
• 4. A receiving Application Role
• 5. Optionally, additional interactions the
  receiving application must initiate

79
An example Interaction Diagram
80
Using the RIM to Build Messages
81
RMIM Example from the V3 Ballot -
82
Message Development Phases
83
Version 3 in a nut shell

• Domain specialists define the essentials of their
  messaging requirements. Visio RMIM tooling is
  available as is a Publications database to
  document storyboards, interactions and
  application roles.
• Specialist prepares a design R-MIM using Rosetree
  and then builds a preliminary HMD by walking the
  graph
• Committee reviews HMD content. Revise as
  necessary.
• Working with spreadsheets of the HMD (or directly
  using Rosetree), the committee maps out the
  constraints on the HMD that constitute the
  specific message types
• The resulting databases are assembled and
  processed with publication tooling to include in
  the ballot package
• Steps 1-4 are iterative as the Committee
  clarifies the specifications

84
10 Steps to V-3 Interactions from Storyboards

• 1. Storyboard Write a simple example for your
  domain that illustrates where information is (or
  should be) transferred to accomplish a clinical
  scenario. This is to help you understand who is
  involved how, what they need to know when,
  and how they use computers to accomplish their
  tasks. It will also be part of the documentation
  of the standard
• 2. Application roles
• Look at the storyboard and decide where
  communication between systems will be needed.
  Consider the kind of system involved (HIS, lab,
  etc.) and include possible decomposition (e.g.
  if a hospital has a monolithic system, consider
  sub-functions like ADT and lab.)
• Use arrows to signify the information exchanges
  implied in the story board. (e.g. A queries B for
  results, B responds.)
• Review the communications and determine the
  primary content or subject of each.(e.g. patient
  admission, x-ray results, orders, etc.)
• Use the above to list application roles
  (e.g.order manager, admission tracker, etc.)
• 3. Interactions
• Lay out a rough collaboration diagram, in which
  the application roles are boxes, and the
  information flows are directed arrows between
  them
• Each arrow is an interaction. Label it with
• An identifier
• The name of the trigger event
• The name or a summary of the message content to
  be transferred
• 4. Fill out the Publication Database for the
  Trigger Events, Application Roles, Message Types
  and Interactions you have defined.

85
10 Steps to V-3 R-MIM design from Interactions

• 5. Consider the message contents for the
  interactions you have just defined. For each,
  summarize in list form, using common terms the
  information elements that need to be transferred.
  (e.g. Admission including patient demographics,
  MRN, Admitting MD an order for a tele-health
  specialty consultation query for lab and
  radiology results for last ten days etc.)
• 6. Order and structure the lists from the
  previous step to indicate what is subordinate to
  what, how the information elements might be
  grouped, etc.
• 7. For the information groupings, identify which
  ones your team will need to design, and which you
  expect to receive from other committees (or for
  which a string starter-set will come from other
  committees).
• 8. For the information groupings you will design,
  further classify them by their likely RIM (R-MIM)
  representations
• Acts Act-relationships Participations
• Entities Role-relationships Other or
  undetermined
• 9. Use the Visio R-MIM notation using the Visio
  tooling (perhaps on flip charts) to diagram the
  R-MIM fragment for each of your groupings.
  Include the likely or critical attributes for
  each. And specify the class or type code for each
  class, and the mood code for each Act.
• 10. Link your fragments together on the diagram
  to document your R-MIM.

86
Message basics (1)

• Every part of the message, from the entire
  message down to the smallest subcomponent of a
  subcomponent of a data type, is a message
  element.
• Every message element has a type.
• Every message element that is an attribute of a
  RIM has a type that is an HL7 data type.
• Every message element that represents a component
  of an HL7 data type also has a type that is an
  HL7 data type.
• Every message that represents a class has a type
  that is based on that class or a Common Message
  Element Type.

87
Message basics (2)

• Every message element that represents an
  association has a type that is based on the
  distal class of the association or a Common
  Message Element Type.
• Every message element type is one of these four
  metatypes primitive, composite, collection, or
  choice.
• Primitives have no subordinate components.
• Composites have heterogeneous subordinate
  components, each with its own name.
• Collections have repetitions of a homogeneous
  message element.
• The name of the repeating message element is
  derived from its type.

88
Hierarchical Message Description

• Includes
• path
• choices
• interpolated items for collections
• Special treatment for specializations that are
  not subsumed in the R-MIM
• Other than the path, there is no additional
  semantic content in the HMD, when compared to the
  Tabular R-MIM (the other differences are
  algorithmically developed)

89
R-MIM components

• The information model section (left) lists the
  information model entities (classes,
  associations, and attributes), one per row.
• The constraints and defaults section (right)
  states specific constraints on the information
  model entities that will be applied to all
  message formats defined in HMDs derived from the
  R-MIM. Some of the constraints are also a part of
  the MIM, although they may be tightened in the
  R-MIM. Many of the constraints are not UML
  constructs they apply specifically to the HL7
  messages defined based on the R-MIM.

90
R-MIM - Information model section

• Row types
• rmim - the first row of the table, identifies the
  R-MIM
• class - identifies a "class" in the Refined
  Message Information Model
• attr - identifies an attribute of the "class"
  that is most directly above this row
• assoc - identifies an association leading from
  the class that is most directly above this row
• stc - subtype constraint row corresponds to a
  subcomponent of the row above included in order
  to be able to state a constraint on the subtype
• Class or Property -- contains the information
  model name of the entity
• Short name -- an abbreviated form of the name of
  the entity that will be used to tag the
  corresponding message elements in ITS-specific
  syntaxes that use tags.
• Inherited from. This is the class where the
  property (attribute or association) appears in
  the Message Information Model.
• Message Element Type. For attributes, this is the
  data type of the attribute. For associations,
  this is the name of the distal class.

91
R-MIM - Constraint section (1)

• Cardinality. This column contains the minimum and
  maximum number of times that the message element
  can appear in any message instance based on this
  R-MIM. The cardinality of most classes can be
  left blank and inferred. Most frequently this
  column is used to state that a central, or root
  class for messages derived from the R-MIM will be
  present exactly once, or at least once.
• Domain Specification. This column contains a
  specification of the domain for message elements
  that contain codes. The syntax of such a
  specification is defined in Chapter 7 of the
  Message Development Framework (MDF).
• Coding Strength. This column contains either CWE
  (coded with exceptions) or CNE (coded, no
  exceptions). It is blank in rows that do not
  describe a message element that contains a code.

92
R-MIM - Constraint section (2)

• Mandatory. This column contains an M (mandatory)
  or is empty (not mandatory). If mandatory, all
  message elements derived from this entity in any
  message instance must contain a non-null value,
  or they must have a default that is not null.
• Default Value. This column may contain a value
  that the receiver should use when it receives a
  message instance that does not contain the
  message element derived from this information
  model entity. If the column is left empty for a
  specific row, the "default default" is the simple
  form of null (NI).
• Conformance Flag. A cell in this column may
  contain an R (required) or be empty. Possible
  conformance values are
• Required. The message element must appear every
  time the message description is used for an
  Interaction (subject to the rules of multiplicity
  and conditionality.) Note that all message
  elements that have an inclusion value of
  mandatory must have a conformance value of
  required.
• Not Required. The message element may be
  populated or used by one system sponsor, but not
  by another. Each system sponsor is required to
  state its ability to accept or send the message
  element as part of its conformance claim.
• Not Permitted. This message element may never
  occur when the message type is used for an
  interaction. (Having this is an artifact of using
  a single HMD to describe multiple message types.)
• Only the Required value may be asserted in the
  R-MIM. The other values are only appropriate in
  the message section of an HMD
• Constraint/Note. describes a constraint that
  applies to all message instances derived from
  this Refined Message Information Model. Example
  might be "at least one instance of this message
  element must identify the attending physician.

93
R-MIM - Constraint section (3)

• Default Update Mode. This column may contain a
  value that defines the update mode that will be
  used for a message element when no update mode is
  explicitly sent in the message. When the column
  is left empty for a cell, "default default"
  update mode is R (replace).
• Update mode set. This column may contain a list
  of values that may be sent in message instances
  to alter the receiver's processing from the
  default update mode. If the column is left blank,
  the only permitted value is the default update
  mode.
• Update code values
• R replace
• D Delete
• I Ignore
• K (Key) this message element is used as a key to
  a collection of message elements
• V (Verify) this message element must match a
  value already in the receiving systems database
  in order to process the message
• ESA Edit set add, add the message element to the
  collection of items on the receiving system that
  correspond to the message element
• ESD Edit set delete, delete the item on the
  receiving system that corresponds to this message
  element
• ESC Edit set change, change the item on the
  receiving system that corresponds to this message
  element do not process if a matching element
  does not exist
• ESAC Edit set change, change the item on the
  receiving system that corresponds to this message
  element if a matching element does not exist,
  add a new one created with the values in the
  message

94
HMD components (1)

• The Information Model Mapping. The columns that
  are in this section describe classes and
  attributes of the R-MIM, organized in a sequence
  that describes a "walk" from class to class on
  the R-MIM.
• The Message Elements. The columns in this section
  describe the message elements and define the
  Message Element Types. The message elements
  compose a hierarchy. This hierarchy is
  illustrated by indentation in the column Message
  Element Name.
• General constraints and defaults. Describe
  specific constraints and defaults for the message
  element defined in the row. The columns are the
  same as the corresponding section of the R-MIM.
  The values in the columns may be the same or may
  be a more restrictive constraint.

95
HMD components (2)

• Message type definitions (repeating). This
  section repeats, once for each message type
  defined in the Hierarchical Message Definition.
  The columns that are in this section describe one
  or more message types. Each message type is
  identified with one or more interactions in the
  interaction model. The column headings for each
  message type are the same as the column headings
  for the general constraints. If the cells are
  left empty, the values will be the same as in the
  general constraints section. When filled in,
  they, may represent more restrictive constraints,
  or may indicate that the specific message element
  is not a part of the specific message type being
  defined in the section.

96
HMD Information model section

• Row types
• hmd - identifies the particular Hierarchical
  Message Definition
• class - is only one class entry in HMD - the root
  class for the message.
• assoc - identifies an association from the class
  that is most directly above this row
• attr - identifies an attribute of a "class" in
  the R-MIM
• item - identifies an element that represents one
  of whatever is repeated in a collection
• stc - subtype constraint corresponds to a
  subcomponent of the row above included in order
  to be able to state a constraint on the subtype
• Class or Property of Class. For an item, the name
  is empty. For an stc row, the name will be
  populated if the subtype corresponds to an entity
  of the information model. In an hmd row, this
  column identifies the parent R-MIM.
• Rim Source Class. This column gives the name of
  the RIM class from which the entity stems,
  regardless of inheritance or cloning that may
  appear in the R-MIM.

97
HMD Message Elements Section (1)

• Message Element Name. By row type, it contains
• hmd - the identifier for the parent R-MIM
• class - same as the name in the R-MIM in the
  Class or Property of Class column.
• attr - same as the in the R-MIM in the Class or
  Property of Class column, unless the item has a
  maximum cardinality greater than one, in which
  case the name is constructed by prepending Set or
  List to the name of the attribute and an item row
  is included immediately underneath this row.
• assoc - name is constructed by combining the name
  of the association with the name of the distal
  class of the association.
• item
• stc - name of the message element that is the
  subcomponent described by this row.
• Message Element Short Name. An abbreviation of
  the name in the Message Element Name column.
• In Message Element Type (MET) . Every message
  element type except the one defined in the first
  (class) row is a sub-element of a larger
  composite MET. This column contains the name of
  the containing MET.

98
HMD Message Elements Section (2)

• Source Of Message Element Type (MET). Possible
  entries are
• N - New type. This row starts the definition of a
  new MET. The subordinate rows beneath it compose
  the definition of the type. Each subordinate row
  has the name of the MET being defined in the In
  MET column. That name will be the same one that
  is in the Of MET of this row.
• D - This MET is an HL7 data type.
• C - This MET is an HL7 common message element
  type.
• U - This MET was previously defined in this HMD
  and is being reused
• R - This row represents the recursive reuse of
  the MET within which it appears.
• Of MET - states the type of the message element
  defined in a row. Short names are used. By row
  type
• class - The cell contains the short name of the
  class.
• attr - The cell contains the short name of the
  data type of the attribute.
• assoc - This name is the short name of the distal
  class of the association. However, if the
  association has a maximum cardinality greater
  than one, the name is preceded by Setlt or Listlt
  and followed by gt. Multiple class names may
  appear in this cell, in the case of choices.
• Item - Represents a single item in a set or list
  of elements
• stc - The type of the message element that is the
  subcomponent described by this row.

99

• Working With XML to Deliver Version 3 Messages

100
Messaging and Message Formats

• An HL7 message definition, a Hierarchical Message
  Description (HMD) is technology neutral.
• An actual message is not it cant be.
• Version 3 includes the idea of an Implementable
  Technology Specification (ITS) to define how a
  message can be instantiated from its definition.
• HL7 has chosen XML as the target of the first (so
  far only) ITS specification.

101
Using a Standard for Message Representation

• Version 3 messages will use XML as the vehicle to
  structure their contents - as opposed to todays
  custom representation.
• HL7 tooling will combine with standard XML tools
  to manage the process of constructing the
  interface.
• XML schemas and non-healthcare specific XML
  parsers can be used to parse inbound and outbound
  messages.

102
XML Defined Message Instances

• A Version 3 message is an XML document.
• The model classes, associations, and attributes
  are identified with tags derived from their RIM
  names.
• The representation of data within each attribute
  draws on the datatype specifications that are out
  to ballot.

103
From Specification to Interface

• Once a message is specified - as a Hierarchical
  Message Description, that specification is
  generated as an XML instance by the RoseTree
  tool.
• At the same time, the ITS and Datatype ballot
  packages contain XML style sheets containing the
  definitional information to complement the
  message definition.
• Commercially available tools are used to
• Generate a message schema from the message
  definition XML instance, and the style sheets.
• Use the schema as the template to create message
  instances for sending, and to process received
  messages.

104

• HL7 Version 3 and the EHR Opportunities for the
  future

105
Electronic Health Record(s)

• Not a single data store!!
• Assemble on demand (virtual record)
• Multiple views to meet multiple needs, based on
  consent and need to know
• Same concepts may be expressed in different
  representations to meet different needs
• Different levels of specificity required
  depending on intended use

106
HL7 Specifications to help?

• HL7 RIM common source of health information
• HL7 MDF consistent way to refine and constrain
  RIM to express information of interest
• HL7 Vocabulary Domains common concepts
  different representations if needed
• HL7 Clinical Document Architecture standard way
  to package clinical information in persistent
  documents at different levels of specificity.
• Templates (work in progress) offers potential to
  express rich clinical statements in consistent
  ways

107
HL7 Specifications to help?

• CCOW visual integration across applications on
  a workstation
• Clinical Decision Support mechanisms working to
  use RIM refinements in Medical Logic Modules and
  Clinical Guidelines
• EHR Special Interest group exploring messages to
  transfer complete electronic medical record from
  one provider to another
• Various vendors exploring use of RIM to
  standardize data content of their applications

108
Questions? Comments? Discussion?