introduction to hl7 version 3 jane curry sierra systems hl7 canada – halifax october 18 th, 2001
TRANSCRIPT
Introduction to HL7 Version 3
Jane CurrySierra Systems
HL7 Canada – HalifaxOctober 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.
Semanticinteroperability
Interoperability & Innovation
Functionalinteroperability
• Main Entry: in·ter·op·er·a·bil·i·tyFunction: 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]
Interoperability & Innovation
• Main Entry: in·no·va·tionFunction: nounDate: 15th century1 : the introduction of something new2 : a new idea, method, or device : novelty
Source: Merriam-Webster web site
Interoperability & InnovationHL7’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.”
HL7 specificationsNouns
.
Adjectives Verbs
What must be specified for communication?
The semantics of the communicationThe 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 communicationThe 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 communicationExamples include the post office, a telephone switchboard, SMTP, FTP, Telnet, RPC, ORB services, etc.
A channel to carry the communicationExamples 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 completedStill in progress
HL7 Modeling
Abstractions:
ActivitiesActivities(Use Case (Use Case
Model)Model)
Dispense Medications
Manage Care
Perform Lab Tests
Review Utilization
Objects Objects (Information (Information
Model)Model)
AccountAccount PatientPatient ProviderProvider EncounterEncounter OrderOrder
Communication Communication (Interaction and (Interaction and Message Models)Message Models)
ADT Pharmacy
HL7 message
Finance
HALHAL
Version 2.x focused its energies at the communication level and covered the other abstractions only loosely in the specifications.
By demanding analysis of the requirements and information content, Version 3 assures consistency in and enhances the value of the resulting products.
HL7 message
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.
Use Case Model
Information Model
Interaction Model
2-nd Order 1 choice of 0-n Drug 0-1 Nursing
2-nd Order 1 choice of 0-n Drug 0-1 Nursing
Message Specification
• 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
HL7 Version 3 Models and Specifications
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)
Reference Model RepositoryReference Model RepositoryReference Model RepositoryReference Model Repository
RequirementsRequirementsAnalysisAnalysis
Use CaseUse CaseModelModel(UCM)(UCM)
RequirementsRequirementsAnalysisAnalysis
Use CaseUse CaseModelModel(UCM)(UCM)
DomainDomainAnalysisAnalysis
Information Information Model &Model &
VocabularyVocabulary(RIM)(RIM)
DomainDomainAnalysisAnalysis
Information Information Model &Model &
VocabularyVocabulary(RIM)(RIM)
AnalysisAnalysisAnalysisAnalysis DesignDesignDesignDesign
InteractionInteractionDesignDesign
InteractionInteractionModelModel(IM)(IM)
InteractionInteractionDesignDesign
InteractionInteractionModelModel(IM)(IM)
MessageMessageDesignDesign
HierarchicalHierarchicalMessageMessage
DescriptionsDescriptions(HMD)(HMD)
MessageMessageDesignDesign
HierarchicalHierarchicalMessageMessage
DescriptionsDescriptions(HMD)(HMD)
ApplicationApplicationApplicationApplication
2-nd Order2-nd Order 1 choice of1 choice of 0-n Drug0-n Drug
0-1 Nursing0-1 Nursing
2-nd Order2-nd Order 1 choice of1 choice of 0-n Drug0-n Drug
0-1 Nursing0-1 Nursing
Medical logicMedical logic
VariableVariabledefinition for definition for Arden syntaxArden syntax
(AVD)(AVD)
Medical logicMedical logic
VariableVariabledefinition for definition for Arden syntaxArden syntax
(AVD)(AVD)
data:data:location_of_actionlocation_of_action := READ LAST := READ LAST MPSLOC ; MPSLOC ; ‘ ‘ {patient{patient location} location}
data:data:location_of_actionlocation_of_action := READ LAST := READ LAST MPSLOC ; MPSLOC ; ‘ ‘ {patient{patient location} location}
DocumentsDocuments
Document Document Types forTypes forHL7 PRAHL7 PRA
(DTD)(DTD)
DocumentsDocuments
Document Document Types forTypes forHL7 PRAHL7 PRA
(DTD)(DTD)
<!ENTITY %DT_MPSLOC<!ENTITY %DT_MPSLOC“MPSLOC.id,“MPSLOC.id, MPSLOC.name?, MPSLOC.name?, MPSLOC.addr?, MPSLOC.addr?, MPSLOC.phon?, MPSLOC.phon?, MPSLOC.emlAdr?"> MPSLOC.emlAdr?">
<!ENTITY %DT_MPSLOC<!ENTITY %DT_MPSLOC“MPSLOC.id,“MPSLOC.id, MPSLOC.name?, MPSLOC.name?, MPSLOC.addr?, MPSLOC.addr?, MPSLOC.phon?, MPSLOC.phon?, MPSLOC.emlAdr?"> MPSLOC.emlAdr?">
MessagingMessaging
Message TypesMessage Typesfor use with for use with
XML, ER7, etcXML, ER7, etc(MET)(MET)
MessagingMessaging
Message TypesMessage Typesfor use with for use with
XML, ER7, etcXML, ER7, etc(MET)(MET)
TYPE MPSLOC TYPE MPSLOC CONTAINS {CONTAINS {id[id].TYPE IIDid[id].TYPE IIDnm[name].TYPE STnm[name].TYPE STad[addr].TYPE XADad[addr].TYPE XADph[phon].TYPE XTN ph[phon].TYPE XTN email_addressemail_address [emlAdr].TYPE XTN [emlAdr].TYPE XTN}}
TYPE MPSLOC TYPE MPSLOC CONTAINS {CONTAINS {id[id].TYPE IIDid[id].TYPE IIDnm[name].TYPE STnm[name].TYPE STad[addr].TYPE XADad[addr].TYPE XADph[phon].TYPE XTN ph[phon].TYPE XTN email_addressemail_address [emlAdr].TYPE XTN [emlAdr].TYPE XTN}}
HL7 V3 Message Development Lifecycle
C Code c Codea artb bluec color
Message Development Phases
Use Case ModelUse Case ModelUse Case ModelUse Case Model
Use Case Diagram
Spec
UCM Spec
Information ModelInformation ModelInformation ModelInformation Model
Spec
DIM Spec
State Diagram Class Diagram
Message DesignMessage DesignMessage DesignMessage Design
2-nd Order 1 choice of 0-n Drug 0-1 Nursing
2-nd Order 1 choice of 0-n Drug 0-1 Nursing
h//mt:50”d”………
h//mt:50”d”………
Interaction ModelInteraction ModelInteraction ModelInteraction Model
Interaction Diagram
Spec
Inter Spec
Common Specs
Common Specs
Chapter-Specific Specs
Chapter-Specific Specs
Chapter-Specific Specs
Chapter-Specific Specs
Chapter-Specific Specs
Chapter-Specific Specs
Chapters2 and 8
Chapters 3, 4, 6, ...
Trigger Event and Messages
Trigger Event and Messages
Segments and FieldsSegments and Fields
An HL7 Version 2.x Message Spec
Common Specs
Chapter-Specific Specs
Use Case Use Case ModelModel
Use Case Use Case ModelModel
Information Information ModelModel
Information Information ModelModel
Message ModelMessage ModelMessage ModelMessage Model
2-nd Order 1 choice of 0-n Drug 0-1 Nursing
2-nd Order 1 choice of 0-n Drug 0-1 Nursing
Implementable Implementable Message Message
SpecificationSpecification
EDIFACT*EDIFACT*
Implementable Implementable Message Message
SpecificationSpecification
EDIFACT*EDIFACT*
*Future Consideration
Implementable Implementable Message Message
SpecificationSpecification
OLE/CORBAOLE/CORBA
Implementable Implementable Message Message
SpecificationSpecification
OLE/CORBAOLE/CORBA
Implementable Implementable Message Message
SpecificationSpecification
XML/ER7/…XML/ER7/…
Implementable Implementable Message Message
SpecificationSpecification
XML/ER7/…XML/ER7/…
HL7 Reference
Model
HL7 Reference
Model
Interaction Interaction ModelModel
Interaction Interaction ModelModel
An HL7 Version 3.x Message Spec
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.
HL7-ConformantApplication
Data
HL7MessageCreation
HL7-ConformantApplication
HL7MessageParsing Data
"Discontinuepharmacy order"
"Send as ASCIIstring in XML
format"
ITSfor
XML
ImplementationTechnology
Specification
HierarchicalMessageDefinition
MessageInstance
How do you get an encoded message?
Building an HL7 Reference Information
Model
Observation_intent_or_orderpatient_hazard_codereason_for_study_cdrelevant_clinical_information_txtreporting_priority_cdspecimen_action_cd
Clinical_observation
abnormal_result_ind : IDlast_observed_normal_values_dttm : DTMnature_of_abnormal_test ing_cd : CEclinically_relevant_begin_dttm : DTMclinically_relevant_end_dttm : DTMobservation_value_txt : NMprobability_number : NMreferences_range_text : STvalue_units_code : CE
Assessment
Healthcare_service_providerspecialty_cd : CNE
Stakeholder_identifierid : STident if ier_type_cd : ID
Organizationorganization_name_type_cd : CNEorganization_nm : STstandard_industry_class_cd 0..*
0..1 is_a_subdivision_of
0..*
has_as_a_subdivision
0..1
Person
birth_dttm : DTMgender_cd : CNEmarital_status_cd : CNEprimary_name_representation_cd : CNEprimary_name_type_cd : CNEprimary_prsnm : PNrace_cd : CNE
Individual_healthcare_practitionerdesc : TXpractitioner_type_cd : CNE
1
0..1
takes_on_role_of1
is_a_role_of0..1
Stakeholderaddr : XADphon : XTN
0..*
1
is_assigned_to0..*
is_assigned1
Healthcare_provider_organization
0..1
1
is_a_role_of0..1
takes_on_role_of
1
Collected_specimen_samplebody_site_cd : CEcollection_end_dttm : DTMcollection_start_dttm : DTMcollection_volume_amt : CQhandling_cd : IDid : IIDmethod_of_collection_desc : TXspecimen_addit ive_txt : STspecimen_danger_cd : IDspecimen_source_cd : CE
0..*1
is_collected_by
0..*
collects
1
Patient
ambulatory_status_cdbirth_order_numberliving_arrangement_cdliving_dependency_cdmultiple_birth_indnewborn_baby_indorgan_donor_indpreferred_pharmacy_id
0..1
1
is_a_role_of
0..1takes_on_role_of
1
0..*
0..1
has_a_primary_provider
0..*is_the_primary_provider_for
0..1
0..*
0..1
is_sourced_from0..*
is_source_for0..1
Active_participation
participation_type_cd : ID
0..1
0..*
participates_in0..1
has_as_participant0..*
Master_patient_service_location
addr : XADemail_address : XTNid : IDnm : STphon : XTN
1..*
0..*provides_patient_services_at
1..*
provides_services_on_behalf_of0..*
0..*
0..1
is_included_in
0..*
includes 0..1
0..1
0..*
is_primary_facility_for0..1
has_as_primary_facility
0..*
Target_participationparticipation_type_cd : CE
0..1
0..*
is_target_of
0..1
has_as_target0..*
0..1
0..*
is_target_of
0..1
has_as_target
0..*
0..1
0..*
is_target_for0..1
has_as_target
0..*
Service_intent_or_orderfiller_order_id : IIDfiller_txt : TXorder_idorder_placed_dttm : DTMorder_quant itytiming_qt : TQplacer_order_id : IIDplacer_txt : TXreport_results_to_phone : XTNintent_or_order_cd : ID
0..* 0..1
participates_in
0..*
has_as_participant
0..1
1..*
0..1
is_target_of
1..*
has_as_target
0..1
1
0..*
is_entry_location_for
1
is_entered_at
0..*
Master_service
method_cd : CEmethod_desc : TXservice_desc : TXtarget_anatomic_site_cd : CEuniversal_service_id : CE
0..*
1
is_an_instance_of
0..*
is_instantiated_as
1
Service_event
service_desc : STservice_event_descspecimen_received_dttm : DTMname : CE
0..*
0..1
participates_in0..*
has_as_active_participant
0..1
0..*
0..1
is_performed_at
0..*
is_location_for
0..1
0..*
0..1
is_target_of
0..*
has_as_target
0..1
0..1
0..*
is_fulfilled_by0..1
fulfills0..*
1
0..*
is_delivered_during1
delivers
0..*
Table 18: Classes
Abbr Laboratory Term Classes Abbr Clinical Term ClassesABXBACT Antibiotic susceptibility BDYCRC Body circumferenceALLERGY Response to antigens BDYHGT Body heightBC Cell counts (blood, CSF,
pleuritic fluid)BDYSURF Body surface area
BLDBK Blood bank BDYTMP Body temperatureCELLMARK
Cell surface models BDYWGT Body weight
CHAL Challenge tests BP Blood pressureCHALSKIN Skin challenge tests BP.CENT Blood pressure – centralCHEM Chemistry BP.PSTN Blood pressure – positionalCOAG Coagulation study BP.TIMED Blood pressure – timedCYTO Cytology BP.VENOU
SBlood pressure – venous
DRUG Drug levels CLIN Clinical NECDRUGDOSE
Drug dose (for transmittingdoses for pharmacokinetics)
ED Emergency department
FERT Fertility EKG ElectrocardiogramHEM Hematology (excluding
coagulation & differentialcount)
EKG.IMP Electrocardiogramimpression
HLA HLA tissue typing antigens EKG.MEAS Electrocardiogram measuresMICRO Microbiology EYE EyePATH Pathology FUNCTION Functional status (e.g.
Glasgow)SERO Serology (antibodies and most
antigens except blood bank andinfectious agents)
H&P History and physical
SURGPATH
Sugical pathology HEMODYN Hemodynamics
TOX Toxicology HRTRATE Heart rateUA Urinalysis IO Input/OutputVET Veterinary Medicine NEONAT Neonatal measures
OB.US Obstetric ultrasoundOBGYN Obstetrics/gynecologyRESP RespirationSKNFLD Skinfold measurementsUS.URO Urological ultrasoundVOLUME Volume (specimens)
Domain expertise
HL7 committees, affiliates, members & collaborators
Domain expertise
Vocabulary developers, professional societies, government agencies, HL7 committees
Messaging, Document structures, Clinical templates, Arden syntax, Component specification, …..
Applications
HL7 core requirement - Common semantic models
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• 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 M&M committee
• Format, syntax, style• Revision histories
– The Technical Steering Committee• Dispute resolution• Overseer
HL7 RIM Harmonization Process
Change Proposal Preparation
Prepare RIMChange Proposal
Prepare RIMChange Proposal
Review RIMChange Proposal
w/ Stewards
Review RIMChange Proposal
w/ Stewards
Document Rationalefor not supporting
RIM change proposal
Document Rationalefor not supporting
RIM change proposal
Revise or WithdrawRIM Proposal
Revise or WithdrawRIM Proposal
Post RIM Change Proposals
SubmitRIM Change
Proposal
SubmitRIM Change
Proposal
Post RIMChange Proposal
Post RIMChange Proposal
Notify HL7 Membersof RIM ChangeProposal Posting
Notify HL7 Membersof RIM ChangeProposal Posting
Provide Commenton RIM Change
Proposals
Provide Commenton RIM Change
Proposals
Harmonization Meeting
Discuss the RIMChange ProposalDiscuss the RIMChange Proposal
Revise, withdraw,or Table RIM
Change Proposal
Revise, withdraw,or Table RIM
Change Proposal
Vote on RIMChange Proposal
Vote on RIMChange Proposal
Apply ApprovedChanges to RIMApply ApprovedChanges to RIM
Apply TechnicalCorrections
Apply TechnicalCorrections
Post Harmonization Meeting Review
Present RIMHarmonization Report
to TSC
Present RIMHarmonization Report
to TSC
Hold TSC and/orBoard AppealsHold TSC and/orBoard Appeals
FinalizeRevised RIM
FinalizeRevised RIM
Reference Information Model
Referral
authorized_visits_qty : REALdesc : EDreason_txt : ED
Observation
value : ANYderivation_expr : STmethod_cd : SET<CV>target_site_cd : SET<CD>interpretation_cd : SET<CS>
Substance_administration
route_cd : CDdose_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
Procedure
approach_site_cd : SET<CD>method_cd : SET<CV>target_site_cd : SET<CD>
Supply
qty : PQ
Diet
energy_qty : PQcarbohydrate_qty : PQ
Consent
Clinical_document
completion_cd : CVset_id : IIstorage_cd : CVversion_nbr : INTcopy_time : TSchange_reason_cd : CV
Container
capacity_qty : PQheight_qty : PQdiameter_qty : PQbarrier_delta_qty : PQbottom_delta_qty : PQseparator_type_cd : CDcap_type_cd : CD
Access
gauge_qty : PQapproach_site_cd : CDtarget_site_cd : CD
Device
manufacturer_model_nm : STlast_calibration_time : TSsoftware_nm : STlocal_remote_control_state_cd : CEalert_level_cd : CE
Employee
hazard_exposure_txt : EDjob_class_cd : CVjob_title_nm : STprotective_equipment_txt : EDsalary_qty : MOsalary_type_cd : CVjob_cd : CE
Living_subject
birth_time : TSdeceased_time : TSdeceased_ind : BLadministrative_gender_cd : CEorgan_donor_ind : BLmultiple_birth_ind : BLbirth_order_nbr : INT
Material
form_cd : CVeffective_time : IVL<TS>
Assigned_practitioner
position_cd : CVprimary_care_ind : BL
Certified_practitioner
board_certification_type_cd : CVrecertification_time : TS
Place
gps_txt : STposition_txt : EDaddr : ADdirections_txt : EDmobile_ind : BL
Manufactured_material
expiration_time : TSlot_nm : STstability_time : IVL<TS>
Inpatient_encounter
length_of_stay_qty : PQ
Non_Person_living_subject
taxonomic_classification_cd : CEbreed_cd : CEstrain_txt : EDeuthanasia_ind : BLproduction_class_cd : CEgender_status_cd : CE
Patient
confidentiality_cd : CVvery_important_person_cd : CV
Organization
standard_industry_class_cd : CEaddr : SET<AD>
Account
allowed_balance_qty : IVL<MO>currency_cd : CVinterest_rate_qty : RTOnm : ST
Qualified_practitioner
fellowship_field_cd : CEresidency_field_cd : CE
Financial_act
net_qty : MO
Person
disability_cd : CEethnic_group_cd : SET<CV>race_cd : SET<CV>ambulatory_status_cd : CVeducation_level_cd : CVliving_arrangement_cd : CVmarital_status_cd : CVreligious_affiliation_cd : CVaddr : SET<AD>special_accommodation_cd : SET<CV>mothers_maiden_nm : ST
Working_list
ownership_level_cd : CV
Public_health_case
detection_method_cd : CEtransmission_mode_cd : CEdisease_imported_cd : CE
Outbreak
time : IVL<TS>
Transportation
Patient_encounter
discharge_disposition_cd : CVacuity_level_cd : CVbirth_encounter_ind : BLstatus_reason_cd : CVvaluables_desc : EDpre_admit_test_ind : BLreferral_source_cd : CVspecial_courtesies_cd : CVvaluables_location_desc : EDadmission_source_cd : CVaccident_cd : CVurgency_cd : CV
Schedulable_resource
slot_size_increment_qty : PQ
Resource_slot
slot_time : GTS
Acts (Financial)
Acts (Services)
Infrastructure (Structured documents)
HEALTH LEVEL 7 REFERENCE INFORMATION MODEL RIM_0110Version 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
Billboard produced by:Rochester Outdoor Advertising
Roles
Guarantor
credit_rating_cd : CV
Diagnostic_image
subject_orientation_cd : CV
Imaging_modality
pixel_padding_qty : PQpixel_intensity_relationship_cd : CVspacial_resolution_qty : PQ
Query_ack
id : IIquery_status_cd : CVmessage_query_cd : CVresult_count_total : INTresult_count_current : INTresult_count_remaining : INT
Get_more_results
query_id : IIquantity : INTstart_result_nbr : INT
Query_message_interaction
Table
rules : CScellspacing : STcellpadding : STsummary : STwidth : STborder : INTframe : CS
Table_structure
halign : CSchar : STcharoff : STvalign : CSlocal_id : ST
Table_column_structure
span : INTwidth : ST
Table_cell
rowspan : INTcolspan : INTabbr : STaxis : STheaders : SET<ED>scope : CS
Link
Character_data
value : ST
Local_attr
name : STvalue : ST
Local_markup
ignore_cd : CSdescriptor : STrender : ST
Link_html
title : STname : SThref : EDrel : SET<CE>rev : SET<CE>
Entry
local_id : ST
0..1
0..*
contains0..1
is_contained_in0..*
Context_structure
local_id : ST
0..*
0..1
is_contained_in
0..*
contains
0..1
Infrastructure (Structured documents)
Infrastructure (Message control)
Enitites
Message Control
Covered_party
handicap_cd : CVstudent_ind : BL
Act_relationship
type_cd : CSinversion_ind : BLsequence_nbr : INTpriority_nbr : INTpause_qty : PQcheckpoint_cd : CSsplit_cd : CSjoin_cd : CSnegation_ind : BLconjunction_cd : CS
Act_context
level_cd : CVlanguage_cd : CS
File_of_batch
control_id : IIname : STcreation_time : TSreference_control_id : IIsending_application_id : IIreceiving_application_id : IIsecurity : STfile_batch_count : INTfile_comment : SET<ST>
Act
id : SET<II>mood_cd : CSclass_cd : CStxt : EDstatus_cd : CSactivity_time : GTSeffective_time : GTSconfidentiality_cd : SET<CV>repeat_nbr : IVL<INT>interruptible_ind : BLpriority_cd : SET<CV>independent_ind : BLavailability_time : TScd : CDreason_cd : CVstatus_time : TS
0..*1
has_target
0..*
is_target_for
1
0..*1
has_source
0..*
is_source_for
1
1..*
0..*
originates_in_context_of
1..*
prov ides_context_f or
0..*
Attention_line
key_word_txt : STvalue : ST
Batch
control_id : IIname : STcreation_time : TSreference_control_id : IIsending_application_id : IIreceiving_application_id : IIsecurity : STmessage_count : INTbatch_totals : SET<INT>batch_comment : SET<ST>
0..10..*
contains
0..1
is_contained_by
0..*
Acknowledgement
type_cd : CVnote_txt : EDerror_detail_cd : CVexpected_sequence_nbr : INT
Message_interaction
message_type_id : IIresponse_cd : CS
Participation
type_cd : CStime : IVL<TS>note_txt : EDsignature_cd : CVfunction_cd : CDawareness_cd : CVsignature_txt : EDencounter_accommodation_cd : CVstatus_cd : CSmode_cd : CVsequence_nbr : INT
0..* 1
for
0..*
has
1
Relationship_link
effective_time : IVL<TS>type_cd : CS
Message
sending_application_id : IIid : SET<II>creation_time : TSinteraction_id : IIversion_id : STprofile_id : SET<OID>processing_cd : CVsequence_nbr : INTreply_to_com : TELreceiving_application_id : SET<II>processing_mode_cd : CVattachment_txt : EDaccept_ack_cd : CVapplication_ack_cd : CV
0..*1
can_accompany
0..*
can_include
1
0..1
0..*
contains
0..1
is_contained_by
0..*
1..*
1
acknowledges1..*
is_acknowledged_by1
0..1
1
occurs_with0..1
has 1
0..1
0..*
is_communicated_as0..1
has_payload0..*
Role
class_cd : CSeffective_time : IVL<TS>id : SET<II>status_cd : CSposition_nbr : LIST<INT>qty : RTOcertificate_txt : EDaddr : SET<AD>telecom : SET<TEL>cd : CE
0..*1
has_as_participant
0..*
participates_in
1
0..*1
has_source
0..*
is_source_for
1
0..*1
has_target
0..*
is_target_for
1
Entity
id : SET<II>class_cd : CSdeterminer_cd : CSimportance_status_txt : EDqty : SET<PQ>telecom : SET<TEL>desc : EDstatus_cd : CScd : CEnm : SET<EN>risk_cd : CEhandling_cd : CE
1..*
0..*
shall_receive 1..*
has_recipient
0..*
1..1
0..*
sends 1..1
has_sender
0..*
0..*0..1
played_by
0..*
plays
0..1
0..*0..1
is_scoped_by
0..*
scopes
0..1
Language_communication
language_cd : CEpreference_ind : BLmode_cd : CVproficiency_level_cd : CV
10..*
communicates_with
1
used_by
0..*
Financial_transaction
payment_terms_cd : CVdebit_exchange_rate_qty : RTOcredit_exchange_rate_qty : RTOinterest_rate_qty : RTO
Invoice_element
item_nbr : REALitem_qualifier_cd : CEgross_qty : MOcoverage_source_cd : CEunit_qty : RTOnotify_subject_ind : BLmodifier_cd : CEfactor_nbr : REALpoints_nbr : REAL
Financial_contract
payment_terms_cd : CV
Role_heirEntity_heir
Sort_control
element_name : STsequence_nbr : INTdirection_cd : CV
Query
message_query_cd : CVid : IIpriority : CVmodify_indicator : CVexecution_and_delivery_time : TSinitial_qty : PQresponse_modality_cd : CVreturn_element_group : SET<CV>
0..* 1
is_for
0..*
has
1
Relational_expression
element_name : STvalue : STrelational_operator_cd : CV
Query_by_selection
Selection_expression
0..*
1
is_for 0..*
has_ex pression1
Logical_expression
relational_conjunction_cd : CV
1
0..*
has_left_side
1
is_lhs_for0..*
1
0..*
has_right_side
1
is_rhs_for0..*
Query_by_parameter
Parameter_list
Parameter
name : ST
0..*
1
is_parameter_of0..*
has 1
0..1
0..*
may_contain0..1
is_part_of
0..*
A_parameter
value : ANY
Device_task
parameter_value : LIST<ANY>
0..*
1 0..*
1
RIM Core Classes
EntityEntity ParticipationParticipation ActAct
RelationshipRelationshipLinkLink
0..* 0..*
1 1
ActActRelationshipRelationship
1 1
0..* 0..*
EncounterReferralSupplyProcedureObservationSubstance AdministrationFinancial act
OrganizationLiving SubjectMaterialPlace
PatientEmployeeCertified PractitionerAssigned PractitionerSpecimenHealthcare Facility
RoleRole0..1
0..*
0..1
0..*
DefinitionsAct - 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).
Entity
class_cd : CCcd: CEdeterminer_cd : CSstatus_cd : CSid : II
Role
class_cd : CScd: CEeffective_time : IVL<TS>status_cd : CSid : II
Participation
type_cd : CStime : IVL<TS>status_cd : CS
Act
class_cd : CCcd: CDmood_cd : CSstatus_cd : CSeffective_time : GTSid : II
1
0..*1
0..*
1
0..*
Relationship Link
type_cd : CSeffective_time : IVL<TS>
Act Relationship
type_cd : CS
0..* 0..*
0..1 0..1
0..* 0..*
0..1 0..1
RIM Core Attributes
Six attributes: Class_cd+cd/type_cd, time, mood, determiner, status, id
1
0..*
plays
scopes
Entity
class_cd : CCdeterminer_cd : CSstatus_cd : CScd: CE
Role
class_cd : CSeffective_time : IVL<TS>cd: CE
Participation
type_cd : CStime : IVL<TS>status_cd : CS
Act
class_cd : CCmood_cd : CSstatus_cd : CSCd: CDeffective_time : GTS
1
0..* 1
0..*
1
0..*
RIM Core Attribute Value Sets
EntityClass Code
• Living SubjectLiving Subject• PersonPerson• OrganizationOrganization• MaterialMaterial• PlacePlace• ......
RoleClass Code
• PatientPatient• ProviderProvider• EmployeeEmployee• SpecimenSpecimen• Certified Certified PractitionerPractitioner• ......
ParticipationType Code
• PerformerPerformer• AuthorAuthor• WitnessWitness• SubjectSubject• DestinationDestination• ......
ActMood Code
• DefinitionDefinition• IntentIntent• OrderOrder• EventEvent• CriterionCriterion• ......
ActClass Code
• ObservationObservation• ProcedureProcedure• SupplySupply• Substance Substance AdminAdmin• FinancialFinancial• ......
EntityDeterminerCode
• KindKind• InstanceInstance• (Quantified(Quantified
Group)Group)
1
0..*
plays
scopes
Act State Model
normal
held
cancelled
suspended
completed
aborted
activenew
null
held
cancelled
suspended
nullified obsolete
revise
revise
completed
revise
aborted
active
reactivate
revise
new
create completeactivate
release
hold
cancel
activate
suspend
complete
abort
nullify obsolete
resume
end
abort
Act
Define plansand guidelines
Master Act(definition)Care plan for a patient
Ordering(order)
Scheduling
Performing
Documenting & reporting(event)
Reviewing
Business Cycle
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.
Coded attributes
Over 40% of RIM attributes are coded!
Attributes, domains, and value sets
Person.gender_cd
RIMAttribute
Gender
Domain
Sub-domainR-MIM
Patient.gender_cdPatientGender
A subset of Gender
Specialization
HMD (PAFM)
Patient.gender_cd Administrative
Gender
Value Set
Realm (USA)Code System (HL7)
Specialization
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> CWEA code indicating the married or similar partnership status
of a person,e.g., married, separated, divorced, widowed, common-law
marriage.
Codes and Print names in the Vocabulary TablesAdministrativeGender
M MaleF Female
LivingArrangement
H Independent HouseholdI InstitutionN Nursing HomeX Extendedcare facilityR Retirement CommunityG Group HomeT TransientM Nomadic
MaritalStatus
S SingleM MarriedD DivorcedSP 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 Actinvariant(Act x) where x.nonNull {
x.cd.implies(x.class_cd) };• To specialize Act to be a LOINC
observationinvariant(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
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 Race
AmericanIndianOrAlaskaNative Asian White BlackOrAfricanAmerican
AmericanIndian AlaskaNative
Navajo Apache
Abstract
Specializable
Leaf
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)
PointInTime : TS
offset : PQcalendar : CSprecision : INTtimeZone : PQ
GeneralTimingSpecification : GTS
Quantity : QTY
Set_of_TS : SET<TS>
DataValue : ANY
<<extends>>
<<extends>>
<<extends>>
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
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”
T
Interval : IVL
low : Tlow_closed : BLhigh : Thigh_closed : BL
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.
Selected “flavors” of nullName 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 Backbone
•Welcome•Introduction•V3 Principles•Quick Start•Getting Started•Glossary
V3 Guide
ImplementableTechnology
Specifications
XML
Data Types
Data TypesPart I
Part II
Sub-sectionsSection
InfrastructureManagement
Sub-sectionsSection
AdministrativeManagement
Sub-sectionsSection
Health & ClinicalManagement
Normative: Content is balloted by general membership and is considered structural component of HL7 standard. Negative ballots MUST be resolved.
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. Vocabulary
Normative
Reference
Informative
Legend:
Reference Information
Model State Machines
Literary Expression
RIM Diagram
HL7 3.0 Section Publication Structure
Sub-sections
Domain
CMET
Storyboard
Application Roles
Interaction Category
R-MIM HMD Message Type
Interaction
Trigger Event
R-MIM HMD
StoryboardExamples
Message Type
Normative
Reference
Informative
Legend:
Use Case ModelUse Case ModelUse Case ModelUse Case Model
Use Case Diagram
Spec
UCM SpecAssociate Actors and Use Cases
Develop Scope
Identify actors and Use Cases
Message Development Phases
Message DesignMessage DesignMessage DesignMessage Design
2-nd Order 1 choice of 0-n Drug 0-1 Nursing
2-nd Order 1 choice of 0-n Drug 0-1 Nursing
h//mt:50”d”………
h//mt:50”d”………
Develop Refined Message Information Model
Specify HMD & METs with constraints
Specify CMET
Information ModelInformation ModelInformation ModelInformation Model
State DiagramClass Diagram Define vocabulary domains and codesDefine states, transitions and triggers
Define classes, attributes, and relationships
Spec
RIM Spec
Interaction ModelInteraction ModelInteraction ModelInteraction Model
Interaction Diagram
Define Application Roles
DefineInteractions
Define Conformance Criteria
Spec
Inter Spec
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
RIM
(1)Define aDMIM
DMIM
(2)Define aR-MIM
R-MIM
(3)Create
an HMD
HMD
RIMReference Information Model
DMIMDomain Message Information Model
R-MIMRefined Message Information Model
HMDHierarchical Message Definition
• Select a subset of the RIM classesSelect a subset of the RIM classes
• Select a subset of class relationshipsSelect a subset of class relationships
• Select a subset of class attributes Select a subset of class attributes
• Select a subset of attribute datatypesSelect a subset of attribute datatypes
• Select a subset of attribute domains and value setsSelect a subset of attribute domains and value sets
• Created clones of classes and attributesCreated clones of classes and attributes
• Assign alias class and attribute namesAssign alias class and attribute names
• Eliminate unnecessary class hierarchiesEliminate unnecessary class hierarchies
• Finalize class relationships and multiplicityFinalize class relationships and multiplicity
• Finalize attribute domains and value setsFinalize attribute domains and value sets
• Select a root class for the messageSelect a root class for the message
• Arrange classes and attributes hierarchicallyArrange classes and attributes hierarchically
• Declare inclusion and repetition constraintsDeclare inclusion and repetition constraints
• Declare domain value constraintsDeclare domain value constraints
• Assign message element namesAssign message element names
Using the RIM to Build Messages
RMIM Example from the V3 Ballot -
Use Case ModelUse Case ModelUse Case ModelUse Case Model
Use Case Diagram
Spec
UCM SpecAssociate Actors and Use Cases
Develop Scope
Identify actors and Use Cases
Message Development Phases
Message DesignMessage DesignMessage DesignMessage Design
2-nd Order 1 choice of 0-n Drug 0-1 Nursing
2-nd Order 1 choice of 0-n Drug 0-1 Nursing
h//mt:50”d”………
h//mt:50”d”………
Develop Refined Message Information Model
Specify HMD & METs with constraints
Specify CMET
Information ModelInformation ModelInformation ModelInformation Model
State DiagramClass Diagram Define vocabulary domains and codesDefine states, transitions and triggers
Define classes, attributes, and relationships
Spec
RIM Spec
Interaction ModelInteraction ModelInteraction ModelInteraction Model
Interaction Diagram
Define Application Roles
DefineInteractions
Define Conformance Criteria
Spec
Inter Spec
Version 3 in a nut shell1. 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 Storyboards1. 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 Interactions5. 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
undetermined9. 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 sectionRow types
rmim - the first row of the table, identifies the R-MIM class - identifies a "class" in the Refined Message Information Modelattr - identifies an attribute of the "class" that is most directly above this rowassoc - identifies an association leading from the class that is most directly
above this rowstc - subtype constraint: row corresponds to a subcomponent of the row
above; included in order to be able to state a constraint on the subtypeClass or Property -- contains the information model name of the entityShort 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 ninecolumns 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
• 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
HL7 Specifications to help?
Questions? Comments? Discussion?