Transcript Document 7166114

Introduction to HL7 Version 3
Jane Curry
Sierra Systems
HL7 Canada – Halifax
October 18th, 2001
Today’s 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
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)
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: HL7’s chosen message
transport mechanism
• Discussion on HL7 V3 and the
EHR
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.
Interoperability & Innovation
• Main Entry: in·ter·op·er·a·bil·i·ty
Function: noun
Date: 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]
Semantic
interoperability
Functional
interoperability
Interoperability & Innovation
• Main Entry: in·no·va·tion
Function: noun
Date: 15th century
1 : the introduction of something new
2 : a new idea, method, or device :
novelty
Source: Merriam-Webster web site
Interoperability & Innovation
HL7’s 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)
HL7’s strategy is innovation – both by
ourselves and by our users
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.”
What must be specified for
HL7 specifications communication?
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.
A channel to carry the communication
Examples of channels include written documents, telephones, network
connections, satellite links, etc.
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.
• HL7’s primary goal for version 3.0 is to offer a standard that is definite
and testable, and to provide certification of vendor’s conformance.
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.
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
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
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.
Outline of a Method for
building Messages:
a “Methodology”
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”.
History of HL7 V3 Messaging
Activities
•
•
•
•
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
•
•
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
Still in progress
HL7 Modeling
Abstractions:
Activities
(Use Case
Model)
Objects
(Information
Model)
Dispense
Medications
Perform Lab
Tests
Review
Utilization
By demanding analysis
Version 2.x focused
its energies
at and
of the
requirements
the communication
level and content,
information
covered the other Version
abstractions
3 assures
Account
Encounter
Provider
Patient
only loosely
in the
specifications.
consistency
in and Order
enhances the value of
the resulting products.
Communication
(Interaction and
Message Models)
Manage
Care
HL7 message
Finance
HL7 message
ADT
Pharmacy
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.
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.
HL7 Version 3 Models and Specifications
Use Case Model
• Captures healthcare requirements
• Defines scope for TSC approval
• Specifies data and its semantics
Information Model
• Specifies major state transitions
• Specifies vocabulary for domains
Interaction Model
• Defines information flows
• Defines communication roles
• Forms basis for conformance claims
2-nd Order
1 choice of
0-n Drug
0-1 Nursing
• Defines message contents
Message Specification
• Apply constraints to the
information model and vocabulary
HL7 V3 Messaging Deliverables
• Use case model
– Hierarchy of tasks
and actors
• Message design model
– Refined Message
Information Model (RMIM)
• Interaction model
– Abstract message
definitions (HMDs)
– Trigger events,
abstract messages & • Vocabulary
application profiles
– Domain definitions
– Representations and
• Information model
mappings
• Implementation
– Classes,
Specification
relationships, states,
– Implementation
and lifecycles
Technology
Specification (ITS)
HL7 V3 Message Development Lifecycle
Requirements
Analysis
Application
Design
Analysis
Domain
Analysis
Interaction
Design
2-nd Order
1 choice of
0-n Drug
0-1 Nursing
C Code
a art
b blue
c color
Use Case
Model
(UCM)
Messaging
Message
Design
Documents
Medical logic
TYPE MPSLOC
CONTAINS {
id[id].TYPE IID
<!ENTITY %DT_MPSLOC
nm[name].TYPE ST
“MPSLOC.id,
ad[addr].TYPEdata:
XAD
MPSLOC.name?,
ph[phon].TYPElocation_of_action
XTN
MPSLOC.addr?,
email_address := READ LAST
MPSLOC.phon?,
[emlAdr].TYPE XTNMPSLOC ;
MPSLOC.emlAdr?">
‘ {patient
}
location}
c Code
Information
Model &
Vocabulary
(RIM)
Interaction
Model
(IM)
Hierarchical
Message
Descriptions
(HMD)
Message Types
for use
with
Document
XML, ER7,
etc
TypesVariable
for
(MET)
HL7
PRA for
definition
Reference Model Repository
(DTD)
Arden syntax
(AVD)
Message Development Phases
Information Model
Use Case Model
Spec
Spec
DIM Spec
State Diagram Class Diagram
UCM Spec
Use Case Diagram
Interaction Model
Spec
Inter Spec
Interaction Diagram
Message Design
2-nd Order
1 choice of
0-n Drug
0-1 Nursing
h//mt:50”d”
…
…
…
An HL7 Version 2.x Message
Spec
Chapters
2 and 8
Common
Specs
ChapterChapterChapterSpecific
Specific
Specific
Specs
Specs
Specs
Segments
and Fields
Chapters
3, 4, 6, ...
Trigger
Event and
Messages
An HL7 Version 3.x Message Spec
HL7
Reference
Model
Common
Specs
ChapterSpecific
Specs
*Future
Consideration
Use Case
Model
Information
Model
Interaction
Model
Message Model
2-nd Order
1 choice of
0-n Drug
0-1 Nursing
Implementable
Message
Implementable
Specification
Implementable
Message
Message
Specification
XML/ER7/…
Specification
OLE/CORBA
EDIFACT*
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.
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.
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.
How do you get an encoded message?
Implementation
Technology
Specification
"Send as ASCII
string in XML
format"
Hierarchical
Message
Definition
"Discontinue
pharmacy order"
ITS
for
XML
Data
HL7
Message
Creation
HL7-Conformant
Application
Message
Instance
HL7
Message
Parsing
HL7-Conformant
Application
Data
Building an HL7
Reference Information
Model
HL7 core requirement - Common semantic models
Domain expertise
Domain expertise
Vocabulary developers,
professional societies, government
agencies, HL7 committees
HL7 committees, affiliates,
members & collaborators
Table 18: Classes
Stakeholder_identifier
id : ST
identifier_type_cd : ID
participates_in
Active_participation
participation_type_cd : ID 0..*
0..*
is_assigned_to
is_assigned
1
0..1
Stakeholder participates_in
addr : XAD
1
phon : XTN
collects
Organization
organization_name_type_cd : CNE
organization_nm : ST
1 standard_industry_class_cd
0..*
takes_on_role_of
0..*
has_as_participant
0..*
is_collected_by
Person
birth_dttm : DTM
gender_cd : CNE
marital_status_cd : CNE
is_a_subdivision_of primary_name_representation_cd : CNE
0..1
primary_name_type_cd : CNE
has_as_a_subdivision
primary_prsnm : PN
race_cd : CNE
0..*
participates_in
Service_intent_or_order
0..*
filler_order_id : IID
has_as_participant filler_txt : TX
is_entered_at
order_id
0..1 order_placed_dttm : DTM
order_quantitytiming_qt : TQ
placer_order_id : IID
placer_txt : TX
is_an_instance_of
has_as_target
report_results_to_phone : XTN
0..*
intent_or_order_cd : ID
0..1
Collected_specimen_sample
body_site_cd : CE
collection_end_dttm : DTM
collection_start_dttm : DTM
collection_volume_amt : CQ
handling_cd : ID
id : IID
method_of_collection_desc : TX
specimen_additive_txt : ST
specimen_danger_cd : ID
specimen_source_cd : CE
0..*
is_sourced_from
0..1
is_fulfilled_by
Observation_intent_or_order
patient_hazard_code
reason_for_study_cd
relevant_clinical_information_txt
reporting_priority_cd
specimen_action_cd
0..1
has_as_active_participant
is_target_of
fulfills
0..1
0..*
delivers
0..1
Service_event
has_as_target service_desc : ST
0..*
0..*
Tar get_par ticipation
is_instantiated_as
0..1 ambulatory_status_cd
service_event_desc
0..*
birth_order_number
has_as_targetparticipation_type_cd : CE
specimen_received_dttm : DTM is_delivered_during
Healthcare_service_provider
is_a_role_ofliving_arrangement_cd 0..1
1
1
is_target_of
name : CE
specialty_cd : CNE
Master_service
living_dependency_cd
0..*
0..*
is_target_of
multiple_birth_ind
method_cd : CE
has_as_target
is_performed_at
newborn_baby_ind
method_desc : TX
has_a_primary_providerorgan_donor_ind
service_desc : TX
Assessm ent
preferred_pharmacy_id
target_anatomic_site_cd : CE
0..*
universal_service_id : CE
is_the_primary_provider_for
is_a_role_of
is_a_role_of
0..*
0..1
0..1
0..1
has_as_primary_facility
Individual_healthcare_practitioner
Healthcare_provider_organization
Clinical_observation
desc : TX
abnormal_result_ind
:
ID
practitioner_type_cd : CNE
1..*
last_observed_normal_values_dttm : DTM
nature_of_abnormal_testing_cd : CE
is_primary_facility_for
clinically_relevant_begin_dttm : DTM
0..1
clinically_relevant_end_dttm : DTM
provides_patient_services_at
is_target_for
0..*
..* Master_patient_service_location 0..1
provides_services_on_behalf_of0
observation_value_txt : NM
addr : XAD
probability_number : NM
0..1
references_range_text : ST
0..* email_address : XTN
id : ID
value_units_code : CE
is_location_for
is_included_in
nm : ST
phon : XTN
is_entry_location_for
1
takes_on_role_of
1
takes_on_role_of
includes 0..1
is_source_for
0..1
is_target_of
has_as_target
0..*
Patient
1
Abbr
ABXBACT
ALLERGY
BC
Laboratory Term Classes
Antibiotic susceptibility
Response to antigens
Cell counts (blood, CSF,
pleuritic fluid)
Blood bank
Cell surface models
BLDBK
CELLMAR
K
CHAL
Challenge tests
CHALSKIN Skin challenge tests
CHEM
Chemistry
COAG
Coagulation study
CYTO
Cytology
DRUG
DRUGDOS
E
FERT
HEM
1..*
HLA
MICRO
PATH
SERO
SURGPAT
H
TOX
UA
VET
Drug levels
Drug dose (for transmitting
doses for pharmacokinetics)
Fertility
Hematology (excluding
coagulation & differential
count)
HLA tissue typing antigens
Microbiology
Pathology
Serology (antibodies and most
antigens except blood bank and
infectious agents)
Sugical pathology
Toxicology
Urinalysis
Veterinary Medicine
Abbr
BDYCRC
BDYHGT
BDYSURF
Clinical Term Classes
Body circumference
Body height
Body surface area
BDYTMP
BDYWGT
Body temperature
Body weight
BP
BP.CENT
BP.PSTN
BP.TIMED
BP.VENOU
S
CLIN
ED
Blood pressure
Blood pressure – central
Blood pressure – positional
Blood pressure – timed
Blood pressure – venous
EKG
EKG.IMP
Electrocardiogram
Electrocardiogram
impression
Clinical NEC
Emergency department
EKG.MEAS Electrocardiogram measures
EYE
Eye
FUNCTION Functional status (e.g.
Glasgow)
H&P
History and physical
HEMODYN Hemodynamics
HRTRATE
IO
NEONAT
OB.US
OBGYN
RESP
SKNFLD
US.URO
VOLUME
Heart rate
Input/Output
Neonatal measures
Obstetric ultrasound
Obstetrics/gynecology
Respiration
Skinfold measurements
Urological ultrasound
Volume (specimens)
Messaging, Document structures, Clinical templates, Arden
syntax, Component specification, …..
Applications
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
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
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!
Committee Models Vs. HL7 Model
• How will we coordinate these
• What is the RIM?
efforts?
– A HL7-wide common
– Iterative reviews
reference model that
– Harmonization meetings
integrates all Technical
Committees’ domain
• Who controls RIM?
views
– The M&M committee
• Why do we need a
• Format, syntax, style
common model?
• Revision histories
– To ensure consistency
– The Technical Steering
of concepts
Committee
– To ensure consistent
• Dispute resolution
vocabulary
• Overseer
Change Proposal Preparation
HL7 RIM Harmonization
Process
Review RIM
Change Proposal
w/ Stewards
Prepare RIM
Change Proposal
Document Rationale
for not supporting
RIM change proposal
Revise or Withdraw
RIM Proposal
Notify HL7 Members
of RIM Change
Proposal Posting
Provide Comment
on RIM Change
Proposals
Post RIM Change Proposals
Submit
RIM Change
Proposal
Post RIM
Change Proposal
Harmonization Meeting
Discuss the RIM
Change Proposal
Revise, withdraw,
or Table RIM
Change Proposal
Vote on RIM
Change Proposal
Apply Approved
Changes to RIM
Hold TSC and/or
Board Appeals
Finalize
Revised RIM
Post Harmonization Meeting Review
Present RIM
Harmonization Report
to TSC
Apply Technical
Corrections
Reference Information Model
1
Entity
Language_communication
language_cd : CE
preference_ind : BL
mode_cd : CV
proficiency_level_cd : CV
id : SET<II>
class_cd : CS
determiner_cd : CS
importance_status_txt : ED
qty : SET<PQ>
telecom : SET<TEL>
1 desc : ED
status_cd : CS
cd : CE
nm : SET<EN>
sends 1..1 risk_cd : CE
handling_cd : CE
used_by
plays
0..*
shall_receive
Relationship_link
class_cd : CS
effective_time : IVL<TS>
id : SET<II>
status_cd : CS
position_nbr : LIST<INT>
qty : RTO
certificate_txt : ED
addr : SET<AD>
telecom : SET<TEL>
cd : CE
0..*
scopes
Participation
0..*
Role
played_by
0..1
communicates_with
is_scoped_by
0..1
0..*
is_source_for
has_source
1
0..*
is_target_for
Act
type_cd : CS
time : IVL<TS>
note_txt : ED
signature_cd : CV
function_cd : CD
awareness_cd : CV
signature_txt : ED
encounter_accommodation_cd : CV
status_cd : CS
has_as_participant
mode_cd : CV
sequence_nbr : INT
effective_time : IVL<TS>
type_cd : CS
has_target
participates_in
has
0..*
0..*
1
1..*
Act_relationship
id : SET<II>
mood_cd : CS
class_cd : CS
txt : ED
status_cd : CS
activity_time : GTS
1 effective_time : GTS
confidentiality_cd : SET<CV>
repeat_nbr : IVL<INT>
interruptible_ind : BL
priority_cd : SET<CV>
independent_ind : BL
availability_time : TS
cd : CD
1..*
reason_cd : CV
originates_in_context_of status_time : TS
for
type_cd : CS
inversion_ind : BL
sequence_nbr : INT
priority_nbr : INT
pause_qty : PQ
checkpoint_cd : CS
split_cd : CS
join_cd : CS
has_target negation_ind : BL
conjunction_cd : CS
is_source_for
has_source
1
0..*
is_target_for
1
0..*
Certified_practitioner
Living_subject
birth_time : TS
deceased_time : TS
deceased_ind : BL
administrative_gender_cd : CE
organ_donor_ind : BL
multiple_birth_ind : BL
birth_order_nbr : INT
Material
Organization
standard_industry_class_cd : CE
addr : SET<AD>
Role_heir
gps_txt : ST
position_txt : ED
addr : AD
directions_txt : ED
mobile_ind : BL
form_cd : CV
effective_time : IVL<TS>
provides_context_f or
Act_context
Guarantor
Patient
credit_rating_cd : CV
gauge_qty : PQ
approach_site_cd : CD
target_site_cd : CD
Non_Person_living_subject
Device
discharge_disposition_cd : CV
acuity_level_cd : CV
birth_encounter_ind : BL
status_reason_cd : CV
valuables_desc : ED
pre_admit_test_ind : BL
referral_source_cd : CV
special_courtesies_cd : CV
valuables_location_desc : ED
admission_source_cd : CV
accident_cd : CV
urgency_cd : CV
Assigned_practitioner
position_cd : CV
primary_care_ind : BL
Covered_party
handicap_cd : CV
student_ind : BL
Container
capacity_qty : PQ
height_qty : PQ
diameter_qty : PQ
barrier_delta_qty : PQ
bottom_delta_qty : PQ
separator_type_cd : CD
cap_type_cd : CD
Financial_contract
Supply
qty : PQ
Observation
Employee
Referral
Working_list
authorized_visits_qty : REAL
desc : ED
reason_txt : ED
ownership_level_cd : CV
Diet
energy_qty : PQ
carbohydrate_qty : PQ
route_cd : CD
dose_qty : IVL<PQ>
rate_qty : IVL<PQ>
dose_check_qty : SET<RTO>
max_dose_qty : SET<RTO>
approach_site_cd : SET<CD>
substitution_cd : CV
Device_task
0..1
is_communicated_as
Inpatient_encounter
length_of_stay_qty : PQ
pixel_padding_qty : PQ
pixel_intensity_relationship_cd : CV
spacial_resolution_qty : PQ
Invoice_element
Public_health_case
detection_method_cd : CE
transmission_mode_cd : CE
disease_imported_cd : CE
Diagnostic_image
Context_structure
local_id : ST
subject_orientation_cd : CV
contains
0..1
Outbreak
time : IVL<TS>
Message Control
Batch
0..1
contains
has_payload
0..*
0..*
0..*
Message
has_recipient
0..*
has_sender
HEALTH LEVEL 7
REFERENCE INFORMATION MODEL
RIM_0110
Version is basis for first committee-level ballots of Version 3. It
was released July 2001, and reflects RIM changes through
Harmonization on 07/20/2001
Enitites
Acts (Services)
sending_application_id : II
id : SET<II>
creation_time : TS
interaction_id : II
version_id : ST
profile_id : SET<OID>
processing_cd : CV
sequence_nbr : INT
reply_to_com : TEL
receiving_application_id : SET<II>
processing_mode_cd : CV
attachment_txt : ED
accept_ack_cd : CV
application_ack_cd : CV
1
has
File_of_batch
control_id : II
name : ST
creation_time : TS
reference_control_id : II
sending_application_id : II
receiving_application_id : II
security : ST
message_count : INT
batch_totals : SET<INT>
batch_comment : SET<ST>
is_contained_by
0..*
Attention_line
can_include can_accompany
0..*
1
Infrastructure (Structured documents)
control_id : II
name : ST
creation_time : TS
reference_control_id : II
sending_application_id : II
receiving_application_id : II
contains
security : ST
file_batch_count : INT
0..1
file_comment : SET<ST>
Query_message_interaction
0..*
Clinical_document
completion_cd : CV
set_id : II
storage_cd : CV
version_nbr : INT
copy_time : TS
change_reason_cd : CV
Query
key_word_txt : ST
value : ST
Sort_control
element_name : ST is_for
sequence_nbr : INT
direction_cd : CV 0..*
has
1
message_query_cd : CV
id : II
priority : CV
modify_indicator : CV
execution_and_delivery_time : TS
initial_qty : PQ
response_modality_cd : CV
return_element_group : SET<CV>
0..1
Acts (Financial)
is_contained_in 0..1
rules : CS
cellspacing : ST
cellpadding : ST
summary : ST
width : ST
border : INT
frame : CS
contains
Entry
local_id : ST
0..*
is_contained_in
Link_html
title : ST
name : ST
href : ED
rel : SET<CE>
rev : SET<CE>
Link
1
Table_cell
acknowledges
1..*
rowspan : INT
colspan : INT
abbr : ST
axis : ST
headers : SET<ED>
scope : CS
Get_more_results
query_id : II
quantity : INT
start_result_nbr : INT
Acknowledgement
Roles
Infrastructure (Structured
documents)
Table
Table_structure
halign : CS
char : ST
charoff : ST
valign : CS
local_id : ST
Local_attr
name : ST
value : ST
is_acknowledged_by
occurs_with
type_cd : CV
note_txt : ED
error_detail_cd : CV
expected_sequence_nbr : INT
Query_by_parameter
Infrastructure (Message
control)
has
Query_by_selection
1
has_expression 1
Query_ack
is_parameter_of
0..*
Billboard produced by:
Rochester Outdoor Advertising
is_part_of
Parameter
name : ST
1
has_right_side
is_rhs_for
0..*
Logical_expression
0..1
Parameter_list
id : II
query_status_cd : CV
message_query_cd : CV
result_count_total : INT
result_count_current : INT
result_count_remaining : INT
0..*
Selection_expression
1
is_lhs_for
0..*
may_contain
is_for
has_left_side
0..*
A_parameter
value : ANY
relational_conjunction_cd : CV
Relational_expression
element_name : ST
value : ST
relational_operator_cd : CV
Account
parameter_value : LIST<ANY>
Imaging_modality
is_contained_by
Transportation
Procedure
approach_site_cd : SET<CD>
method_cd : SET<CV>
target_site_cd : SET<CD>
Message_interaction
message_type_id : II
response_cd : CS
hazard_exposure_txt : ED
job_class_cd : CV
job_title_nm : ST
protective_equipment_txt : ED
salary_qty : MO
salary_type_cd : CV
job_cd : CE
Table_column_structure
span : INT
width : ST
Financial_act
net_qty : MO
payment_terms_cd : CV
Substance_administration
value : ANY
derivation_expr : ST
method_cd : SET<CV>
target_site_cd : SET<CD>
interpretation_cd : SET<CS>
Patient_encounter
slot_size_increment_qty : PQ
Person
manufacturer_model_nm : ST
last_calibration_time : TS
software_nm : ST
local_remote_control_state_cd : CE
alert_level_cd : CE
confidentiality_cd : CV
very_important_person_cd : CV
Consent
level_cd : CV
language_cd : CS
Qualified_practitioner
fellowship_field_cd : CE
residency_field_cd : CE
Schedulable_resource
Access
taxonomic_classification_cd : CE
breed_cd : CE
strain_txt : ED
euthanasia_ind : BL
production_class_cd : CE
gender_status_cd : CE
0..*
Resource_slot
slot_time : GTS
Manufactured_material
expiration_time : TS
lot_nm : ST
stability_time : IVL<TS>
disability_cd : CE
ethnic_group_cd : SET<CV>
race_cd : SET<CV>
ambulatory_status_cd : CV
education_level_cd : CV
living_arrangement_cd : CV
marital_status_cd : CV
religious_affiliation_cd : CV
addr : SET<AD>
special_accommodation_cd : SET<CV>
mothers_maiden_nm : ST
board_certification_type_cd : CV
recertification_time : TS
Place
Entity_heir
Local_markup
ignore_cd : CS
descriptor : ST
render : ST
Character_data
value : ST
item_nbr : REAL
item_qualifier_cd : CE
gross_qty : MO
coverage_source_cd : CE
unit_qty : RTO
notify_subject_ind : BL
modifier_cd : CE
factor_nbr : REAL
points_nbr : REAL
allowed_balance_qty : IVL<MO>
currency_cd : CV
interest_rate_qty : RTO
nm : ST
Financial_transaction
payment_terms_cd : CV
debit_exchange_rate_qty : RTO
credit_exchange_rate_qty : RTO
interest_rate_qty : RTO
RIM Core Classes
Relationship
Link
Act
Relationship
0..*
0..*
1
0..*
0..*
1
1
1
0..*
Entity
0..1
0..*
Role
0..*
1
Participation
1
0..*
Act
0..1
Organization
Living Subject
Material
Place
Patient
Employee
Certified
Practitioner
Assigned
Practitioner
Specimen
Healthcare
Facility
Encounter
Referral
Supply
Procedure
Observation
Substance
Administration
Financial act
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.
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).
RIM Core Attributes
Relationship Link
Act Relationship
type_cd : CS
effective_time : IVL<TS>
type_cd : CS
0..1
0..*
Entity
class_cd : CC
cd: CE
determiner_cd : CS
status_cd : CS
id : II
0..1
0..1
0..*
0..*
Role
1
scopes
0..*
class_cd : CS
cd: CE
effective_time : IVL<TS>
status_cd : CS
id : II
1
1
0..*
type_cd : CS
time : IVL<TS>
status_cd : CS
0..*
Act
plays
0..*
1
Participation
0..1
0..*
class_cd : CC
cd: CD
mood_cd : CS
status_cd : CS
effective_time : GTS
id : II
Six attributes: Class_cd+cd/type_cd, time, mood, determiner, status, id
RIM Core Attribute Value Sets
Entity
Class Code
• Living Subject
• Person
• Organization
• Material
• Place
• ...
Entity
Participation
Type Code
Role
1
class_cd : CC
determiner_cd : CS
status_cd : CS
cd: CE
• Performer
• Author
• Witness
• Subject
• Destination
• ...
Participation
Act
Class Code
Act
plays
0..*
1
• Observation
• Procedure
• Supply
• Substance
Admin
• Financial
• ...
1
class_cd : CS
effective_time : IVL<TS>
cd: CE
1
0..*
type_cd : CS
time : IVL<TS>
status_cd : CS
0..*
scopes
class_cd : CC
mood_cd : CS
status_cd : CS
Cd: CD
effective_time : GTS
0..*
Entity
Determiner
Code
• Kind
• Instance
Role
• (Quantified Class Code
Group)
• Patient
• Provider
• Employee
• Specimen
• Certified
Practitioner
• ...
• Definition
• Intent
• Order
• Event
• Criterion
• ...
Act
Mood Code
Act State Model
normal
revise
aborted
revise
abort
suspended
end
held
resume
hold
revise
revise
suspend
abort
release
complete
new
active
completed
activate
reactivate
cancel
create
cancelled
complete
activate
null
nullify
nullified
obsolete
obsolete
Master Act(definition)
Care plan for a patient
Define plans
and guidelines
Ordering(order)
Act
Scheduling
Performing
Reviewing
Documenting &
reporting(event)
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.
A RIM is not enough –
what about Vocabularies.
and Data Types?
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.
RIM
Attributes, domains, and value
sets
Attribute
Domain
Person.gender_cd
Gender
Specialization
R-MIM
Patient.gender_cd
HMD (PAFM)
Specialization
Patient.gender_cd
Sub-domain
Patient
Gender
A subset of Gender
Value Set
Administrative
Gender
Realm (USA)
Code System (HL7)
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,).
Vocabulary Domain
Specification
Vocabulary Codes &
Definitions
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.
Each coded attribute has a
domain
specification
administrative_gender_cd : CE
<AdministrativeGender> CWE
A code depicting the gender (sex) of a person (e.g.,
female, male).
living_arrangement_cd : CV <LivingArrangement>
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 <MaritalStatus> CWE
A code indicating the married or similar partnership
status of a person,
e.g., married, separated, divorced, widowed, commonlaw marriage.
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
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
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 name:Realm:Terminology”
– Examples: Gender:Root:HL7, Diagnosis:USA:SMI
Vocabulary Domain
Specification
• General form:
• One and only one domain for each coded
RIM attribute
–
–
<domain name, list of domain qualifiers>
<Gender, Ext:CWE>
• 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
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.1<LOINC>)
};
V3 Coded Data Types
ConceptRole : CR
name : CV
value : CD
1
1
ConceptDescriptor : CD
code : ST
displayName : ST
codeSystem : OID
codeSystemName : ST
code SystemVersion : ST
originalText : ED
modifier : LIST<CR>
translation : SET<CD>
<<restriction>>
CodedWithEquivalents : CE
code : ST
displayName : ST
codeSystem : OID
codeSystemPrintName : ST
codeSystemVersion : ST
originalText : ED
translation : SET<CV>
<<restriction>>
<<restriction>>
CodedValue : CV
code : ST
displayName : ST
codeSystem : OID
codeSystemPrintName : ST
code SystemVersion : ST
originalText : ST
CodedSimpleValue : CS
code : ST
displayName : ST
CodedSimpleValue (CS)
type CodedSimpleValue alias CS restricts CD {
ST code;
ST displayName;
};
XML
<mood_cd T=“CS” C=”INT”/>
<mood_cd T=“CS” C=”INT” D=“Intent”/>
“Structural” type attribute or CNE field.
Code must come from the specified HL7 domain
Hierarchical Relationships
Abstract
Race
AmericanIndianOrAlaskaNative
AmericanIndian
Asian
AlaskaNative
Specializable
Navajo
Apache
Leaf
White
BlackOrAfricanAmerican
You can use the Rosetree tools to view
Vocabulary domains
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
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)
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
DataValue
: ANY type
Data types have
hierarchies
<<extends>>
Data
types have
implicit associations
Quantity : QTY
(at best)
Some data types are
aliases
<<extends>>
PointInTime : TS
offset : PQ
calendar : CS
precision : INT
timeZone : PQ
Set_of_TS : SET<TS>
<<extends>>
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
T
“attributes” of the stereotype classes
Interval : IVL
• Generic data types are modeled
low : T
as parameterized classes
low_closed : BL
• Special properties for the data type high : T
high_closed : BL
“classes”
Data type specialization
• HL7 uses two “stereotypes” of the
generalization/specialization (supertype/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.
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 sender’s
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.
Understanding Basic
Ballot Components
HL7 3.0 Core Publication
Structure
V3 Guide
Reference
Information
Model
V3 Backbone
•Welcome
•Introduction
•V3 Principles
•Quick Start
•Getting Started
•Glossary
Literary Expression
RIM Diagram
State Machines
Vocabulary
Implementable
Technology
Specifications
XML
Data Types
Part I
Reference: Content is harmonized
during HL7 meetings or approved by
the HL7 Board. It is not subject to
ballot acceptance
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.
Data Types
Part II
Section
Infrastructure
Management
Sub-sections
Legend:
Section
Health & Clinical
Management
Sub-sections
Section
Administrative
Management
Sub-sections
Reference
Informative
Normative
HL7 3.0 Section Publication
Structure
CMET
R-MIM
Domain
Application
Roles
HMD
Message Type
HMD
Message Type
Sub-sections
R-MIM
Legend:
Interaction
Category
Storyboard
Reference
Informative
Trigger Event
Normative
Interaction
Storyboard
Examples
Message Development Phases
Information Model
Identify actors and
Use Cases
Use Case Model
RIM Spec
Spec
Class Diagram
Associate Actors
and Use Cases
Define
Application Roles
Define
Interactions
Define
Conformance
Criteria
Define classes,
attributes, and
relationships
Spec
Develop Scope
State Diagram
Define vocabulary
domains and codes
UCM Spec
Use Case Diagram
Interaction Model
Spec
Inter Spec
Interaction Diagram
Define states,
transitions and
triggers
Message Design
2-nd Order
1 choice of
0-n Drug
0-1 Nursing
h//mt:50”d”
…
…
…
Develop Refined
Message Information
Model
Specify CMET
Specify HMD &
METs with
constraints
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.
Application Roles: Who’s 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
•
•
•
•
•
•
•
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
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
An example Interaction
Diagram
Using the RIM to Build
Messages
RIM
RIM
• Select a subset of the RIM classes
• Select a subset of class relationships
Reference Information Model
(1)
Define a
DMIM
• Select a subset of class attributes
• Select a subset of attribute datatypes
• Select a subset of attribute domains and value sets
DMIM
DMIM
• Created clones of classes and attributes
Domain Message Information Model
• Assign alias class and attribute names
(2)
Define a
R-MIM
• Eliminate unnecessary class hierarchies
• Finalize class relationships and multiplicity
• Finalize attribute domains and value sets
R-MIM
R-MIM
• Select a root class for the message
Refined Message Information Model
• Arrange classes and attributes hierarchically
(3)
Create
an HMD
• Declare inclusion and repetition constraints
• Declare domain value constraints
• Assign message element names
HMD
Hierarchical Message Definition
HMD
RMIM Example from the V3 Ballot -
Message Development Phases
Information Model
Identify actors and
Use Cases
Use Case Model
RIM Spec
Spec
Class Diagram
Associate Actors
and Use Cases
Define
Application Roles
Define
Interactions
Define
Conformance
Criteria
Define classes,
attributes, and
relationships
Spec
Develop Scope
State Diagram
Define vocabulary
domains and codes
UCM Spec
Use Case Diagram
Interaction Model
Spec
Inter Spec
Interaction Diagram
Define states,
transitions and
triggers
Message Design
2-nd Order
1 choice of
0-n Drug
0-1 Nursing
h//mt:50”d”
…
…
…
Develop Refined
Message Information
Model
Specify CMET
Specify HMD &
METs with
constraints
Version 3 in a nut shell
1. 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.
2. Specialist prepares a design R-MIM using
Rosetree and then builds a preliminary HMD by
“walking the graph”
3. Committee reviews HMD content. Revise as
necessary.
4. 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
5. 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
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.
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.
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.
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.
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)
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.
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.
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.
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.”
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
•
•
•
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.
Repeat this set of nine
columns for each
message type defined
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.
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.
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.
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 Set< or List< and followed by >. 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.
Working With XML to
Deliver Version 3
Messages
Messaging and Message
Formats
• An HL7 message definition, a
Hierarchical Message Description
(HMD) is technology neutral.
• An actual message is not; it can’t
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.
Using a Standard for Message
Representation
• Version 3 messages will use XML
as the vehicle to structure their
contents - as opposed to today’s
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.
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.
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.
HL7 Version 3 and the
EHR – Opportunities for
the future
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
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
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
Questions? Comments?
Discussion?