HL7 message system: from RIM through DMIM, RMIM

Dipartimento di 

Elettronica e Informazione 

V School of Information Engineering 

Master of Science in Information Engineering 

ICT for Health Care and Life Sciences 

Emanuele Della Valle emanuele.dellavalle@polimi.it

ICT for Health Care and Life Sciences 

HL7 message creation process 

© Alessio Carenini - Revised by Emanuele Della Valle 

2

HL7 V3 Message Constrained Information Models 

• RIM: Reference Information Model 

• D-MIM: Domain Message Information Model 

• R-MIM: Refined Message Information Model 

• HMD: Hierarchical Message Definition 

RIM 

R-MIM 

HMD 

Derive 

D-MIM 

Restrict 

Serialize 

[Source: http://www.slideshare.net/AShakir/hl7-v3-reference-models-20091123 ] 

3 of 164

Storyboard 

Example 

HL7 V3 Message Development Framework 

References 

Storyboard 

Example 

Application 

Role 

Sender Receiver 

Interaction 

Interaction Modeling 

Content 

Use Case Modeling 

Trigger 

Event 

Information Modeling 

Triggers 

Message Design 


D-MIM 

R-MIM 

HMD 

Derive 

Restrict 

Serialize 

Restrict 

Message 

Type 

[Source: http://www.slideshare.net/AShakir/hl7-v3-reference-models-20091123 ] 4 of 164

The idea: one reference model, multiple 

domains, as many messages as needed 

ITS 

(serialization format 

of instances) 

R-MIM / SIM 

Serializable Model 

Refinement of 

D-MIM / DIM 

Domain Model 

Refinement of 


Stable model, 

Domain agnostic 

Pharmacy 



Clinical 

Documents 

5

HL7 v.3 message creation process 

Analysis 

Design 

Implementation 

Guide 

• Requirements Analysis 

• Domain Analysis 

• Use Case Model (UCM) 

• Information Model (RIM & DIM) 

• Vocabulary Domain Specification 

• Component and Object Interaction Design 

• Message Design 

• Interaction Model (IM) 

• Message Information Model (MIM) 

• Hierarchical Message Description (HMD) 

• Implementation Technology Specification (ITS) 


6

2-nd Order 

1 choice of 

0-n Drug 

0-1 Nursing 

V3 process in HL7 Development Framework (MDF) 

Use Case Model 

Information Model 

Interaction Model 

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 

7

HDF Model Relationships 

Requirements 

Analysis 

Use Case 

Model 

(UCM) 


Analysis Design 

Domain 

Analysis 

Domain 

Information 

Model 

(DIM) 


Interaction 

Design 

Interaction 

Model 

(IM) 

Message 

Design 

2-nd Order 

1 choice of 

0-n Drug 

0-1 Nursing 

Hierarchical 

Message 

Descriptions 

(HMD) 

Reference Model Repository 

Voting 

Approval 

Ballots 

8

Models are used to build the HMD 

Reference 

Information Model 

Domain Specification Database 

Hierarchical 

Message 

Description 

Domain 

Information 

Model 


Encounter_practitioner 

Person_name_for_IHCP 

is_participant_for 0..* 

1 

is_associated_with 

participation_type_cd 

cd : CV 

Person_as_IHCP 

has 

1..* 

purpose_cd : CV 

phon : TIL 

type_cd : CV 

1 

Exactly one 

nm : PN 

is_for 

1 takes_on_role_of 

occurrence 

1 participates_as 

has_as_participant 1 

1 Individual_healthcare_practitioner 

Patient_encounter 

is_a_role_of id : TII 

id : TII 

status_cd : CV 

Person_as_Patient 

0..1 is_the_primary_provider_for 

encounter_classification_cd : CV 

birth_dttm : TS 

start_dttm 

birthplace_addr : ST 

0..* has_a_primary_provider involves end_dttm 

expected_insurance_plan_qty : NM 

1 

deceased_dttm : TS 

Patient 

1 

education_level_cd : CV 1..1 

first_similar_illness_dttm 

has gender_cd : CV 

takes_on_role_of id : TII 

marital_status_cd : CV 

status_cd : CV 1 

race_cd : CV 

1..1 newborn_baby_ind 

religious_affiliation_cd : CV is_a_role_of multiple_birth_ind is_involved_in 

phon : TIL 

organ_donor_ind 

Inpatient_encounter 

1 

1..* 

has 

actual_days_qty 

Patient_admission 

is_for 

estimated_days_qty 

admission_dttm 

Person_name_for_Patient 

Patient_billing_account 

admission_reason_cd 

1 

nm : PN 

id : TII 

admission_referral_cd is_preceded_by 

effective_dt : TS 


admission_source_cd 1 

cd : CV 

0..1 

billing_status_cd : CV 

admission_type_cd 


patient_financial_class_cd : CV 

pre_admit_test_ind preceded 

termination_dt : TS 

price_schedule_id : TII 

belongs_to readmission_ind 

type_cd : CV 

Use Case Model 

Message 

Information 

Model 

Interaction 

Model 

Common 

Message 

Element 

Types 

10

The HMD & ITS then give messages 

Implementation 

Technology 

Specifications 

ITS 

"Send as ASCII 

string in XML 

Data 

format" 

HL7 

Message 

Creation 

HL7-Conformant 

Application 


Message 

Instance 

Hierarchical 

Message 

Definition 

HL7 

Message 

Parsing 

HL7-Conformant 

Application 

"Discontinue 

pharmacy order" 

Data 

11

The HL7 Development Framework in detail

Use Case Model: Definitions 

• Scope statement 

§� A high level use case for the entire project 

• Use case 

§� Describes specific situations in which communication between 

healthcare entities is needed 

• Actor 

§� An entity which initiates or participates in the use case. Discovered in 

the process of developing use cases 

• Use Case Diagram 

§� Provides a graphical form to develop the use case model from the 

business process analysis - UML notation 

§� Makes it easy to show the relationship between use cases 

• Use cases can be decomposed 

• Use cases can be shared 


14

Sample Use Case Model 

Manage 

Membership 

Manage Health Plans 

Manage Membership 

Enroll Member 

Approve Services 

Discharge 

Member 

Manage 

Health Plans 

Manage 

Network 

Manage Network 

Evaluate Provider 

Market Services 

Health Care Enterprise 


Provide 

Services 

Treat Patient 

Treat Patient 

Administer Procedure 

Record Results 

Evaluate 

Outcomes 

Provide Services 

Perform Triage 

Schedule 

Service 

Schedule Service 

Create Appointment 

Monitor 

Appointment 

Order Service 

Order Service 

Create Order 

Status Order 

Sign 

Order 

16

The Information Model 

• A detailed and precise definition for the information from which all 

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 all HL7 

messages. 


18

Parts of the Information Model 

• Classes, Attributes, and Relationships 

§� Documented in the Reference Information Model, the Domain 

Message Information Model, and the Refined Message Information 

Model (see also slides from 31 to 41) 

§� Consistency ensured by a Style Guide 

• State Transition Models 

§� For certain selected classes (Subject Classes) 

• Data Types and Constraints 

§� Vocabulary definitions, Domains 


19

RIM Subject Classes 

• The Subject Classes are those classes in the RIM that express the 

concepts that are central to managing healthcare, e.g. Patient, 

Order. 

• Subject Classes are the focus for trigger events, use cases & 

application roles. 

• State transition modeling of Subject Classes discovers potential 

trigger events. 

• Subject Classes capture the domain behaviors that the HL7 

committee feels are most important 


20

State Transition Modeling 

• Identify States 

§� From Use Cases 

• Document States 

§� Which attributes must be valued/unvalued? 

§� What are the constraints on the values? 

§� What associations must be established? 

§� What associations must not exist? 

• Capture State Model 

§� UML State Transition Model 


21

State Transition Diagrams 

• Figure State diagram for Patient class. 

Scheduled 

s chedule_encounter ^C00XMT003 

null 

s tart_encounter ^C00XMT004 

s tart_encounter ^C00XMT005 

Active 

Transitions include reference to 

the trigger event. 


delete_s cheduled_encounter ^C00XMT006 

delete_ac tive_ encounter ^C00XMT007 

dis charge_patient ^C00XMT008 

cancel_discharge ^C00XMT009 

Deleted 

delete_dis charged_encounter 

Discharged 

• State diagram for Patient_encounter class 

22

Vocabulary and Domains 

• Attributes in the RIM must be associated with a Domain to have 

meaning 

• Domains are associated with Vocabularies 

§� Held in the Domain Specification Database 

• The vocabulary and domain define the values that may be taken on 

by an attribute in a defined message 

§� Set of coded values or defined words/phrases 

§� Statements in a constraint language 


23

Modeling Interactions 

• Derived from the leaf-level Use Cases 

• Specifies all Trigger Events and Message Flows 

• Does not define standard system or application functions, only 

messaging roles 

• Fine-grained abstraction; every system will claim several roles 

• Basis for contractual agreement: describes roles to which systems 

may claim conformance 

• Potential basis for conformance testing 

• Captured in 

§� an Interaction Diagram and 

§� an Application Role Diagram 


25

Interaction Model Contents 

• Each Interaction consists of: 

§� Trigger event 

• Event dependency usually expressed as the state of one or more 

classes 

§� Message ID 

• Each interaction sends one particular message 

§� Sender role 

• When trigger event detected, message is sent 

§� Receiver role 

• Receiver responsibility - a specific functional responsibility for the 

receiver to initiate another (consequential) interaction 


26

Interaction Model Diagram 

Figure Interactions for Patient subject class.b 

AR _Patient_m anager : 

AR_Patient_m anager 

Interaction - 

Trigger Event causes a Message 

to be sent by a Sending role to a 

Receiving role for which there may 

be a Receiver responsibility 

1: add_patient(tid) 

3: delete_patient 


2: add_patient(tidx) 

4: delete_patient(tidx) 

AR_Patient_trac ker : 

AR_Patient_tracker 

Application Role - 

identifies an information 

management responsibility for 

one of the subject classes. 

Responsibilities typically are: 

Creator, Manager, Tracker 

and Archivist. 

Healthcare applications are 

assumed to take on one or 

more application roles. 

27

Application Roles 

• All Application Roles that participate in the interactions for a trigger 

event must be identified 

• All trigger events that a particular application role participates in 

must be identified 

• All Classes that participate in the interactions must be identified 

• Captured in an Application Role Diagram 


28

Application Role Diagram 

• Application role diagram for example model. 

RIM Classes 

Patient 

AR_Patient_manager 

add_patient() 

delete_patient() 

SC_Application_role_root 

SC_Patient 

AR_Patient_tracker 

add_patient() 

delete_patient() 


SC_Patient_encounter 


AR_Encounter_archivist 

admit_patient() 

activate_scheduled_encounter() 

delete_active_encounter() 

discharge_patient() 

cancel_discharge() 

Application Roles 

AR_Encounter_tracker 

schedule_encounter() 



delete_scheduled_encounter() 




AR_Encounter_manager 






29

Application Roles and Conformance Claims 

• A conformance claim is a commitment to fulfill one or more 

interactions relating to an Application Role 

• For each Role, the application must send and receive all of the 

interactions (messages) specified for that Role: 

§� At specified trigger events, obeying specifications about conditionality, 

required presence, etc. 

§� Upon receipt of certain messages, perform the receiver responsibilities 

• Provides a consistent, unambiguous vocabulary for precontract 

understanding of vendor capabilities 

• Grouped into a Conformance Claim Set 


30


Reference 

Information 

Model (RIM) 

Domain 

Message 

Information 

Model (D-MIM) 

Refined 

Message 

Information 

Model 

(R-MIM) 




1 



cd : CV 


has 

1..* 


phon : TIL 

type_cd : CV 

1 

Exactly one 

nm : PN 

is_for 

1 takes_on_role_of 

occurrence 






id : TII 



0..1 is_the_primary_provider_for 



start_dttm 


0..* has_a_primary_provider involves end_dttm 


1 


Patient 

1 

education_level_cd : CV 1..1 


has gender_cd : CV 



status_cd : CV 1 

race_cd : CV 


religious_affiliation_cd : CV is_a_role_of multiple_birth_ind is_involved_in 

phon : TIL 



1 

1..* 

has 



is_for 






1 

nm : PN 

id : TII 

admission_referral_cd is_preceded_by 



admission_source_cd 1 

cd : CV 

0..1 





pre_admit_test_ind preceded 



belongs_to readmission_ind 

type_cd : CV 


Use Case 

Model 

Hierarchical 

Message 

Description (HMD) 

Interaction 

Model 

32


• The RIM must first be refined by subsetting and constraining it 

§� Create a Domain Message Information Model (D-MIM) with RIM 

classes needed 

§� Develop an Refined Message Information Model (R-MIM) from these 

classes 

• Define the structure for the message 

§� Tree walk the R-MIM (Define a Path) 

§� Identify Message Element Types (MET, CMET) 

• Document the Message Specification 

§� Create the Hierarchical Message Definition (HMD) 

• HL7 Tooling to assist with these steps 


33

Subset the RIM ⇒ D-MIM 

• Select the portion of the RIM that contains the classes of interest in 

the message 

§� Classes that participate in the Use Cases as documented in the Use 

Case Model 

§� Classes that participate in interactions and application roles as 

documented in the Interaction Model 

§� Attributes of interest in these interactions 

• Collection of classes with some constraints 

• Collection of attributes and associations to support the R-MIM 

• No need for high precision at this point, can be corrected later – this 

is the first draft stage 


34

Convert the D-MIM ⇒ R-MIM 

• Constrain cardinality on Associations 

§� May be limited in the interactions for which messages are being 

designed 

• Constraints on Attributes 

§� Some may be left out 

§� Sub-components may be individually constrained 

• Classes are duplicated for different uses 

• May modify the Inheritance structure 

§� Some specializations may subsume the generalization 

§� Always inherit downwards to specializations 

• One block for each class structure 

• Defines patterns of constraints for each class 


35

Refine and Document R-MIM 

• Document the R-MIM in tabular form 

§� Identify information not in graphical form 

• Domains, Update Semantics, Conditionality, etc. 

• Contains all information needed for the HMD 

§� But the classes are shown in arbitrary order 

§� Usually multiple class instances shown for some RIM classes 

• Tooling simplifies entire process 


36

Sample D-MIM 


cd : CV 


type_cd : CV 

nm : PN 

has 

1..* 

is_for 

1 

1 

1 

has 

is_for 



phon : TIL 




education_level_cd : CV 

gender_cd : CV 


race_cd : CV 

religious_affiliation_cd : CV 

phon : TIL 

This example will include 

those messages 

requiring data from 

Patient and 



nm : PN 


cd : CV 



type_cd : CV 




id : TII 


0..1 




belongs_to 


1 

takes_on_role_of 

0..1 



is_the_primary_provider_for 

0..* has_a_primary_provider 

1..1 

Patient 




is_a_role_of multiple_birth_ind 


1 

has 

1 



Exactly one 

occurrence 

is_involved_in 

involves 

1 




admission_referral_cd 

admission_source_cd 


pre_admit_test_ind 

readmission_ind 

1 


1..* 



id : TII 



start_dttm 

end_dttm 






preceded 

1 

is_preceded_by 

37

Sample Tabular R-MIM 

A small piece of it … 


38

Construct the HMD by defining 

the Message Element Types (METs) 

• The HMD combines the structure and semantics of the message 

contents 

• Produced by performing a tree walk 

§� Select nodes to start each tree based on the Interactions and Use 

Cases 

§� Follow the appropriate connections in the R-MIM 

§� Re-orders and structures the information in the R-MIM to follow a Path 

through the Information Model 

• Note each class instance block in the R-MIM is a MET; the entire 

table is the full message MET, which is the HMD 


39

MET and Common MET (CMET) 

• Some Message Element Types are unique 

§� Used only for a specific message 

• e.g. structure for an EKG waveform result 

• Some Message Element Types may be reused in many 

messages 

§� Analogous to v2.x segments like PID, PV1, etc. 

§� May have finer granularity than v2.x 

§� Have certain constraints loosened for re-use 

§� CMETs (Common Message Element Types) 


40

Build the HMD 

• All of the information of the MET and CMET is documented in the 

Hierarchical Message Description – HMD 

• Tabular 

• Stored in the repository 

• Final specification of a particular message 

• Contains conformance parameters 


41

HL7 message system: from RIM through DMIM, RMIM

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?