Introduction to HL7 Version 3 Jane Curry Sierra Systems HL7 Canada – Halifax October 18 th, 2001.

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


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



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






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


Use Case Use Case ModelModel

Use Case Use Case ModelModel

Information Information ModelModel

Information Information ModelModel

Message ModelMessage ModelMessage ModelMessage Model



Implementable Implementable Message Message

SpecificationSpecification

EDIFACT*EDIFACT*



EDIFACT*EDIFACT*

*Future Consideration



OLE/CORBAOLE/CORBA



OLE/CORBAOLE/CORBA



XML/ER7/…XML/ER7/…



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 Diagram

Spec

UCM SpecAssociate Actors and Use Cases

Develop Scope

Identify actors and Use Cases





h//mt:50”d”………

h//mt:50”d”………

Develop Refined Message Information Model

Specify HMD & METs with constraints

Specify CMET


State DiagramClass Diagram Define vocabulary domains and codesDefine states, transitions and triggers

Define classes, attributes, and relationships

Spec

RIM Spec


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 Diagram

Spec

UCM SpecAssociate Actors and Use Cases

Develop Scope

Identify actors and Use Cases





h//mt:50”d”………

h//mt:50”d”………

Develop Refined Message Information Model

Specify HMD & METs with constraints

Specify CMET


State DiagramClass Diagram Define vocabulary domains and codesDefine states, transitions and triggers

Define classes, attributes, and relationships

Spec

RIM Spec


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?

Introduction to HL7 Version 3 Jane Curry Sierra Systems HL7 Canada – Halifax October 18 th, 2001.

Documents

hl7 version

hl7 v3

clinical interoperability

personal health information

emerging information

system source

interoperability function

building hl7 messagediscussion