You are on page 1of 114

By: Dr.

Abbas Shojaee February, 2010


Faculty of paramedical sciences, Beheshti University of Medical Sciences

This presentation uses works of:


1. 2. 3.

4. 5.

Tim Benson W. Ted Klein Evangelos Milios Gunther Schadow Veli BICER

This is an introduction and it does not go into the details of concepts and interactions. Introduces RIM in detail Does not teach how to design models Does not cover details of project issues (e.g., tools, coordination, balloting, etc.) Contains a simple practice on how to design a software architecture for imposed security needs by HL7.

BUMS, Abbas Shojaee, Feb. 2010

1999, 2000 Health Level 7

January 24, 2000

Standards in Health care informatics


What is it? Why is needed?

HL7 evolution and history HL7 standard version 3.0


Describe the models in Version 3 Show how they are used to develop the HL7 message specifications that make up the standard?

Practicing development of a standard Practicing implementation of HL7 required functionalities for Security

BUMS, Abbas Shojaee, Feb. 2010

1999, 2000 Health Level 7

January 24, 2000

Part I - Introduction
HL7, business problem, and how HL7 solves it What is Version 3? Why HL7 is making the move to Version 3

Part II - Technical Concepts


Background information

Part III - Methodology


Modeling process

BUMS, Abbas Shojaee, Feb. 2010

1999, 2000 Health Level 7

January 24, 2000

What is a standard in medical informatics? Why and where is it needed? What urge them? The process of standard development in Medical Informatics?

January 24, 2000

1999, 2000 Health Level 7

Migration Towards a Wellness Model

Managing Visit

Managing Care
Clintons Reform

Managing Health

Initial
Fee-for-service, on-demand
BUMS, Abbas Shojaee, Feb. 2010

Transitional
Capitated, case-based
1999, 2000 Health Level 7

Anticipated

Present time

Preventive, episodal
January 24, 2000
6

Client/Server, Internet, Multimedia


Centralized Computing (Batch)
Network Computing (RPC, ORBs, etc)

Digital

Dell
Micron

HP

Enterprise Computing (Client/Server)


BUMS, Abbas Shojaee, Feb. 2010
1999, 2000 Health Level 7

January 24, 2000

Business Strategy & Motivation

Methodology, Measurement, Coordination

Planning & Enforcement


BUMS, Abbas Shojaee, Feb. 2010

Modeling & Voting


1999, 2000 Health Level 7

January 24, 2000

Evolution and history The structure Organization and methodology

BUMS, Abbas Shojaee, Feb. 2010

1999, 2000 Health Level 7

January 24, 2000

Health care environment is a complex environment and a language to describe it needs to accommodate this complexity HL7 is such a language The result of an ad hoc effort to make HIS information exchangeable The HL7 organization was founded in 1987

In June 1994 HL7 was designated as an ANSI accredited standards development organization (SDO)

BUMS, Abbas Shojaee, Feb. 2010

1999, 2000 Health Level 7

January 24, 2000

10

Implementation Technology Specification

"Send as ASCII string in XML format"

Hierarchical Message Definition

"Discontinue pharmacy order"

ITS for XML

Data

HL7 Message Creation HL7-Conformant Application

Message Instance

HL7 Message Parsing HL7-Conformant Application

Data

BUMS, Abbas Shojaee, Feb. 2010

1999, 2000 Health Level 7

January 24, 2000

11

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. ... the complete life cycle of a standards specification -- development, adoption, market recognition, utilization and adherence.

BUMS, Abbas Shojaee, Feb. 2010

1999, 2000 Health Level 7

January 24, 2000

12

A domain-specific, common protocol for the exchange of health care information.

Function

Communication

7 6 5 4 3 2 1

Application Presentation Session Transport Network Data Link Physical


1999, 2000 Health Level 7 January 24, 2000 13

ISO-OSI Communication Architecture Model


BUMS, Abbas Shojaee, Feb. 2010

2.0 (1988) 2.1 (1990) 2.2 (1994) 2.3 (1997) 2.3.1 (1999) 2.4 (2000) 3.0

Prototype First standard Widely Adopted In operation Current ANSI standard In Ballot

BUMS, Abbas Shojaee, Feb. 2010

1999, 2000 Health Level 7

January 24, 2000

14

The HL7 RIM (Reference Information Model) specifies the grammar of V3 messages and, specifically, the basic building blocks of the language (nouns, verbs, etc.), their permitted relationships, and Data Types. The RIM is not a model of health care. It is not a model of any message, either. Although it is healthcare-specific and it is used in messages.

BUMS, Abbas Shojaee, Feb. 2010

Organization addr : BAG<AD> standardIndustryClassCode : CE

Place mobileInd : BL addr : AD directionsText : ED positionText : ED gpsText : ST

Patient confidentialityCode : CE veryImportantPersonCode : CE ManagedParticipation

ActRelationship

typeCode : CS id : SET<II> inversionInd : BL outboundRelationship statusCode : SET<CS> contextControlCode : CS Access LicensedEntity 0..n contextConductionInd : BL approachSiteCode : CD sequenceNumber : INT recertificationTime : TS Person targetSiteCode : CD 1 source priorityNumber : INT gaugeQuantity : PQ addr : BAG<AD> pauseQuantity : PQ Act Participation maritalStatusCode : CE checkpointCode : CS classCode : CS educationLevelCode : CE Entity typeCode : CS splitCode : CS Role moodCode : CS raceCode : SET<CE> classCode : CS functionCode : CD player joinCode : CS id : SET<II> disabilityCode : SET<CE> classCode : CS contextControlCode : CS ... determinerCode : CS negationInd : BL 0..1 code : CD 0..n livingArrangementCode : CE id : SET<II> sequenceNumber : INT id : SET<II> 0..n conjunctionCode : CS 1 negationInd : BL religiousAffiliationCode : CE code : CE code : CE playedRole negationInd : BL localVariableName : ST 1 derivationExpr : ST ethnicGroupCode : SET<CE> negationInd : BL quantity : SET<PQ> 0..n noteText : ED seperatableInd : BL text : ED addr : BAG<AD> time : IVL<TS> name : BAG<EN> inboundRelationship 0..n title : ST telecom : BAG<TEL> desc : ED modeCode : CE statusCode : SET<CS> statusCode : SET<CS> statusCode : SET<CS> awarenessCode : CE target scopedRole LivingSubject effectiveTime : GTS effectiveTime : IVL<TS> signatureCode : CE existenceTime : IVL<TS>... 0..n certificateText : ED activityTime : GTS 1 administrativeGenderCode : CE telecom : BAG<TEL> signatureText : ED 0..1 availabilityTime : TS birthTime : TS quantity : RTO source performInd : BL riskCode : CE ControlAct deceasedInd : BL scoper positionNumber : LIST<INT> ... 1 substitutionConditionCode ... : CE priorityCode : SET<CE> handlingCode : CE confidentialityCode : SET<CE>... deceasedTime : TS 1 target repeatNumber : IVL<INT> multipleBirthInd : BL 1 interruptibleInd : BL multipleBirthOrderNumber : INT WorkingList levelCode : CE organDonorInd : BL Employee outboundLink 0..n FinancialContract ownershipLevelCode : CE independentInd : BL 0..n jobCode : CE RoleLink paymentTermsCode : CE uncertaintyCode : CE jobTitleName : SC Material inboundLink typeCode : CS reasonCode : SET<CE> NonPersonLivingSubject jobClassCode : CE effectiveTime : IVL<TS> ... formCode : CE languageCode : CE strainText : ED salaryTypeCode : CE genderStatusCode : CE ManufacturedMaterial lotNumberText : ST expirationTime : IVL<TS> stabilityTime : IVL<TS> 0..n LanguageCommunication languageCode : CE modeCode : CE proficiencyLevelCode : CE preferenceInd : BL salaryQuantity : MO hazardExposureText : ED protectiveEquipmentText : ED InvoiceElement SubstanceAdministration routeCode : CE approachSiteCode : SET<CD> doseQuantity : IVL<PQ> rateQuantity : IVL<PQ> doseCheckQuantity : SET<RTO> maxDoseQuantity : SET<RTO> Observation value : ANY interpretationCode : SET<CE> methodCode : SET<CE> targetSiteCode : SET<CD> Procedure methodCode : SET<CE> approachSiteCode : SET<CD> targetSiteCode : SET<CD> modifierCode : SET<CE> unitQuantity : RTO<PQ,PQ> unitPriceAmt : RTO<MO,PQ> netAmt : MO factorNumber : REAL pointsNumber : REAL

Device

manufacturerModelName : SC softwareName : SC Container localRemoteControlStateCode... : CE capacityQuantity : PQ alertLevelCode : CE heightQuantity : PQ lastCalibrationTime : TS diameterQuantity : PQ capTypeCode : CE separatorTypeCode : CE barrierDeltaQuantity : PQ bottomDeltaQuantity : PQ

DiagnosticImage subjectOrientationCode : CE PatientEncounter preAdmitTestInd : BL admissionReferralSourceCode : CE lengthOfStayQuantity : PQ dischargeDispositionCode : CE specialCourtesiesCode : SET<CE> specialAccommodationCode : SET<CE> acuityLevelCode : CE PublicHealthCase detectionMethodCode : CE transmissionModeCode : CE diseaseImportedCode : CE Diet energyQuantity : PQ carbohydrateQuantity : PQ Supply quantity : PQ expectedUseTime : IVL<TS>

Account name : ST balanceAmt : MO currencyCode : CE interestRateQuantity : RTO<MO,PQ> allowedBalanceQuantity : IVL<MO>

FinancialTransaction DeviceTask parameterValue : LIST<ANY> amt : MO creditExchangeRateQuantity : REAL debitExchangeRateQuantity : REAL

RIM 2.01 July 17,2003

BUMS, Abbas Shojaee, Feb. 2010

16

Large pictorial representation of the clinical data (domains) Identifies the life cycle of events that a message or groups of related messages will carry. Shared model between all the domains and as such is the model from which all domains create their messages. Explicitly representing the connections that exist between the information carried in the fields of HL7 messages

BUMS, Abbas Shojaee, Feb. 2010

17

Specifies the grammar of HL7 messages The RIM backbone has just three core classes and a number of permitted relationships between them. Specialization
the basic building blocks of the language their permitted relationships.

Each class has a predefined set of attributes


HL7 V3 uses a graphical representation, called Refined Message Information Model (RMIM) to display the structure of a message as a colorcoded diagram.

specializations are only shown explicitly in the RIM when they add additional attributes to the general class

BUMS, Abbas Shojaee, Feb. 2010

18

ActRelationship typeCode : CS inversionInd : BL outboundRelationship contextControlCode : CS 0..n contextConductionInd : BL sequenceNumber : INT 1 source priorityNumber : INT pauseQuantity : PQ Act Participation checkpointCode : CS classCode : CS Entity typeCode : CS splitCode : CS Role moodCode : CS classCode : CS functionCode : CD player joinCode : CS id : SET<II> classCode : CS contextControlCode : CS ... determinerCode : CS negationInd : BL 0..1 code : CD 0..n id : SET<II> sequenceNumber : INT 0..n id : SET<II> conjunctionCode : CS 1 negationInd : BL code : CE playedRole code : CE negationInd : BL localVariableName : ST 1 derivationExpr : ST negationInd : BL quantity : SET<PQ> 0..n noteText : ED seperatableInd : BL text : ED addr : BAG<AD> time : IVL<TS> name : BAG<EN> inboundRelationship 0..n title : ST telecom : BAG<TEL> desc : ED modeCode : CE statusCode : SET<CS> statusCode : SET<CS> statusCode : SET<CS> awarenessCode : CE target scopedRole effectiveTime : GTS effectiveTime : IVL<TS> signatureCode : CE existenceTime : IVL<TS> ... 0..n certificateText : ED activityTime : GTS 1 telecom : BAG<TEL> signatureText : ED 0..1 availabilityTime : TS quantity : RTO source performInd : BL riskCode : CE scoper positionNumber : LIST<INT> ... 1 substitutionConditionCode ... : CE priorityCode : SET<CE> handlingCode : CE confidentialityCode : SET<CE> 1 target repeatNumber : IVL<INT> interruptibleInd : BL levelCode : CE outboundLink 0..n independentInd : BL 0..n RoleLink uncertaintyCode : CE inboundLink typeCode : CS reasonCode : SET<CE> effectiveTime : IVL<TS> ... languageCode : CE

BUMS, Abbas Shojaee, Feb. 2010

19

The RIM defines a set pre-defined Attributes for each class These are the only ones allowed in HL7 messages. Denoting attributes? E.g. Act.id Each attribute has a specified Data Type. These Attributes and Data Types become tags in HL7 XML messages.

BUMS, Abbas Shojaee, Feb. 2010

20

One common data type is the Instance Identifier (e.g. id), which is used to give unique identity to people, persons, organizations, things and information objects. The datatype for id is II(instance identifier)
II: Object Identifier (OID) Universal Unique Identifier (UUID)

BUMS, Abbas Shojaee, Feb. 2010

21

ClassCode to identify the type of Act


Code to further identify a classcode


to specify precisely what the class means at a leaf level of granularity. HL7 uses two main types of code.
1. 2. The first type covers the specialized codes used for structural attributes and are defined by HL7 itself. The second type covers externally defined terms and codes such as SNOMED CT (Clinical Terms).

An structural attribute Obligatory

BUMS, Abbas Shojaee, Feb. 2010

22

Used to specify more precisely what each RIM class means when used in a message. For example, Act has a class code and a mood code.
The class code states what sort of Act this is, such as an observation, an encounter, or the administration of a drug. Mood is analogous to the tense of a verb. Mood code indicates whether an Act has happened (an event), or is a request for something to happen, or a goal or even a criterion. "weight = 100kg" is an observation event; "measure weight daily" is a request; "reduce weight to 80Kg" is a goal "if weight is greater than 80Kg" is a criterion.

For example,

23

Every happening is an Act, analogous to a verb in English. Each Act may have any number of Participations, in Roles, played by Entities. These are analogous to nouns. Act
Kind of act (what happens) Actor (who performs) Subject whom is affected (e.g. patient) Where (location) When (time) How (manner) Why (Reasons ) What for (motives)

Each Act may also be related to other Acts, via ActRelationships.

BUMS, Abbas Shojaee, Feb. 2010

24

Acts.classCode specifies the type


of act.
Event Observation Notification

Times Lets discuss act specializations


Observation, Procedure, Substance Administration, Supply, and ActivityTime EffectivityTime

Acts.modeCode specifies the


tense of act:

Acts.StatusCode
New Active Completed Canceled Aborted

Fact (indicative mood) =EVN Command (imperative mood) = RQO Question (interrogative mood) Wish (optative mood) Conditionality (Subjunctive mood) Promise = PRMS Proposal = PRP

PatientEncounter.

25

BUMS, Abbas Shojaee, Feb. 2010

Entity is anything, which has or will have existence.


Living Non living Abstract

Structural attributes
Individual instance Collection Generic class

Entity.classCode identifies the represented concept. Entity.determinerCode identifies the type of representation

Either plays a Role or defines the scope for a Role Every Role is played just by a single Entity Some attributes of an Entity, are also found in the Role class. These include id, code, name, addr (address), telecom,

statusCode, and quantity

What is the rule, how can I choose using Entity and Role overlapping attributes?

BUMS, Abbas Shojaee, Feb. 2010

Living subject
Person NonPersonLivingSubject

Material Places Organization

BUMS, Abbas Shojaee, Feb. 2010

BUMS, Abbas Shojaee, Feb. 2010

Role is defined as a competency of an Entity playing the Role Samples:


Whar are Roles for people What are Roles for inanimate objects

People, such as patient, practitioner, or employee Places, such as hospital, home, clinic, or place of birth Organizations, such as care provider, employer, or supplier

The most important Role specialization is Patient.

Things, such as drug, instrument, or computer system Responsible entities, such as parent, employer, or manufacturer

BUMS, Abbas Shojaee, Feb. 2010

BUMS, Abbas Shojaee, Feb. 2010

Are used to constrain and verify conformance to profiled HL7 Version 3 Refined Message Information Models (RMIMs). Expresses the data content needed in a specific clinical or administrative context

BUMS, Abbas Shojaee, Feb. 2010

32

Explicit connection between core classes are needed

ActRelationship:
To link Acts together, from a Source Act to a Target Act ActRelationship .typeCode to specify the type of association
Composition comprises entries Discharge summary documents a hospital visit Test report fulfills a test request Discharge summary refers to a referral Final report replaces a preliminary report

Role Link:
Role Link is a relationship between two Roles.

BUMS, Abbas Shojaee, Feb. 2010

Participation:
It shows how an Entity, in a particular Role, functions during the scope of an Act Participants (entities) perform in an act as either actor (active) or target (passive) A participant in particular role, can contribute to an act in many ways. (e.g. a surgen) Participation.typeCode specifies the type of association between an Act and each participating Role
Performer of act (surgeons, observers, practitioners) Subject of act, such as the patient Location of act Author, informant, addressee, or information recipient

BUMS, Abbas Shojaee, Feb. 2010

Classification: ordered system of concepts related to a domain Clinical terminology: terminology needed to record all important aspects of health care in standardized form

BUMS, Abbas Shojaee, Feb. 2010

35

Entity Act
0..* participant 0..*participant scopedRole / participation Role type Code *: <= ParticipationType classCode *: <= ROL functionCode: CD CWE [0..1] <= ParticipationFunction id: SET<II> [0..*] contextControlCode: CS CNE [0..1] <= ContextControl code: CE CWE [0..1] <= RoleCode sequenceNumber: INT [0..1] negationInd: BL [0..1] negationInd: BL [0..1] addr: BAG<AD> [0..*] noteText: ED [0..1] telecom: BAG<TEL> [0..*] time: IVL<TS> [0..1] statusCode: SET<CS> CNE [0..*] <= RoleStatus modeCode: CE CWE [0..1] <= ParticipationMode effectiveTime: IVL<TS> [0..1] awarenessCode: CE CWE [0..1] <= TargetAwareness certificateText: ED [0..1] signatureCode: CE CNE [0..1] <= ParticipationSignature quantity: RTO<QTY,QTY> [0..1] signatureText: ED [0..1] positionNumber: LIST<INT> [0..*] 0..* playedRole performInd: BL [0..1] 0..* act 0..1 playingEntity 0..1 scopingEntity classCode *: <= ACT m oodCode *: <= EVN id: SET<II> [0..*] code: CD CWE [0..1] <= ActCode negationInd: BL [0..1] derivationExpr: ST [0..1] text: ED [0..1] statusCode: SET<CS> CNE [0..*] <= ActStatus effectiveTime: GTS [0..1] activityTime: GTS [0..1] availabilityTime: TS [0..1] priorityCode: SET<CE> CWE [0..*] <= ActPriority confidentialityCode: SET<CE> CWE [0..*] <= Confidentiality repeatNumber: IVL<INT> [0..1] interruptibleInd: BL [0..1] levelCode: CE CWE [0..1] <= ActContextLevel independentInd: BL [0..1] uncertaintyCode: CE CNE [0..1] <= ActUncertainty reasonCode: SET<CE> CWE [0..*] <= ActReason languageCode: CE CWE [0..1] <= HumanLanguage

Entity
classCode *: <= ENT de te r m ine r Code *: <= INSTANCE id: SET<II> [0..*] code: CE CWE [0..1] <= EntityCode quantity: SET<PQ> [0..*] name: BAG<EN> [0..*] desc: ED [0..1] statusCode: SET<CS> CNE [0..*] <= EntityStatus existenceTime: IVL<TS> [0..1] telecom: BAG<TEL> [0..*] riskCode: CE CWE [0..1] <= EntityRisk handlingCode: CE CWE [0..1] <= EntityHandling

sourceOf / targetOf
type Code *: <= ActRelationshipType inversionInd: BL [0..1] contextControlCode: CS CNE [0..1] <= ContextControl contextConductionInd: BL [0..1] sequenceNumber: INT [0..1] priorityNumber: INT [0..1] pauseQuantity: PQ [0..1] checkpointCode: CS CNE [0..1] <= ActRelationshipCheckpoint splitCode: CS CNE [0..1] <= ActRelationshipSplit joinCode: CS CNE [0..1] <= ActRelationshipJoin negationInd: BL [0..1] conjunctionCode: CS CNE [0..1] <= RelationshipConjunction localVariableName: ST [0..1] seperatableInd: BL [0..1]

0..* source

0..* target

Act

BUMS, Abbas Shojaee, Feb. 2010

11/10/2002

36

Organization
classCode *: <= OR G de te r m ine r Code *: <= INSTANCE name: BAG<EN> [0..*] standardIndustryClassCode: CE CWE [0..1] <= OrganizationIndustryClass 0..1 researchSponsor

ObservationEvent ResearchSubject
0..* sponsoredSubject classCode *: <= RESBJ 0..* researchSubject id: SET<II> [0..*] subject code: CE CWE [0..1] <= RoleCode type Code *: <= SBJ addr: BAG<AD> [0..*] telecom: BAG<TEL> [0..*] statusCode: SET<CS> CNE [0..*] <= RoleStatus effectiveTime: IVL<TS> [0..1] 0..* subjectOf classCode *: <= OBS m oodCode *: <= EVN id*: II [1..1] code*: CD CWE [1..1] <= Ob servationType text: ED [0..1] statusCode*: CS CNE [1..1] <= completed effectiveTime*: IVL<TS> [1..1] confidentialityCode: SET<CE> CWE [0..*] <= Confidentiality

component
type Code *: <= C OMP 0..* observationEvent

0..1 subjectPerson

Person
classCode *: <= PSN de te r m ine r Code *: <= INSTANCE id: SET<II> [0..*] code: CE CWE [0..1] <= EntityCode name: BAG<EN> [0..*] riskCode: CE CWE [0..1] <= EntityRisk handlingCode: CE CWE [0..1] <= EntityHandling administrativeGenderCode: CE CWE [0..1] <= AdministrativeGender birthTime: TS [0..1] deceasedTime: TS [0..1] maritalStatusCode: CE CWE [0..1] <= MaritalStatus educationLevelCode: CE CWE [0..1] <= EducationLevel disabilityCode: SET<CE> CWE [0..*] <= PersonDisab ilityType livingArrangementCode: CE CWE [0..1] <= LivingArrangement religiousAffiliationCode: CE CWE [0..1] <= ReligiousAffiliation raceCode: SET<CE> CWE [0..*] <= Race ethnicGroupCode: SET<CE> CWE [0..*] <= Ethnicity

ObservationEvent
classCode *: <= OBS m oodCode *: <= EVN id*: II [1..1] code*: CD CWE [1..1] <= Ob servationType statusCode: CS CNE [1..1] <= completed effectiveTime*: IVL<TS> [0..1] confidentialityCode: SET<CE> CWE [0..*] <= Confidentiality

BUMS, Abbas Shojaee, Feb. 2010

37

BUMS, Abbas Shojaee, Feb. 2010

A model is a collection of subject areas, scenarios, classes, attributes, use cases, actors, trigger events, interactions, etc. that depict the information needed to specify HL7 Version3 messages. HL7 models are further divided into four specific models - a use case model, an information model, an interaction model, and a message design model.

BUMS, Abbas Shojaee, Feb. 2010

Decomposition
Divide-and-conquer

Abstraction
Chunking the information

Hierarchy
Increasing semantic content of individual chunks of information through reuse

BUMS, Abbas Shojaee, Feb. 2010

40

Captures healthcare requirements

Use Case Model

Defines scope for TSC approval

Specifies data and its semantics

Information Model

Specifies major state transitions Specifies vocabulary for domains Defines information flows

Interaction Model

Defines communication roles Forms basis for conformance claims

2-nd Order 1 choice of 0-n Drug 0-1 Nursing

Defines message contents

Message Specification

Apply constraints to the information model and vocabulary


41

BUMS, Abbas Shojaee, Feb. 2010

BUMS, Abbas Shojaee, Feb. 2010

HL7 Models

BUMS, Abbas Shojaee, Feb. 2010

Use Case Model

Describes specific situations in which communication between healthcare entities is needed.

BUMS, Abbas Shojaee, Feb. 2010

BUMS, Abbas Shojaee, Feb. 2010

Information Model

A detailed and precise definition for the information from which all data content of HL7 messages are drawn. Classes, Attributes, and Relationships

State Transition Models for certain selected classes. Data Types and Constraints.

Documented in the Reference Information Model, the Domain Information Model, and the Message Information Model

BUMS, Abbas Shojaee, Feb. 2010

Root of all information models. Provides a static view of the information. A HL7-wide common reference model that is result of the combined consensus view of information and integrates all Technical Committees domain views. HL7 development methodology calls for creation of small subset of the RIM - called Domain specific Information Model or DIM and incremental refining to achieve Problem-area-specific design models

BUMS, Abbas Shojaee, Feb. 2010

Foundation Classes
Acts Entities Roles

Communication Infrastructure
Core Infrastructure Message Communications Control Structured Documents

BUMS, Abbas Shojaee, Feb. 2010

BUMS, Abbas Shojaee, Feb. 2010

Interaction Model

Specifies all Trigger Events and Message Flows. Specifies the Application Roles.

BUMS, Abbas Shojaee, Feb. 2010

Each Interaction consists of:


Trigger event
Initiators of Interactions.

Message ID
Each interaction sends one particular message

Sender role
Receiver role
When trigger event detected, message is sent Receiver responsibility

BUMS, Abbas Shojaee, Feb. 2010

Encounter_manager : AR_Encounter_

Encounter_tracker : AR_Encounter_

Encounter_archivist : AR_Encounter_

1: schedule_encounter

Application Role 2: delete_scheduled_encounter identifies an information management responsibility for one of the subject classes. 3: admit_patient Responsibilities typically are: Creator, Manager, Tracker and Archivist. 4: admit_patient

Interactio n
BUMS, Abbas Shojaee, Feb. 2010

5: admit_patient

Healthcare applications are assumed to take on one or more application roles.

Interaction ID Interaction Name Trigger Event Name Event Dependency

PA231 Send Registration to Trackers Patient Registers for Encounter Account must be in the unregistered or pregistered state A01 Encounter Manager Encounter Tracker

PA232 Send Registration to Archivists Patient Registers for Encounter Account must be in the unregistered or pregistered state A02 Encounter Manager Encounter Archivist

Message ID Sender Receiver Receiver Responsibility

BUMS, Abbas Shojaee, Feb. 2010

BUMS, Abbas Shojaee, Feb. 2010

Message Model

Domain Information Model Reference Information Model


Person_name_for_IHCP 1 Person_as_IHCP cd : CV has purpose_cd : CV phon : TIL 1 type_cd : CV nm : PN is_for takes_on_role_of 1 is_participant_for 0..* Encounter_practitioner is_associated_with participation_type_cd 1..* Exactly one occurrence 1 participates_as has_as_participant 1 1 Individual_healthcare_practitioner Patient_encounter is_a_role_of id : TII id : TII s tatus_cd : CV encounter_classification_cd : CV Person_as_Patient 0..1 is_the_primary_provider_for start_dttm birth_dttm : TS involves end_dttm birthplace_addr : ST 0..* has_a_primary_provider expected_insurance_plan_qty : NM 1 deceased_dttm : TS 1 first_similar_illness_dttm Patient education_level_cd : CV 1..1 id : TII gender_cd : CV takes_on_role_of has 1 s tatus_cd : CV marital_s tatus_cd : CV 1..1 newborn_baby_ind race_cd : CV is_involved_in is_a_role_of multiple_birth_ind religious_affiliation_cd : CV Inpatient_encounter organ_donor_ind phon : TIL 1 actual_days_qty 1..* has Patient_admission estimated_days_qty is_for admission_dttm Person_name_for_Patient Patient_billing_account admission_reason_cd 1 nm : PN admission_referral_cd id : TII is_preceded_by effective_dt : TS admission_source_cd 1 s tatus_cd : CV 0..1 cd : CV admission_type_cd billing_s tatus_cd : CV preceded purpose_cd : CV pre_admit_test_ind patient_financial_class_cd : CV belongs_to termination_dt : TS readmission_ind price_schedule_id : TII type_cd : CV

Use Case Model


Hierarchical
Message

Interaction Model

Description

Message Information Model

BUMS, Abbas Shojaee, Feb. 2010

The RIM must first be refined by subsetting and constraining it


Create a MIM with RIM classes needed Develop an R-MIM from these classes

Collection of classes with some constraints Collection of attributes and associations to support the R-MIM

BUMS, Abbas Shojaee, Feb. 2010

Person_name effective_dt cd nm purpose_cd termination_dt type_cd 0..* is_for 1 has

Stakeholder addr credit_rating_cd email_address_txt phon type_cd real_id : SET<RWII> id : SET<II>

participates_as_primary_in 0..* has_as_primary_participant 1 0..* participates_as_secondary_in 1 has_as_secondary_participant

Stakeholder_affiliation affiliation_type_cd desc effective_dt termination_dt

has_as_a_subdivision 0..1 Person Organization 0..* is_a_subdivision_of organization_name_type_cd organization_nm standard_industry_class_cd

Fewer attributes
BUMS, Abbas

birth_dttm birthplace_addr citizenship_country_cd confidentiality_constraint_cd deceased_dttm deceased_ind disability_cd 0..* participates_as_primary_in education_level_cd Stakeholder Person_name ethnic_group_cd 1..1 has_as_primary_participant Stakeholder_affiliation addr : ST nm : ST administrative_gender_cd participates_as_secondary_in email_address_txt : TEL 0..* affiliation_type_cd : CD type_cd : CD language_cd id : SET<II> 1..1 has_as_secondary_participant marital_status_cd military_branch_of_service_cd 0..* is_for military_rank_nm military_status_cd nationality_cd race_cd religious_affiliation_cd has_as_a_subdivision 1..1 student_cd has very_important_person_cd 0..1 status_cd Person Organization 0..* ambulatory_status_cd organization_nm : ST id education_level_cd : CD is_a_subdivision_of hispanic_ind birth_order_nbr 1..1 1..1 proposes 1..1 living_arrangement_cd has_as_role sponsors living_dependency_cd multiple_birth_ind Shojaee, Feb. 20100..* is_role_of organ_donor_ind

RIM content

MIM content

(a proper subset of the RIM)

Constrain cardinality on Associations Constraints on Attributes

Classes are duplicated for different uses May modify the Inheritance structure
Some specializations may subsume the generalization Always inherit downwards to specializations

Some may be left out Sub-components may be individually constrained

BUMS, Abbas Shojaee, Feb. 2010

Person_name nm : ST type_cd : CD 0..* is_for

0..* participates_as_primary_in Stakeholder 1..1 has_as_primary_participant Stakeholder_affiliation addr : ST email_address_txt : TEL participates_as_secondary_in 0..* affiliation_type_cd : CD id : SET<II> 1..1 has_as_secondary_participant

1..1 has Person education_level_cd : CD 1..1 has_as_role 0..* is_role_of Voting_member draft_level_voting_ind : BL 1..1 standard_level_voting_ind : BL casts sponsors

has_as_a_subdivision 0..1 Organization 0..* organization_nm : ST is_a_subdivision_of 1..1 1..1 proposes

Proposed_item ballot_period_tmr : IVL<TS> proposed_by content_txt : ED standard_level_ind : BL 0..* 1..1 receives_votes

0..* sponsored_by Individual_representative dues_current_ind : BL Organizational_representative

cast_by

BUMS, Abbas Shojaee, Feb. 2010

Ballot 0..* comments_txt : ST dttm : TS vote_cd : CV

votes_on 0..*

MIM

Person_name is_for nm : ST type_cd : CD 0..1 is_for 0..*

has_as_secondary_participant 0..* 0..* participates_as_secondary_in has_as_primary_participant

Stakeholder_affiliation affiliation_type_cd : CD

1..1 has 1..1 Person_as_Committee_contact email_address_txt : TEL participates_as_primary_in has_as_a_subdivision 0..1 1..1 Organization_as_Committee organization_nm : ST 1..1 0..* is_a_subdivision_of

has

1..1

Person_as_Voter education_level_cd : CD email_address_txt : TEL 1..1 has_as_role is_role_of 0..* Voting_member draft_level_voting_ind : BL 1..1 standard_level_voting_ind : BL casts

proposes

proposed_by Organization_as_HL7_member organization_nm : ST email_address_txt : TEL sponsors 0..1 0..* Proposed_item ballot_period_tmr : IVL<TS> content_txt : ED standard_level_ind : BL 1..1 receives_votes

Individual_representative dues_current_ind : BL

0..* sponsored_by Organizational_representative

cast_by

BUMS, Abbas Shojaee, Feb. 2010

votes_on Ballot 0..* 0..* comments_txt : ST dttm : TS vote_cd : CV

RMIM

Person_name is_for nm : ST type_cd : CD 0..1

has_as_secondary_participant 0..* 0..* participates_as_secondary_in has_as_primary_participant

Stakeholder_affiliation affiliation_type_cd : CD

is_for

0..*

1..1 has 1..1 Person_as_Committee_contact email_address_txt : TEL

has

1..1

Person_as_Voter education_level_cd : CD email_address_txt : TEL 1..1 has_as_role is_role_of 0..* Voting_member draft_level_voting_ind : BL 1..1 standard_level_voting_ind : BL casts

participates_as_primary_in has_as_a_subdivision 0..1 1..1 Organization_as_Committee organization_nm : ST 1..1 0..*

2a

is_a_subdivision_of

proposes

proposed_by Organization_as_HL7_member organization_nm : ST email_address_txt : TEL sponsors 0..1 0..* Proposed_item ballot_period_tmr : IVL<TS> content_txt : ED standard_level_ind : BL

1..1 receives_votes

Individual_representative dues_current_ind : BL

0..* sponsored_by Organizational_representative

cast_by

BUMS, Abbas Shojaee, Feb. 2010

votes_on Ballot 0..* 0..* comments_txt : ST dttm : TS vote_cd : CV

BUMS, Abbas Shojaee, Feb. 2010

BUMS, Abbas Shojaee, Feb. 2010

A method of encoding and sending HL7 messages. XML represents one of several ITS to be developed

BUMS, Abbas Shojaee, Feb. 2010

MSH|^~\&|LABGL1||DMCRES||199812300100||ORU^R01|LABGL1199510221838581|P|2.3 |||NE|NE PID|||6910828^Y^C8||Newman^Alfred^E||19720812|M||W|25 Centscheap Ave^^ Whatmeworry^UT^85201^^P||(555)777-6666|(444)677-7777||M||773789090 OBR||110801^LABGL|387209373^DMCRES|18768-2^CELL COUNTS+DIFFERENTIAL TESTS (COMPOSITE)^LN|||199812292128||35^ML|||||||IN2973^Schadow^Gunther^^^^MD^UPIN ||||||||||^Once||||||CA20837^Spinosa^John^^^^MD^UPIN OBX||NM|4544-3^HEMATOCRIT (AUTOMATED)^LN||45||39-49 ||||F|||199812292128||CA20837 OBX||NM|789-8^ERYTHROCYTES COUNT (AUTOMATED)^LN||4.94|10*12/mm3 |4.30-5.90||||F|||199812292128||CA20837

BUMS, Abbas Shojaee, Feb. 2010

<ClinicalDocument xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > <id root="" /> <code code="11488-4" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" /> <statusCode code="completed" /> <effectiveTime value="20030506230256" /> <confidentialityCode code="N" /> <component> <documentBody> <component> <documentSectionEvent> <code code="10164-2" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" /> <text /> </documentSectionEvent> </component> <component> <documentSectionEvent> <code code="11384-5" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" /> <text /> <component> <observation> <id root="2.16.840.1.113883.9876.368.2" /> ..
BUMS, Abbas Shojaee, Feb. 2010

<act classCode=ACT moodCode=> <id root=1.3.6.1.4.1.12009.3 extension=A1234/> <code code=... codeSystem=2.16.840.1.113883.6.1/> <participant typeCode=> <participant classCode=ROL> <id root=1.3.6.1.4.1.12009.4 extension=1234567-8/> <code code= codeSystem=2.16.840.1.113883.6.21/> <playingEntity classCode=ENT> <name>...</name> </playingEntity> <scopingEntity classCode=ENT> <name>...</name> </scopingEntity> </participant> </participant> <sourceOf typeCode=REL> <target classCode=ACT> <id root=1.3.6.1.4.1.12009.3 extension=A1235/> </target> </sourceOf> </act>
BUMS, Abbas Shojaee, Feb. 2010
67

Organization
classCode *: <= OR G de te r m ine r Code *: <= INSTANCE name: BAG<EN> [0..*] standardIndustryClassCode: CE CWE [0..1] <= OrganizationIndustryClass 0..1 providerOrganization

Patient

0..* patient

ObservationEvent
classCode *: <= OBS m oodCode *: <= EVN id*: II [1..1] code*: CD CWE [1..1] <= Ob servationType text: ED [0..1] statusCode*: CS CNE [1..1] <= completed effectiveTime*: IVL<TS> [1..1] confidentialityCode: SET<CE> CWE [0..*] <= Confidentiality

classCode *: <= PAT 0..* patient id: SET<II> [0..*] subject code: CE CWE [0..1] <= RoleCode addr: BAG<AD> [0..*] type Code *: <= SBJ telecom: BAG<TEL> [0..*] awarenessCode: CE CWE [0..1] <= TargetAwareness statusCode: SET<CS> CNE [0..*] <= RoleStatus effectiveTime: IVL<TS> [0..1] confidentialityCode: CE CWE [0..1] <= Confidentiality veryImportantPersonCode: CE CWE [0..1] <= PatientImportance 0..* healthCareProvider 0..1 patientPerson

component
type Code *: <= C OMP 0..* observationEvent

Person
classCode *: <= PSN de te r m ine r Code *: <= INSTANCE id: SET<II> [0..*] code: CE CWE [0..1] <= EntityCode name: BAG<EN> [0..*] riskCode: CE CWE [0..1] <= EntityRisk handlingCode: CE CWE [0..1] <= EntityHandling administrativeGenderCode: CE CWE [0..1] <= AdministrativeGender birthTime: TS [0..1] deceasedTime: TS [0..1] maritalStatusCode: CE CWE [0..1] <= MaritalStatus educationLevelCode: CE CWE [0..1] <= EducationLevel disabilityCode: SET<CE> CWE [0..*] <= PersonDisab ilityType livingArrangementCode: CE CWE [0..1] <= LivingArrangement religiousAffiliationCode: CE CWE [0..1] <= ReligiousAffiliation raceCode: SET<CE> CWE [0..*] <= Race ethnicGroupCode: SET<CE> CWE [0..*] <= Ethnicity

ObservationEvent
classCode *: <= OBS m oodCode *: <= EVN id*: II [1..1] code*: CD CWE [1..1] <= Ob servationType statusCode: CS CNE [1..1] <= completed effectiveTime*: IVL<TS> [0..1] confidentialityCode: SET<CE> CWE [0..*] <= Confidentiality

BUMS, Abbas Shojaee, Feb. 2010

68

<observationEvent classCode=OBS moodCode=EVN> <id root=1.3.6.1.4.1.12009.3 extension=A1234/> <code code=... codeSystem=2.16.840.1.113883.6.1/> <subject typeCode=> <patient classCode=ROL> <id root=1.3.6.1.4.1.12009.4 extension=1234567-8/> <code code= codeSystem=2.16.840.1.113883.6.21/> <patientPerson classCode=PSN> <name><given>John</given><family>Doe</family></name> </patientPerson> <providerOrganization classCode=ORG> <name>St., Josephs Hospital</name> </providerOrganization> </patient> </subject> <component typeCode=REL> <observationEvent classCode=ACT> <id root=1.3.6.1.4.1.12009.3 extension=A1235/> </observationEvent> </component> </observationEvent>

BUMS, Abbas Shojaee, Feb. 2010

69

BUMS, Abbas Shojaee, Feb. 2010

BUMS, Abbas Shojaee, Feb. 2010

BUMS, Abbas Shojaee, Feb. 2010

Clinical Document Architecture

BUMS, Abbas Shojaee, Feb. 2010

CDA: document model using XML tags RIM: defines the tags Why CDA is needed:
Difference between documents and databases Documents carry meta data persistence, stewardship, authentication, wholeness, and human readability.

CDA evolution history

BUMS, Abbas Shojaee, Feb. 2010

74

exchange model for clinical documents


Discharge Summary, Imaging Report, Admission & Physical, Pathology Report

Based on XML, HL7, RIM and coded vocabularies, CDA makes documents both
Machine readable Human readable

BUMS, Abbas Shojaee, Feb. 2010

75

Users set their own level of compliance Minimal CDA: High end CDA:

small number of XML-encoded metadata fields Body in pdf, doc or scanned image file

RIM Controlled vocabulary (LOINC, SNOMED, ICD,

BUMS, Abbas Shojaee, Feb. 2010

76

CDA structure

BUMS, Abbas Shojaee, Feb. 2010

Limitations of Version 2.3 Benefits of Version 3 Version 3 Statement of Principles Goals Mission

BUMS, Abbas Shojaee, Feb. 2010

Complex integration: at least 2-4 months to install HL7 interfaces

Problem Honest misunderstanding of specifications

Cause Different implicit information models


No vocabulary to describe conformance concepts

Misleading conformance claims

BUMS, Abbas Shojaee, Feb. 2010

79

Unmeasurable progress Unpredictable results Metastasizing optionality

Outcome...

Past V2 Process
Patient Care ADT/ Financ e

MnM
Orders Control / Home Health
80

BUMS, Abbas Shojaee, Feb. 2010

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

BUMS, Abbas Shojaee, Feb. 2010

81

Reduces optionality: results in more specific messages Uncovers hidden assumptions about application boundaries

Facilitates defining clear, fine-grained, conformance claims

HL7 V3.0 Certified

BUMS, Abbas Shojaee, Feb. 2010

82

Deals with complexity of the HC environment:


Facilitates

integration of heterogeneous systems


best-of-breed

Increases choices of innovative solutions

Provides support for legacy systems Allows reliable verification of vendors conformance claims

BUMS, Abbas Shojaee, Feb. 2010

24, 2000

83

Provides improved protocol for interconnecting heterogeneous systems installation effort

Reduces

reduces site-specific negotiations


simplifies interface programming

Promotes

vendor specialization by allowing segmentation of product lines into niche market spaces
84

BUMS, Abbas Shojaee, Feb. 2010

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

BUMS, Abbas Shojaee, Feb. 2010

85

Explicit Scope, Target Users Support for Legacy Systems Loosely Coupled Systems Internationalization Compatibility with Versions 2.X (limited) Management - ANSI and by-laws Uniform Trigger Event Model Information System Role

BUMS, Abbas Shojaee, Feb. 2010

86

Conformance Claims The Version 3 Development Process Project Scope Version 3 Methodology - MDF Quality Assurance Processes Process Support Confidentiality of Patient Information Authenticated Authorization for Services Security, Privacy, and Integrity

BUMS, Abbas Shojaee, Feb. 2010

87

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

BUMS, Abbas Shojaee, Feb. 2010

88

Chapters 2 and 8

Common Specs

ChapterChapterChapterSpecific Specific Specific Specs Specs Specs

Chapters 3, 4, 6, ...

Segment s and Fields

Trigger Event and Message s

BUMS, Abbas Shojaee, Feb. 2010

89

Trigger events
Actions or occurrences

Messages
Information content

Segments
Repeating structures

Data elements
Data representation

BUMS, Abbas Shojaee, Feb. 2010

90

HL7 Referenc e Model Commo n Specs

Chapter Specific Specs


*Future Considerati on

Use Case Model

Information Model

Interaction Model

Message Model

Implementable Message Implementable Specification Implementable Message 2-nd Order Message Specification 1 choice of XML/ER7/ Specification 0-n Drug OLE/CORBA 0-1 Nursing EDIFACT*
91

BUMS, Abbas Shojaee, Feb. 2010

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 to to to improve the internal consistency of HL7 provide sound semantic definitions enable future architectures produce an evolution not a revolution

Done by applying MODELING to the HL7 process


92

BUMS, Abbas Shojaee, Feb. 2010

By demanding Dispense Manage Perform Lab Review Abstractions: analysis of the Medications Tests Utilization Version Care 2.x focused its requirements and Activities energies at the information (Use Case communication level and content, Version 3 Model) covered the other assures Account Encounter Provider Patient abstractions only loosely in Order Objects consistency in and the specifications. (Information enhances the value Model) of the resulting messages. HL7 message HL7 message Communicatio n (Interaction
and Message Models)
BUMS, Abbas Shojaee, Feb. 2010

Finance

ADT

Pharmacy
93

Use case model


Hierarchy of tasks and actors

Message design model


Refined Message Information Model (R-MIM) Abstract message definitions (HMDs)

Interaction model
Trigger events, abstract messages & application profiles

Vocabulary

Information model
Classes, relationships, states, and lifecycles

Domain definitions Representations and mappings

Implementation

Implementation Technology Specification (ITS)


94

BUMS, Abbas Shojaee, Feb. 2010

Concepts
Modeling

January 24, 2000

1999, 2000 Health Level 7

95

Process:
Method: Model: subject
Operation

Activities leading to the orderly


construction of the models An approach to problem solving Abstract representation of a

Attributes (Data)
Operation

Object:

Domain specific concept


1999, 2000 Health Level 7

BUMS, Abbas Shojaee, Feb. 2010

January 24, 2000

96

Domain Analysis

Requirements Analysis

Release 3.0

Message Design
BUMS, Abbas Shojaee, Feb. 2010
1999, 2000 Health Level 7

Message Specification
January 24, 2000 97

Decomposition
Divide-and-conquer

Abstraction
Chunking the information

Hierarchy
Increasing semantic content of individual chunks of information through reuse

BUMS, Abbas Shojaee, Feb. 2010

1999, 2000 Health Level 7

January 24, 2000

98

Applying analysis techniques leads to solutions to integrate components Modeling provides the framework for the analysis steps and products Object Oriented Analysis and Modeling form the basis of the standard techniques adopted for Version 3

BUMS, Abbas Shojaee, Feb. 2010

1999, 2000 Health Level 7

January 24, 2000

99

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 merged The HL7 standard message specification will be derived from the models Models are expressed in UML

BUMS, Abbas Shojaee, Feb. 2010

1999, 2000 Health Level 7

January 24, 2000

10 0

Process Overview
Model Deliverables and Phases Generation of Messages

Process in Detail
Methodology Activities Coordination of Parallel Committee Projects (Harmonization)

BUMS, Abbas Shojaee, Feb. 2010

1999, 2000 Health Level 7

January 24, 2000

10 1

Tasks Deliverables Phases

January 24, 2000

1999, 2000 Health Level 7

102

Analysis
Requirements Analysis Domain Analysis

Use Case Model (UCM) Information Model (RIM & DIM) Vocabulary Domain Specification

Design

Component and Object Interaction Model (IM) Message Information Model Interaction Design (MIM) Message Design

Voting and Publishing Implementation Guide


Technology

Hierarchical Message Description (HMD)

BUMS, Abbas Shojaee, Feb. 2010

Implementation Technology 1999, 2000 Health Level 7 January 24, 2000

10 3

Use Case Model

Captures healthcare requiremen

Defines scope for TSC approval


Specifies data and its

Information Model

2-nd Order 1 choice of 0-n Drug 0-1 Nursing

semantics

Specifies major state

Interaction Model

transitions Defines information flows Specifies vocabulary for Defines communication roles domains Forms basis for conformance c

Defines message contents

Message Specification Apply constraints to the


information model and
1999, 2000 Health Level 7

BUMS, Abbas Shojaee, Feb. 2010

vocabulary

January 24, 2000

10 4

Is a Methodology for building HL7 models Is a description for defining HL7 standard messages Full instruction book for HL7 participants Basis for member training Five years in development Continues to evolve as we gain experience

BUMS, Abbas Shojaee, Feb. 2010

1999, 2000 Health Level 7

January 24, 2000

10 5

Analysis
Requirements Analysis Domain Analysis

Design
Interaction Design Message Design

Voting
Approval

2-nd Order 1 choice of 0-n Drug 0-1 Nursing


Domain Information Model (DIM) Hierarchical Message Descriptions (HMD)

Use Case Model (UCM)


RIM

Interaction Model (IM)

Ballots

BUMS, Abbas Shojaee, Feb. 2010

Reference Model Repository


1999, 2000 Health Level 7

January 24, 2000

10 6

Develop Scope Create Use Cases

Information Model Use Case Model


Spec DIM Spec Class Diagram State Diagram UCM Spec Use Case Diagram Spec

Draw initial contents from RIM


Model new concepts

Identify Actors & Events


Define Trigger Events Define Application Roles Define Interactions Create Conformanc e Claims

Harmonize with RIM

Interaction Model
Spec

Message Design

Develop Message Information Mode Develop Message Object Diagram Specify HMD

Inter Spec Interaction Diagram

2-nd Order h//mt:50d 1 choice of 0-n Drug 0-1 Nursing

BUMS, Abbas Shojaee, Feb. 2010

1999, 2000 Health Level 7

January 24, 2000

10 7

Reference Information Model

Domain Information Model

Use Case Model

Interaction Model
Message Information Model

Person_name_for_IHCP 1 Person_as_IHCP cd : CV has purpose_cd : CV phon : TIL 1 type_cd : CV nm : PN is_for takes_on_role_of 1

is_participant_for

0..*

Encounter_practitioner is_associated_with participation_type_cd 1..* Exactly one occurrence

1 participates_as 1 Individual_healthcare_practitioner is_a_role_of id : TII

has_as_participant

Patient_encounter id : TII s tatus_cd : CV encounter_classification_cd : CV Person_as_Patient 0..1 is_the_primary_provider_for start_dttm birth_dttm : TS involves end_dttm birthplace_addr : ST 0..* has_a_primary_provider expected_insurance_plan_qty : NM 1 deceased_dttm : TS 1 first_similar_illness_dttm Patient education_level_cd : CV 1..1 id : TII gender_cd : CV takes_on_role_of has 1 s tatus_cd : CV marital_s tatus_cd : CV 1..1 newborn_baby_ind race_cd : CV is_involved_in is_a_role_of multiple_birth_ind religious_affiliation_cd : CV Inpatient_encounter organ_donor_ind phon : TIL 1 actual_days_qty 1..* has Patient_admission estimated_days_qty is_for admission_dttm Person_name_for_Patient Patient_billing_account admission_reason_cd 1 nm : PN admission_referral_cd id : TII is_preceded_by effective_dt : TS admission_source_cd 1 s tatus_cd : CV 0..1 cd : CV admission_type_cd billing_s tatus_cd : CV preceded purpose_cd : CV pre_admit_test_ind patient_financial_class_cd : CV belongs_to termination_dt : TS readmission_ind price_schedule_id : TII type_cd : CV

Domain Specification Database

Hierarchical Message Description

Common Message Element Types


1999, 2000 Health Level 7 January 24, 2000 10 8

BUMS, Abbas Shojaee, Feb. 2010

Implementation Technology Specifications

"Send as ASCII string in XML format"

Hierarchical Message Definition

"Discontinue pharmacy order"

ITS

Data

HL7 Message Creation

Message Instance

HL7 Message Parsing

Data

HL7-Conformant Application

HL7-Conformant Application
10 9

BUMS, Abbas Shojaee, Feb. 2010

1999, 2000 Health Level 7

January 24, 2000

Internal consistency - enforced in models Sound definitions - captured in a repository Enables variety of implementation technologies
ranging from ASCII to ORBs and EDIFACT to XML

Eliminates rampant optionality in the messages


reduces implementation effort

Application roles are a basis for component functional specifications Provides verifiable conformance claims

BUMS, Abbas Shojaee, Feb. 2010

1999, 2000 Health Level 7

January 24, 2000

11 0

Jacobson, I. Et Al, Object-Oriented Software Engineering: A Use Case Driven Approach, Addison-Wesley, Reading, MA, 1994. Rumbaugh, J. Et Al, Object-Oriented Modeling and Design, Prentice Hall International, Englewood Cliffs, NJ, 1991. Booch, G., Object-Oriented Analysis and Design with Applications, 2nd ed., The Benjamin/Cummings Publishing Company, Inc., Redwood City, CA, 1994.

BUMS, Abbas Shojaee, Feb. 2010

1999, 2000 Health Level 7

January 24, 2000

11 1

White, I., Using the Booch Method. A Rational Approach, The Benjamin/Cummings Publishing Company, Inc. Redwood City, CA, 1994. M. Fowler, UML Distilled. Applying the Standard Object Modeling Language, Addison-Wesley, Reading, MA, 1997. Vaskevitch, D., Client/Server Strategies, IDG Books, San Mateo, CA, 1993. Taylor, D.A., Object-Oriented Technology: A Managers Guide, Addison-Wesley, Reading, MA, 1990. Taylor, D.A., Business Engineering with Object Technology, John Wiley & Sons, Inc.. New York, NY, 1995.

BUMS, Abbas Shojaee, Feb. 2010

1999, 2000 Health Level 7

January 24, 2000

11 2

Object Magazine, SIGS Publication Distributed Object Computing (DOC) Journal of Object-Oriented Programming (JOOP)

BUMS, Abbas Shojaee, Feb. 2010

1999, 2000 Health Level 7

January 24, 2000

11 3

BUMS, Abbas Shojaee, Feb. 2010