Introduction to hl7 v3

July 14, 2015 Page: 1 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
HL7 v3 History and Rationale
July 14, 2015

SESSION OVERVIEW
• ABOUT ME
• SCOPE AND LEARNING OBJECTIVES
• COURSE AGENDA
• HL7 V3 HISTORY AND RATIONALE
• Q&A

About Me
• I have been, and continue to be,
an active member of HL7 since
1991.
• I currently co-chair the HL7
Modeling and Methodology
Workgroup.
• My HL7 History:
o Chaired the HL7 Education
Workgroup from 1996 to 2010.
o Received the HL7 volunteer of
the year award in 1997
o Served on the HL7 Board of
Directors from 2000 to 2005
o Board appointed member of the
HL7 ARB since 2001and ARB
modeling facilitator since 2012
o Received the HL7 Fellowship
award in 2012
AbdulMalik Shakir
President and Chief Informatics Scientist
Hi3 Solutions | your healthcare standards conformance partner
3500 West Olive Ave, Suite # 300, Burbank, CA 91505.

Scope and Learning Objectives
• Scope - an introduction to HL7’s health information
exchange standards:
 HL7 Family of Standards
 HL7 v2 Messaging (v2)
 HL7 v3 Messaging (v3)
 HL7 v3 Clinical Document Architecture (CDA)
 HL7 Compliance and Conformance Specification
• Learning Objectives –
 To better understand the business case for HL7,
 Gain familiarity with the full suite of HL7 standards,
 Receive an in-depth overview of the HL7 information exchange standards

Course Agenda
July 13, 2015 July 14, 2015
• 09:00 – 09:30 Introductions and
Course Overview
• 09:30 – 10:30 Health Level Seven
and the HL7 Family of
Standards
 10:30 – 10:45 Break
• 10:45 – 12:00 HL7 v2 Abstract
Message Definition
 12:00 - 12:30 Break
• 12:30 – 02:00 HL7 v2 Message
Construction Rules
 02:00 - 02:15 Break
• 02:15 – 03:30 Local Extensions and
inter-version Compatibility
• 03:30 – 04:00 HL7 v2 Retrospective
• 09:00 – 09:30 HL7 v3 History and
Rationale
• 09:30 – 10:30 HL7 v3 Development
Frameworks and
Architectures
 10:30 – 10:45 Break
• 10:45 – 12:00 HL7 v3 Messaging Artifacts
 12:00 - 12:30 Break
• 12:30 – 02:00 HL7 v3 Clinical Document
Architecture
 02:00 - 02:15 Break
• 02:15 – 03:30 HL7 Standards Compliance
and Profile Conformance
• 03:30 – 04:00 HL7 v3 Retrospective

HL7 V3 HISTORY AND RATIONALE

International
National
Inter-Enterprise
Enterprise
Institution
Ever-Increasing Circles
Source: Gartner

HL7 v3 Messaging
 HL7 Version 3 (V3) introduced a common Reference
Information Model (RIM), data type model and set of
vocabulary as well as a formal standards
development methodology.
 In addition, it introduced the use of "documents" as
an alternative architecture for sharing healthcare
information. However, the term "V3" is typically used
to refer to "V3 messaging".
 The data types used as a basis for V3 have also
been adopted by ISO as ISO 21090. The HL7 RIM
has also been adopted as an ISO standard.

World-class System Interface Standards
 The HL7 v3.0 messaging standard is not a replacement for
HL7 v2.0; it is an alternative specification providing enhanced
capabilities.
 New versions of HL7 v2.x will continue to be developed for as
long as it continues to address the needs of HL7 members
and the healthcare community in general.
 HL7 v3.0 uses a model driven methodology and includes
specifications for messaging and non-messaging standards.
 The community of users served by HL7 is continually
increasing in size. As the size of the community
increases so does the complexity and the diversity of
their needs.
 HL7 v3.0 increases the quality and reduces the variability
in HL7 standards enabling it to address the more
complex and diverse needs of the HL7 members.

HL7 Version 3.0: What and Why
 Version 3.0 is a fundamental shift in the methodology HL7
uses to develop its standards specifications.
 Version 3.0 is a model-driven methodology based upon the
Object Management Group’s Unified Modeling Language
(UML).
 Version 3.0 uses datatype specifications, vocabulary
specifications, and a Reference Information Model (RIM), to
derive the information component of V3 message
specifications.
 Version 3.0 reduces optionality, maximizes reuse, and
increases consistency in HL7 message specifications.
 Version 3.0 improves the quality of HL7 message
specifications and includes support for conformance
validation.
 Version 3.0 enables HL7 implementers to leverage emerging

Difficulties with the Existing HL7 v2.x Process
 The HL7 V2.x development process is entirely ad hoc.
There is no explicit methodology.
 Members receive no formal guidance in constructing
messages. Trigger events and data fields are described
solely in natural language.
 The structural relationships among data fields are not
clear. Segments are reused in many messages and
message definitions are reused for many trigger events.
 In order to accommodate this extensive reuse, most data
fields are optional. Chapters are inconsistent in their use
of trigger events versus status codes.

Opportunities to Improve
 HL7 spent four years creating a methodology to adapt modern
analysis techniques from system building to message design.
 Initially, the HL7 Board of Directors chartered an independent task
force to establish the broad outline of the approach.
 In January 1996, the Technical Steering Committee (TSC) agreed to
adopt the main features of the approach and take over its
management.
 Planning work continued in the Modeling and Methodology Work
Group and the Implementation/Conformance Work Group.
 At the completion of V2.3, in the spring of 1997, the HL7 Work
Groups all began to use the V3 process.

What's New with HL7 V3
 HL7 employs a completely new development approach with V3, an
Object Oriented approach that is model and repository-based.
 This OO approach is supported with trained facilitators, formal
education classes, and computerized tools.
 This approach leads to increased detail, clarity and precision of the
specification and finer granularity in the ultimate message.
 HL7 isn't just Level 7 any more! HL7 standard developers realized it
was necessary to include other levels of the ISO OSI Model.
 Today, Work Groups exist for XML, Security & Accountability, Service
Oriented Architecture, Clinical Document Architecture, and Restful
Services Resource Definitions.

Questions

Hi3 Solutions
3500 W. Olive Ave, Suite
300
Burbank, CA 91505
ww.hi3solutions.com +1 800 918-
6520

HL7 v3 Development
Frameworks and Architectures

SESSION OVERVIEW
 HL7 V3 MESSAGE DEVELOPMENT FRAMEWORK
(MDF)
 HL7 DEVELOPMENT FRAMEWORK (HDF)
 SERVICES AWARE INTEROPERABILITY FRAMEWORK
(SAIF)
 HL7 V3 REFERENCE MODELS

HL7 v3 Message Development
Framework

The MDF Methodology Overview

HL7 V3 Message Design Information Models
 RIM: Reference Information Model
 D-MIM: Domain Message Information Model
 R-MIM: Refined Message Information Model
 HMD: Hierarchical Message Definition
RIM
Restrict
R-MIM
Serialize
HMD
D-MIM
Derive

HL7 V3 Message Development Framework
Use Case Modeling
Interaction Modeling
Message Design
Information Modeling
RIM
Restrict
R-MIM
Serialize
HMD
Restrict
Message
Type
Example
Storyboard
Storyboard
Example
D-MIM
Derive
Application
Role
Sender Receiver
Trigger
Event
Triggers
Content
Interaction
References

HL7 V3 Message Development
Methodology: How
 Use Case Modeling
• Produce a storyboard example
• Generalize the storyboard example into a storyboard
 Information Modeling
• Define classes, attributes, datatypes, and relationships
• Define vocabulary domains, code systems, and value sets
• Define states, trigger events, and transitions
 Interaction Modeling
• Define application roles
• Define interactions
 Message Design
• Define D-MIM, CMETs, and R-MIMs
• Define HMD and Message Types

HL7 V3 Methodology (in plain language):
How
 What application interface problem are we trying to
solve?
 What application systems are within the scope of the
problem domain?
 What events initiate communication between
applications?
 What information needs to be communicated between
participating applications?
 What is the definition, format, and interrelationship of the
information to be communicated?
 How should the information to be communicated between
applications be structured and packaged?

HL7 V3 Message Design Information Models
RIM
Account
name : ST
balanceAmt : MO
currencyCode : CE
interestRateQuantity : RTO<MO,PQ>
allowedBalanceQuantity : IVL<MO>
DeviceTask
parameterValue : LIST<ANY>
DiagnosticImage
subjectOrientationCode : CE
Diet
energyQuantity : PQ
carbohydrateQuantity : PQ
FinancialContract
paymentTermsCode : CE
FinancialTransaction
amt : MO
creditExchangeRateQuantity : REAL
debitExchangeRateQuantity : REAL
InvoiceElement
modifierCode : SET<CE>
unitQuantity : RTO<PQ,PQ>
unitPriceAmt : RTO<MO,PQ>
netAmt : MO
factorNumber : REAL
pointsNumber : REAL
ManagedParticipation
id : SET<II>
statusCode : SET<CS>
Observation
value : ANY
interpretationCode : SET<CE>
methodCode : SET<CE>
targetSiteCode : SET<CD>
PatientEncounter
preAdmitTestInd : BL
admissionReferralSourceCode : CE
lengthOfStayQuantity : PQ
dischargeDispositionCode : CE
specialCourtesiesCode : SET<CE>
specialAccommodationCode : SET<CE>
acuityLevelCode : CE
Procedure
approachSiteCode : SET<CD>
PublicHealthCase
detectionMethodCode : CE
transmissionModeCode : CE
diseaseImportedCode : CE
SubstanceAdministration
routeCode : CE
doseQuantity : IVL<PQ>
rateQuantity : IVL<PQ>
doseCheckQuantity : SET<RTO>
maxDoseQuantity : SET<RTO>
substitutionCode : CE
Supply
quantity : PQ
expectedUseTime : IVL<TS>
WorkingList
ownershipLevelCode : CE
Container
capacityQuantity : PQ
heightQuantity : PQ
diameterQuantity : PQ
capTypeCode : CE
separatorTypeCode : CE
barrierDeltaQuantity : PQ
bottomDeltaQuantity : PQ
Device
manufacturerModelName : SC
softwareName : SC
localRemoteControlStateCode : CE...
alertLevelCode : CE
lastCalibrationTime : TS
LivingSubject
administrativeGenderCode : CE
birthTime : TS
deceasedInd : BL
deceasedTime : TS
multipleBirthInd : BL
multipleBirthOrderNumber : INT
organDonorInd : BL
ManufacturedMaterial
lotNumberText : ST
expirationTime : IVL<TS>
stabilityTime : IVL<TS>
Material
formCode : CE
NonPersonLivingSubject
strainText : ED
genderStatusCode : CE
Organization
addr : BAG<AD>
standardIndustryClassCode : CE
Person
addr : BAG<AD>
maritalStatusCode : CE
educationLevelCode : CE
raceCode : SET<CE>
disabilityCode : SET<CE>
livingArrangementCode : CE
religiousAffiliationCode : CE
ethnicGroupCode : SET<CE>
Place
mobileInd : BL
addr : AD
directionsText : ED
positionText : ED
gpsText : ST
Access
approachSiteCode : CD
targetSiteCode : CD
gaugeQuantity : PQ
Employee
jobCode : CE
jobTitleName : SC
jobClassCode : CE
salaryTypeCode : CE
salaryQuantity : MO
hazardExposureText : ED
protectiveEquipmentText : ED
LicensedEntity
recertificationTime : TS
Patient
confidentialityCode : CE
veryImportantPersonCode : CE
ActRelationship
typeCode : CS
inversionInd : BL
contextControlCode : CS
contextConductionInd : BL
sequenceNumber : INT
priorityNumber : INT
pauseQuantity : PQ
checkpointCode : CS
splitCode : CS
joinCode : CS
negationInd : BL
conjunctionCode : CS
localVariableName : ST
seperatableInd : BL
Act
classCode : CS
moodCode : CS
id : SET<II>
code : CD
negationInd : BL
derivationExpr : ST
text : ED
effectiveTime : GTS
activityTime : GTS
availabilityTime : TS
priorityCode : SET<CE>
confidentialityCode : SET<CE>
repeatNumber : IVL<INT>
interruptibleInd : BL
levelCode : CE
independentInd : BL
uncertaintyCode : CE
reasonCode : SET<CE>
languageCode : CE
0..n
1
outboundRelationship
0..n
source1
0..n
1
inboundRelationship
0..n
target
1
LanguageCommunication
languageCode : CE
modeCode : CE
proficiencyLevelCode : CE
preferenceInd : BL
Participation
typeCode : CS
functionCode : CD
negationInd : BL
noteText : ED
time : IVL<TS>
modeCode : CE
awarenessCode : CE
signatureCode : CE
signatureText : ED
performInd : BL
substitutionConditionCode : CE...
0..n
1
0..n
1
Entity
classCode : CS
determinerCode : CS
id : SET<II>
code : CE
quantity : SET<PQ>
name : BAG<EN>
desc : ED
existenceTime : IVL<TS>
telecom : BAG<TEL>
riskCode : CE
handlingCode : CE
1
0..n
1
0..n
RoleLink
typeCode : CS
effectiveTime : IVL<TS>
Role
classCode : CS
id : SET<II>
code : CE
negationInd : BL
addr : BAG<AD>
telecom : BAG<TEL>
certificateText : ED
quantity : RTO
positionNumber : LIST<INT>
0..n
1
0..n
1
0..n0..1
playedRole
0..n
player
0..1
0..n
0..1
scopedRole
0..n
scoper
0..1
0..n
1
outboundLink 0..n
source1
0..n
1
inboundLink
0..n
target1
HMD
D-MIM
PatientIncident
classCode*:<=ENC
moodCode*:<=EVN
id:[1..*](RegistNum)
code:CVCNE[0..1]<=ExternallyDefinedActCodes(PatientType)
statusCode:LIST<CS>CNE<=ActStatus(IDPHStatus)
activityTime:TS(EDDate)
Injury
classCode*:<=ACT
moodCode*:<=EVN
activityTime:TS(InjuryDate)
0..1pertinentInjury
typeCode*:<=PERT
pertinentInformation1
TraumaRegistryExport
(IDPH_RM00001)
DatacontentofHL7
messagesusedtoexport
datafromtheIDPHTrauma
Registry.
PatientPerson
classCode*:<=PSN
determinerCode*:<=INSTANCE
name:PN[0..1](*Name)
existenceTime:(Age)
administrativeGenderCode:CVCWE<=AdministrativeGender
(GenderID)
birthTime:(DateOfBirth)
addr:AD[0..1](AddressHome)
raceCode:CVCWE[0..1]<=Race(RaceID)
ethnicGroupCode:CVCWE[0..1]<=Ethnicity(EthnicID)
1..1patientPatientPerson
1..1providerTraumaParticipant
Patient
classCode*:<=PAT
id:II[0..1](MedicaRecordNum)
TraumaParticipant
classCode*:<=ORG
id:[1..1](HospitNum)
code:CVCWE[0..1]<=EntityCode
name:ON[0..1](HospitName)
statusCode:CSCNE[0..1]<=EntityStatus(ActiveFacili)
addr:AD[0..1](HospitCity)
1..1patient
typeCode*:<=SBJ
subject
InjuryLocation
classCode*:<=PLC
code:CVCWE[0..1]<=EntityCode(InjuryPlaceID)
addr:AD[0..1](AddressScene)
0..1playingInjuryLocation
Role
classCode*:<=ROL
1..1participant
typeCode*:<=LOC
location
InjuryRelatedObservation
classCode*:<=OBS
moodCode*:<=EVN
code:<=ExternallyDefinedActCodes
priorityCode:CVCWE[0..1]<=ActPriority
value:[0..1]
0..*pertinentInjuryRelatedObservation
typeCode*:<=PERT
sequenceNumber:INT[0..1](InjurySequen)
pertinentInformation
Procedure
classCode*:<=PROC
moodCode*:<=EVN
code:CVCWE<=ActCode(ICDCodeID)
activityTime:TS(ProcedDate)
0..*pertinentProcedure
typeCode*:<=PERT
0..1medicalStaff
typeCode*:<=PRF
performer
MedicalStaff
classCode*:<=PROV
id:II[0..1](MedicalStaffID)
0..1procedureLocation
typeCode*:<=LOC
location
ProcedureLocation
classCode*:<=SDLOC
code:<=RoleCode(ProcedLocateID)
PatientIncidentRelatedObservation
classCode*:<=OBS
moodCode*:<=EVN
code:<=ActCode
reasonCode:CVCWE[0..1]<=ActReason
value:ANY[0..1]
0..*pertinentPatientIncidentRelatedObservation
typeCode*:<=PERT
PatientTransfer
classCode*:<=TRNS
moodCode*:<=EVN
activityTime:IVL<TS>(DischaDatetoArriveDate)
reasonCode:CVCWE[0..1]<=TransferActReason(REASONTRANSFID)
1..1arrivalPatientTransfer
typeCode*:<=ARR
arrivedBy
0..*aRole
typeCode*:<=ORG
origin
0..1playingTraumaParticipant
aRole
classCode*:<=ROL
TransferRelatedObservation
classCode*:<=OBS
moodCode*:<=EVN
code:CVCWE<=ExternallyDefinedActCodes
value:PQ[0..1]
methodCode:CVCWE[0..1]<=ObservationMethod
1..*pertinentTransferRelatedObservation
typeCode*:<=PERT
1..1transferVehicle
typeCode*:<=VIA
via
1..1owningVehicleProvider
TransferVehicle
classCode*:<=OWN
id:II[0..1](VehiclNum)
code:<=RoleCode(VehiclLevelID)
VehicleProvider
classCode*:<=ORG
id:II[0..1](VehiclProvide)
code:<=EntityCode(MaxVehiclLevelID)
name:ON[0..1](VehiclProvidName)
HospitalVisit
classCode*:<=ENC
moodCode*:<=EVN
code:CVCWE<=ActCode(AdmitServicID)
activityTime:TS(DischaDate)
dischargeDispositionCode:CVCWE[0..1]
<=EncounterDischargeDisposition
1..1pertinentHospitalVisit
typeCode*:<=PERT
HospitalVisitRelatedObservation
classCode*:<=OBS
moodCode*:<=EVN
value:[0..1]
0..*pertinentHospitalVisitRelatedObservation
typeCode*:<=PERT
1..1admittingProvider
typeCode*:<=ADM
admitter
0..1healthCareMedicalStaffPerson
AdmittingProvider
classCode*:<=PROV
id:II[0..1](ADMITMEDICASTAFFID)
code:CVCWE<=RoleCode(StaffTypeID)
0..*hospitalVisitPhysician
typeCode*:<=RESP
time:TS
responsibleParty
HospitalVisitPhysician
classCode*:<=PROV
id:II[0..1]
MedicalStaffPerson
classCode*:<=PSN
name:PN[0..1](MedicaStaffName)
0..1licensedEntity
typeCode*:<=DST
destination
0..1subjectChoice
LicensedEntity
classCode*:<=LIC
id:II[0..1]
Choice
Facility
classCode*:<=ORG
id:
code*:CSCNE<=EntityCode"FAC"
name:
Hospital
classCode*:<=ORG
id:
code*:CSCNE<=EntityCode"HOSP"
name:
EmergencyDepartmentEncounter
classCode*:<=ENC
moodCode*:<=EVN
activityTime:IVL<TS>
dischargeDispositionCode:CVCWE<=EncounterDischargeDisposition
0..1pertinentEmergencyDepartmentEncounter
typeCode*:<=PERT
EmergencyDepartmentRelatedObservation
classCode*:<=OBS
moodCode*:<=EVN
text:
activityTime:TS
reasonCode:<=ActReason
value:[0..1]
targetSiteCode:CVCWE[0..1]<=HumanActSite
0..*pertinentEmergencyDepartmentRelatedObservation
typeCode*:<=PERT
0..*emergencyDepartmentPhysician
typeCode*:<=PRF
performer
0..1healthCareMedicalStaffPerson EmergencyDepartmentPhysician
classCode*:<=PROV
id:II[0..1]
code:CECWE[0..1]<=RoleCode(StaffTypeID)
PreHospitalEncounter
classCode*:<=ENC
moodCode*:<=EVN
id:II[0..1](crashNum)
0..1priorPreHospitalEncounter
typeCode*:<=PREV
predecessor
PreHosptialRelatedObservation
classCode*:<=OBS
moodCode*:<=EVN
value:ANY[0..1]
0..*pertinentPreHosptialRelatedObservation
typeCode*:<=PERT
1..1preHospitalVehicle
typeCode*:<=ParticipationType
participant
PreHospitalVehicle
classCode*:<=OWN
0..*emergencyDepartmentPhysicianAct
typeCode*:<=COMP
component
EmergencyDepartmentPhysicianAct
classCode*:<=ACT
moodCode*:<=EVN
code:CSCNE[0..1]<=ExternallyDefinedActCodes
activityTime*:TS[0..1]
component
0..*patientIncidentRelatedObservation
typeCode*:<=COMP
VehicleProvider
MedicalStaffPerson
TraumaParticipant
R-MIM
PatientIncident
classCode*: <= ENC
moodCode*: <= EVN
id: [1..*] (RegistNum)
code: CV CNE <= ExternallyDefinedActCodes (PatientType)
statusCode: LIST<CS> CNE <= ActStatus (IDPHStatus)
activityTime: TS (EDDate)
Injury
classCode*: <= ACT
moodCode*: <= EVN
activityTime: TS (InjuryDate)
0..1 pertinentInjury
typeCode*: <= PERT
PatientPerson
classCode*: <= PSN
determinerCode*: <= INSTANCE
name: PN [0..1] (*Name)
existenceTime: (Age)
administrativeGenderCode: CV CWE <= AdministrativeGender
(GenderID)
birthTime: (DateOfBirth)
addr: AD [0..1] (AddressHome)
raceCode: CV CWE [0..1] <= Race (RaceID)
ethnicGroupCode: CV CWE [0..1] <= Ethnicity (EthnicID)
1..1 patientPatientPerson
1..1 providerTraumaParticipant
Patient
classCode*: <= PAT
id: II [0..1] (MedicaRecordNum)
TraumaParticipant
classCode*: <= ORG
id: [1..1] (HospitNum)
code: CV CWE [0..1] <= EntityCode
name: ON [0..1] (HospitName)
statusCode: CS CNE [0..1] <= EntityStatus (ActiveFacili)
addr: AD [0..1] (HospitCity)
1..1 patient
typeCode*: <= SBJ
subject
InjuryLocation
classCode*: <= PLC
code: CV CWE [0..1] <= EntityCode (InjuryPlaceID)
addr: AD [0..1] (AddressScene)
0..1 playingInjuryLocation
Role
classCode*: <= ROL
1..1 participant
typeCode*: <= LOC
location
classCode*: <= OBS
moodCode*: <= EVN
code: <= ExternallyDefinedActCodes
priorityCode: CV CWE [0..1] <= ActPriority
value: [0..1]
0..* pertinentInjuryRelatedObservation
typeCode*: <= PERT
sequenceNumber: INT [0..1] (InjurySequen)
classCode*: <= OBS
moodCode*: <= EVN
code: <= ActCode
reasonCode: CV CWE [0..1] <= ActReason
value: ANY [0..1]
0..* pertinentPatientIncidentRelatedObservation
typeCode*: <= PERT
component
0..* patientIncidentRelatedObservation
typeCode*: <= COMP

HL7 XML Schema Generator
HL7 Vocabulary
Specification
HL7 Data Type
Specification
HL7 XML
Schema
Generator
Hierarchical Message
Definition
And
CMET Specifications
XML Schema
Specification

HL7 V3 Message Implementation Technology
HL7-Conformant
Application
Data
HL7
Message
Creation
HL7-Conformant
Application
HL7
Message
Parsing Data
Message
Instance
XML Schema
Specification
Definition

HL7 Development Framework

Seven Phases of the HDF Methodology
1. Project initiation
2. Requirements Documentation
3. Specification Modeling
4. Specification Documentation
5. Specification Approval
6. Specification Publication
7. Specification Profiling

HDF Workflow Diagram
Initiate
Project
Project
Charter
Specify
Requirements
Reference
Models
Requirement
Specification
Prepare Specification
Design Models
Specification
Design Models
Prepare
Specification
Approve
Specification
Approved
Specification
Publish
Approved
Specification
Published
Specification
Profiles
Specification
Profile
Conformance
Statement
Proposed
Specification
The HDF workflow is not a waterfall methodology.
Each phase builds upon the prior and may cause
prior activities to be revisited and their deliverables
adjusted.

Project initiation
During project initiation the project is defined, a project plan is produced, and
project approval is obtained. The primary deliverable produced during project
initiation is the project charter.
Project
Initiation
Project
Charter
1. Define project scope, objectives, and intended deliverables
2. Identify project stakeholders, participants, and required resources
3. Document project assumptions, constraints, and risk
4. Prepare preliminary project plan and document inter-project dependencies
5. Obtain project approval and launch the project

Requirements Documentation
During requirements documentation the problem domain is defined, a model of the
domain is produced, and the problem domain model is harmonized with HL7
reference models. The primary deliverable produced during requirements
documentation is the requirements specification.
Requirements
Documentation
Requirements
Specification
1. Document Business Process: Dynamic Behavior and Static Structure
2. Capture Process Flow: UML Activity Diagram
3. Capture Structure: Domain Information Model and Glossary
4. Capture Business Rules: Relationships, Triggers, and Constraints
5. Harmonize the Domain Analysis Model with HL7 Reference Models
Project
Charter

Specification Modeling
During specification modeling reference models are constrained into design models
through an iterative process of requirements driven refinements following specification
design rules, conventions, and guidelines. The primary deliverable produced during
specification modeling is a set of specification design models.
Specification
Modeling
Specification
Design Models
1. Build design models of static information views
2. Construct design models of behavioral views
3. Define reusable design model components
4. Construct design models of collaboration and interaction
5. Harmonize design models with HL7 Reference Models
Requirements
Specification

Specification Documentation
During specification Documentation the specification design models are packaged
into logical units, supplemented with explanatory text, and prepared for approval.
The primary deliverable produced during specification documentation is a
proposed specification.
Specification
Documentation
Proposed
Specification
1. Organize design model elements into logical packages
2. Compose explanatory text, examples, and design rationale
3. Update design models and requirement specifications
4. Assemble a proposed specification package
5. Submit specification for approval
Specification
Design Models

Specification Approval
During specification approval the pre-approval specification is subjected to a series of
approvals steps. The specific approval steps vary by kind of specification, level of
approval, and realm of interest. The primary deliverable produced during specification
approval is an approved specification.
Specification
Approval
Approved
Specification
1. Obtain TSC and Board approval to ballot specification
2. Form a ballot pool and conduct specification ballot
3. Assess negative ballots and affirmative comments
4. Modify specification in response to ballot comments
5. Resolve negative ballot responses and if necessary re-ballot
Proposed
Specification

Specification Publication
During specification publication the approved specification is prepared for
prepared for publication and distribution. The primary deliverable produced during
specification publication is a published specification.
Specification
Publication
Published
Specification
1. Obtain TSC and Board approval to publish specification
2. Prepare specification for publication
3. Submit publication to standards authorities (ANSI/ISO)
4. Render the specification in various forms of publication media
5. Post and distribute approved specifications
Approved
Specification

Specification Profiling
During specification profiling specification models and published specifications are
further refined to produce a specification profile for use in a particular environment by
a defined community of users. The primary deliverable produced during specification
profiling is a set of specification constraints and conformance statements.
Specification
Profiling
Specification
Constraints and
Conformance
Statements
1. Identify community of user for the published specification
2. Further refine and constrain specification design models
3. Document exceptions, extensions, and annotations to specifications
4. Prepare and publish specification profile
5. Prepare and publish conformance statements
Published
Specification

SAIF Canonical Definition

SAIF Canonical Definition
 The development of the SAIF Canonical Definition (SAIF-CD) began in early
2008 .
 It was motivated and directed by a high-level set of requirements
communicated to the HL7 Architecture Board (ArB) by the HL7 Chief
Technology Officer (CTO), John Quinn.
 The ArB was asked to specify a Services Aware Interoperability Framework
(SAIF) to serve as the foundation for an HL7 enterprise architecture.
 The HL7 enterprise architecture enables the explicit description of
technology components from the perspective of the interactions between
those components as they are involved in scenarios whose purpose is to
achieve an agreed-upon goal based on “cross-boundary shared purpose.”
 The scope of the components themselves was not specified, i.e. a
“component” could be defined as a system, a service, an enterprise, or a
generic party.

ECCF Overview
 A key component of the SAIF Enterprise Architecture is the creation
of the Enterprise Conformance and Compliance Framework (ECCF).
 ECCF is an architecture for organizing service specification artifacts.
It combines concepts from RM-ODP, the ISO Reference Model for
Open Distributed Processing; and MDA, the OMG Model Driven
Architecture.
 RM-ODP provides a framework specification used to describe
distributed, heterogeneous systems within and across organizations.
It defines five viewpoints of a distributed system specification. The
ECCF uses four of the five RM-ODP viewpoints.
 MDA is a framework for building systems that abstracts systems into
a hierarchy of abstraction specification layers. The ECCF utilizes
three level of the four abstractions defined by MDA.

RM-ODP Viewpoints
 The five viewpoints defined
within the
RM-ODP standard are:
 Enterprise Viewpoint: focused on purpose,
scope and policy for the system; promoting
an understanding of the business
environment and its influences upon the
distributed system.
 Information Viewpoint: focused on the
semantics of the information and the
information processing performed;
essentially the articulation of the business
rules and content to be supported by the
system.
 Computational Viewpoint: focused on the
functional decomposition of the system. It
provides for the logical design of the system
through encapsulation of capability,
separation of functionality, and interface
definition.
 Engineering Viewpoint: focused on
mechanisms and functions to support
distributed interaction between the
components of the system.
 Technology Viewpoint: focused on the
choice of technology to be employed within
the system. It includes a description of the
implementation of the system and testing
requirements

OMG MDA Abstraction Layers
 The four levels of abstaction
defined by the OMG MDA are:
 Computational-Independent Model
(CIM): The CIM represents the highest-
level business model. The CIM
transcends computer systems. It
describes business processes, the
interaction between processes, and the
responsibilities of the actors involved.
 Platform-Independent Model (PIM): The
PIM represents the business model to be
implemented by an information system.
The PIM describes the processes and
structure of the system, without reference
to the delivery platforms.
 Platform-Specific Model (PSM): The
PSM projects the PIM onto a specific
platform. One PIM may be transformed
into multiple PSMs, however, the PSMs
collaborate to deliver a consistent and
complete solution.
 Code Model (CM): The code model
represents the deployable code, usually
in a high-level language such as XML,
Java, or VB..

ECCF Specification Stack

ECCF Organizing Paradigm
 The ECCF is an organizing
paradigm for the models,
specifications, and other work
products produced as part of a
systems development project.
 The ECCF provides a foundation
for assessing the conformance and
compliance of system analysis,
design, and construction artifacts.
 The ECCF also provides the basis
for organization of project teams
and the assignment of project team
functional boundaries,
interrelationships.

ECCF Influence on Model Artifacts
 The viewpoints of the ECCF provide a framework for organizing UML model elements,
diagrams, and specifications.
 The Enterprise viewpoint includes the UML concept of actor and the business perspectives
of requirements and reference materials.
 The Information, Computation, and Engineering viewpoints correspond to the UML diagram
categories of Structure, Behavior, and Interaction.
 The four viewpoints taken collectively across one layer of abstraction is a single internally
consistent model and is used along with expository text to form a single model
specification.

ECCF Influence on Project Teams
 Domain experts are the providers of
system requirements and the
deployment team is the provider of the
solution systems.
 Sandwiched between the domain
experts and the deployment team are
the Analyst, Architecture, and
Development teams.
 The Analyst team is responsible for the
transformation of system requirements
into a CIM.
 The Architecture team is responsible for
the transformation of a CIM into a PIM.
 The Development team is responsible
for transformation of a PIM into a PSM.
 The quality assurance team is
responsible for ensuring traceability and
compliance from deployment to
requirements.

Health Level Seven
Version 3 Reference Models
The HL7 reference models are the foundational artifacts
of HL7 version 3.0.

HL7 v3.0 Foundational Artifacts
Reference
Information
Model
Datatype
Specification
Vocabulary
Specification
The HL7 Reference Information Model is the
information model from which all other information
models and message specifications are derived.
The HL7 Vocabulary Specification defines the set of all
concepts that can be taken as valid values in an instance
of a coded attribute or data type property.
The HL7 Datatype Specification defines the structural
format of the data carried in an attribute and influences
the set of allowable values an attribute may assume.

HL7 Version 3.0 Reference Models
Reference Information Model
Data Type
Specification
Vocabulary
Specification

SESSION RETROSPECTIVE
 HL7 V3 MESSAGE DEVELOPMENT FRAMEWORK
(MDF)
 HL7 DEVELOPMENT FRAMEWORK (HDF)
 SERVICES AWARE INTEROPERABILITY FRAMEWORK
(SAIF)
 HL7 V3 REFERENCE MODELS

Hi3 Solutions
300
Burbank, CA 91505
6520

HL7 v3 Messaging Artifacts
July 14, 2015

SESSION OVERVIEW
 Messaging Artifacts ECCF
 Foundational Artifacts
 Design Artifacts
 Specification Artifacts
 HL7 v3 Message Design Example
 HL7 v3 Development Tools

HL7 v3.0 Messaging Artifacts
Reference
Information
Model
Datatype
Specification
Vocabulary
Specification
Foundational
Models
(CIM)
Dynamic
Model
Constrained
Information
Model
Common
Message Type
Model
Design
Models
(PIM)
Hierarchical
Message
Definition
Message
Type
Definition
Implementation
Technology
Specification
Message
Specifications
(PSM)

Reference
Information
Model
Datatype
Specification
Vocabulary
Specification
Foundational
Models
Dynamic
Model
Constrained
Information
Model
Common
Message Type
Model
Design
Models
Hierarchical
Message
Definition
Message
Type
Definition
Implementation
Technology
Specification
Message
Specifications

Health Level Seven
Version 3 Reference Models
The HL7 reference models are the foundational artifacts
of HL7 version 3.0.

Reference
Information
Model
Datatype
Specification
Vocabulary
Specification

Data Type
Specification
Vocabulary
Specification

Reference
Information
Model
Datatype
Specification
Vocabulary
Specification

HL7 Version 3.0
Reference Information
Model
The HL7 Reference Information Model is the information
model from which all other information models and message
specifications are derived.

HL7 Reference Information Model
 The HL7 Reference Information Model (RIM) is a static model of
health and health care information as viewed within the scope of HL7
standards development activities.
 It is the combined consensus view of information from the perspective
of the HL7 working group and the HL7 international affiliates.
 The RIM is the ultimate source from which the information-related
content of all HL7 version 3.0 protocol specification standards is
drawn.
 The RIM is modeled using the modeling syntax defined by the Object
Management Group’s Unified Modeling Language (UML).
 UML is a graphical language for visualizing, specifying, constructing,
and documenting the artifacts of a software-intensive system.

Reference Information Model History
 Development of the HL7 Reference Information Model began in April 1996.
 The first draft of the RIM was created by consolidating data models developed
by HL7 Technical Committees, contributed by HL7 Member Organizations,
and published by national and international standards organizations and
government bodies.
 The first release of the RIM (v0.80) was adopted by the HL7 Technical
Steering Committee at the January 1997 working group meeting.
 The next two working group meetings focused on gaining familiarity with the
draft RIM and implementing a process for obtaining and reconciling proposed
enhancements to the model.
 The RIM maintenance process became known as "RIM harmonization.” The
first RIM harmonization meeting was held July 1997 in Indianapolis, Indiana.

RIM Development Process
B
X F
E
C A D
G
1
0..*
0..* 1 0..* 1
0..* 0..1 0..*1
Model I Model II Model III
A
C
B
0..*
0..*
0..* 1 X
C
B
0..*
0..*
0..* 1
D
A B0..* 0..*
0..*
1

Contributing Data Models
circa April 1996
 HL7 Technical Committees
 Admission/Discharge/Transfer
 Finance
 Medical Records
 Orders/Results
 Patient Care
 Standards Development Organizations
 CEN TC251
 DICOM
 HL7 Member Organizations
 Eli Lilly and Company
 HBO and Company
 Health Data Sciences
 IBM Worldwide
 Kaiser Permanente
 Mayo Foundation
 Hewlett Packard
 National Health Programs
 United Kingdom
 Australia
Abdul-Malik Shakir
Manager, Information Administration
Kaiser Foundation Health Plan, Inc.
One Kaiser Plaza, Oakland, CA 94612
v: (510) 271-6856 f: (510) 271-6859
Email: 74353.1431@Compuserve.com

RIM Harmonization Process
Change Proposal Preparation
Prepare RIM
Change Proposal
Review RIM
Change Proposal
w/ Stewards
Document Rationale
for not supporting
RIM change proposal
Revise or Withdraw
RIM Proposal
Post RIM Change Proposals
Submit
RIM Change
Proposal
Post RIM
Change Proposal
Notify HL7 Members
of RIM Change
Proposal Posting
Provide Comment
on RIM Change
Proposals
Harmonization Meeting
Discuss the RIM
Change Proposal
Revise, withdraw,
or Table RIM
Change Proposal
Vote on RIM
Change Proposal
Apply Approved
Changes to RIM
Apply Technical
Corrections
Post Harmonization Meeting Review
Present RIM
Harmonization Report
to TSC
Hold TSC and/or
Board Appeals
Finalize
Revised RIM

Major Early Harmonization Themes
 Ensure coverage of HL7 version 2.x. This set of change proposals
introduced content to the draft model to ensure that it included all the
information content of HL7 version 2.x.
 Remove unsubstantiated content from the model. This set of change
proposals focused on removing content from the draft model that the
steward technical committee did not originate and could find no rationale for
retaining.
 Unified service action model. This set of change proposals introduced a
concise, well-defined set of structures and vocabularies that address the
information needs of a wide variety of clinical scenarios. This collection of
proposals, known as USAM, involved the combined effort of multiple
technical committees.
 Ensure quality. This set of change proposals addressed inconsistencies in
the draft model and conflicts between the model and the modeling style
guide. It began the practice of recording and tracking open issues in the
model.
 Address the "left hand side" of the model. This set of change proposals
introduced powerful structures and vocabularies for the non-clinical portions

USAM

The RIM Prior to USAM

The Unified Service Action Model

Observation
value : ANY
routeCode : CE
Procedure
Supply
quantity : PQ
Diet
energyQuantity : PQ
Document
setId : II
versionNumber : INT
completionCode : CE
storageCode : CE
copyTime : TS
Container
heightQuantity : PQ
capTypeCode : CE
Access
targetSiteCode : CD
gaugeQuantity : PQ
Device
softwareName : SC
localRemoteControlStateCode : CE
alertLevelCode : CE
Employee
jobCode : CE
jobTitleName : SC
jobClassCode : CE
salaryTypeCode : CE
salaryQuantity : MO
LivingSubject
birthTime : TS
deceasedInd : BL
deceasedTime : TS
organDonorInd : BL
Material
formCode : CE
LicensedEntity
Place
mobileInd : BL
addr : AD
directionsText : ED
positionText : ED
gpsText : ST
lotNumberText : ST
strainText : ED
Patient
Organization
addr : BAG<AD>
Account
name : ST
balanceAmt : MO
currencyCode : CE
Person
addr : BAG<AD>
raceCode : SET<CE>
WorkingList
PublicHealthCase
PatientEncounter
Other
Acts
Infrastructure (Structured documents)
HEALTH LEVEL 7
REFERENCE INFORMATION MODEL
VERSION 1.25 (RIM_0125)
Reflects changes to RIM in RIM Harmonization Through 06/30/2003.
Billboard produced by:
Rochester Outdoor Advertising
Roles
DiagnosticImage
QueryAck
queryResponseCode : CS
resultTotalQuantity : INT
resultCurrentQuantity : INT
resultRemainingQuantity : INT
QueryContinuation
startResultNumber : INT
continuationQuantity : INT
Table
summary : ST
width : ST
rules : CS
cellspacing : ST
cellpadding : ST
border : INT
frame : CS
TableStructure
char : ST
charoff : ST
halign : CS
valign : CS
TableColumnStructure
span : INT
width : ST
TableCell
scope : CS
abbr : ST
axis : ST
colspan : INT
headers : SET<ED>
rowspan : INT
LocalAttr
name : ST
value : ST
LocalMarkup
descriptor : ST
render : ST
ignoreCode : CS
LinkHtml
href : ED
name : ST
rel : SET<CE>
rev : SET<CE>
title : ST
ContextStructure
localId : ST
Infrastructure (Structured
documents)
Infrastructure
(Communications)
Enitites
Message Control
amt : MO
InvoiceElement
netAmt : MO
factorNumber : REAL
pointsNumber : REAL
FinancialContract
RoleHeir
EntityHeir
SortControl
elementName : SC
directionCode : CS
QuerySpec
modifyCode : CS
responseElementGroupId : SET<II>
responseModalityCode : CS
responsePriorityCode : CS
initialQuantity : INT
initialQuantityCode : CE
executionAndDeliveryTime : TS
0..n
1
0..n
1
RelationalExpression
elementName : SC
relationalOperatorCode : CS
value : ST
QueryBySelection
SelectionExpression
0..n
1
0..n
1
LogicalExpression
relationalConjunctionCode : CS
0..n
0..1
userAsRight
0..n
rightSide 0..1
0..n
0..1
userAsLeft0..n
leftSide0..1
QueryByParameter
ParameterList
Parameter
id : II 0..n 0..10..n 0..1
0..1
0..n
0..1
0..n
ParameterItem
value : ANY
semanticsText : ST
DeviceTask
id : SET<II>
ActHeir
ActRelationship
typeCode : CS
inversionInd : BL
pauseQuantity : PQ
checkpointCode : CS
splitCode : CS
joinCode : CS
negationInd : BL
seperatableInd : BL
Act
classCode : CS
moodCode : CS
id : SET<II>
code : CD
negationInd : BL
derivationExpr : ST
text : ED
effectiveTime : GTS
activityTime : GTS
levelCode : CE
independentInd : BL
languageCode : CE
0..n
1
inboundRelationship
0..n
target
1
0..n1
0..n
source
1
Participation
typeCode : CS
functionCode : CD
negationInd : BL
noteText : ED
time : IVL<TS>
modeCode : CE
awarenessCode : CE
signatureCode : CE
signatureText : ED
performInd : BL
substitutionConditionCode : CE
0..n
1
0..n
1
RoleLink
typeCode : CS
Role
classCode : CS
id : SET<II>
code : CE
negationInd : BL
addr : BAG<AD>
telecom : BAG<TEL>
quantity : RTO
0..n
1
0..n
1
0..n1
outboundLink
0..n
source
1 0..n1
inboundLink
0..n
target
1
languageCode : CE
modeCode : CE
preferenceInd : BL
AttentionLine
keyWordText : SC
value : ST
Entity
classCode : CS
determinerCode : CS
id : SET<II>
code : CE
quantity : SET<PQ>
name : BAG<EN>
desc : ED
telecom : BAG<TEL>
riskCode : CE
handlingCode : CE
0..n0..1
playedRole
0..n
player
0..1
0..n0..1
scopedRole
0..n
scoper
0..1
10..n 10..n
Transmission
id : II
creationTime : TS
securityText : ST
0..n
1
0..n
1
CommunicationFunction
typeCode : CS
telecom : TEL
1..n
0..*
1..n
0..*
1..*
0..*
1..*
0..*
InfrastructureRoot
templateId : SET<OID>
realmCode : SET<CS>
typeID : SET<OID>
nullFlavor : CS
QueryEvent
queryId : II
statusCode : CS
ControlAct
0..1
1
0..1
1
Message
versionCode : CS
interactionId : II
profileId : SET<II>
processingCode : CS
processingModeCode : CS
acceptAckCode : CS
attachmentText : SET<ED>
responseCode : CS
0..1
0..n
0..1
payload
0..n
Acknowledgement
typeCode : CS
messageWaitingNumber : INT
messageWaitingPriorityCode : CE
expectedSequenceNumber : INT
0..n
1
acknowledgedBy
0..n
acknowledges
1
0..1
1
conveyedAcknowledgement
0..1
conveyingMessage
1
AcknowledgementDetail
typeCode : CS
code : CE
text : ED
location : SET<ST>
1
0..n
1
0..n
Batch
referenceControlId : II
name : SC
batchComment : SET<ST>
transmissionQuantity : INT
batchTotalNumber : SET<INT>
0..1
0..n
0..1
0..n
RoleEntity
Participation
Acts
The RIM After USAM
Version 1.25 06/30/2003
Infrastructure

Normative R6 RIM Class Diagram
Version 2.44 11/22/2013

Entity and Act
 Entity
a physical thing or an
organization/group of physical
things capable of participating in
Acts. This includes living subjects,
organizations, material, and places.
 Act
a discernible action of interest in the
healthcare domain. An instance of
Act is a record of that action. Acts
definitions (master files), orders,
plans, and performance records
(events)
are all represented by an
instance of Act.
Entity Act

Entity
classCode : CS
determinerCode: CS
code: CE
statusCode : CS
id : II
Act
classCode : CS
moodCode: CS
code: CD
statusCode : CS
effectiveTime : GTS
id : II
RIM Core Classes
 Entity - a physical thing or an organization/group of physical things
capable of participating in Acts. This includes living subjects, organizations,
material, and places.
 Act – a discernible action of interest in the healthcare domain. An
instance of Act is a record of that action. Acts definitions (master files), orders,
plans, and performance records (events) are all represented by an instance of
Act.
0..* 0..*

Entity
classCode : CS
determinerCode: CS
code: CE
statusCode : CS
id : II
Role
classCode : CS
code: CE
statusCode : CS
id : II
Act
classCode : CS
moodCode: CS
code: CD
statusCode : CS
effectiveTime : GTS
id : II
RIM Core Classes
0..* 0..*1 0..*plays

0..1
0..*
0..1
0..*
plays
scopes
Entity
classCode : CS
determinerCode: CS
code: CE
statusCode : CS
id : II
Role
classCode : CS
code: CE
statusCode : CS
id : II
Act
classCode : CS
moodCode: CS
code: CD
statusCode : CS
effectiveTime : GTS
id : II
RIM Core Classes
 Role – a classification/specialization of an Entity defined by the
relationship of the playing Entity to a scoping Entity. An example of Role
is “Employee”. An employee is a classification attributed to a person which
has an employment relationship with an organization (Employer).
0..* 0..*

Entity
classCode : CS
determinerCode: CS
code: CE
statusCode : CS
id : II
Role
classCode : CS
code: CE
statusCode : CS
id : II
Participation
typeCode : CS
time : IVL<TS>
statusCode : CS
Act
classCode : CS
moodCode: CS
code: CD
statusCode : CS
effectiveTime : GTS
id : II
0..1
0..* 1
0..*
1
0..*
RIM Core Classes
 Participation – an association between a Role and an Act representing
the function assumed by the Role within the context of the Act. A single
Role may participate in multiple Acts and a single Act may have multiple
participating Roles. A single Participation is always an association between a
particular Role and a particular Act.
0..1
0..*
plays
scopes

Entity
classCode : CS
determinerCode: CS
code: CE
statusCode : CS
id : II
Role
classCode : CS
code: CE
statusCode : CS
id : II
Participation
typeCode : CS
time : IVL<TS>
statusCode : CS
Act
classCode : CS
moodCode: CS
code: CD
statusCode : CS
effectiveTime : GTS
id : II
0..1
0..*
1
0..*
1
0..*
Act Relationship
typeCode : CS
1 1
0..* 0..*
RIM Core Classes
 Act relationship – an association between two Acts.
This includes Act to Act associations such as
collector/component, predecessor/successor, and
cause/outcome. The semantics of the association is
captured by the Act Relationship attributes.
0..1
0..*
plays
scopes

Entity
classCode : CS
determinerCode: CS
code: CE
statusCode : CS
id : II
Role
classCode : CS
code: CE
statusCode : CS
id : II
Participation
typeCode : CS
time : IVL<TS>
statusCode : CS
Act
classCode : CS
moodCode: CS
code: CD
statusCode : CS
effectiveTime : GTS
id : II
0..1
0..*
1
0..*
1
0..*
Role Link
typeCode : CS
Act Relationship
typeCode : CS
RIM Core Classes
 Role Link – An association between
two Roles. It is used to capture
relationships that exists between
Entities other than the scoping
relationships. A
0..1
0..*
plays
scopes
single Role may
have a Role Link
with multiple other
Roles. A single Role
Link is always
between two distinct
instances of Role.
1 1
0..* 0..*
1 1
0..* 0..*

Definition of RIM Core Classes
 Act – a discernible action of interest in the healthcare domain. An instance of Act is a record of
that action. Acts definitions (master files), orders, plans, and performance records (events) are all
represented by an instance of Act.
 Act relationship – an association between two Acts. This includes Act to Act associations such
as collector/component, predecessor/successor, and cause/outcome. The semantics of the
association is captured by the Act Relationship attributes.
 Entity - a physical thing or an organization/group of physical things capable of participating
in Acts. This includes living subjects, organizations, material, and places.
 Participation – an association between a Role and an Act representing the function
assumed by the Role within the context of the Act. A single Role may participate in multiple Acts
and a single Act may have multiple participating Roles. A single Participation is always an
association between a particular Role and a particular Act.
 Role – a classification/specialization of an Entity defined by the relationship of the playing
Entity to a scoping Entity. An example of Role is “Employee”. An employee is a classification
attributed to a person which has an employment relationship with an organization (Employer).
 Role Link – An association between two Roles. It is used to capture relationships that exists
between Entities other than the scoping relationships. A single Role may have a Role Link
with multiple other Roles. A single Role Link is always between two distinct instances of Role.

Entity
classCode : CS
determinerCode: CS
code: CE
statusCode : CS
id : II
Role
classCode : CS
code: CE
statusCode : CS
id : II
Participation
typeCode : CS
time : IVL<TS>
statusCode : CS
Act
classCode : CS
moodCode: CS
code: CD
statusCode : CS
effectiveTime : GTS
id : II
0..1
0..*
1
0..*
1
0..*
Role Link
typeCode : CS
Act Relationship
typeCode : CS
RIM Backbone Classes
0..1
0..*
plays
scopes
1 1
0..* 0..*
1 1
0..* 0..*

Entity
classCode : CS
determinerCode: CS
code: CE
statusCode : CS
id : II
Role
classCode : CS
code: CE
statusCode : CS
id : II
Participation
typeCode : CS
time : IVL<TS>
statusCode : CS
Act
classCode : CS
moodCode: CS
code: CD
statusCode : CS
effectiveTime : GTS
id : II
0..1
0..*
1
0..*
1
0..*
0..1
0..*
plays
scopes

Entity
classCode : CS
determinerCode: CS
code: CE
statusCode : CS
id : II
Role
classCode : CS
code: CE
statusCode : CS
id : II
Participation
typeCode : CS
time : IVL<TS>
statusCode : CS
Act
classCode : CS
moodCode: CS
code: CD
statusCode : CS
effectiveTime : GTS
id : II
0..1
0..*
1
0..*
1
0..*
0..1
0..*
plays
scopes
Living Subject
Place
Organization
Material
Licensed Entity
Patient
Access
Employee
Managed Participation
Observation
Supply
Patient Encounter
Procedure
Device Task
Substance Administration
Financial Transaction
Invoice Element
Financial Contract
Account
Working List
Control Act

HL7 RIM Class Diagram

Entity
classCode : CS
determinerCode : CS
statusCode : CS
code: CE
Role
classCode : CS
code: CE
Participation
typeCode : CS
time : IVL<TS>
statusCode : CS
Act
classCode : CS
moodCode : CS
statusCode : CS
code: CD
effectiveTime : GTS
0..1
0..* 1
0..*
1
0..*
RIM Core Attribute Value Sets
Entity
Class Code
• Living Subject
• Person
• Organization
• Material
• Place
• ...
Role
Class Code
• Patient
• Provider
• Employee
• Specimen
• Certified
Practitioner
• ...
Participation
Type Code
• Performer
• Author
• Witness
• Subject
• Destination
• ...
Act
Mood Code
• Definition
• Intent
• Order
• Event
• Criterion
• ...
Act
Class Code
• Observation
• Procedure
• Supply
• Substance
Admin
• Financial
• ...
Entity
Determiner
Code
• Kind
• Instance
• Quantified
Group
0..1
0..*
plays
scopes

Coded Structural Attributes
 RIM coded attributes with a data type of Coded Simple (CS) are referred
to as “structural”
 A CS data type is assigned to an attribute when the only allowable code
values for the attribute are determined by HL7
 There are 18 such attributes in the RIM. Each of them is bound to a
vocabulary value set defined by HL7.
 These attributes are referred to as “structural” because their presence in
the model eliminates the need to include other structural model
components such as classes, generalizations, and associations.
 Vocabulary value sets bound to coded structural attributes are
normative.

Coded “Structural” Attributes
 Act.classCode
 Act.moodCode
 Act.statusCode
 ActRelationship.checkpointCode
 ActRelationship.conjunctionCode
 ActRelationship.joinCode
 ActRelationship.splitCode
 ActRelationship.Type
 ActRelationship.contextControlCode
 Entity.classCode
 Entity.determinerCode
 Entity.statusCode
 ManagedParticipation.statusCode
 Participation.contextControlCode
 Participation.typeCode
 Role.classCode
 Role.statusCode
 RoleLink.typeCode

Act.classCode
3.1.1.1 Act.classCode :: CS (1..1) Mandatory
Vocabulary domain: ActClass (CNE)
Attribute description:
A code specifying the major type of Act that this Act-instance represents.
Constraints:
The classCode domain is a tightly controlled vocabulary, not an external or
user-defined vocabulary.
Every Act-instance must have a classCode. If the act class is not further
specified, the most general Act.classCode (ACT) is used.
The Act.classCode must be a generalization of the specific Act concept (e.g., as
expressed in Act.code), in other words, the Act concepts conveyed in an Act
must be specializations of the Act.classCode. Especially, the classCode is not a
"modifier" or the Act.code that can alter the meaning of a class code. (See
Act.code for contrast.)
Name DatatypeCardinalityUsageValue DomainCoding Strength

Act.moodCode
3.1.1.2 Act.moodCode :: CS (1..1) Mandatory
Vocabulary domain: ActMood (CNE)
A code distinguishing whether an Act is conceived of as a factual statement or in some
other manner as a command, possibility, goal, etc.
Constraints:
An Act-instance must have one and only one moodCode value. The moodCode of a single
Act-instance never changes. Mood is not state. To describe the progression of a business
activity from defined to planned to executed, etc. one must instantiate different Act-
instances in the different moods and link them using ActRelationship of general type
"sequel". (See ActRelationship.typeCode.)
Discussion:
The Act.moodCode includes the following notions: (1) event, i.e., factual description of an
actions that occurred; (2) definition of possible actions and action plans (the master file
layer); (3) intent, i.e., an action plan instantiated for a patient as a care plan or order; (4)
goal, i.e., an desired outcome attached to patient problems and plans; and (5) criterion, i.e.,
a predicate used to evaluate a logical expression

Act.code
3.1.1.4 Act.code :: CD (0..1)
Vocabulary domain: ActCode (CWE)
A code specifying the particular kind of Act that the Act-instance represents
within its class.
Constraints:
The kind of Act (e.g. physical examination, serum potassium, inpatient
encounter, charge financial transaction, etc.) is specified with a code from one
of several, typically external, coding systems. The coding system will depend
on the class of Act, such as LOINC for observations, etc. Conceptually, the
Act.code must be a specialization of the Act.classCode. This is why the
structure of ActClass domain should be reflected in the superstructure of the
ActCode domain and then individual codes or externally referenced
vocabularies subordinated under these domains that reflect the ActClass
structure.

ActRelationship.typeCode
3.1.2.1 ActRelationship.typeCode :: CS (1..1) Mandatory
Vocabulary domain: ActRelationshipType (CNE)
A code specifying the meaning and purpose of every ActRelationship instance. Each of its
values implies specific constraints to what kinds of Act objects can be related and in which
way.
Discussion:
The types of act relationships fall under one of 5 categories:
1.) (De)-composition, with composite (source) and component (target).
2.) Sequel which includes follow-up, fulfillment, instantiation, replacement, transformation,
etc. that all have in common that source and target are Acts of essentially the same kind but
with variances in mood and other attributes, and where the target exists before the source
and the source refers to the target that it links back to.
3.) Pre-condition, trigger, reason, contraindication, with the conditioned Act at the source
and the condition or reason at the target.
4.) Post-condition, outcome, goal and risk, with the Act at the source having the outcome or
goal at the target.
5.) A host of functional relationships including support, cause, derivation, etc. generalized
under the notion of "pertinence".

Participation.typeCode
3.1.3.1 Participation.typeCode :: CS (1..1) Mandatory
Vocabulary domain: ParticipationType (CNE)
A code specifying the kind of Participation or involvement the Entity
playing the Role associated with the Participation has with regard to
the associated Act.
Constraints:
The Participant.typeCode contains only categories that have crisp
semantic relevance in the scope of HL7. It is a coded attribute without
exceptions and no alternative coding systems allowed.

Entity.classCode
3.2.1.1 Entity.classCode :: CS (1..1) Mandatory
Vocabulary domain: EntityClass (CNE)
An HL7 defined value representing the class or category that the Entity instance
represents.
Examples:
Person, Animal, Chemical Substance, Group, Organization
Rationale:
Due to the extremely large number of potential values for a code set
representing all physical things in the universe, the class code indicates both
the subtype branch of the Entity hierarchy used as well as a high level classifier
to represent the instance of Entity. This can be used to constrain the eligible
value domains for the Entity.code attribute.

Entity.determinerCode
3.2.1.2 Entity.determinerCode :: CS (1..1) Mandatory
Vocabulary domain: EntityDeterminer (CNE)
An HL7 defined value representing whether the Entity represents a kind-of or a
specific instance.
Examples:
1 human being (an instance), 3 syringes (quantified kind) or the population of
Indianapolis (kind of group)
Rationale:
An Entity may at times represent information concerning a specific instance
(the most common), a quantifiable group with common characteristics or a
general type of Entity. This code distinguishes these different representations.

Entity.code
3.2.1.4 Entity.code :: CE (0..1)
Vocabulary domain: EntityCode (CWE)
A value representing the specific kind of Entity the instance represents.
Examples:
A medical building, a Doberman Pinscher, a blood collection tube, a tissue
biopsy.
Rationale:
For each Entity, the value for this attribute is drawn from one of several coding
systems depending on the Entity.classCode, such as living subjects (animal and
plant taxonomies), chemical substance (e.g., IUPAC code), organizations,
insurance company, government agency, hospital, park, lake, syringe, etc. It is
possible that Entity.code may be so fine grained that it represents a single
instance. An example is the CDC vaccine manufacturer code, modeled as a
concept vocabulary, when in fact each concept refers to a single instance.

Role.classCode
3.3.1.1 Role.classCode :: CS (1..1) Mandatory
Vocabulary domain: RoleClass (CNE)
A code specifying the major category of a Role as defined by HL7 vocabulary.

Role.code
3.3.1.3 Role.code :: CE (0..1)
Vocabulary domain: RoleCode (CWE)
A code further specifying the kind of Role.
Discussion:
The Role.code must conceptually be a proper specialization of Role.classCode.
Role.code does not modify Role.classCode. Rather, each is a complete concept
or a Role-like relationship between two Entities, but Role.code may be more
specific than Role.classCode.
The Role.code may not be coded if only an un-coded name for the type of role is
commonly used.

RoleLink.typeCode
3.3.2.1 RoleLink.typeCode :: CS (1..1) Mandatory
Vocabulary domain: RoleLinkType (CNE)
A code specifying the kind of connection represented by this RoleLink, e.g.,
has-part, has-authority.

Accessing the RIM
http://www.hl7.org/participate/toolsandresources.cfm?ref=nav

RoseTree

Model Browsing Tree - Attributes
Packages (AKA Subject Areas)
Classes
Attributes
Datatype
Datatype Components
(AKA Properties)
Descriptive
Text

Model Browsing Tree - Relationships
Source Class (AKA Focal Class)
Relationships
Distal Class
Descriptive
Text

Model Browsing Tree - States
States
Transitions
Descriptive
Text

State Machine
 The HL7 Reference Information
Model includes state machines for
the Entity, Role,
ManagedParticipation, and Act
classes.
 A state machine specifies the
allowable states and valid state
transitions for a given class.
 A class transitions from one state
to another sometimes triggers one
or more interactions.

Entity State Machine
normal
active inactive
null
active inactivecreate
revise revise
reactivate
inactivate
nullified
nullify

Role State Machine

Managed Participation State Machine
normal
pending active completed
cancelled
pending active completed
null
revise revise revise
complete
reactivate
activate
nullified
nullify
cancelled
cancel
createcreatecreate

Act State Machine

HL7 RIM Class Diagram

RIM is First ISO/HL7 Standard
 On August 3, 2006 the HL7
was published as an ISO
standard (21731:2006).
 The RIM was accepted and
approved through the ISO
Technical Committee 215 –
Health Informatics.
 The RIM is the first publication
of an ISO/HL7 standard.
 Other ISO/HL7 collaborations
include:
 HL7 V2.5 Messaging Standard
 Clinical Data Architecture –
 Common Terminology Server
 Structured Product Labeling
 Annotated Electrocardiogram
 Individual Case Safety Report

RIM From Draft to Normative
 Apr 96 – Dec 96: Initial development
 Jan 97 – Jan 00: Pre-USAM Harmonization
 Jan 00 – Jul 03: Post-USAM and Pre-Normative
 Normative Releases:
– V1.25 Release 1.0: Jul 2003
– V2.29 Release 2.0: Oct 2009
– V2.33 Release 3.0: Nov 2010
– V2.36 Release 4.0: Jul 2011
– V2.40 Release 5.0: Jul 2012
– V2.46 Release 6.0: Dec 2013

Reference
Information
Model
Datatype
Specification
Vocabulary
Specification

HL7 Version 3.0
Data Type Specification
The HL7 v3 Abstract Datatype Specification defines the
structural format of the data carried in an attribute and
influences the set of allowable values an attribute may assume.

HL7 Version 3.0 Data Types
 HL7 data types define the structure and constrain the allowable
values of attributes in the RIM.
 The HL7 v3 abstract data type specification declares the set of
data types, identifies components of complex types, and defines
relationships between data types.
 The HL7 data type implementation technology specification
defines constraints and operations for data types and describes
how data types are to be represented in XML.
 Data types are reusable atomic building blocks used to create all
HL7 V3 information structures.
 Each RIM attribute is assigned one data type; each data type is
assigned to zero, one, or more RIM attribute.

HL7 Version 3.0 Data Types (R1)
 AD: Postal Address
 ANY: DataValue
 BAG: Bag
 BL: Boolean
 CD: Concept Descriptor
 CE: Coded With Equivalents
 CS: Coded Simple Value
 ED: Encapsulated Data
 EN: Entity Name
 GTS: General Timing Specification
 HIST: History
 II: Instance Identifier
 INT: Integer Number
 IVL: Interval
 LIST: Sequence
 MO: Monetary Amount
 ON: Organization Name
 PN: Person Name
 PPD: Parametric Probability Distribution
 PQ: Physical Quantity
 REAL: Real Number
 RTO: Ratio
 SC: Character String with Code
 SET: Set
 ST: Character String
 TEL: Telecommunication Address
 TN: Trivial Name
 TS: Point in Time
 UVP: Uncertain Value - Probabilistic

Datatype Class Diagram
T
Sequence : LIST
T
Set : SET
T
Bag : BAG
Quantity : QTY
IntegerNumber : INT
RealNumber : REAL
PhysicalQuantity : PQ
MonetaryAmount : MO
Ratio : RTO
PointInTime : TS
Boolean : BL
CharacterString : ST
ConceptDescriptor : CD
CodedValue : CV
InstanceIdentifier : II
TelecommunicationAddress : TEL
T
Interval : IVL
DataValue : ANY
BinaryData : BIN
List_of_Boolean : LIST<BL>
<<extends>>
EncapsulatedData : ED
<<extends>>
ConceptRole : CR
CodedSimpleValue : CS
<<restricts>>
CodedWithEquivalents : CE
ISO_object_identifier : OID
List_ADXP : LIST<ADXP>
PostalAndResidentialAddress : AD
<<extends>>
AddressPart : ADXP
PersonNameType : PN
List_ENXP : LIST<ENXP>
EntityNamePart : ENXP
T
PeriodicIntervalOfTime : PIVL
T
EventRelatedPeriodicIntervalOfTime : EIVL
GeneralTimingSpecification : GTS
Set_of_TS : SET<TS>
<<extends>>
T : T
T
Annotated : ANT
T
History_item : HXIT
T
History : HIST
Set_of_HXIT : SET<HXIT<T>>
T
UncertainValueNarrative : UVN
<<extends>>
T
UncertainValueProbabilistic : UVP
T
NonParametricProbabilityDistribution : NPPD
Set_UVP : SET<UVP<T>>
T
ParametricProbabilityDistribution : PPD
UniversalResourceLocator : URL
<<extends>>
OrganizationName : ON
<<extends>>
<<extends>><<extends>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<restricts>>
<<restricts>>
<<restricts>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<restricts>>
<<extends>>
<<extends>>
<<extends>>
<<extends>> <<extends>>
<<extends>>

AddressDataTypes
+ AddressPart : ADXP
+ PostalAndResidentialAddress : AD
+ TelecommunicationAddress : TEL
+ UniversalResourceLocator : URL
CharacterStringDatatypes
+ CharacterString : ST
+ EncapsulatedData : ED
+ StringWithCode : SC
ConceptDescriptorDataTypes
+ CodedSimpleValue : CS
+ CodedValue : CV
+ CodedWithEquivalents : CE
+ ConceptDescriptor : CD
+ ConceptRole : CR
AnyDataType
+ DataValue : ANY
ParameterizedDataTypes
+ Bag : BAG
+ Interval : IVL
+ Sequence : LIST
+ Set : SET
IdentifierDataTypes
+ ISOObjectIdentifier : OID
+ InstanceIdentifier : II
EntityNameDataTypes
+ EntityName : EN
+ EntityNamePart : ENXP
+ OrganizationName : ON
+ PersonNameType : PN
+ TrivialName : TN
QuantityDataTypes
+ BinaryData : BIN
+ Boolean : BL
+ IntegerNumber : INT
+ MonetaryAmount : MO
+ PhysicalQuantity : PQ
+ Quantity : QTY
+ Ratio : RTO
+ RealNumber : REAL
TimingExpressionDatatypes
+ GeneralTimingSpecification : GTS
+ GeneralTimingSpecificationTerm
+ PointInTime : TS
HL7 Data Type Packages

Basic Datatype Descriptions
Name Symbol Description
Boolean BL The Boolean type stands for the values of two-valued logic. A Boolean value can be either
true or false.
Encapsulated Data ED Data that is primarily intended for human interpretation or for further machine processing
outside the scope of this specification. This includes unformatted or formatted written
language, multimedia data, or structured information in as defined by a different standard
(e.g., XML-signatures.) Instead of the data itself, an ED may contain only a reference (see
TEL.) Note that the ST data type is a specialization of the ED data type when the ED
media type is text/plain.
Character String ST Text data, primarily intended for machine processing (e.g., sorting, querying, indexing,
etc.) Used for names, symbols, and formal expressions.) Note that the ST data type is a
specialization of the ED data type when the ED media type is text/plain.
Coded Simple Value CS Coded data, consists of a code and display name. The code system and code system
version is fixed by the context in which the CS value occurs. CS is used for coded
attributes that have a single HL7-defined value set.
Coded Value CV Coded data, consists of a code, display name, code system, and original text. Used when
a single code value must be sent.
Coded With Equivalents CE Coded data, consists of a coded value (CV) and, optionally, coded value(s) from other
coding systems that identify the same concept. Used when alternative codes may exist.
Concept Descriptor CD Coded data, is like a CE with the extension of modifiers. Modifiers for codes have an
optional role name and a value. Modifiers allow one to express, e.g., "FOOT, LEFT" as a
postcoordinated term built from the primary code "FOOT" and the modifier "LEFT".

Instance Identifier II An identifier to uniquely identify an individual instance. Examples are medical record
number, order number, service catalog item number, etc. Based on the ISO Object
Identifier (OID)
Telecommunication Address TEL A telephone number or e-mail address specified as a URL. In addition, this type
contains a time specification when that address is to be used, plus a code describing
the kind of situations and requirements that would suggest that address to be used
(e.g., work, home, pager, answering machine, etc.)
Postal Address AD For example, a mailing address. Typically includes street or post office Box, city,
postal code, country, etc.
Entity Name EN A name of a person, organization, place, or thing. Can be a simple character string or
may consist of several name parts that can be classified as given name, family name,
nickname, suffix, etc.
Person Name PN A name of a person. Person names usually consist of several name parts that can be
classified as given, family, nickname etc. PN is a restriction of EN.
Organization Name ON A name of an organization. ON name parts are typically not distinguished, but may
distinguish the suffix for the legal standing of an organization (e.g. "Inc.", "Co.", "B.V.",
"GmbH", etc.) from the name itself. ON is a restriction of EN.
Trivial Name TN A restriction of EN that is equivalent with a plain character string (ST). Typically used
for the names of things, where name parts are not distinguished.
Integer Number INT Positive and negative whole numbers typically the results of counting and
enumerating. The standard imposes no bounds on the size of integer numbers.

Decimal number REAL Fractional numbers. Typically used whenever quantities are measured, estimated, or
computed from other real numbers. The typical representation is decimal, where the
number of significant decimal digits is known as the precision.
Physical Quantity PQ A dimensioned quantity expressing the result of measurement. It consists of a real
number value and a physical unit. Physical quantities are often constrained to a certain
dimension by specifying a unit representing the dimension (e.g. m, kg, s, kcal/d, etc.)
However, physical quantities should not be constrained to any particular unit (e.g.,
should not be constrained to centimeter instead of meter or inch.)
Monetary Amount MO The amount of money in some currency. Consists of a value and a currency
denomination (e.g., U.S.$, Pound sterling, Euro, Indian Rupee.)
Ratio RTO A quantity explicitly including both a numerator and a denominator (e.g. 1:128.) Only in
the rare cases when the numerator and denominator must stand separate should the
Ratio data type should be used. Normally, the REAL, PQ, or MO data types are more
appropriate.
Point in Time TS A time stamp.
General Timing Specification GTS One or more time intervals used to specify the timing of events. Every event spans one
time interval (occurrence interval). A repeating event is timed through a sequence of
such occurrence intervals. Such timings are often specified not directly as a sequence of
intervals but as a rule, e.g., "every other day (Mon - Fri) between 08:00 and 17:00 for 10
minutes."

ED: Encapsulated Data
Name Type Status Definition
BIN BIN mandatory The binary data.
type CS mandatory Identifies the encoding of the data and a method to interpret the data.
charset CS optional Where applicable, specifies the character set and character encoding
used. The charset may be implied or fixed by the ITS.
language CS optional Where applicable, specifies the language of text data.
compression CS optional Indicates whether the raw byte data is compressed, and what
compression algorithm was used.
reference TEL optional A telecommunication address that resolves to the binary data.
integrityCheck BIN optional A short binary value representing a cryptographically strong checksum
over the binary data.
integrityCheckAlgorithm CS optional Specifies the algorithm used to compute the integrityCheck value.
thumbnail ED optional An abbreviated rendition of the full data.

ST: Character String
data BIN mandatory The binary data of the character string.
charset CS optional Specifies the character set and character encoding used.
language CS optional Specifies the language of text data.

CD: Concept Descriptor
Name Description
code A string containing the value of the code (e.g., "F150")
displayName A string containing a short, human-readable description of the code. ("Ford F150 Full-size Pickup Truck")
codeSystem An Object Identifier (OID) that uniquely identifies the code system to which the code belongs (e.g.,
"106.75.314.67.89.24," where this uniquely identifies Ford Motor Company's set of model numbers).
codeSystemName A string containing a short, human-readable description of the code system (e.g., "Ford Car and Truck Models ").
codeSystemVersion A string qualifying the version of the code system (e.g., "Model Year 2001").
originalText This is the text, phrase, etc., that is the basis for the coding. (e.g., "The new truck purchased for hospital facility
maintenance was a Ford model F150 ...").
modifier Some code systems permit modifiers, additional codes that refine the meaning represented by the primary code.
HL7 Version 3 accommodates a list of modifiers. Continuing with our truck example, the list of modifiers "Body-
ECAB, Eng-V8, EM-CE" modify "F150" to designate that the truck has an extended cab, V8 engine, and California
Emissions package. "Body-," "Eng-," and "EM" designate the roles (body, engine, emissions) represented by the
codes "ECAB," "V8," and "CE."
translation Quite often in an interfaced environment, codes need to be translated into one or more other coding systems. In our
example, the California DMV may have their own code

Concept Descriptor Datatypes
Name Type Status
code ST mandatory
displayName ST optional
Name Type Status
code ST mandatory
codeSystem OID mandatory
codeSystemName ST optional
codeSystemVersion ST optional
originalText ST optional
Name Type Status
code ST mandatory
codeSystem OID mandatory
codeSystemName ST optional
codeSystemVersion ST optional
originalText ST optional
translation SET<CV> optional
CS: Coded Simple
CV: Coded Value
CE: Coded With Equivalents

II: Instance Identifier
extension ST optional The value of the identifier, unique within its assigning authority's namespace.
root OID mandatory A unique identifier that guarantees the global uniqueness of the instance identifier.
The root alone may be the entire instance identifier, an extension value is not
needed.
assigningAuthorityName ST optional A human readable name or mnemonic for the assigning authority. This name is
provided solely for the convenience of unaided humans interpreting an II value.
Note: no automated processing must depend on the assigning authority name to be
present in any form.
validTime IVL<TS> optional If applicable, specifies during what time the identifier is valid. By default, the
identifier is valid indefinitely. Any specific interval may be undefined on either side
indicating unknown effective or expiry time.
Note: identifiers for information objects in computer systems should not have
restricted valid times, but should be globally unique at all times. The identifier valid
time is provided mainly for real-world identifiers, whose maintenance policy may
include expiry (e.g., credit card numbers.)

Tel: Telecommunication Address
URL URL mandatory The essence of a telecommunication address is a Universal Resource Locator.
use SET<CS> optional
A code advising a system or user which telecommunication address in a set of like
addresses to select for a given telecommunication need.
validTime GTS optional
Identifies the periods of time during which the telecommunication address can be
used. For a telephone number, this can indicate the time of day in which the party
can be reached on that telephone. For a web address, it may specify a time range in
which the web content is promised to be available under the given address.

AD: Postal Address
LIST<ADXP> mandatory The address data
use SET<CS> optional
A code advising a system or user which address in a set of like addresses to
select for a given purpose
validTime GTS optional
Identifies the periods of time during which the address can be used. Typically
used to refer to different addresses for different times of the year or to refer to
historical addresses.
ST ST mandatory The address part data
type CS optional
Indicates whether an address part is the street, city, country, postal code, post
box, etc.
ADXP: Postal Address Part

EN: Entity Name
Name Type Status Default Constraint Definition
ST mandatory NULL The entity name part data
type CS optional NULL EntityNamePartType Indicates whether the name part is a
given name, family name, prefix,
suffix, etc.
qualifier SET<CS> optional NULL EntityNameQualifier A set of codes each of which specifies
a certain subcategory of the name part
in addition to the main name part type
LIST<ENXP> mandatory NULL The name data
use SET<CS> optional NULL NamePurpose A code advising a system or user
which name in a set of names to select
for a given purpose
validTime IVL<TS> optional NULL Identifies the interval of time during
which the name was used. Typically
used to record historical names.
ENXP: Entity Name Part
Entity Name Specializations:
TN: Trivial Name
PN: Person Name
ON: Organization Name

RTO: Ratio
numerator QTY mandatory The numerator of the ratio.
denominator QTY mandatory
The denominator of the ratio
The QTY data type is an abstract generalization that stands for INT, REAL, PQ,
and MO.

PQ: Physical Quantity
value REAL mandatory The magnitude of the quantity measured in terms of the unit
unit CS mandatory The unit of measure
original value REAL optional The magnitude of the quantity measured in terms of the original unit.
original unit CV optional The original unit of measure.

MO: Monetary Amount
value REAL mandatory NULL
The magnitude of the monetary amount in terms of
the currency unit.
currency CS mandatory NULL ISO 4217 The currency unit

Additional Datatypes and Collections
 BL: Boolean
 INT: Integer
 Real: Real
 Precision :: Int
 TS: Point in Time
 Offset :: PQ
 Calendar :: CS
 Precision :: INT
 Timezone :: PQ
 SET
 LIST
 BAG
 IVL
 Low
 Center
 Width
 High

Reference
Information
Model
Datatype
Specification
Vocabulary
Specification

HL7 Version 3.0
Vocabulary Specification
of a coded attribute or message element.

HL7 V3 Vocabulary Specification
 The HL7 V3 Vocabulary Specification defines vocabulary domains
used in RIM coded Attributes and coded data type properties.
 A vocabulary domain is an abstract collection of interrelated
concepts. It describes the purpose or intent of a coded attribute.
 A value set is a collection of coded concepts drawn from one or
more code systems. A vocabulary domain may be associated with
many value sets (e.g. for use in different countries).
 A context expression provides a means of designating which value
set for a given domain are applicable for a given usage context.
 A coded concept has a concept code assigned by the coding
system and a concept designation which names the referenced
concept.
 A coded concept may be a parent concept for a collection of
additional concepts within the same code system.

Metamodel
ParentConcept
VocabularyDomain
name : String
description : String
CodedConcept
conceptCode : String
conceptDesignation : String
0..*0..*
ValueSet
name : String
definingExpression : String
0..*
0..*
0..*
0..*
0..*
0..*
0..*
0..*
includes
CodeSystem
identifier : OID
name : String
0..*0..*
0..*
0..1
0..*
0..1
based on
ValueSetContext
contextExpression : String

ActCode

EntityCode

RoleCode

ParticipationType

Vocabulary TermsVocabulary BindingInformation Model
Vocabulary Binding
Class
Attribute
Vocabulary
Domain
Value Set Coded
Concept
Code
System
1
0..* 0..*
0..1
0..10..*
0..*
0..*
0..* 0..*
0..*
1
0..*
0..1

CodeSystem
- id: II
- fullName: ST
- localName: ST
- description: ST
- copyright: ST
- status: CS
- statusDate: TS
CodeSystemVersion
- versionId: II
- effectiveDate: TS
- isComplete: boolean
- versionOrder: int
- releaseDate: TS
- releaseFormats: SET[ST]
- releaseLocation: ST
- supportedLanguages: SET[CS]
- status: CS
- statusDate: TS
ConceptCodeSystemVersionMembership
- /isConceptInitiator: boolean
ValueSet
- id: II
- name: ST
- description: ST
- ruleSetID: ST
- status: CS
- statusDate: TS
ValueSetVersion
- versionID: II
- effectiveDate: TS
- releaseDate: TS
- versionOrder: int
- isComplete: boolean
- rulesSetVersionID: ST
- supportedLanguages: SET[CS]
- status: CS
- statusDate: TS
ConceptValueSetMembership
- effectiveDate[0..1]: TS
Designation
- id: II
- name: ST
- description: ST
- isPreferred: boolean
- language: CS
- format: ST
- status: CS
- statusDate: TS
CodeSystemConcept
- code: ST
- codeSynonyms: SET[ST]
- id[0..1]: II
- status: CS
- statusDate: TS
CodeSystemVersionConceptAssociation
- associationKind: CS
- status: CS
- statusDate: TS
DefinedConceptProperty
- id: II
- name: ST
- description: ST
- status: CS
- statusDate: TS
These identify the defined or
"allowable" properties and associations
that may be applied to a concept.
DefinedConceptAssociation
- id: II
- associationKind: enum
- forwardName: ST
- reverseName: ST
- isDirected: boolean
- ruleSetID: ST
- description: ST
- status: CS
- statusDate: TS
DesignationValueSetVersionMembership
- isDefault: boolean
- effectiveDate[0..1]: TS
Includes both assocations within a
ocde set (hierarchic) and associations
between concpets in different code
sets. Type may indicate: map, rules
based, lexical etc. May need
specializations if different properties
needed.
CodeSystemConceptVersion
- versionId: II
- effectiveDate: TS
- versionOrder: int
- status: CS
- statusDate: TS
ConceptPropertyVersion
- value: ST
- status: CS
- statusDate: TS
This covers the Concept of "supplemental"
(per MIF) or realm/local specifc variations,
with restriction (per HL7 principles) that they
cannot actually add additional "codes".
UsageContext
- id: II
- name: ST
- description: ST
JurisdictionalDomain
- id: II
- name: ST
- description: ST
1..*10..*
1
0..*
1
1..*
1..*
11..*
0..*
used in
0..*
0..*
0..*
1
0..*
1..*
1..*
+targetConcept
1
0..*
0..1
0..*
1
0..*
0..*
1
1..*
0..*
0..1
0..*
1..*
0..*isSourceOf
0..*
isTargetOf
1
1..*
0..1
0..*
+sourceConcept
1
0..*
Controlled Terminology Service Conceptual Data Model

July 13, 2015 Page: 145 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
HL7 v2 Message Elements
Message Specification
Segment Group
Message Segment
Segment Segment Field
Data Element
Data Type Composite Data Type
Data Type Component
Code Table Code Table Item
Code System Term
Code System

July 13, 2015 Page: 146 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner
Reference
Information
Model
Datatype
Specification
Vocabulary
Specification
Foundational
Models
(CIM)
Dynamic
Model
Constrained
Information
Model
Common
Message Type
Model
Design
Models
(PIM)
Hierarchical
Message
Definition
Message
Type
Definition
Implementation
Technology
Specification
Message
Specifications
(PSM)

Data Type
Specification
Vocabulary
Specification

ParentConcept
VocabularyDomain
name : String
CodedConcept
0..*0..*
ValueSet
name : String
0..*
0..*
0..*
0..*
0..*
0..*
0..*
0..*
includes
CodeSystem
identifier : OID
name : String
0..*0..*
0..*
0..1
0..*
0..1
based on
ValueSetContext
T
Sequence : LIST
T
Set : SET
T
Bag : BAG
Quantity : QTY
IntegerNumber : INT
RealNumber : REAL
MonetaryAmount : MO
Ratio : RTO
PointInTime : TS
Boolean : BL
CodedValue : CV
T
Interval : IVL
DataValue : ANY
BinaryData : BIN
<<extends>>
<<extends>>
ConceptRole : CR
<<restricts>>
<<extends>>
AddressPart : ADXP
PersonNameType : PN
T
T
Set_of_TS : SET<TS>
<<extends>>
T : T
T
Annotated : ANT
T
History_item : HXIT
T
History : HIST
T
<<extends>>
T
T
T
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<restricts>>
<<restricts>>
<<restricts>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<restricts>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>

Reference
Information
Model
Datatype
Specification
Vocabulary
Specification
Foundational
Models
Dynamic
Model
Constrained
Information
Model
Common
Message Type
Model
Design
Models
Hierarchical
Message
Definition
Message
Type
Definition
Implementation
Technology
Specification
Message
Specifications

HL7 v3.0 Messaging Design Models
A Dynamic Model is a specification of information
exchanges within a particular domain as described in
storyboards and storyboard examples.
A Design Information Model is an information
structure that represents the information content for a
set of messages within a particular domain area.
A Common Message Type Model is a definition of a set
of common message components that can be
referenced in various message specifications.
Dynamic
Model
Design
Information
Model
Common
Message Type
Model

HL7 Version 3.0
Dynamic Model
A Dynamic Model is a specification of
information exchanges within a particular
domain as described in storyboards and
storyboard examples.

Message Development Framework
RIM
Restrict
R-MIM
Serialize
HMD
Restrict
Message
Type
Example
Storyboard
Storyboard
Example
D-MIM
Derive
Application
Role
Sender Receiver
Trigger
Event
Triggers
Content
Interaction
References

DynamicModel
RIM
Restrict
R-MIM
Serialize
HMD
Restrict
Message
Type
Example
Storyboard
Storyboard
Example
D-MIM
Derive
Application
Role
Sender Receiver
Trigger
Event
Triggers
Content
Interaction
References

v3 Dynamic Model
Example
Storyboard
Storyboard
Example
Application
Role
Sender Receiver
Trigger
Event
Triggers
Interaction
References

SAIF View of v3 Dynamic Model
«Interaction»
Storyboard
artifactId
name
narrative
«Exchange»
Interaction
artifactID
name
narrative
structuredName
interactionType
«InterchangePoint»
ApplicationRole
artifactID
name
description
structuredName
«ProviderInterchangePoi...
SendingApplicationRole
::ApplicationRole
artifactID
name
description
structuredName
«ConsumerInterchangePoint»
RecievingApplicationRole
::ApplicationRole
artifactID
name
description
structuredName
TriggerEvent
artifactID
name
description
type
structuredName
InteractionBasedTriggerEvent
::TriggerEvent
artifactID
name
description
type
structuredName
StateTransitionBasedTriggerEvent
::TriggerEvent
artifactID
name
description
type
structuredName
UserRequestBasedTriggerEvent
::TriggerEvent
artifactID
name
description
type
structuredName
«ConstrainedInformationMod...
StaticModel
artifactID
name
type
ReceiverResponsibility
reason
«SoftwareUnit»
Application
ConformanceStatement
StoryboardExample
narrative
«ImplementableInformationModel»
InformationStructure
disjoint = false
1..*
1..*
sends
sender 1
1..*
receives
receiver 1
1..* {ordered} 0..*contains
1
0..*
0..*
0..*
0..*
fulfills
1
0..*
invokes
0..1
0..*
invokes
0..1
0..*
fulfills
0..*
0..*
0..*
intiates
1
Name:
Package:
Version:
Author:
Behavioral Model
Behavioral Model
v01r04
AbdulMalik Shakir

V3 Dynamic Model
 The v3 Dynamic Model provides behavioral context for static v3
message types. The v3 Dynamic Model is made up of:
1. Interactions
2. Storyboards and Storyboard Examples
3. Sender and Receiver Application Roles
4. Trigger Events
 An Interaction is an ordered collection of information exchanges
supporting one or more Use Cases outlined in a Storyboard.
 Interactions are initiated by a single Trigger Event and are
associated with one or more Application Roles.
 An Application Role is a collection of interaction exchanges. It
defines a generic interface specification to which a particular
healthcare application can conform.
 A UML sequence diagram is used to document application roles
and interactions.

An example Interaction Diagram
Application Roles
Interactions

v3 Dynamic Model
Example
Storyboard
Storyboard
Example
Application
Role
Sender Receiver
Trigger
Event
Triggers
Interaction
References

v3 Dynamic Model - Interaction
Example
Storyboard
Storyboard
Example
Application
Role
Sender Receiver
Trigger
Event
Triggers
Interaction
References

Interaction
 Interactions are at the heart of messaging.
 An interaction is a unique association between:
• a specific message type (information transfer)
• a particular trigger event that initiates or "triggers" the transfer
• the Receiver Responsibilities (in terms of response
interactions) associated with the receipt of the Interaction.
 Interactions are presented with a name, the artifact ID,
and a table that lists the sending and receiving
application roles, the trigger event, the message type, the
Event type and the Wrapper types.

Example Interaction Specification

Example Interaction
w/Receiver Responsibilities

v3 Dynamic Model
Example
Storyboard
Storyboard
Example
Application
Role
Sender Receiver
Trigger
Event
Triggers
Interaction
References

v3 Dynamic Model - Storyboard
Example
Storyboard
Storyboard
Example
Application
Role
Sender Receiver
Trigger
Event
Triggers
Interaction
References

Storyboard
 The storyboard concept is borrowed from the movie and animation
industry, and is useful to the development of HL7 messages for the
same reasons proven in that industry:
 A storyboard depicts a story using a series of "snapshots" or events in
chronological sequence;
 Each snapshot represents a recognizable, meaningful moment in the
sequence of events in a functional domain
 Each snapshot illustrates the key participants in the storyboard and
their interaction with other players;
 The whole series of snapshots provides a coherent description of a
complete process or activity.
 A storyboard narrative provides the necessary context for
development of specific interactions using a fictitious illustrative
storyboard example. The process of storyboarding lays the
foundation for describing HL7 messages and their content.

Example Storyboard
(Complex Laboratory Result (POLB_ST221000UV01)
 Storyboard Purpose
 To illustrate a complex laboratory result message involving a
substance administration and several specimen collections over a
period of time.
 A preliminary and final report will be messaged.
 Storyboard Narrative:
 Eve Everywoman, a 27-year-old female, presents at Good Health
Hospital Outpatient Clinic and is seen by Dr. Patricia Primary. Eve
reports extreme thirst, fatigue, and recent unexplained weight loss.
She also reports having a family history of diabetes. Dr. Patricia
Primary wants to rule out diabetes mellitus by performing a GTT2HR
 Sequence of Events:
1. Eve Everywoman, a 27-year-old female, presents at Good Health Hospital
Outpatient Clinic and is seen by Dr. Patricia Primary.
2. Eve reports extreme thirst, fatigue, and recent unexplained weight loss. She also
reports having a family history of diabetes.
3. Dr. Patricia Primary wants to rule out diabetes mellitus by performing a GTT2HR
(Two- Hour Glucose Tolerance Test).

v3 Dynamic Model
Example
Storyboard
Storyboard
Example
Application
Role
Sender Receiver
Trigger
Event
Triggers
Interaction
References

v3 Dynamic Model – Application Role
Example
Storyboard
Storyboard
Example
Application
Role
Sender Receiver
Trigger
Event
Triggers
Interaction
References

Application Role
 As an HL7 interaction is defined, one application role is assigned
responsibility for sending (initiating) that interaction, and one
application role is assigned responsibility to receive that interaction
and fulfill appropriate receiver responsibilities.
 The sending and receiving responsibilities for a particular interaction
may both be assigned to a single application role.
 Application roles are the basis of conformance statements and
conformance claims in a conformance profile.
 Application roles are realizations of actors in a use case scenario or
storyboard specification.
 An application role has a name, an artifact ID and a description.

Example Application Roles

Sending Application Role
Prescribing System (Prescription processing) (PORX_AR990101UV02)
Description
This is a system which supports a clinician with prescribing authority. This role specifically captures
those interactions pertaining to management.

Receiving Application Role
Dispensing System
(Prescription processing)
(PORX_AR990102UV02)
Description
This is a system which supports a
clinician with dispensing authority.
This role specifically captures those
interactions pertaining to
management.

Receiver Responsibility

v3 Dynamic Model
Example
Storyboard
Storyboard
Example
Application
Role
Sender Receiver
Trigger
Event
Triggers
Interaction
References

v3 Dynamic Model – Trigger Event
Example
Storyboard
Storyboard
Example
Application
Role
Sender Receiver
Trigger
Event
Triggers
Interaction
References

Trigger Event
 A trigger event is an explicit set of conditions that initiate the transfer
of information between system components (application roles).
 Trigger events have a specified Type, from the following list:
 State-Transition Based: Trigger events resulting from a state
transition as depicted in the State Transition Model for a particular
message interaction. The trigger for canceling a document, for
example, may be considered a State Transition Based trigger event
 Interaction Based: Trigger events can be based on another
interaction. For example, the response to a query (which is an
interaction) is an Interaction Based trigger event.
 User Request Based: Trigger events may be based on a user
request. For example, the trigger event that prompts a system to send
all accumulated data to a tracking system every 12 hours is
considered User Based.
 Trigger events have a name, artifact ID, description, and a type.

Example Trigger Event

State Machine
 The HL7 Reference Information
Model includes state machines for
the Entity, Role, Managed
Participation, and Act classes.
 A state machine specifies the
allowable states and valid state
transitions for a given class.
 A class transitions from one state
to another sometimes triggers one
or more interactions.

Act State Machine

Design-Level State Machine
 A design-level state machine defines the allowable states
and state transitions for the focal class of a design
information model.
 The design-level state machine is a proper subset of the
state machine associated with the Reference Information
Model (RIM) class that the DIM focal class is derived
from.
 An annotated version of the RIM class state machine is
used to depict the scope of a design level state machine.
 Design-level state machine annotations may include
optional alias term names for in-scope States and State
Transition triggers.

Example Design-Level State Machine
Result Activate (POLB_TE004102UV01)

State Transition
 State transitions are depicted by a line
with a arrowhead showing the
direction of the transition.
 An example of a state transition might
be the change in the state of an Act
from Active to Complete.
 The change in state is associated with
a trigger event that causes the
transition.
 The trigger event in this example is the
fulfillment of an order.
 An order is a special type of Act. The
transition from an Active order to a
Completed order is triggered by the
fulfillment of the Order.
 The state diagram depicts the states,
trigger event, and state transitions of
interest.

v3 Dynamic Model
Example
Storyboard
Storyboard
Example
Application
Role
Sender Receiver
Trigger
Event
Triggers
Interaction
References

RIM
Restrict
R-MIM
Serialize
HMD
Restrict
Message
Type
Example
Storyboard
Storyboard
Example
D-MIM
Derive
Application
Role
Sender Receiver
Trigger
Event
Triggers
Content
Interaction
References

StaticModel
RIM
Restrict
R-MIM
Serialize
HMD
Restrict
Message
Type
Example
Storyboard
Storyboard
Example
D-MIM
Derive
Application
Role
Sender Receiver
Trigger
Event
Triggers
Content
Interaction
References

StaticModel
v3 Dynamic Model - Message Type
Message
Type
Example
Storyboard
Storyboard
Example
Application
Role
Sender Receiver
Trigger
Event
Triggers
Content
Interaction
References

Example Interaction

HL7 v3 Dynamic Model
Interaction
TriggerEvent
CompositeMessageStructure
ReceiverResponsibilityTransportMessageType ControlActMessageType DomainContentMessageType
ApplicationRole
Interface HealthcareApplication
ConformanceSpecification
1..*
0..*
1..*1
«instantiate»
1
0..1
1 0..*
0..* 1
+sending
0..* 1
+recieving
1+recieving
0..*
1
0..*
0..1
0..* 0..*
0..* 0..*
1
Transport
Message
Type
Control
Message
Type
Content
Message
Type
Composite
Message
Structure
Trigger
Event
Interaction
Receiver
Responsibility
Application
Role
Interface
Healthcare
Application
Conformance
Specification

v3 Dynamic Model –
Composite Message Structure
Interaction
TriggerEvent
ApplicationRole
1..*
0..*
1..*1
«instantiate»
1
0..1
1 0..*
0..* 1
+sending
0..* 1
+recieving
1+recieving
0..*
1
0..*
0..1
0..* 0..*
0..* 0..*
1
Transport
Message
Type
Control
Message
Type
Content
Message
Type
Composite
Message
Structure
Trigger
Event
Interaction
Receiver
Responsibility
Application
Role
Interface
Healthcare
Application
Conformance
Specification

A Transport Message Type specifies the metadata
about an interaction that is necessary to establish
message identity and facilitate message routing.
A Control Message Type specifies additional optional
interaction metadata necessary to establish message
context (trigger event, timeframes, actors involved) .
A Content Message Type is the payload of the
interaction. It is the message instance containing the
data of primary interest to the exchange.
Transport
Message Type
Control
Message Type
Content
Message Type

Transport Message Type
 The Transport Message Type, also know as the transmission
wrapper, is required for all Version 3 messages.
 It contains a number of optional fields whose usage vary from one
context to another, (e.g., loosely coupled systems may require the
use of a larger set of attributes than tightly coupled systems).
 All Transmission Wrappers have mandatory attributes which identify
the sending and receiving systems of a message transmission
 Additional information about the Sender and Receiver may also be
transmitted, but the use of mandatory attributes ensures that a
Messaging Infrastructure has sufficient metadata to facilitate
message routing.
 The Transmission Wrapper in v3 is similar in function as the MSH
segment in v2.

Transport Message Type
 Optional Elements:
 SecurityText
 VersionCode
 ProfileId
 SequenceNumber
 AttachmentText
 RespondTo
 AttentionLine
 ControlActProcess
 Mandatory Elements:
 ID
 CreationTime
 InteractionId
 ProcessingCode
 ProcessingModeCode
 AcceptAckCode
 Receiver
 Sender

Interaction
TriggerEvent
ApplicationRole
1..*
0..*
1..*1
«instantiate»
1
0..1
1 0..*
0..* 1
+sending
0..* 1
+recieving
1+recieving
0..*
1
0..*
0..1
0..* 0..*
0..* 0..*
1
Transport
Message
Type
Control
Message
Type
Content
Message
Type
Composite
Message
Structure
Trigger
Event
Interaction
Receiver
Responsibility
Application
Role
Interface
Healthcare
Application
Conformance
Specification

Control Message Type
 The Control Message Type, also known as the control act wrapper,
provides interaction metadata required to establish message context
and facilitate appropriate processing by the receiving application.
 It also contains data that are useful to facilitate overall message
management and audit capabilities.
 In some exceptional cases there is no need for such information to
be included in the exchange. Therefore, the Control Message Type is
an optional component of the complex message structure.
 The control act wrapper in v3 is similar in function to the EVN
segment in v2.

Control Message Type Elements
 Id
 Code
 Text
 EffectiveTime
 PriorityCode
 ReasonCode
 LanguageCode
 Overseer
 authorOrPerformer
 DataEnterer
 InformationRecipient
 Subject
 ReasonOf

Interaction
TriggerEvent
ApplicationRole
1..*
0..*
1..*1
«instantiate»
1
0..1
1 0..*
0..* 1
+sending
0..* 1
+recieving
1+recieving
0..*
1
0..*
0..1
0..* 0..*
0..* 0..*
1
Transport
Message
Type
Control
Message
Type
Content
Message
Type
Composite
Message
Structure
Trigger
Event
Interaction
Receiver
Responsibility
Application
Role
Interface
Healthcare
Application
Conformance
Specification

Content Message
 A Content Message Type is the payload of the interaction. It is the
message instance containing the data of primary interest to the
exchange
 The Content Message is included in the Interaction as the subject of
a control act wrapper
 The linkage includes a reference to the entry point of the content
message message type:
 <xs:element name="actRequest" type="PORX_MT990020UV02.ActRequest"
nillable="true" minOccurs="1" maxOccurs="1"/>

Interaction
TriggerEvent
ApplicationRole
1..*
0..*
1..*1
«instantiate»
1
0..1
1 0..*
0..* 1
+sending
0..* 1
+recieving
1+recieving
0..*
1
0..*
0..1
0..* 0..*
0..* 0..*
1
Transport
Message
Type
Control
Message
Type
Content
Message
Type
Composite
Message
Structure
Trigger
Event
Interaction
Receiver
Responsibility
Application
Role
Interface
Healthcare
Application
Conformance
Specification

v3 Dynamic Model - Message Type
Message
Type
Example
Storyboard
Storyboard
Example
Application
Role
Sender Receiver
Trigger
Event
Triggers
Content
Interaction
References

Reference
Information
Model
Datatype
Specification
Vocabulary
Specification
Foundational
Models
Dynamic
Model
Constrained
Information
Model
Common
Message Type
Model
Design
Models
Hierarchical
Message
Definition
Message
Type
Definition
Implementation
Technology
Specification
Message
Specifications

HL7 Version 3.0
Constrained Information Model
A Constrained Information Model is an
information structure derived from the HL7
RIM that represents the information content for
a set of messages within a particular domain
area.

StaticModel
RIM
Restrict
R-MIM
Serialize
HMD
Restrict
Message
Type
Example
Storyboard
Storyboard
Example
D-MIM
Derive
Application
Role
Sender Receiver
Trigger
Event
Triggers
Content
Interaction
References

StaticModel
V3 Static Models
RIM
Restrict
R-MIM
Serialize
HMD
Restrict
Message
Type
D-MIM
Derive

Implementable Information Models
Constrained Information Models
V3 Static Models
RIM
Restrict
R-MIM
Serialize
HMD
Restrict
Message
Type
D-MIM
Derive
CIM
PIM
PSM

RIM
Account
name : ST
balanceAmt : MO
currencyCode : CE
DeviceTask
DiagnosticImage
Diet
energyQuantity : PQ
FinancialContract
amt : MO
InvoiceElement
netAmt : MO
factorNumber : REAL
pointsNumber : REAL
id : SET<II>
Observation
value : ANY
PatientEncounter
Procedure
PublicHealthCase
routeCode : CE
substitutionCode : CE
Supply
quantity : PQ
WorkingList
Container
heightQuantity : PQ
capTypeCode : CE
Device
softwareName : SC
localRemoteControlStateCode : CE...
alertLevelCode : CE
LivingSubject
birthTime : TS
deceasedInd : BL
deceasedTime : TS
organDonorInd : BL
lotNumberText : ST
Material
formCode : CE
strainText : ED
Organization
addr : BAG<AD>
Person
addr : BAG<AD>
raceCode : SET<CE>
Place
mobileInd : BL
addr : AD
directionsText : ED
positionText : ED
gpsText : ST
Access
targetSiteCode : CD
gaugeQuantity : PQ
Employee
jobCode : CE
jobTitleName : SC
jobClassCode : CE
salaryTypeCode : CE
salaryQuantity : MO
LicensedEntity
Patient
ActRelationship
typeCode : CS
inversionInd : BL
pauseQuantity : PQ
checkpointCode : CS
splitCode : CS
joinCode : CS
negationInd : BL
seperatableInd : BL
Act
classCode : CS
moodCode : CS
id : SET<II>
code : CD
negationInd : BL
derivationExpr : ST
text : ED
effectiveTime : GTS
activityTime : GTS
levelCode : CE
independentInd : BL
languageCode : CE
0..n
1
0..n
source1
0..n
1
inboundRelationship
0..n
target
1
languageCode : CE
modeCode : CE
preferenceInd : BL
Participation
typeCode : CS
functionCode : CD
negationInd : BL
noteText : ED
time : IVL<TS>
modeCode : CE
awarenessCode : CE
signatureCode : CE
signatureText : ED
performInd : BL
substitutionConditionCode : CE...
0..n
1
0..n
1
Entity
classCode : CS
determinerCode : CS
id : SET<II>
code : CE
quantity : SET<PQ>
name : BAG<EN>
desc : ED
telecom : BAG<TEL>
riskCode : CE
handlingCode : CE
1
0..n
1
0..n
RoleLink
typeCode : CS
Role
classCode : CS
id : SET<II>
code : CE
negationInd : BL
addr : BAG<AD>
telecom : BAG<TEL>
quantity : RTO
0..n
1
0..n
1
0..n0..1
playedRole
0..n
player
0..1
0..n
0..1
scopedRole
0..n
scoper
0..1
0..n
1
outboundLink 0..n
source1
0..n
1
inboundLink
0..n
target1
HMD
Constrained Information Model
D-MIM
PatientIncident
classCode*:<=ENC
moodCode*:<=EVN
id:[1..*](RegistNum)
code:CVCNE[0..1]<=ExternallyDefinedActCodes(PatientType)
statusCode:LIST<CS>CNE<=ActStatus(IDPHStatus)
activityTime:TS(EDDate)
Injury
classCode*:<=ACT
moodCode*:<=EVN
activityTime:TS(InjuryDate)
0..1pertinentInjury
typeCode*:<=PERT
TraumaRegistryExport
(IDPH_RM00001)
DatacontentofHL7
messagesusedtoexport
datafromtheIDPHTrauma
Registry.
PatientPerson
classCode*:<=PSN
name:PN[0..1](*Name)
existenceTime:(Age)
administrativeGenderCode:CVCWE<=AdministrativeGender
(GenderID)
birthTime:(DateOfBirth)
addr:AD[0..1](AddressHome)
raceCode:CVCWE[0..1]<=Race(RaceID)
ethnicGroupCode:CVCWE[0..1]<=Ethnicity(EthnicID)
1..1patientPatientPerson
1..1providerTraumaParticipant
Patient
classCode*:<=PAT
id:II[0..1](MedicaRecordNum)
TraumaParticipant
classCode*:<=ORG
id:[1..1](HospitNum)
code:CVCWE[0..1]<=EntityCode
name:ON[0..1](HospitName)
statusCode:CSCNE[0..1]<=EntityStatus(ActiveFacili)
addr:AD[0..1](HospitCity)
1..1patient
typeCode*:<=SBJ
subject
InjuryLocation
classCode*:<=PLC
code:CVCWE[0..1]<=EntityCode(InjuryPlaceID)
addr:AD[0..1](AddressScene)
0..1playingInjuryLocation
Role
classCode*:<=ROL
1..1participant
typeCode*:<=LOC
location
classCode*:<=OBS
moodCode*:<=EVN
priorityCode:CVCWE[0..1]<=ActPriority
value:[0..1]
0..*pertinentInjuryRelatedObservation
typeCode*:<=PERT
sequenceNumber:INT[0..1](InjurySequen)
Procedure
classCode*:<=PROC
moodCode*:<=EVN
code:CVCWE<=ActCode(ICDCodeID)
activityTime:TS(ProcedDate)
0..*pertinentProcedure
typeCode*:<=PERT
0..1medicalStaff
typeCode*:<=PRF
performer
MedicalStaff
classCode*:<=PROV
id:II[0..1](MedicalStaffID)
0..1procedureLocation
typeCode*:<=LOC
location
ProcedureLocation
classCode*:<=SDLOC
code:<=RoleCode(ProcedLocateID)
classCode*:<=OBS
moodCode*:<=EVN
code:<=ActCode
reasonCode:CVCWE[0..1]<=ActReason
value:ANY[0..1]
0..*pertinentPatientIncidentRelatedObservation
typeCode*:<=PERT
PatientTransfer
classCode*:<=TRNS
moodCode*:<=EVN
activityTime:IVL<TS>(DischaDatetoArriveDate)
reasonCode:CVCWE[0..1]<=TransferActReason(REASONTRANSFID)
1..1arrivalPatientTransfer
typeCode*:<=ARR
arrivedBy
0..*aRole
typeCode*:<=ORG
origin
0..1playingTraumaParticipant
aRole
classCode*:<=ROL
TransferRelatedObservation
classCode*:<=OBS
moodCode*:<=EVN
value:PQ[0..1]
1..*pertinentTransferRelatedObservation
typeCode*:<=PERT
1..1transferVehicle
typeCode*:<=VIA
via
TransferVehicle
classCode*:<=OWN
VehicleProvider
classCode*:<=ORG
id:II[0..1](VehiclProvide)
code:<=EntityCode(MaxVehiclLevelID)
name:ON[0..1](VehiclProvidName)
HospitalVisit
classCode*:<=ENC
moodCode*:<=EVN
code:CVCWE<=ActCode(AdmitServicID)
activityTime:TS(DischaDate)
dischargeDispositionCode:CVCWE[0..1]
<=EncounterDischargeDisposition
1..1pertinentHospitalVisit
typeCode*:<=PERT
HospitalVisitRelatedObservation
classCode*:<=OBS
moodCode*:<=EVN
value:[0..1]
0..*pertinentHospitalVisitRelatedObservation
typeCode*:<=PERT
1..1admittingProvider
typeCode*:<=ADM
admitter
AdmittingProvider
classCode*:<=PROV
id:II[0..1](ADMITMEDICASTAFFID)
0..*hospitalVisitPhysician
typeCode*:<=RESP
time:TS
responsibleParty
HospitalVisitPhysician
classCode*:<=PROV
id:II[0..1]
MedicalStaffPerson
classCode*:<=PSN
name:PN[0..1](MedicaStaffName)
0..1licensedEntity
typeCode*:<=DST
destination
0..1subjectChoice
LicensedEntity
classCode*:<=LIC
id:II[0..1]
Choice
Facility
classCode*:<=ORG
id:
code*:CSCNE<=EntityCode"FAC"
name:
Hospital
classCode*:<=ORG
id:
code*:CSCNE<=EntityCode"HOSP"
name:
EmergencyDepartmentEncounter
classCode*:<=ENC
moodCode*:<=EVN
dischargeDispositionCode:CVCWE<=EncounterDischargeDisposition
0..1pertinentEmergencyDepartmentEncounter
typeCode*:<=PERT
EmergencyDepartmentRelatedObservation
classCode*:<=OBS
moodCode*:<=EVN
text:
activityTime:TS
reasonCode:<=ActReason
value:[0..1]
targetSiteCode:CVCWE[0..1]<=HumanActSite
0..*pertinentEmergencyDepartmentRelatedObservation
typeCode*:<=PERT
0..*emergencyDepartmentPhysician
typeCode*:<=PRF
performer
0..1healthCareMedicalStaffPerson EmergencyDepartmentPhysician
classCode*:<=PROV
id:II[0..1]
code:CECWE[0..1]<=RoleCode(StaffTypeID)
classCode*:<=ENC
moodCode*:<=EVN
id:II[0..1](crashNum)
0..1priorPreHospitalEncounter
typeCode*:<=PREV
predecessor
PreHosptialRelatedObservation
classCode*:<=OBS
moodCode*:<=EVN
value:ANY[0..1]
0..*pertinentPreHosptialRelatedObservation
typeCode*:<=PERT
1..1preHospitalVehicle
typeCode*:<=ParticipationType
participant
PreHospitalVehicle
classCode*:<=OWN
0..*emergencyDepartmentPhysicianAct
typeCode*:<=COMP
component
EmergencyDepartmentPhysicianAct
classCode*:<=ACT
moodCode*:<=EVN
code:CSCNE[0..1]<=ExternallyDefinedActCodes
activityTime*:TS[0..1]
component
0..*patientIncidentRelatedObservation
typeCode*:<=COMP
VehicleProvider
MedicalStaffPerson
TraumaParticipant
R-MIM
PatientIncident
classCode*: <= ENC
moodCode*: <= EVN
id: [1..*] (RegistNum)
code: CV CNE <= ExternallyDefinedActCodes (PatientType)
statusCode: LIST<CS> CNE <= ActStatus (IDPHStatus)
activityTime: TS (EDDate)
Injury
classCode*: <= ACT
moodCode*: <= EVN
activityTime: TS (InjuryDate)
0..1 pertinentInjury
typeCode*: <= PERT
PatientPerson
classCode*: <= PSN
name: PN [0..1] (*Name)
existenceTime: (Age)
administrativeGenderCode: CV CWE <= AdministrativeGender
(GenderID)
birthTime: (DateOfBirth)
addr: AD [0..1] (AddressHome)
raceCode: CV CWE [0..1] <= Race (RaceID)
ethnicGroupCode: CV CWE [0..1] <= Ethnicity (EthnicID)
1..1 patientPatientPerson
1..1 providerTraumaParticipant
Patient
classCode*: <= PAT
id: II [0..1] (MedicaRecordNum)
TraumaParticipant
classCode*: <= ORG
id: [1..1] (HospitNum)
code: CV CWE [0..1] <= EntityCode
name: ON [0..1] (HospitName)
statusCode: CS CNE [0..1] <= EntityStatus (ActiveFacili)
addr: AD [0..1] (HospitCity)
1..1 patient
typeCode*: <= SBJ
subject
InjuryLocation
classCode*: <= PLC
code: CV CWE [0..1] <= EntityCode (InjuryPlaceID)
addr: AD [0..1] (AddressScene)
0..1 playingInjuryLocation
Role
classCode*: <= ROL
1..1 participant
typeCode*: <= LOC
location
classCode*: <= OBS
moodCode*: <= EVN
code: <= ExternallyDefinedActCodes
priorityCode: CV CWE [0..1] <= ActPriority
value: [0..1]
0..* pertinentInjuryRelatedObservation
typeCode*: <= PERT
sequenceNumber: INT [0..1] (InjurySequen)
classCode*: <= OBS
moodCode*: <= EVN
code: <= ActCode
reasonCode: CV CWE [0..1] <= ActReason
value: ANY [0..1]
0..* pertinentPatientIncidentRelatedObservation
typeCode*: <= PERT
component
0..* patientIncidentRelatedObservation
typeCode*: <= COMP

 Domain Message Information Models (D-MIMs) and
Refined Message Information Models (R-MIMs) are types
of Constrained Information Models (CIMs).
 Constrained information models are composed of class
clones that are a restricted subset of the HL7 RIM.
 Class clones contain a subset of the attributes and
relationships that are defined for the RIM class upon
which the clone is based.
 Multiple class clones based upon the same RIM class
may be included in a constrained information model.
 Each class clone in a constrained information model is
assigned a unique name.

Constrained Information Model Diagram
SubstanceAdministrationStep
classCode*: <= SBADM
moodCode*: <= x_ActMoodOrdPrmsEvn
id*: II [1..1]
code*: CE CWE <= SubstanceAdministrationActCode
text*:
statusCode*: CS CNE [0..1]
effectiveTime*: IVL<TS>
routeCode: <= RouteOfAdministration
doseQuantity: PQ
rateQuantity: PQ
1..1 manufacturedProduct *
typeCode*: <= CSM
consumable
1..1 manufacturedDrug *
0..1 manufacturerOrganization
ManufacturedProduct1
classCode*: <= MANU
Organization
classCode*: <= ORG
name*: ON [1..1]
Drug
classCode*: <= MMAT
code*: [1..1] <= DrugEntity (Drug code)
quantity:
desc:
 A Constrained Information Model
diagrams used a variety of visual
tools to document message
design.
 Entities, Roles, and Acts are
represented by rectangular
shapes colored Green, Yellow,
and Red respectively.
 Participations, Role Links, and
Act Relationships are
represented by arrow shapes
colored blue, gold, and pink
respectively.
 Bold font is used to denote
mandatory attributes.

V3 Constrained Information Model
A_AbnormalityAssessment
(COCT_RM420000UV)
Description: assessment of clinical findings, including lab test results,
for indications of the presence and severity of abnormal conditions
AbnormalityAssessment
classCode*: = "OBS"
moodCode*: = "EVN"
code*: CD CWE [1..1] <= V:ObservationType ("ADVERSE_REACTION")
statusCode*: CS CNE [1..1] <= V:ActStatusAbortedCancelledCompleted
activityTime*: TS.DATETIME [1..1]
value: CD CWE [0..1] <= V:AbnormalityAssessmentValue
methodCode: SET<CE> CWE [0..*] <= V:AbnormalityAssessmentMethod
1..* assessmentOutcome *
typeCode*: = "OUTC"
contextConductionInd*: BL [1..1] ="true"
outcome
AssessmentException
classCode*: = "OBS"
moodCode*: = "EVN"
code*: CD CWE [1..1] <= V:ObservationType ("ASSERTION")
value*: SC CWE [1..1] <= V:AssessmentExceptionValue
AbnormalityGrade
classCode*: = "OBS"
moodCode*: = "EVN"
code*: CD CWE [1..1] <= V:ObservationType ("SEV")
uncertaintyCode: CE CNE [0..1] <= V:ActUncertainty
value*: CD CWE [1..1] <= V:AbnormalityGradeValue
AssessmentOutcome
0..* assessmentOutcomeAnnotation
typeCode*: = "APND"
appendageOf
AssessmentOutcomeAnnotation
classCode*: = "OBS"
moodCode*: = "EVN"
value*: SC CWE [1..1] <= V:AssessmentOutcomeAnnotationValue
Model Components
 Entry Point(s)
 Clones
• Focal Class
• Traversal Path
• Choice Structure
 Attributes
• Datatype
• Cardinality
• Terminology Binding

Discovery of the underlying meta-model
(COCT_RM420000UV)
classCode*: = "OBS"
moodCode*: = "EVN"
typeCode*: = "OUTC"
outcome
AssessmentException
classCode*: = "OBS"
moodCode*: = "EVN"
AbnormalityGrade
classCode*: = "OBS"
moodCode*: = "EVN"
AssessmentOutcome
typeCode*: = "APND"
appendageOf
classCode*: = "OBS"
moodCode*: = "EVN"
«clone»
Class
localName: char
fixedName: char
businessName: char
comment: Annotation
isEntryPointIndicator: boolean
isStubIndicator: boolean
«RIM»
Class
name: char
description: Annotation
«clone»
Attribute
businessName: char
datatype: DataType
cardinality: Cardinality
conformance: Conformance
comment: Annotation
initialValue: char
initialValueRole: ValueRole
maximumLength: int
«RIM»
Attribute
name: char
datatype: DataType
mandatoryInclusionIndicator: boolean
«RIM»
Relationship
name: char
relationshipType: RelationshipType
«clone»
Relationship
ConstrainedInformationModel
name: char
modelType: ModelType
ControllingAttribute
constraints
{datatype = CS}
{cardinality = (1..1)}
{conformance = Mandatory}
{codingStrength = CNE}
{terminologyReference = CodeSystem}
«RIM»
AssociationEnd
roleName: char
multiplicity: Cardinality
navigabilityIndicator: boolean
«clone»
TraversalPath
name: char
enabledIndicator: boolean
requiredIndicator: boolean
mandatoryIndicator: boolean
«enumeration»
Cardinality
0..1
0..n
0..*
1
1..1
1..n
1..*
n..m
n..*
«enumeration»
RelationshipType
Generalization
Association
Composition
Aggregation
«clone»
Choice
name: char
nameExtension: char
«enumeration»
Conformance
Optional
Required
Mandatory
«enumeration»
ValueRole
Fixed
Default
«enumeration»
ModelType
DMIM = Domain Message ...
RMIM = Refined Message...
CMET = Common Message ...
HMD = Hierarchical Me...
0..*
associates source
1
«restrict»
1..*
0..*
associates target
1
0..*
associates target
1
0..*
associates source
1
0..*
isDerivedFrom
1
0..*
{ordered}
1..*
{ordered}
0..*
isDerivedFrom
1
0..*
isDerivedFrom
1
0..*
isDerivedFrom
root1
1..*
0..1
0..*
isDerivedFrom
1
2
0,2

HL7 CIM Clones, Attributes, and Traversals
«clone»
Class
localName: char
fixedName: char
businessName: char
comment: Annotation
isEntryPointIndicator: boolean
isStubIndicator: boolean
«RIM»
Class
name: char
«clone»
Attribute
businessName: char
datatype: DataType
comment: Annotation
initialValue: char
maximumLength: int
«RIM»
Attribute
name: char
datatype: DataType
«RIM»
Relationship
name: char
relationshipType: RelationshipType
«clone»
Relationship
ConstrainedInformationModel
name: char
modelType: ModelType
constraints
{datatype = CS}
«RIM»
AssociationEnd
roleName: char
navigabilityIndicator: boolean
«clone»
TraversalPath
name: char
enabledIndicator: boolean
requiredIndicator: boolean
mandatoryIndicator: boolean
«enumeration»
Cardinality
0..1
0..n
0..*
1
1..1
1..n
1..*
n..m
n..*
«enumeration»
RelationshipType
Generalization
Association
Composition
Aggregation
«clone»
Choice
name: char
nameExtension: char
«enumeration»
Conformance
Optional
Required
Mandatory
«enumeration»
ValueRole
Fixed
Default
«enumeration»
ModelType
DMIM = Domain Message ...
RMIM = Refined Message...
CMET = Common Message ...
HMD = Hierarchical Me...
0..*
associates source
1
«restrict»
1..*
0..*
associates target
1
0..*
associates target
1
0..*
associates source
1
0..*
isDerivedFrom
1
0..*
{ordered}
1..*
{ordered}
0..*
isDerivedFrom
1
0..*
isDerivedFrom
1
0..*
isDerivedFrom
root1
1..*
0..1
0..*
isDerivedFrom
1
2
2

HL7 CIM Terminology and Datatype
«clone»
Attribute
businessName: char
datatype: DataType
comment: Annotation
initialValue: char
maximumLength: int
«RIM»
Attribute
name: char
datatype: DataType
constraints
{datatype = CS}
«RIM»
TerminologyBinding
codingStrength: CodingStrength
«clone»
TerminologyBinding
TerminologyReference
{abstract}
name: char
VocabularyDomain
ValueSet
conceptIdentifier: char
CodeSystem
objectIdentifier: char
releaseIdentifier: char
isExternalIndicator: boolean
CodeSystemTerm
code: char [0..1]
designation: char
internalIdentifier: char
DataType
longName: char
shortName: char
DatatypeAttribute
name: char
datatype: DataType
ParentDatatype
«datatype»
TerminologyBinding
Annotation
{abstract}
«enumeration»
CodingStrength
CNE
CWE
ParentCodeSystemTerm
AnnotationSection
sectionRole: AnnotationSectionRole
sectionText: char
«enumeration»
AnnotationSectionRole
Description
Rationale
Design Comment
Issue
Implementation Note
History
Mapping
0..*
binds
1
0..1
binds
1
0..1
binds
1
0..*
isDerivedFrom
1
«restrict»
0..*
isDerivedFrom
1
0..*
binds
1
1..*
subkind
1..*
0..*
0..*
binds
1
0..1
binds
1
0..*
0..*
isBoundTo
1
member
1..*0..*
1..*
subkind
1..*
0..1

CIM Retrospective
 A Constrained information models is a constrained subset of the HL7
Reference Information Model.
 CIM Classes (clones) contain a subset of the attributes and
relationships that are defined for the RIM class upon which the clone is
based.
 CIM Attributes constrain the cardinality, datatypes, and terminology
bindings defined for the RIM attribute upon which the CIM attribute is
based.
 The information needs for a CIM are typically expressed in a Domain
Analysis model that has been cross referenced to the RIM.
 Types of Constrained Information Models include:
 Domain Message Information Models (D-MIMs)
 Refined Message Information Models (R-MIMs)

V3 Constrained Information Models
RIM
Restrict
R-MIM
Serialize
HMD
Restrict
Message
Type
D-MIM
Derive

Reference
Information
Model
Datatype
Specification
Vocabulary
Specification
Foundational
Models
Dynamic
Model
Constrained
Information
Model
Common
Message Type
Model
Design
Models
Hierarchical
Message
Definition
Message
Type
Definition
Implementation
Technology
Specification
Message
Specifications

HL7 Version 3.0
Common Message Element Type
A Common Message Type Model is a definition
of a set of common message components that
can be referenced in various message
specifications.

Common Message Element Types
 A Common Message Element Type (CMET) is a fragment of a
constrained information model (CIM) that is intended to be
included in other constrained information models by reference.
 Common Message Element types provide a means of
constructing reusable building blocks to be used across a range
of domain areas and message types.
 Usage of CMETs increases the consistency of message types
developed by separate workgroups and project teams.
 CMETs accelerate the development process by reducing the
need to redesign information structures that have already been
developed.
 A CMET model has one entry point. It is included in other design
information models by reference to its entry point name.

CMET Reference
Accession
classCode*: <= ACSN
moodCode*: <= EVN
id*: II [1..1]
CMET: (AGNT)
R_Responsible
[universal]
(COCT_MT040000)
0..1 roleName
1..1 agent *
typeCode*: <= AUT
author
CMET
R-MIM

CMET Retrospective
 Technically a CMET is just another type of
constrained information model.
 A CMET has a single entry point and is always
serializable. It is a special type of RMIM.
 CMETs differs from other RMIMs in that they are
domain area agnostic.
 CMETs are balloted as domain independent
artifacts.
 Their status as DSTU or Normative is dependent
upon the status of RMIMs and DMIMs that
reference them.

Reference
Information
Model
Datatype
Specification
Vocabulary
Specification
Foundational
Models
Dynamic
Model
Constrained
Information
Model
Common
Message Type
Model
Design
Models
Hierarchical
Message
Definition
Message
Type
Definition
Implementation
Technology
Specification
Message
Specifications

An Hierarchical Message Definition is a specification
of message elements including a specification of their
grouping, sequence, optionality, and cardinality.
A Message Type Definition is a specification of a
collection of message elements and a set of rules for
constructing a message instance.
The Implementation Technology Specification, or ITS,
defines how to represent RIM objects for transmission
in messages.
Hierarchical
Message
Definition
Message
Type
Definition
Implementation
Technology
Specification

HL7 V3 Hierarchical Message
Definition
An Hierarchical Message Definition is a
specification of message elements including a
specification of their grouping, sequence,
optionality, and cardinality.

V3 Hierarchical Message Definition
 An HMD is a tabular representation of the sequence of
elements (i.e., classes, attributes and associations)
represented in an R-MIM.
 It defines the message without reference to the
implementation technology.
 The HMD defines a single base message structure - the
"common" message type.
 This base message structure is never sent and thus has
no corresponding trigger event.
 It is the template from which the other specific and
corresponding message types are drawn.

Hierarchical Message Definition

HMD Components
InformationModelMapping
MessageElementSpecifications
CommonConstraints
MessageTypeSpecification(S)

HMD Components
MappingtotheInformationModel
CommonConstraints

HMD Columns

HMD Columns (A – F)
ColHeading Description
A (row type) Each row represents either a class, an association or an attribute from
the R-MIM. Class rows have their name displayed in bold; associations
have their name in italics; and attributes have their names in plain font.
B No Row number. Each row is sequentially numbered and identifies the order
in which the data were serialized from the R-MIM.
C Element Name The name of the element as it appears in the R-MIM. This may or may
not be the same as the value in Property. This value will be different
when a class, association or role is cloned and renamed in the process of
creating the R-MIM.
D Card Cardinality. This specifies the minimum and maximum number of
occurrences of the message element.
E Mand Mandatory. Valid values are M (Mandatory) or Blank. An M in the field
requires that some data be sent for this element. If the data is not
known, a value of unknown, not given, etc. must be sent. An M in this
column (for Mandatory) differs from a 1 in the Cardinality column in that
an M indicates that the message cannot be validly parsed without a value
in this field or without defining a default. If no default is provided, you
either do not send a message or must send a value. An M in this column
also differs from an R in the Conformance column (explained below).
F Conf Conformance. Valid values are R (required), NP (not permitted), and
Blank (not required). A value of R(required) means that the message
elements must appear every time the message description is used for an
Interaction. If the data is available, the element must carry the data. If
the data is not available, a blank may be sent. NP (not permitted) means
that the message element is never sent for this essage type. Blank
means that conformance for this element is to be negotiated on a site-
specific basis.

HMD Columns (G – M)
ColHeading Description
G RIM Source Identifies the class from which the attribute or association
originates.
H Of Message Element Type This column identifies the data type of attributes or class
name of associations.
I SRC Message Element Type Source. Valid values are D (data
type), N (new, being defined starting at this row), U (use,
meaning that an element, but not its value, from a previous
row in the HMD is being reused), C (CMET), I (Instance,
refers to the reuse of a particular element and its value as
defined previously in the HMD), and R (recursive, into itself).
J Domain Vocabulary Domain Specification. Clicking on this link will
take you to the Domain Specification for this element.
K CS Coding Strength. Valid values are CWE (coded with
extensions, meaning that the code set can be expanded to
meet local implementation needs) and CNE (coded no
extensions, meaning that the code set cannot be expanded).
L Abstract Is a boolean assigned to classes or associations in a gen-
spec hierarchy, which becomes a choice in an HMD. If the
value is true, then this type may not appear in message
instances.
M Nt Note. If one is provided, this is simply a free text note
provided by the work group.

Constraint Descriptions
Constraint Description
Cardinality This specifies the minimum and maximum number of occurrences of the field/association. For
example, 1..* implies the minimum number of occurrences is 1 whereas the maximum number of
occurrences is unlimited.
Mandatory Valid values are M (mandatory) or Blank (not mandatory). M (mandatory) means that the
field/association must be present in the message, otherwise the message is non-conformant. For
Mandatory fields, HL7 sets the minimum cardinality to 1. Blank (not mandatory) means that the
field/association need not be present in a conformant message.
Conformance Valid values are R (required), NP (not permitted), and Blank (optional). R (required) means that the
sending application must support this field/association. If the data is available, then the
field/association is included in the message. If the minimum cardinality is 0 and the data is not
available, the field/association may be omitted from the message and still be conformant. If the
minimum cardinality is 1 and the data is not available, a NullFlavor is required. NP (not permitted)
means that the field/association is not included in the message schema and never included in a
message instance. Blank (optional) means that the field/association may/may not be sent and
support for this field/association is not required of sending applications. Conformance for this
element is to be negotiated on a site-specific basis.
NullFlavor For required fields/associations with a minimum cardinality of 1, a NullFlavor must be sent for
fields/associations that are not available to a sending application. Sample Nullflavors are "no
information", "unknown", "masked", "not asked" and "asked, but unknown".

Cardinality Requirements
Cardinality Mandatory Conformance
NullFlavor
Required?
Explanation of Rules
0.., 1.. No The field/association may or may not be
present in a message. Conformance for this
element is to be negotiated on a site-specific
basis
0.., 1.. NP Not allowed The field/association is not present in the
schema and cannot be included in a message
instance.
0.. R No Support for the field/association is required in a
sending application. The field/assocation may
or may not be present in a message.
1.. R Yes Support for the field/association is required in a
sending application. The field/assocation must
be present in a message, but may not be
valued. If the field/assocation is not valued, a
NullFlavor must be specified.
1.. M R Not Allowed Support for the field/association is required in a
sending application. NullFlavor may not be
specified. The field/association must be
present and valued in a message.

Reference
Information
Model
Datatype
Specification
Vocabulary
Specification
Foundational
Models
Dynamic
Model
Constrained
Information
Model
Common
Message Type
Model
Design
Models
Hierarchical
Message
Definition
Message
Type
Definition
Implementation
Technology
Specification
Message
Specifications

HL7 Version 3.0
Message Type Definition
A Message Type Definition is a specification of
a collection of message elements and a set of
rules for constructing a message instance.

Message Type Definition
 An HMD contains one or more message type definition.
 Each message type definition includes the collection of
message elements defined in the HMD.
 The message type inherits or overrides aspects of the
common constraints defined in the HMD.
 Message elements defined in the HMD can be eliminated
from the message type definition by specifying “NP” for
conformance.
 Each message type definition is independent of each
other.
 A message type definition may be referenced in one or
more interaction specification.

Reference
Information
Model
Datatype
Specification
Vocabulary
Specification
Foundational
Models
Dynamic
Model
Constrained
Information
Model
Common
Message Type
Model
Design
Models
Hierarchical
Message
Definition
Message
Type
Definition
Implementation
Technology
Specification
Message
Specifications

Implementation
Technology Specification
The Implementation Technology Specification,
or ITS, defines how to represent RIM objects
for transmission in messages.

Implementation Technology Specification
 HL7 v3 uses XML as the implementation technology for messaging.
The XML ITS specifies the wire format for HL7 messages.
 The ITS provides encodings for all the types of component that are
defined in an HL7 message specification.
 The XML schema specifies what is acceptable in an XML document
through defining constraints.
 The schema for an HL7 message can be used by standard XML
tools to determine whether any particular HL7 message is valid
according to that particular schema.
 The most extensive part of the ITS definition is for data types where
specific schema fragments have been defined against each of the
Data Types that HL7 supports.

XML Implementation Technology
Specification

Essential XML ITS Transformation Rules
 All XML elements and attributes are to be represented in the namespace
defined by "urn:hl7-org:v3".
 The XML representation for the members of a class will be a sequence of
child elements, one for each attribute followed by one for each outbound
association.
 Where the HL7 static model allows for an association to a choice of classes,
the representation of the XML shall be the same as would be the case if
there had been no choice, and only the class corresponding to the
information items in the HL7 instances were included in the specification.
 All HL7 RIM structural attributes are represented as XML attributes. All other
HL7 RIM attributes are represented as XML elements.
 The type of the HL7 attribute will be one of the types defined in the ISO
datatypes. That specification includes a definition of the XML serialization to
be used.
 When included in an instance local extensions MUST be in a namespace
other than the HL7v3 namespace.

HL7 Vocabulary
Specification
HL7 Data Type
Specification
HL7 XML
Schema
Generator
Definition
XML Schema
Specification

Reference
Information
Model
Datatype
Specification
Vocabulary
Specification
Foundational
Models
Dynamic
Model
Constrained
Information
Model
Common
Message Type
Model
Design
Models
Hierarchical
Message
Definition
Message
Type
Definition
Implementation
Technology
Specification
Message
Specifications

HL7 V3 Message Specification
Design Example
Pharmacy OTC Sales Data

Purchase date Units Category Promotion Zipcode County State Reporting stores Participating stores
20040109 5 Cough/Cold N 88019 Some County XX 1 1
20040109 1 Thermometers N 88019 Some County XX 1 1
20040110 27 Cough/Cold Y 88245 Some County XX 1 1
20040110 1 Baby/Child Electrolytes N 88245 Some County XX 1 1

Purchase date Units Category Promotion Zipcode County State Reporting stores Participating stores
20040110 27 Cough/Cold Y 88245 Some County XX 1 1
• Purchase Date
• Units
• Product Category
• Promotion Indicator
• Postal Zone
• County
• State
• Reporting Stores
• Participating Stores

Pharmacy OTC Sales Domain Analysis
Model
ProductType
- categoryCode : String
OTCSale
- unitsSold : Integer
- purchaseDate : Date
- promotionIndicator : Boolean
1
0..n
1
0..n
ReportingPharmacy
- count : Integer
1
1..n
1
1..n
ParticipatingPharmacy
- count : Integer
PostalZone
- ZipCode : String
1 1..n
1
0..1
1
0..1
County
- name : String
1
1..n
State
- name : String
1
1..n
1
1..n
1
1..n
1 1..n
OTC Sales
Domain Analysis Model
3/30/2004

Pharmacy OTC Sales R-MIM
OTCSaleEvent
classCode *: <= SPLY
moodCode*: <= EVN
activityTime *: TS[1..1] (PurchaseDate)
quantity*: PQ[1..1] (UnitsSold)
1..1 retailedProduct *
typeCode *: <= SBJ
subject
1..1 retailedManufacturedMaterialKind *
1..1retailerReportingPharmacy *
RetailedProduct
classCode *: <= RET
ManufacturedMaterialKind
classCode *: <= MMAT
determinerCode *: <= KIND
code*: CSCNE[1..1] <=ProductEntityType(Category )
ReportingPharmacy
classCode *: <= ORG
determinerCode *: <= QUANTIFIED_KIND
quantity *:PQ[0..1](Count)
PostalArea
classCode *: <= PLC
determinerCode *: <= INSTANCE
id*:II [1..1](PostalZone)
1..1 location *
ReportingPharamacyLocation 1..1 playedReportingPharamacyLocation *
classCode *: <= LOCE
ParticipatingPharmacy
classCode *: <= ORG
determinerCode *: <= QUANTIFIED_KIND
quantity*: PQ[1..1] (Count)
1..1locatedParticipatingPharmacy *
ParticipatingPharmacyLocation
0..1scopedParticipatingPharmacy Location
classCode *: <= LOCE
OTCSalesEventData
(PHIM_RM000001)
Description
Ov er-the-counter pharmacy product
saledata.
OTC Pharmacy Product Sales Events
RM000001v5
3/30/04
County
classCode *: <= COUNTY
name *:TN[1..1](County Name)
State
classCode *: <= PROVINCE
name *:TN [1..1](StateName)
1..1wholeCounty
PartOfCounty
1..1 playedPartOfCounty *
classCode *: <= PART
1..1 wholeState
PartOfState 1..1 playedPartOfState *
classCode *: <= PART
1..1 pertinentPromotion *
typeCode *: <= PERT
Promotion
classCode *: <= COND
moodCode*: <= EVN
value*:BL[1..1](PromotionIndicator)

Pharmacy OTC Sales HMD
No Element Name Rim Source of Message Element Type Domain CS Nt
(Link to tabular view)
OTCSalesEventData
1 OTCSaleEvent Supply OTCSaleEvent
2 classCode Act CS SPLY CNE
3 moodCode Act CS EVN CNE
4 activityTime Act TS DesignNote: PurchaseDate
5 quantity Supply PQ DesignNote: UnitsSold
6 subject Act Subject
7 typeCode Participation CS SBJ CNE
8 retailedProduct Participation RetailedProduct
9 classCode Role CS RET CNE
10 retailedManufacturedMaterialKind Role ManufacturedMaterialKind
11 classCode Entity CS MMAT CNE
12 determinerCode Entity CS KIND CNE
13 code Entity CS ProductEntityType CNE DesignNote: Category
14 retailerReportingPharmacy Role ReportingPharmacy
15 classCode Entity CS ORG CNE
16 determinerCode Entity CS QUANTIFIED_KIND CNE
17 quantity Entity PQ DesignNote: Count
18 playedReportingPharamacyLocation Entity ReportingPharamacyLocation
19 classCode Role CS LOCE CNE
20 location Role PostalArea
21 classCode Entity CS PLC CNE
22 determinerCode Entity CS INSTANCE CNE
23 id Entity II DesignNote: PostalZone
24 playedPartOfCounty Entity PartOfCounty
25 classCode Role CS PART CNE
26 wholeCounty Role County
27 classCode Entity CS COUNTY CNE
29 name Entity TN DesignNote: CountyName
30 playedPartOfState Entity PartOfState
31 classCode Role CS PART CNE
32 wholeState Role State
33 classCode Entity CS PROVINCE CNE
35 name Entity TN DesignNote: StateName
36 scopedParticipatingPharmacyLocation Entity ParticipatingPharmacyLocation
37 classCode Role CS LOCE CNE
38 locatedParticipatingPharmacy Role ParticipatingPharmacy
39 classCode Entity CS ORG CNE
40 determinerCode Entity CS QUANTIFIED_KIND CNE
41 quantity Entity PQ DesignNote: Count
42 pertinentInformation Act PertinentInformation
43 typeCode ActRelationship CS PERT CNE
44 pertinentPromotion ActRelationship Promotion
45 classCode Act CS COND CNE
46 moodCode Act CS EVN CNE

Pharmacy OTC Sales XML Schema
<?xml version="1.0" encoding="UTF-8" standalone="no" ?>
- <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:hl7-org:v3" elementFormDefault="qualified" xmlns="urn:hl7-
org:v3" xmlns:voc="urn:hl7-org:v3/voc" xmlns:hl7="urn:hl7-org:v3"
xmlns:msg="urn:hl7-org:v3/mif" xmlns:fo="http://www.w3.org/1999/XSL/Format">
<xs:include schemaLocation="../dt/datatypes.xsd" />
<xs:include schemaLocation="../voc/voc.xsd" />
- <xs:group name="PHIM_MT000001">
- <xs:sequence>
<xs:element name="OTCSaleEvent" type="PHIM_MT000001.OTCSaleEvent" />
</xs:sequence>
</xs:group>
- <xs:complexType name="PHIM_MT000001.OTCSaleEvent">
- <xs:sequence>
<xs:element name="activityTime" minOccurs="1" maxOccurs="1" type="TS" />
<xs:element name="quantity" minOccurs="1" maxOccurs="1" type="PQ" />
<xs:element type="PHIM_MT000001.Subject" minOccurs="1" maxOccurs="1"
name="subject" />
<xs:element type="PHIM_MT000001.PertinentInformation" minOccurs="1"
maxOccurs="1" name="pertinentInformation" />
</xs:sequence>
<xs:attribute name="type" type="Classes" default="Supply" />
<xs:attribute name="classCode" type="ActClass" />
<xs:attribute name="moodCode" type="ActMood" />
</xs:complexType>
- <xs:complexType name="PHIM_MT000001.Subject">
- <xs:sequence>
<xs:element type="PHIM_MT000001.RetailedProduct" minOccurs="1" maxOccurs="1"
name="retailedProduct" />
</xs:sequence>
<xs:attribute name="type" type="Classes" default="Participation" />
<xs:attribute name="typeCode" type="ParticipationType" />
</xs:complexType>
- <xs:complexType name="PHIM_MT000001.RetailedProduct">
- <xs:sequence>
<xs:element type="PHIM_MT000001.ManufacturedMaterialKind" minOccurs="1"
maxOccurs="1" name="retailedManufacturedMaterialKind" />
<xs:element type="PHIM_MT000001.ReportingPharmacy" minOccurs="1"
maxOccurs="1" name="retailerReportingPharmacy" />
</xs:sequence>
<xs:attribute name="type" type="Classes" default="RoleHeir" />

Pharmacy OTC Data XML Example
<?xml version="1.0" encoding="utf-8" standalone="no" ?>
- <OTCSaleEvent xmlns="urn:hl7-org:v3"
xmlns:xsi="http://www.w3.org/2002/XMLSchema-instance"
xsi:schemaLocation="urn:hl7-org:v3 PHIM_HD000001.xsd">
<activityTime value="20040109" />
<quantity value="5" unit="" />
- <subject>
- <retailedProduct>
- <retailedManufacturedMaterialKind>
<code code="Cough/Cold" />
</retailedManufacturedMaterialKind>
- <retailerReportingPharmacy>
- <playedReportingPharamacyLocation>
- <location>
<id root="2.16.840.1.113883.19.3.2409" extension="88019" displayable="true" />
- <playedPartOfCounty>
- <wholeCounty>
<name>Some County</name>
- <playedPartOfState>
- <wholeState>
<name>CA</name>
</wholeState>
</playedPartOfState>
</wholeCounty>
</playedPartOfCounty>
- <scopedParticipatingPharmacyLocation>
- <locatedParticipatingPharmacy>
</locatedParticipatingPharmacy>
</scopedParticipatingPharmacyLocation>
</location>
</playedReportingPharamacyLocation>
</retailerReportingPharmacy>
</retailedProduct>
</subject>
- <pertinentInformation>
- <pertinentPromotion>
<value value="false" />
</pertinentPromotion>

HL7 V3 Modeling Tools

Rational
Rose
Reference
Model
Repository
RoseTree
R-MIM
Designer
Schema
Generator
RIM RIM
R-MIM
RIM
R-MIM
HMD HMD
XSD

V3 RMIM Design Tool

MS-Visio R-MIM Designer

HL7 R-MIM Designer Stencil

IDPH-TRE R-MIM

Clone Properties

Attribute Properties

Save RMIM to MIF Repository

V3 RoseTree (Model Browser)

RoseTree RMIM Browser

RoseTree HMD Generator

Generated HMD

Multiple Message Types

RoseTree HMD Export

MS-Excel HMD

V3 Schema Generator

HL7 Vocabulary
Specification
HL7 Data Type
Specification
HL7 XML
Schema
Generator
Definition
XML Schema
Specification

Rational
Rose
Reference
Model
Repository
RoseTree
R-MIM
Designer
Schema
Generator
RIM RIM
R-MIM
RIM
R-MIM
HMD HMD
XSD
R-MIM

HL7 Vocabulary
Specification
HL7 Data Type
Specification
HL7 XML
Schema
Generator
XML Schema
Specification
Refined Message
Information ModelHierarchical Message
Definition

HL7 V3 Message Specification Core
Schema

Core Schema
Our
Schema
Infrastructure
Root.XSD
Datatype.XSD
Datatype-
base.XSD
Voc.XSD
Include Include
Include Include Include
Include
Core Schema
 Our generated schema is used in conjunction with core schema
specifications provided by HL7.
 The core schema specifications include infrastructure root, datatype
base, datatype, and vocabulary.
 The core schema specifications include no domain content. They are
present only to facilitate interpretation of datatypes and validation of
structural vocabulary.

InfrastructureRoot.xsd

Datatype.xsd

Datatype-base.xsd

Voc.xsd

Core Schema
Our
Schema
Infrastructure
Root.XSD
Datatype.XSD
Datatype-
base.XSD
Voc.XSD
Include Include
Include Include Include
Include
Core Schema

HL7 Vocabulary
Specification
HL7 Data Type
Specification
HL7 XML
Schema
Generator
XML Schema
Specification
Refined Message
Information Model
Datatype.XSD
Voc.XSD

Rational
Rose
Reference
Model
Repository
RoseTree
R-MIM
Designer
Schema
Generator
RIM RIM
R-MIM
RIM
R-MIM
HMD HMD
XSD
R-MIM

V3 Design Tools

Electronic Services and Tools Workgroup

SESSION OVERVIEW
 Messaging Artifacts ECCF
 Foundational Artifacts
 Design Artifacts
 Specification Artifacts
 HL7 v3 Message Design Example
 HL7 v3 Development Tools

Hi3 Solutions
300
Burbank, CA 91505
6520

History, Rationale, and Future
HL7 v3 Clinical Document
Architecture

SESSION OVERVIEW
• KEY ASPECTS OF CDA
• EARLY HISTORY OF CDA
• CDA SPECIFICATION FRAMEWORK
• TEMPLATED CDA AND IMPLEMENTATION GUIDES
• SAMPLE HL7 V3 CDA ARTIFACTS
• CONSOLIDATED CDA IMPLEMENTATION GUIDE

Clinical Document Architecture (CDA)
 The HL7 Clinical Document Architecture (CDA) is a
document markup standard that specifies the structure
and semantics of "clinical documents" for the purpose of
exchange.
 A clinical document contains observations and services
and has the following characteristics:
 Persistence – A clinical document continues to exist in an unaltered
state, for a time period defined by local and regulatory requirements.
 Stewardship – A clinical document is maintained by an organization
entrusted with its care.
 Potential for authentication - A clinical document is an assemblage
of information that is intended to be legally authenticated.
 Context - A clinical document establishes the default context for its
contents.
 Wholeness - Authentication of a clinical document applies to the
whole and does not apply to portions of the document without the full
context of the document.
 Human readability – A clinical document is human readable.

Clinical Document Architecture (CDA)
 A CDA document is a defined and complete
information object that can include text, images,
sounds, and other multimedia content.
 Key aspects of the CDA include:
 CDA documents are encoded in Extensible Markup
Language (XML).
 CDA documents derive their meaning from the HL7
Reference Information Model (RIM) and use the HL7
Version 3 Data Types.
 The CDA specification is richly expressive and
flexible. Document-level, section-level and entry-
level templates can be used to constrain the generic
CDA specification

A Brief History of CDA
 1997 – HL7 SGML SIG begins work on the
Patient Record Architecture
 1998 – Patient Record Architecture draft
 1999 – CDA Release 1.0 Approved by HL7
Membership
 2000 – CDA Release 1.0 adopted as an
American National Standard
 2000 – HL7 XML SIG becomes Structured
Documents Technical Committee
 2005 – Clinical Document Architecture
Release 2 Adopted
 2006 – Care Record Summary
Implementation Guide
 2007 – Continuity of Care Document
 2008 – Recognition of HL7 CDA by the
Secretary of HHS
 2008 – Submission of CDA to ISO TC-215
 2009 – ISO TC-215 Approves CDA as an ISO
Standard
 2010 – CDA reaffirmed by HL7 and ANSI as
an American National Standard
 2011 – Consolidated CDA Implementation
Guide
 2012 - HL7 Releases New Tool for Reviewing
CDA Templates
 2013 - HL7 Announces a CCD® to Blue
Button Transform Tool
 2014 – Consolidated CDA R2 DSTU
published

Early History of the CDA
 CDA® grew out of work that originated outside of HL7 in early 1996 when a
group of physicians including Tom Lincoln, John Spinosa, Dan Essin, John
Mattison and Bob Dolin began to meet to discuss the potential for structured
markup in clinical documents.
 The earliest draft was called the Kona Architecture and was developed in
1997 after the group had joined HL7.
 Since that time, many people have worked on it and the basic ideas have
been refined and developed along with the HL7 Version 3 framework and the
Reference Information Model (RIM).
 The original group morphed into the HL7 Structured Documents Work Group
which is responsible for CDA and other HL7 document types.
 CDA introduces the concept of incremental semantic interoperability. The
minimal CDA is a small number of XML-encoded metadata fields (such as
provider name, document type, document identifier, and so on) and a body
which can be any commonly-used MIME type such as pdf or doc (Microsoft
Word) or even a scanned image file.
 The most recent version of CDA is Release 2 which is used as the
foundation for all current CDA Implementation Guides. CDA Release 3 is
currently under development.

CDA “Levels” of Conformance
 The CDA standard describes conformance requirements in
terms of three general levels corresponding to three different,
incremental types of conformance statements:
 Level 1 requirements impose constraints upon the CDA
Header. The body of a Level 1 document may be XML or an
alternate allowed format. If XML, it must be CDA-conformant
markup.
 Level 2 requirements specify constraints at the section level of
a CDA XML document: most critically, the section code and the
cardinality of the sections themselves, whether optional or
required.
 Level 3 requirements specify constraints at the entry level
within a section. A specification is considered “Level 3” if it
requires any entry-level templates.
 These levels are rough indications of what a recipient can
expect in terms of machine-processable coding and content

CDA SPECIFICATION FRAMEWORK

Introduction
 The HL7 Clinical Document Architecture (CDA) is a document
markup standard that specifies the structure and semantics of
"clinical documents" for the purpose of exchange.
 The CDA is a constrained refinement of the HL7 v3 Reference
Information Model (RIM) specific to the purpose of clinical document
exchange.
 The CDA standard is further constrained via the specification of
implementation guides for specific document types, clinical domains,
and document exchange scenarios.
 The CDA is one of the initial set of standards, implementation
specifications, and certification criteria for Electronic Health Record
technology specified in Meaningful Use legislation.
 The collection of implementation guides developed for CDA are
being widely adopted by EMR vendors; secondary users of EMR
data are aligning their information requirements with the guides in
anticipation of these data becoming more readily assessable.

Clinical Document Architecture RMIM
Clinical Document
Participating
Entities
Structured
Document Sections
Section Entries and
Sub-Entries

TEMPLATED CDA AND
IMPLEMENTATION GUIDES

Sample CDA Templated Constraints
Age Observation: templateId 2.16.840.1.113883.10.20.22.4.31 (open)
1. SHALL contain exactly one [1..1] @classCode="OBS" Observation (CodeSystem:
HL7ActClass 2.16.840.1.113883.5.6 STATIC) (CONF:7613).
2. SHALL contain exactly one [1..1] @moodCode="EVN" Event (CodeSystem:
ActMood 2.16.840.1.113883.5.1001 STATIC) (CONF:7614).
3. SHALL contain exactly one [1..1] templateId (CONF:7899) such that it
 SHALL contain exactly one [1..1] @root="2.16.840.1.113883.10.20.22.4.31"
(CONF:10487).
4. SHALL contain exactly one [1..1] code (CONF:7615).
 This code SHALL contain exactly one [1..1] @code="445518008" Age At Onset
(CodeSystem: SNOMED-CT 2.16.840.1.113883.6.96 STATIC) (CONF:16776).
5. SHALL contain exactly one [1..1] statusCode (CONF:15965).
 This statusCode SHALL contain exactly one [1..1] @code="completed" Completed
(CodeSystem: ActStatus 2.16.840.1.113883.5.14 STATIC) (CONF:15966).
6. SHALL contain exactly one [1..1] value with @xsi:type="PQ" (CONF:7617).
 This value SHALL contain exactly one [1..1] @unit, which SHALL be selected from
ValueSet AgePQ_UCUM 2.16.840.1.113883.11.20.9.21 DYNAMIC (CONF:7618).

Segment of the CDA affected by the Age
Observation template
Clinical Document
Participating
Entities
Structured
Document Sections
Section Entries and
Sub-Entries

Segment of the CDA affected by the Age
Observation template

Conformance Verbs
 The conformance verb keyword at the start of a
constraint ( SHALL , SHOULD , MAY, etc.) indicates
usage conformance.
 SHALL is an indication that the constraint is to be
enforced without exception;
 SHOULD is an indication that the constraint is
optional but highly recommended; and
 MAY is an indication that the constraint is optional
and that adherence to the constraint is at the
discretion of the document creator.

Cardinality
 The cardinality indicator (0..1, 0..*, 1..1, 1..*, etc.) specifies the
allowable occurrences within an instance.
 Thus, " MAY contain 0..1" and " SHOULD contain 0..1" both
allow for a document to omit the particular component, but the
latter is a stronger recommendation that the component be
included if it is known.
 The following cardinality indicators may be interpreted as
follows:
 0..1 as contains zero or one
 1..1 as contains exactly one
 2..2 as contains exactly two
 1..* as contains one or more
 0..* as contains zero or more
 Each constraint is uniquely identified (e.g., "CONF:605") by an
identifier placed at or near the end of the constraint.

Value Set Binding
 Value set bindings adhere to HL7 Vocabulary Working Group
best practices, and include both a conformance verb ( SHALL ,
SHOULD , MAY, etc.) and an indication of DYNAMIC vs.
STATIC binding.
 The use of SHALL requires that the component be valued with
a member from the cited value set; however, in every case any
HL7 "null" value such as other (OTH) or unknown (UNK) may
be used.
 STATIC binding means that the allowed values of the value set
do not change automatically as new values are added to a
value set. That is, the binding is to a single version of a value
set.
 DYNAMIC binding means that the intent is to have the allowed
values for a coded item automatically change (expand or
contract) as the value set is maintained over time.

SAMPLE HL7 V3 CDA ARTIFACTS

From Data Dict. to CDA Guide

Implementation Guide Development
311

DAM: a UML representation of dictionary
elements
PreHospitalEcounter
- arrivalDateTime :TS [0..1]
- departureDateTime :TS [0..1]
- dispatchDateTime :TS [0..1]
+ preHospitalTransportationMethodCode :TransportationMethod [0..*]
PreHospitalNervousSystemObservation
+ glasgowComaEyeResponseValue :INT
+ glasgowComaMotorResponseValue :INT
+ glasgowComaScoreValue :INT
+ glasgowComaVerbalResponseCode :INT
PreHospitalCirculatorySystemObservation
+ heartRateAmount :PQ
+ systolicBloodPressureAmount :PQ
PreHospitalRespiratorySystemObservation
+ arterialOxygenSaturationAmount :PQ
+ respiratoryRateAmount :PQ
2.0 Submission::
RegistrySubmissionTransaction
0..1 0..1
0..1
0..1

Organization of DAM Classes
2.0 Submission
+ RegistrySubmissionTransaction
1.0 Patients
+ Patient
3.0 Injury Events
+ InjuryEvent
+ InjurySeverityObservation
4.0 PreHospital Encounters
+ PreHospitalCirculatorySystemObservation
+ PreHospitalEcounter
+ PreHospitalNervousSystemObservation
+ PreHospitalRespiratorySystemObservation
5.0 Hospital Care Episodes
+ HospitalCareEpisode
+ HospitalCirculatorySystemObservation
+ HospitalNervousSystemObservation
+ HospitalPhysiologicalObservation
+ HospitalRespiratorySystemObservation
+ 5.1 Emergency Hospital Encounters
+ 5.2 InpatientHospitalEncounters

Dictionary to DAM
Element ID NTDB Dictionary Element DAM Package DAM Class DAM Attribute
D_01 D_01: PATIENT’S HOME ZIP CODE 2.0 Patients Patient postalAddress
D_02 D_02: PATIENT’S HOME COUNTRY 2.0 Patients Patient postalAddress
D_03 D_03: PATIENT’S HOME STATE 2.0 Patients Patient postalAddress
D_04 D_04: PATIENT’S HOME COUNTY 2.0 Patients Patient postalAddress
D_05 D_05: PATIENT’S HOME CITY 2.0 Patients Patient postalAddress
D_06 D_06: ALTERNATE HOME RESIDENCE 2.0 Patients Patient residenceStatusCode
D_07 D_07: DATE OF BIRTH 2.0 Patients Patient birthDate
D_08 D_08: AGE 2.0 Patients Patient eventRelatedAgeQuantity
D_09 D_09: AGE UNITS 2.0 Patients Patient eventRelatedAgeQuantity
D_10 D_10: RACE 2.0 Patients Patient raceCode
D_11 D_11: ETHNICITY 2.0 Patients Patient ethnicCode
D_12 D_12: SEX 2.0 Patients Patient genderCode
DG_01 DG_01: CO-MORBID CONDITIONS 5.0 Hospital Care Episodes HospitalCareEpisode coMorbidConditionCode
DG_02 DG_02: ICD-9 INJURY DIAGNOSES 5.0 Hospital Care Episodes HospitalCareEpisode injuryDiagnosisCode
DG_03 DG_03: ICD-10 INJURY DIAGNOSES 5.0 Hospital Care Episodes HospitalCareEpisode injuryDiagnosisCode
ED_01 ED_01: ED/HOSPITAL ARRIVAL DATE 5.0 Hospital Care Episodes HospitalCareEpisode arrivalDateTime
ED_02 ED_02: ED/HOSPITAL ARRIVAL TIME 5.0 Hospital Care Episodes HospitalCareEpisode arrivalDateTime
ED_03 ED_03: INITIAL ED/HOSPITAL SYSTOLIC BLOOD PRESSURE 5.0 Hospital Care Episodes HospitalCirculatorySystemObservation systolicBloodPressureAmount
ED_043 ED_043: INITIAL ED/HOSPITAL PULSE RATE 5.0 Hospital Care Episodes HospitalCirculatorySystemObservation heartRateAmount
ED_05 ED_05: INITIAL ED/HOSPITAL TEMPERATURE 5.0 Hospital Care Episodes HospitalPhysiologicalObservation temperatureAmount
ED_06 ED_06: INITIAL ED/HOSPITAL RESPIRATORY RATE 5.0 Hospital Care Episodes HospitalRespiratorySystemObservation respiratoryRateAmount
ED_07 ED_07: INITIAL ED/HOSPITAL RESPIRATORY ASSISTANCE 5.0 Hospital Care Episodes HospitalRespiratorySystemObservation respiratoryAssistanceIndicator
ED_08 ED_08: INITIAL ED/HOSPITAL OXYGEN SATURATION 5.0 Hospital Care Episodes HospitalRespiratorySystemObservation arterialOxygenSaturationAmount
ED_09 ED_09: INITIAL ED/HOSPITAL SUPPLEMENTAL OXYGEN 5.0 Hospital Care Episodes HospitalRespiratorySystemObservation supplementalOxygenIndicator

CIM: a CDA influenced UML
representation of dictionary elements
Domain Analysis
Model
2
CDA RMIM
Constrained
Information Model
ArterialOxygenSaturationObservation
+ code :CD = ObservationType
- value :PQ
::RespiratorySystemObservation
+ classCode :CS = "OBS"
+ moodCode :CS = "EVN"
RespiratoryRateObservation
+ code :CD = ObservationType
- value :PQ
::RespiratorySystemObservation
RespiratorySystemObservation
PreHospitalEncounterDetail::
RespiratorySystemEntryRelationship
+ typeCode :CS = x_ActRelationsh...
+ contextConductionInd :BL = "true"
0..*
1
315

Organization of CIM Classes
InjuryEventSection
+ InjuryEventSection
+ StructuredBodyInjuryEventComponent
+ InjuryEventDetailEntry
(from TraumaRegistrySubmissionDocument)
TraumaRegistrySubmissionDocument
+ HealthcareFacility
+ RegistryParticipant
+ StructuredBodyComponent
+ StucturedBody
+ Submitter
+ TraumaRegistrySubmissionDocument
+ Patient
+ PreHospital Encounter Section
+ Hospital Care Episode Section
+ EntryPoint
Patient
+ RecordTarget
+ Patient
+ PatientRole
+ PatientDetailSection
PreHospital Encounter Section
+ PreHospitalEncounterSection
+ StructoredBodyPreHospitalEncounterComponent
+ PreHospitalEncounterDetail
Hospital Care Episode Section
+ HospitalCareEpisodeSection
+ StructuredBodyHospitalCareEpisodeComponent
+ HospitalCareEpisodeActivityDetail

DAM to CIM
DAM Class DAM Attribute CIM Class CIM Attribute
Patient birthDate Patient birthTime
Patient ethnicCode Patient ethnicGroupCode
Patient eventRelatedAgeQuantity PatientAgeObservation value
Patient genderCode Patient administrativeGenderCode
Patient industryCode PatientIndustryObservation value
Patient occupationCode PatientOccupationObservation value
Patient postalAddress PatientRole addr
Patient raceCode Patient raceCode
Patient residenceStatusCode PatientResidenceStatusObservation value
InjuryEvent abbreviatedInjuryCode AbreviatedInjuryObservation value
InjuryEvent airbagDeploymentCode AirbagDeploymentObservation value
InjuryEvent bodyInjuryRegionCode BodyInjuryObservation value
InjuryEvent injurySeverityScoreValue SeverityScoreObservation value
InjuryEvent locationTypeCode LocationTypeObservation value
InjuryEvent occurenceDateTime InjuryEventAct effectiveTime
InjuryEvent postalAddress PostalAddressObservation value
InjuryEvent primaryInjuryCauseCode PrimaryInjuryCauseObservation value
InjuryEvent safetyEquipmentUsedCode SafetyEquipmentUsedObservation value
InjuryEvent supplementalInjuryCauseCode SupplementalInjuryCauseObservation value
InjuryEvent workRelatedEventInd WorkRelatedObservation value
PreHospitalCirculatorySystemObservation heartRateAmount HeartRateObservation value
PreHospitalCirculatorySystemObservation systolicBloodPressureAmount SystolicBloodPressureObservation value
PreHospitalEncounter arrivalDateTime PreHospitalEncounter effectiveTime
PreHospitalEncounter departureDateTime PreHospitalEncounter effectiveTime

IG: Dictionary elements represented as
templated CDA constraints
3
CDA RMIM
Constrained
Information Model
NTDB
EMS
318

Organization of IG Templates

Organization of IG Templates
StucturedBody
+ classCode :CS = "DOCBODY"
StructuredBodyComponent
+ typeCode :CS = "COMP"
+ contextConductionInd :BL = "true"
TraumaRegistrySubmissionDocument
+ classCode :CS = "DOCCLIN"
+ id :II
+ code :CE = DocumentType
- effectiveTime :TS
PatientDetailSection::PatientDetailSection
Patient::PatientRole RegistryParticipant
+ classCode :CS = "ASSIGNED"
Submitter
+ typeCode :CS = "INF"
+ contextControlCode :CS = "OP"
HealthcareFacility
+ classCode :CS = "ORG"
+ determinerCode :CS = "INSTANCE"
- id :II
EntryPoint
Patient
+ RecordTarget
+ Patient
+ PatientRole
PatientDetailSection
+ StucturedBodyPatientDetailComponent
+ PatientDemographicObservation
+ PatientEmploymentObservation
(from Patient)
InjuryEventSection::InjuryEventSection PreHospital Encounter Section::
PreHospitalEncounterSection
Hospital Care Episode Section::
HospitalCareEpisodeSection
InjuryEventSection
+ StructuredBodyInjuryEventComponent
+ InjuryEventDetailEntry
PreHospital Encounter Section
+ PreHospitalEncounterSection
+ StructoredBodyPreHospitalEncounterComponent
+ PreHospitalEncounterDetail
Hospital Care Episode Section
+ HospitalCareEpisodeSection
+ StructuredBodyHospitalCareEpisodeComponent
+ HospitalCareEpisodeActivityDetail
Name: TraumaRegistrySubmissionDocument
Author: Salimah Shakir
Version: 1.0
Created: 2/7/2013 9:30:31 PM
Updated: 6/14/2013 12:01:15 AM
Act
Entity
Role
Participation
ActRelationship
Foriegn Class
Legend
1..11
1..1
1
1..1
1
1..1
1
1..1
1
1..1
1
0..1
1
1..1
1
HEADER
BODY
ENTRIES

Dict to DAM to CIM to IG
NTDB Dictionary Element CDA Template CDA ITEM CDA Clone CDA Attribute CDA CONF
D_01: PATIENT’S HOME ZIP CODE 3.1 Trauma Registry Submission Document 8.c.111 patientRole addr 27773
D_02: PATIENT’S HOME COUNTRY 3.1 Trauma Registry Submission Document 8.c.111 patientRole addr 27773
D_03: PATIENT’S HOME STATE 3.1 Trauma Registry Submission Document 8.c.111 patientRole addr 27773
D_04: PATIENT’S HOME COUNTY 3.1 Trauma Registry Submission Document 8.c.111 patientRole addr 27773
D_05: PATIENT’S HOME CITY 3.1 Trauma Registry Submission Document 8.c.111 patientRole addr 27773
D_06: ALTERNATE HOME RESIDENCE 5.3 Patient Demographic Observations Organizer 42.c.iv observation value 30000
D_07: DATE OF BIRTH 3.1 Trauma Registry Submission Document 8.c.iv.4 patient birthTime 27776
D_08: AGE 5.3 Patient Demographic Observations Organizer 43.c.iv observation value 30008
D_09: AGE UNITS 5.3 Patient Demographic Observations Organizer 43.c.iv.1 observation value@unit 30455
D_10: RACE 5.3 Patient Demographic Observations Organizer 44.c.iv observation value 30508
D_11: ETHNICITY 3.1 Trauma Registry Submission Document 8.c.iv.5 patient ethnicGroupCode 27778
D_12: SEX 3.1 Trauma Registry Submission Document 8.c.iv.3 patient administrativeGenderCode 27775
DG_01: CO-MORBID CONDITIONS 6.5 Hospital Care Episode Observation Organizer 84.c.iv observation value 30385
DG_02: ICD-9 INJURY DIAGNOSES 6.5 Hospital Care Episode Observation Organizer 85.c.iv observation value 30397
DG_03: ICD-10 INJURY DIAGNOSES 6.5 Hospital Care Episode Observation Organizer 85.c.iv observation value 30397
ED_01: ED/HOSPITAL ARRIVAL DATE 5.1 Hospital Care Episode Encounter 31 encounter effectiveTime 30341
ED_02: ED/HOSPITAL ARRIVAL TIME 5.1 Hospital Care Episode Encounter 31 encounter effectiveTime 30341
ED_03: INITIAL ED/HOSPITAL SYSTOLIC BLOOD PRESSURE 6.1 Circulatory System Observation Entry 63.c.iv observation value 29639
ED_043: INITIAL ED/HOSPITAL PULSE RATE 6.1 Circulatory System Observation Entry 62.c.iv observation value 29633
ED_05: INITIAL ED/HOSPITAL TEMPERATURE 6.7 Hospital Care Physiological Observation 100.c.iv observation value 30431
ED_06: INITIAL ED/HOSPITAL RESPIRATORY RATE 6.16 Respiratory System Observation Entry 145.c.iv observation value 30092
ED_07: INITIAL ED/HOSPITAL RESPIRATORY ASSISTANCE 6.15 Respiratory System Observation 140.c.iv observation value 30437
ED_08: INITIAL ED/HOSPITAL OXYGEN SATURATION 6.16 Respiratory System Observation Entry 144.c.iv observation value 30085
ED_09: INITIAL ED/HOSPITAL SUPPLEMENTAL OXYGEN 6.15 Respiratory System Observation 141.c.iv observation value 30441

Trauma Registry Data Submission IG

Introduction and Specification
Overview

Scope

Templates

Document Template

Section Templates

Entry Templates

Subentry Templates

Vocabulary Tables

From Data Dict. to CDA Impl. Guide

Consolidated CDA

Collaborative Work Product
 This guide was produced and developed through the joint efforts of Health
Level Seven (HL7), Integrating the Healthcare Environment (IHE), the Health
Story Project, and the Office of the National Coordinator (ONC) within the
US Department of Health and Human Services (HHS).
 The project was carried out within the ONC’s Standards and Interoperability
(S&I) Framework as the Clinical Document Architecture (CDA) Consolidation
Project with a number of goals, one of which is providing a set of
harmonized CDA templates for the US Realm.

US Realm Header Template
1. realmCode
2. typeId
3. templateId
4. id
5. code
6. title
7. effectiveDateTime
8. confidentialityCode
9. languageCode
10. setId
11. versionNumber

Document Types
1. Continuity of Care Document (CCD)
2. Consultation Notes
3. Discharge Summary
4. Diagnostic Imaging Reports (DIR)
5. History and Physical (H&P)
6. Operative Note
7. Progress Note
8. Procedure Note
9. Unstructured Documents

Continuity of Care Document (CCD)
 The Continuity of Care Document (CCD) represents a core data set
of the most relevant administrative, demographic, and clinical
information facts about a patient's healthcare, covering one or more
healthcare encounters.
 It provides a means for one healthcare practitioner, system, or setting
to aggregate all of the pertinent data about a patient and forward it to
another to support the continuity of care.
 The primary use case for the CCD is to provide a snapshot in time
containing the germane clinical, demographic, and administrative
data for a specific patient.
 The key characteristic of a CCD is that the ServiceEvent is
constrained to "PCPR". This means it does not function to report new
ServiceEvents associated with performing care. It reports on care
that has already been provided.
 The CCD provides a historical tally of the care over a range of time
and is not a record new services delivered.

CCD Contained Templates

Consultation Notes
 The Consultation Note is generated by a request from a
clinician for an opinion or advice from another clinician.
 Consultations may involve face-to-face time with the
patient or may fall under the auspices of tele-medicine
visits.
 Consultations may occur while the patient is inpatient or
ambulatory.
 The Consultation note should also be used to summarize
an Emergency Room or Urgent Care encounter.
 A consultation note includes the reason for the referral,
history of present illness, physical examination, and
decision-making components (Assessment and Plan).

Consultation Notes Contained Templates

Discharge Summary
 The Discharge Summary is a document which synopsizes a
patient's admission to a hospital, LTPAC provider, or other
admission.
 It provides information for the continuation of care following
discharge.
 The Joint Commission requires the following information to be
included in the Discharge Summary:
• The reason for hospitalization the admission
• The procedures performed, as applicable
• The care, treatment, and services provided
• The patient’s condition and disposition at discharge
• Information provided to the patient and family
• Provisions for follow-up care

Discharge Summary Contained
Templates

14 Document Level Templates

52 Section Level Templates

88 Entry Level Templates

Required and Optional Sections by
Document Type

CDA Implementation Guides

Partial list of Implementation Guides
(by country)
 USA
 CCD (Continuity of Care Document) Rel.1
 CRS (Care Record Summary)
 SPL – Structured Product Label
 HAI (Healthcare associated infections)
 HITSP
 C32 –Summary Documents Using HL7 Continuity of Care Document (CCD)
 C37 – Lab Report
 C48 –Encounter Document Using IHE Medical Summary (XDS-MS)
Component
 Consultation Notes
 History and Physical
 Operative Notes
 Imaging Integration, Basic Imaging Reports
 Canada
 e-MS (electronic Medical Summary)
 Germany
 VHitG-Arztbrief v1.50 (discharge summary)
 Addendum Laboratory
 Addendum Medication
 Addendum notifiable diseases (in progress)
 DRV Reha-Enlassbrief
 Reha-Kurzarztbrief
 Nursing Summary (ePflegebericht)
 South Korea
 CDA conference 2004
 Austria
 ELGA (currently in progress)
 Switzerland
 CDA-CH v1.1
 France
 French CRS CDA Body implementation Guide (in
French)
 Finland
 seamless Care and CDA
 Finnish (CDA) implementation guides: CDA R2, V3,
Medical Records, V2, CDA R (in Finnish)
 Japan
 Japanese Clinical Summary document (in Japanese)

CDA Implementation Guides
(available for download from the HL7 website)
1. Clinical Oncology Treatment Plan and Summary,
DSTU Release 1
2. Personal Healthcare Monitoring Report
3. Patient Generated Document Header Template,
Release 1
4. Plan-to-Plan Personal Health Record (PHR) Data
Transfer, Release 1
5. Public Health Case Reports (US Realm)
6. Quality Reporting Document Architecture –
Category I (QRDA) DSTU Release 2 (US Realm)
7. Level 1 and 2 - Care Record Summary (US realm)
8. Level 3: Emergency Medical Services; Patient
Care Report, Release 1 – US Realm
9. CDA Framework for Questionnaire Assessments,
DSTU Release 2
10. Digital Signatures and Delegation of Rights,
Release 1
11. Exchange of Clinical Trial Subject Data; Patient
Narratives, Release 1 - US Realm
12. Genetic Testing Reports, Release 1
13. Healthcare Associated Infection (HAI) Reports
14. HIV/AIDS Services Report, Release 1 - US Realm
15. IHE Health Story Consolidation, Release 1.1 - US
Realm
16. Long-Term Post-Acute Care Summary, DSTU
Release 1 (US Realm)
17. Patient Assessments, Release 1
18. Quality Reporting Document Architecture - Category
III (QRDA III), DSTU Release 1
19. Questionnaire Form Definition Document, Release
1
20. Questionnaire Response Document, Release 1
21. Reference Profile for EHR Interoperability, Release
1
22. Trauma Registry Data Submission, Release 1
23. Consent Directives, Release 1
24. Procedure Note, Release 1
25. greenCDA Modules for CCD®, Release 1
26. Imaging Integration; Basic Imaging Reports in CDA
and DICOM, Release 1
27. Specification and Use of Reusable Information
Constraint Templates, Release 1
28. Neonatal Care Reports (NCR), R1
29. Continuity of Care Document (CCD®) Release 1

• KEY ASPECTS OF CDA
• EARLY HISTORY OF CDA
• CDA SPECIFICATION FRAMEWORK
• TEMPLATED CDA AND IMPLEMENTATION GUIDES
• SAMPLE HL7 V3 CDA ARTIFACTS
• CONSOLIDATED CDA IMPLEMENTATION GUIDE

Questions

Hi3 Solutions
300
Burbank, CA 91505
6520

Specification and validation
HL7 Compliance and
Conformance

SESSION OVERVIEW
 SPECIFICATION CONFORMANCE PROFILING
 PURPOSE AND GOAL OF CONFORMANCE PROFILING
 HL7 V2 MESSAGE CONFORMANCE PROFILING
 USE CASES OF MESSAGE CONFORMANCE
PROFILING
 CONFORMANCE VALIDATION
 HI3 SOLUTIONS CONFORMANCE VALITATOR

Initiate
Project
Project
Charter
Specify
Requirements
Reference
Models
Requirement
Specification
Design Models
Specification
Design Models
Prepare
Specification
Approve
Specification
Approved
Specification
Publish
Approved
Specification
Published
Specification
Profiles
Specification
Profile
Conformance
Statement
Proposed
Specification
adjusted.

Specification Profiling
During specification profiling specification models and published specifications are
further refined to produce a specification profile for use in a particular environment by
a defined community of users. The primary deliverable produced during specification
profiling is a set of specification constraints and conformance statements.
Specification
Profiling
Specification
Constraints and
Conformance
Statements
1. Identify community of user for the published specification
2. Further refine and constrain specification design models
3. Document exceptions, extensions, and annotations to specifications
4. Prepare and publish specification profile
5. Prepare and publish conformance statements
Published
Specification

Purpose and goals for
conformance profiling

Reveal Assumptions
Revealing assumptions is an essential component of effective communication.
Yes, I do
play
football.
Do you
play
football?

Reveal Assumptions
Message Profiles are an effective means of documenting our assumptions
about message structures
Do you
use
HL7?
MSH
EVN
PID
[PD1]
[ { NK1 } ]
Yes, I
use
HL7.
MSH
EVN
PID
[ NK1 ]
OBX

Reduce Ambiguity
Message Profiles provide a language that allows us to unambiguously express our
understanding and assumptions about the information in a message structure used
in a particular scenario
MSH
EVN
PID
[PD1]
[ { NK1 } ]

Highlight Conflicts
Sharing message profiles provides
an opportunity to identify and reconcile conflicts in our understanding
and to validate our assumptions about message structures.
MSH
EVN
PID
[PD1]
[ { NK1 } ]
MSH
EVN
PID
[ NK1 ]
OBX

Consolidate Viewpoints
Message Profile Message Profile Message Profile
MSH
EVN
PID
[PD1]
[ { NK1 } ]
MSH
EVN
PID
[ NK1 ]
OBX
MSH
EVN
{ PID }
[PD1]
[ { GT1 } ]
MSH
EVN
{ PID }
[PD1]
[ { NK1 } ]
[ { GT1 } ]
[ OBX ]

Value of Profiling
 Reveal Assumptions
 Reduce Ambiguity
 Highlight Conflicts
 Consolidate Viewpoints

Profile Defined
 Unambiguous specification of an HL7 data exchange
standard for use within a particular community of
users for a specified set of requirements
 Prescribes a set of precise constraints upon one or more
standard
 Supported by use case analysis and interaction modeling
 Measurable
 What data will be passed
 The format in which the data will be passed
 The acknowledgement responsibilities of the receiver

Profile Defined (cont’d)
 Based on HL7, although may further constrain
 Static structure and content of each message
 The dynamic interactions
 Parts of a profile
 Use Case Model
 Static Definition
 Dynamic Definition
 Represented as an XML document
 Can be registered with HL7
 May be reused by other HL7 users
 May be used for documentation

HL7 v2 Conformance
Profiling

Conceptual Overview
Message Profile = Static Profile + Dynamic Profile
Critical Care Unit
ADT System
Acknowledgement Message
Initiating Message
Initiating Message
Clinical Data Repository

Message conformance profile
dynamic definition

Use Case Model
 Documents the scope and requirements for an HL7
Message Type or set of Message Types
 May include a use case diagram or detailed text
 Provides a name that clearly and concisely defines
the exchange
 Defines the actors, including the sending and
receiving applications
 Defines the responsibilities of these actors
 Documents the situations in which the exchange of a
particular HL7 Message Profile is required

Dynamic Definition
 Defines interaction between the sender and receiver
 Acknowledgment mode supported
 Conditions under which an accept and/or application level
acknowledgment is expected
 Always
 Never
 Only on success
 Only on error
 Interaction Model
 Defines specific interactions between the applications that
support message profile communication requirements
 Includes interaction diagrams that illustrate the sequence of
trigger event and resulting message flows between the sending
and receiving applications
 Dynamic can refer one to many static definitions

Dynamic Interaction
Vectra
XU
5/90C
BED1OFF
BED1OFF
BED1OFF
BED1OFF
BED1OFF
BED1OFF
BED1OFF
BED1OFF
BED1OFF
BED1OFF
POTASSIUM3.5-5.0
BED1OFF
POTASSIUM3.5-5.0
POTASSIUM3.5-5.0
POTASSIUM3.5-5.0
BED1OFF
POTASSIUM3.5-5.0
BED1OFF BED1OFF
BED1OFF
BED1OFFBED1OFF
Critical Care Unit
HIS/CIS
Vectra
XU
5/90C
BED1OFF
BED1OFF
BED1OFF
BED1OFF
BED1OFF
BED1OFF
BED1OFF
BED1OFF
BED1OFF
BED1OFF
POTASSIUM3.5-5.0
BED1OFF
POTASSIUM3.5-5.0
POTASSIUM3.5-5.0
POTASSIUM3.5-5.0
BED1OFF
POTASSIUM3.5-5.0
BED1OFF BED1OFF
BED1OFF
BED1OFFBED1OFF
Clinical Data
Repository
A/D/T System
Order Filling Application
Accept Ack
Accept + App ACK
MSH-15,16
No ACK

SIIS SIP Use Case Diagram
ud Use Case Model
Local Registry User
1.0 Immunization
History Query
2.0 Patient
Demographic
Update
3.0 Vaccine
Record Update Prov ider Organization
SIIS Registry
Administration
4.0 Immunization
Statistical Analysis
Trusted Third PartiesLocal Registry
Administration
SIIS Analysis Report
SIIS Analysis Report SIIS Analysis Report
Update Confirmation
Update Confirmation
Query Response
Vaccine Record Update
Patient Information Update
Immunization History Request

SIIS SIP Activity Model
ad InteractionActivityModel
Requesting Registry System SIIS SIP Immunization Information Exchange System Responding Registry System
1.1 Request Immunization
Data
«message»
M.01 Immunization Data
Request (VXQ)
2.2 Validate Immunization
Data Request Message
«message»
M.02 Request Error Message
(ACK)
2.3 Route Immunization
Data Request Message2.4 Notify System
Administrator
«message»
M.03 Immunization
Data Request (VXQ)
3.1 Retrive Requested
Immunization Data
«datastore»
D.04 Immunization
Registry
3.2 Retrival
Result?
3.2.1 Return "No Matching
Record" Response
3.2.2 Return "Multiple
Matching Records"
Response
3.2.3 Return Requested
Immunization Data
«message»
M.04 No Matching
Record Response (QCK)
«message»
M.05 Multiple Matching
Records Response (VXX)
«message»
M.06 Requested
Immunization Data (VXR)
4.2 Validate Response
Message
«message»
M.07 Response Message
Error (ACK)
4.3 Route Response
Message
4.4 Notify System
Administrator
«message»
M.08 No Matching Record
Message (QCK)
«message»
Record Message (VXX)
«message»
M.10 Requested Immunization
Data Message (VXR)
5.1 Refine Demographic
Data
5.2 Select Desired Record
5.3 Merge Immunization
Data with existing data
«datastore»
D.01 Immunization
Registry
[Valid Message]
[Invalid Message]
[Valid Message]
[No Matching Record]
[Desired Record Not Present]
[Multiple Matching Records]
[Single Matching Record]
[Desired Record Selected]
[Invalid Message]
1
2 3
4
6
5

SIIP SIP Interaction Model
sd Interactions
Requesting Registry
System
SIIS SIP Immunization
Information Exchange
System
Responding Registry
System
Vaccination Record Query (VXQ)
[Invalid VXQ Message]: General Acknowledgement (ACK)
[Valid VXR Message]: Vaccination Record Query (VXQ)
[No Matching Record]: Query Acknowledgement (QCK)
[Invalid QCK Message]: General Acknowledgement (ACK)
[Valid QCK Message]: Query Acknowledgement (QCK)
[Multiple Matching Records]: Vaccination Query Response (VXX)
[Invalid VXX Message]: General Acknowledgement (ACK)
[Valid VXX Message]: Vaccination Query Response (VXX)
[Single Matching Record]: Vaccination Query Response (VXR)
[Invalid VXR Message]: General Acknowledgement (ACK)
[Valid VXR Message]: Vaccination Query Response (VXR)

SIIS SIP Acknowledgement Requirements
Message Source Destination Acknowledgment
• Vaccination Record Query (VXQ) Requester IIES Only on error
• General Acknowledgement (ACK) IIES Requester Never
• Vaccination Record Query (VXQ) IIES Responder Never
• Query Acknowledgement (QCK) Responder IIES Only on error
• General Acknowledgement (ACK) IIES Responder Never
• Query Acknowledgement (QCK) IIES Requester Never
• Vaccination Query Response (VXX) Responder IIES Only on error
• Vaccination Query Response (VXX) IIES Requester Never
• Vaccination Query Response (VXR) Responder IIES Only on error
• Vaccination Query Response (VXR) IIES Requester Never

Message conformance profile
static definition

Static Definition
 A specification for a message structure intended to
support the use case
 Based on a message defined in HL7 Std
 Defined at the message, segment, and field levels
 Follows the HL7 rules (chapter 2)
 May further constrain
 Identifies only those specific elements used in the exchange
 Removes all instances of optionality, defining explicitly
 Segments, segment groups, fields and components usage rules
 Cardinalities
 Value sets and coding systems
 Implementation notes

Static Definition Example
...
...
...
NK1
MSH
EVN
PID
NK1 NK1 NK1 NK1
PV1
PV2
OBX
AL1
HL7 Message Structure
...
NK1
MSH
EVN
PID
NK1 NK1 NK1 NK1
PV1
PV2
OBX
AL1
Message Profile
Segments/Segment Groups:
•Usage (Optionality)
•Cardinality (min, max)
Fields/Components:
- Usage (Optionality)
- Cardinality (min, max)
- Value Sets/Coding system
- Descriptions

Profiling Concepts
 Profile Types
 HL7 Standard
 Constrainable
 Implementable
 Generic term ‘message element’ used
 Segment groups
 Segments
 Fields
 Components
 Sub-components
 Cardinality
 Usage

Profile Types
 HL7 Standard Profile
 represents a specific HL7 published standard
 creation and publication limited to HL7 use
 Constrainable
 May have optionality - not implementable
 Narrower profiles may be defined based on this
 Realm Specific (National, Regional, SIGs, etc.)
 Organization / Application Specific
 Implementation
 Further constrained
 No optionality

HL7 v2 Message Elements
Message Specification
Segment Group
Message Segment
Segment Segment Field
Data Element
Data Type Composite Data Type
Data Type Component
Code Table Code Table Item
Code System Term
Code System

Cardinality
 Identifies minimum and maximum number of
occurrences
 Special values for cardinality
 Minimum number of occurrences is 0, the element may be
omitted from a message
 The maximum value may have no practical limit
(In this case, it may be identified as ‘*’)

Cardinality Examples
Value Description
[0..0] Element never present
[0..1] Element may be omitted and it can have at most one occurrence
[1..1] Element must have exactly one occurrence
[0..n] Element may be omitted or may repeat up to n times
[1..n] Element must appear at least once, and may repeat up to n times
[0..*] Element may be omitted or repeat for an unlimited number of
times
[1..*] Element must appear at least once, and may repeat unlimited
number of times
[m..n] Element must appear at least “m” and at most” n” times

Usage
 The circumstances under which an element appears in a
message
 Some elements must always be present
 others may never be present
 others may only be present in certain circumstances
 Rules governing restrictions on the sending applications
and the expected behavior of receiving applications with
respect to a message element
 Required
 Required, but may be empty
 Optional
 Conditional
 Conditional, but may be empty
 Not supported

Usage (continued)
 R - Required
 A conforming sending application
 populate all “R” elements with a non-empty value
 A conforming receiving application
 process (save/print/archive/etc.) or ignore the information
conveyed by required elements
 must not raise an error due to the presence of a required
element, but may raise an error due to the absence of a
required element
 For complete compatibility with HL7, any element
designated as required in a standard HL7 message
definition shall also be required in all HL7 Message
Profiles of that standard message

Usage (continued)
 RE - Required but may be empty
 May be missing from the message, but must be sent by the
sending application if there is relevant data
 A conforming sending application
 must be capable of providing all “RE” element
 if it knows the required values for the element, then it must send
that element
 if the conforming sending application does not know the required
values, then element will be omitted
 A conforming receiving applications
 will be expected to process (save/print/archive/etc.) or ignore data
contained in the element
 must be able to successfully process the message if the element is
omitted (I.e. no error message should be generated because the
element is missing

Usage (continued)
 O - Optional
 This code indicates that the Usage for this element has
not yet been defined
 May NOT be used in ‘Implementation’ profiles (no-
optionality profiles)
 Conformance cannot be tested on an Optional field

Usage (continued)
 C - Conditional
 Predicate associated with this element that identifies the
conditions under which the element must be present
 must be testable and based on other values within the message
 may be expressed as a mathematical expression or in text and
may utilize operators such as equivalence, logical AND, logical OR
and NOT
 The conforming sending and receiving applications shall both
evaluate the predicate
 If the predicate is satisfied:
 See rules for R (Required)
 If the predicate is NOT satisfied:
 A conformant sending application must NOT send the element
 A conformant receiving application must NOT raise an error if the
condition predicate is false and the element is not present, though
it MAY raise an error if the element IS present

Usage (continued)
 CE - Conditional but may be empty
 This usage also has an associated condition predicate
similar to Conditional (C)
 If the predicate is satisfied:
 See rules for RE (Required but may be empty)
 If the predicate is not satisfied:
 The conformant sending application must NOT send the
element
 The conformant receiving application MAY raise an application
error if the element IS present
 X - Not supported
 Conformant sending applications will NOT send the
element
 Conformant receiving applications MAY ignore the
element if it IS present, or may raise an application error

Optionality / Usage Relationship
 Conformance Usage codes are more specific than
HL7 Optionality codes
HL7 Optionality Allowed Conformance Usage Comment
R - Required R
O - Optional R, RE, O*, C, CE, X O is only permitted for
constrainable profiles
C - Conditional C, CE, R** ** If satisfied by use case
X – Not Supported X
B – Backward
Compatibility
R, RE, O*, C, CE, X O is only permitted for
constrainable profiles
W – Withdrawn X

Message Level Profile
 Segment Definitions
 The set of segments and segment groups included within
the message of an HL7 Message Profile shall be defined
 Any segments or segment groups that are required by
HL7 shall be included
 Segment Usage
 Segment Cardinality
 Profile does not allow for “empty” segment
 HL7 abstract message syntax PLUS
 Usage
 Cardinality

Message Level Profile Example
ADT^A01^ADT_A01 ADT Message Usage Cardinality Chapter
MSH Message Header R [1..1] 2
EVN Event Type R [1..1] 3
PID Patient Identification R [1..1] 3
[ PD1 ] Additional Demographics X [0..0] 3
[{ ROL }] Role X [0..0] 12
[{ NK1 }] Next of Kin / Associated
Parties
RE [0..3] 3
PV1 Patient Visit R [1..1] 3
[ PV2 ] Patient Visit - Additional
Info.
RE [0..1] 3
[{ ROL }] Role X [0..0] 12
[{ DB1 }] Disability Information X [0..0] 3
[{ OBX }] Observation/Result X [0..0] 7
[{ AL1 }] Allergy Information RE [0..*] 3
[{ DG1 }] Diagnosis Information X [0..0] 6
[ DRG ] Diagnosis Related Group X [0..0] 6
[{ X [0..0]
PR1 Procedures X [0..0] 6
[{ ROL }] Role X [0..0] 12
}]
[{ GT1 }] Guarantor X [0..0] 6
[{ X [0..0]
IN1 Insurance X [0..0] 6
[ IN2 ] Insurance Additional Info. X [0..0] 6
[{ IN3 }] Insurance Additional Info -
Cert.
X [0..0] 6
[{ ROL }] Role X [0..0] 12
}]
[ ACC ] Accident Information X [0..0] 6
[ UB1 ] Universal Bill Information X [0..0] 6
[ UB2 ] Universal Bill 92 Information X [0..0] 6
[ PDA ] Patient Death and Autopsy X [0..0] 3

Parties
RE [0..3] 3
Info.
RE [0..1] 3

Message Level Profile Example 2
[{ ROL }] Role X [0..0] 12
Parties
RE [0..10] 3
Info.
R [1..1] 3
[{ ROL }] Role X [0..0] 12
[{ X [0..0]
[{ ROL }] Role X [0..0] 12
}]
[{ RE [0..3]
IN1 Insurance R [1..1] 6
[ IN2 ] Insurance Additional Info. RE [0..1] 6
Cert.
X [0..0] 6
[{ ROL }] Role X [0..0] 12
}]
[ ACC ] Accident Information RE [0..1] 6

Message Level Profile Example 2
Parties
RE [0..10] 3
Info.
R [1..1] 3
[{ RE [0..3]
IN1 Insurance R [1..1] 6
[ IN2 ] Insurance Additional Info. RE [0..1] 6
}]
[ ACC ] Accident Information RE [0..1] 6

Segment Level Profile
 The set of fields of each instance of a segment
within the Message Profile
 If a segment occurs multiple times, it may be
represented by different segment profiles
 Field Usage
 Field Cardinality
 Syntax (tabular HL7 segment definitions)
 Length (updated)
 Usage (new column)
 Cardinality (new column)

Segment Level Profile Example (PID)
SEQ LEN DT Usage Cardinality TBL# ITEM# ELEMENT NAME
1 4 SI X 00104 Set ID - PID
2 20 CX RE [0..1] 00105 Patient ID
3 20 CX R [1..*] 00106 Patient Identifier List
4 20 CX X 00107 Alternate Patient ID - PID
5 48 XPN R [1..*] 00108 Patient Name
6 48 XPN RE [0..*] 00109 Mother’s Maiden Name
7 26 TS RE [0..*] 00110 Date/Time of Birth
8 1 IS RE [0..*] 0001 00111 Sex
9 48 XPN X 00112 Patient Alias
10 80 CE X 0005 00113 Race
11 106 XAD RE [0..3] 00114 Patient Address
12 4 IS X 0289 00115 County Code
13 40 XTN RE [0..3] 00116 Phone Number - Home
14 40 XTN RE [0..3] 00117 Phone Number - Business
15 60 CE X 0296 00118 Primary Language
16 80 CE X 0002 00119 Marital Status
17 80 CE X 0006 00120 Religion
18 20 CX X 00121 Patient Account Number
19 16 ST RE [0..1] 00122 SSN Number - Patient
20 25 DLN X 00123 Driver's License Number - Patient
21 20 CX X 00124 Mother's Identifier
22 80 CE X 0189 00125 Ethnic Group
23 60 ST RE [0..1] 00126 Birth Place
24 1 ID X 0136 00127 Multiple Birth Indicator
25 2 NM X 00128 Birth Order
26 80 CE X 0171 00129 Citizenship
27 60 CE X 0172 00130 Veterans Military Status
28 80 CE X 0212 00739 Nationality
29 26 TS X 00740 Patient Death Date and Time
30 1 ID X 0136 00741 Patient Death Indicator
SEQ LEN DT OPT RP/# TBL# ITEM# ELEMENT NAME
1 4 SI O 00104 Set ID - PID
2 20 CX B 00105 Patient ID
3 250 CX R Y 00106 Patient Identifier List
4 20 CX B Y 00107 Alternate Patient ID - PID
5 250 XPN R Y 00108 Patient Name
6 250 XPN O Y 00109 Mother’s Maiden Name
7 26 TS O Y 00110 Date/Time of Birth
8 1 IS O Y 0001 00111 Sex
9 250 XPN B 00112 Patient Alias
10 250 CE O 0005 00113 Race
11 250 XAD O Y 00114 Patient Address
12 4 IS B 0289 00115 County Code
13 250 XTN O Y 00116 Phone Number - Home
14 250 XTN O Y 00117 Phone Number - Business
15 250 CE O 0296 00118 Primary Language
16 250 CE O 0002 00119 Marital Status
17 250 CE O 0006 00120 Religion
18 250 CX O 00121 Patient Account Number
19 16 ST B 00122 SSN Number - Patient
20 25 DLN B 00123 Driver's License Number - Patient
21 250 CX O Y 00124 Mother's Identifier
22 250 CE O Y 0189 00125 Ethnic Group
23 250 ST O 00126 Birth Place
24 1 ID O 0136 00127 Multiple Birth Indicator
25 2 NM O 00128 Birth Order
26 250 CE O Y 0171 00129 Citizenship
27 250 CE O 0172 00130 Veterans Military Status
28 250 CE B 0212 00739 Nationality
29 26 TS O 00740 Patient Death Date and Time
30 1 ID O 0136 00741 Patient Death Indicator

Segment Level Profile Example (PID)
2 20 CX RE [0..1] 00105 Patient ID
7 26 TS RE [0..*] 00110 Date/Time of Birth
8 1 IS RE [0..*] 0001 00111 Sex
10 80 CE X 0005 00113 Race
17 80 CE X 0006 00120 Religion
19 16 ST RE [0..1] 00122 SSN Number - Patient
23 60 ST RE [0..1] 00126 Birth Place

Message Profile Identifier
 Uniquely identifies static and dynamic profile
 The static profile identifier is a means to uniquely
identify a message profile, expressed as an ASN.1
Object Identifier (OID)
 The sending application uses the profile identifiers to
determine the specific HL7 Message Profile to send
 Branch from ISO to HL7 and Message Profile
 2.16.840.1.113883.9

MSH-21 Message Profile Identifier
 Sites may use this field to assert adherence to, or
reference, a message profile.
 Message profiles contain detailed explanations of
grammar, syntax, and usage for a particular message or
set of messages.
 Repetition of this field allows more flexibility in creating
and naming message profiles.
 Using repetition, this field can identify a set of message
profiles that the message conforms to.
 As of v2.5, the HL7 message profile identifiers might be
used for conformance claims.
 Prior to v2.5, the field was called Conformance
Statement ID. For backward compatibility, the
Conformance Statement ID can be used here.

How it all ties together
Static Definition – Field Level
Vocabulary
2 20 CX RE [1..1] 00105 Patient ID
7 26 TS RE 00110 Date/Time of Birth
8 1 IS RE 0001 00111 Sex
10 80 CE X 0005 00113 Race
17 80 CE X 0006 00120 Religion
19 16 ST RE 00122 SSN Number - Patient
23 60 ST RE 00126 Birth Place
: ADT Sy stem : ADT Notification
Recip ient
ADTÂ01
ACK Â01
Interaction Model
Segment ADT Message Usage Cardinality Chapter
[{ ROL }] Role X [0..0] 12
Parties
RE [0..3] 3
Info.
RE [0..1] 3
[{ ROL }] Role X [0..0] 12
[{ X [0..0]
[{ ROL
}]
Role X [0..0] 12
}]
[{ X [0..0]
[{ IN3
}]
Insurance Additional Info -
Cert.
X [0..0] 6
[{ ROL
}]
Role X [0..0] 12
}]
Dynamic Definition
Static Definition – Segment Level
P at ie nt
P hy s ic ian
A D T No tific at ion
Re c ipien t
A D T S y s tem
A dm it/ V is it Notific ation
is s u b jec t of
autho riz es
rec e ives notific ations en ds no tific at ion
Reg is trar
trig gers
Use Case Model
Static Definition – Message Level
1 Use Case Model
1.1 Use Case: Admit/Visit Notification
2. Dynamic Interaction Model
3 Dynamic Definition: ADT/ACK (Event A01)
3.1 ADTÂ01
3.2 ACKÂ01
4 Static Definition: - Message Level -
ADT/ACK (event A01)
4.1 ADTÂ01
4.2 ACKÂ01
5 Static Defintiion - Segment Level
5.1 MSH – Message Header Segment Definition
5.2 EVN - Event Type Segment Definition
5.3 PID (Y) - Patient Demographics Segment
Definition
5.4 PD1 – Patient Additional Demographic
Segment Definition
5.5 NK1 - Next of kin Segment Definition
5.6 PV1 (2) - Admit Visit Info Segment
Definition
5.7 AL1 - Allergy Segment Definition
5.8 MSA - Message Acknowledgment Segment
Definition
5.9 ERR - Error Segment Definition
6 Static Definition - Field Level
6.1 Table 0001 – Sex
6.2 Table 0002 – Marital Status
6.3 Table 0003 – Event Type Code
6.4 Table 0004 – Patient Class
6.5 Table 0005 – Race
6.6 Table 0006 – Religion
6.7 Table 0007 – Admission Type
6.8 Table 0008 – Acknowledgement Code
6.9 Table 0009 – Ambulatory Status

Compliance and Conformance
 Compliance
Messages that adhere to the rules
and conventions for constructing
of a specific version of a standard
are compliant to that version of
the standard.
 Conformance
Messages that adhere to the
constraints of a precise and
unambiguous specification called
a message profile are said to be
conformant to the profile.
Compliance Conformance

Conformance Profiling Benefits
 Consistent Documentation
 Reuse of Specification
 Lower Cost of Integration
 Similar to Version 3
 Chaos -> order
 Site Specific Profiles
 Supports specific needs
 Required of third-party application vendors
 RFP
 Simplifies introduction/acquisition of new applications

Use Cases of Message
Conformance Profiling

California Department
of Health Services
Electronic Laboratory Reporting Project

CA ELR Project Use Cases
UC01: Report Laboratory
Result UC02: Reroute Misdirected
Laboratory Result
UC03: Persist Laboratory
Result Message Content
UC04: Laboratory Result
Business Intellegence /
Analytics
Reporting Laboratory
Receiving Public Health
Agency
Accountable Public Health
Agency
ELR HUB
ELR Repository
Business Analysts
and Statisticians

Lab Message
Supplier
Inbound
Laboratory
Message
Inbound
Message Profile
Transform
Translate
Inbound
Message Mapping
Canonical
Laboratory
Message
Canonical
Message Profile
Transform
Translate
Outbound
Message Mapping
Outbound
Laboratory
Message
Lab Message
Consumer
Knowledge
Management
Service
Knowledge
Management
Service
Object Graph
Generation
Laboratory
Message
Objects
Object
Relational
Mapping
Laboratory
Message
Respository
Object Relational
Map
ELR Database
Design Model
CA Public Health
Logical Data
Model
HL7 RIM &
CDC PHLDM
Canonical
Message Profile
Laboratory
Message Object
Model
Extract,
Transform,
and Load
Laboratory
Datamart
Business
Intelligence
Application
Business
Intelligence
Application
Business
Intelligence
Application
Outbound
Message Profile
Extract,
Transform,
and Load
Additional Data
Sources

Inbound Message Processing Outbound Message Processing
Data Persistence
Business Intelligence
Lab Message
Supplier
Inbound
Laboratory
Message
Inbound
Message Profile
Transform
Translate
Inbound
Message Mapping
Canonical
Laboratory
Message
Canonical
Message Profile
Transform
Translate
Outbound
Message Mapping
Outbound
Laboratory
Message
Lab Message
Consumer
Knowledge
Management
Service
Knowledge
Management
Service
Object Graph
Generation
Laboratory
Message
Objects
Object
Relational
Mapping
Laboratory
Message
Respository
Object Relational
Map
ELR Database
Design Model
CA Public Health
Logical Data
Model
HL7 RIM &
CDC PHLDM
Canonical
Message Profile
Laboratory
Message Object
Model
Extract,
Transform,
and Load
Laboratory
Datamart
Business
Intelligence
Application
Business
Intelligence
Application
Business
Intelligence
Application
Outbound
Message Profile
Extract,
Transform,
and Load
Additional Data
Sources

Inbound
Laboratory
Message
Inbound
Message Profile
Transform
Translate
Inbound
Message Mapping
Canonical
Laboratory
Message
Canonical
Message Profile
Transform
Translate
Outbound
Message Mapping
Outbound
Laboratory
Message
Outbound
Lab Message
Supplier
Lab Message
Consumer
Knowledge
Management
Service
Knowledge
Management
Service
Object Graph
Generation
Laboratory
Message
Objects
Object
Relational
Mapping
Laboratory
Message
Repository
Object Relational
Map
ELR Database
Design Model
CA Public Health
Logical Data
Model
HL7 RIM &
CDC PHLDM
Canonical
Message Profile
Laboratory
Message Object
Model
Extract,
Transform,
and Load
Laboratory
Datamart
Business
Intelligence
Application
Business
Intelligence
Application
Business
Intelligence
Application
Message Profile
Extract,
Transform,
and Load
Additional Data
Sources

Message Profiles
 Describe message structure and anticipated application behavior
 Identify required, optional, and conditional message elements
 Identify coding systems or value-sets for coded elements
 Enable message validation, transformation, and persistence
 Are essential for achieving system-to-system interoperability
Inbound
Laboratory
Message
Inbound
Message Profile
Transform
Translate
Inbound
Message Mapping
Canonical
Laboratory
Message
Canonical
Message Profile
Transform
Translate
Outbound
Message Mapping
Outbound
Laboratory
Message
Outbound
Message Profile

California State
Immunization Information System
System Interface Project

 The California State Immunization
Information System (SIIS) is a
collaboration of
 regional immunization registries,
 local health departments,
 the California Department of Health
Services Immunization Branch, and
 a spectrum of key stakeholders
across the state of California.
 The goal of SIIS is to ensure that
health care providers have rapid
access to complete and up-to-date
immunization records.
 The objective is to eliminate both
missed opportunities to immunize and
unnecessary duplicate
immunizations.
 SIIS consists of nine regional
registries and two county registries.
 SIIS is a system of systems each
independently managed and
operated.

Regional and County Registries
 Immunization Network of Northern California (INNC)
 Shots For Tots KIDS Regional Immunization Registry (SFT)
 Bay Area Regional Immunization Registry (BARR)
 Imperial County (IMPL) **
 Contra Costa County Automated Immunization Registry (CCAIR)**
 Regional Immunization Data Exchange (RIDE)
 Central Valley Immunization Information System (CVIIS)
 Central Coast Immunization Registry (CCIR)
 Los Angeles-Orange Immunization Network (LINK)
 VaxTrack Regional Immunization Registry (VaxTrack)
 San Diego Regional Immunization Registry (SDIR)

 The scope of the California Statewide Immunization
Information System (SIIS) Systems Interface Project (SIP) is
to design, construct, and implement a centralized electronic
messaging hub that facilitates the automated exchange of
immunization related data within the state of California.
 The objective is to enable registry users to gain access to an
individual’s complete immunization history regardless of
where that history is maintained.
Project Scope

 The premise behind the project is that, for many reasons,
a person’s immunization history data becomes
fragmented over time.
 The data are stored and maintained in separate state
registries and immunization provider information
systems.
 Typical scenarios that lead to this situation are changes
in a person’s primary residence, changes in a person’s
primary healthcare provider, and ad hoc administration of
immunizations such as during travel or emergencies.
 Once a person’s immunization data becomes fragmented
across multiple registry or provider information systems it
can be difficult to ascertain their current immunization
status.
 This can result in over immunization or under
immunization.
Problem Statement

ad Dynamic View
Health Level Seven CDC / AIRA SIIS SIP Project Team Regional Registry
HL7 v 2.5 Messaging
Standard
IZ Messaging
Implemenation Guide
Prepare Preliminary
Segment Lev el Profile
Preliminary Segment
Lev el Profile
Prepare SIIS SIP
Conceptual Data Model
SIIS SIP Conceptual
Data Model
Map Profile to Regional
Systems
Regional System to
Profile Mapping
Prepare Final Segment
Lev el Profile
Final Segment Lev el
Profile
Prepare SIIS SIP Logical
Data Model
SIIS SIP Logical Data
Model
Prepare SIIS SIP Phase I
Message Lev el Profiles
SIIS SIP Phase I
Message Lev el Profiles
Prepare SIIS SIP
SIIS SIP Vocabulary
Specification
Prepare IZ Implementation
Guide
 Prepare IZ messaging implementation guide
 Prepare preliminary segment level profile
 Prepare SIIS SIP conceptual data model
 Map preliminary profile to regional IZ systems
 Prepare final segment level profile
 Prepare SIIS SIP logical data model
 Prepare SIIS SIP phase I message level profiles
 Prepare SIIS SIP vocabulary specification

Immunization Messaging Implementation
Guide
 The Centers for Disease Control and Prevention (CDC) National
Immunization Program (NIP) publishes an implementation guide for
immunization data messaging.
 The title of the guide is “Implementation Guide for Immunization
Data Transactions using version 2.3.1 of the Health Level Seven
(HL7) Standard Protocol”.
 The intent of the guide is to help familiarize developers of
immunization information systems with HL7 immunization message
definitions and encoding rules and provide a nationally consistent
implementation of those messages.
 Changes to the guide are coordinated through the Data Exchange
Steering Committee of the American Immunization Registry
Association (AIRA) and its associated work groups.
 The members of AIRA are committed to advancing the exchange of
immunization data using a common protocol.

Immunization Messaging Implementation
Guide
 The guide identifies the set of HL7 messages needed to enable
information systems that maintain immunization records to transmit
patient-specific immunization histories electronically to other systems to
allow healthcare providers to have access to these records at the time
health care is given.
 The use cases detailed in the guide indicate that data transmission will
occur as the result of four activities:
 a query from one system for a patient’s vaccination record that
is held in another system using the HL7 VXQ message;
 a response to a query containing multiple patient “matches” to
the query, but not returning vaccination records using the HL7
VXX message;
 a response to a query containing the vaccination record using
the HL7 VXR message; and
 an unsolicited update to a vaccination record using the HL7
VXU message.
 In addition to the messages used for the four primary activities the guide
also includes specifications for transmission confirmation and exception
notification messages; ACK and QCK.

Preliminary Segment Level Profile
Message Tree Seq ETyp DTyp Usage Min Max Table Len Reference
PID 011 Segment R 1 1
Set ID - PID 001 Field SI RE 0 1 4 3.4.2.1
Patient ID 002 Field CX RE 0 1 33 3.4.2.2
Patient Identifier List 003 Field CX R 1 0 250 3.4.2.3
Alternate Patient ID - PID 004 Field CX RE 0 1 33 3.4.2.4
Patient Name 005 Field XPN R 1 0 250 3.4.2.5
Mother's Maiden Name 006 Field XPN RE 0 1 250 6.5.7.40
Date/Time Of Birth 007 Field TS RE 0 1 26 15.4.6.6
Administrative Sex 008 Field IS RE 0 1 0001 1 15.4.6.5
Patient Alias 009 Field XPN RE 0 1 250 3.4.2.9
Race 010 Field CE RE 0 1 0005 250 15.4.6.27
Patient Address 011 Field XAD RE 0 1 250 3.4.2.11
County Code 012 Field IS RE 0 1 0289 4 3.4.2.12
Phone Number - Home 013 Field XTN RE 0 1 250 3.4.2.13
Phone Number - Business 014 Field XTN RE 0 1 250 3.4.2.14
Primary Language 015 Field CE RE 0 1 0296 250 6.5.7.34
Patient Account Number 018 Field CX RE 0 1 250 3.4.2.18
SSN Number - Patient 019 Field ST RE 0 1 16 3.4.2.19
Mother's Identifier 021 Field CX RE 0 1 250 3.4.2.21
Ethnic Group 022 Field CE RE 0 1 0189 250 15.4.6.28
Birth Place 023 Field ST RE 0 1 250 3.4.2.23
Multiple Birth Indicator 024 Field ID RE 0 1 0136 1 3.4.2.24
Birth Order 025 Field NM RE 0 1 2 3.4.2.25
Citizenship 026 Field CE RE 0 2 0171 250 6.5.7.33
Veterans Military Status 027 Field CE RE 0 1 0172 250 3.4.2.27
Patient Death Date and Time 029 Field TS RE 0 1 26 3.4.2.29
Patient Death Indicator 030 Field ID RE 0 1 0136 1 3.4.2.30
Last Update Date/Time 033 Field TS RE 0 1 26 3.4.2.33
Production Class Code 038 Field CE RE 0 1 0429 250 3.4.2.38

SIIS SIP Conceptual Data Model
cd Logical Model Patient Demographics
Facility
identifier: char(20)
name: char(50)
assigningAuthorityId: char(20)
namespaceId: char(20)
streetAddress: char(120)
city: char(50)
stateOrProvince: char(50)
zipOrPostalCode: char(12)
country: char(3)
addressType: char(3)
Patient
dateTimeOfBirth: timestamp
birthState: char(60)
multipleBirthIndicator: char(1)
administrativeSex: char(1)
birthOrder: numeric(2)
deathDateTime: timestamp
deathIndicator: char(1)
lastUpdateDateTime: timestamp
lastUpdateFacility: char(20)
PublicityCodeID: char(20)
publicityCodeEffectiveDate: datetime
publicityCodeText: char(199)
protectionIndicator: char(1)
protectionIndicatorEffectiveDate: datetime
immunizationRegistryStatus: char(1)
immunizationRegistryStatusEffectiveDate: datetime
PersonPostalAddress
streetOrMailingAddress: char(120)
streetName: char(50)
dwellingNumber: char(12)
city: char(50)
stateOrProvince: char(50)
zipOrPostalCode: char(12)
addressType: char(3)
countyParishCode: char(20)
countryCode: char(3)
PatientLanguageAbility
text: char(199)
preferenceIndicator: char(1)
PersonTelecommunicationAddress
telecommunicationUseCode: char(3)
areaCityCode: numeric(5)
phoneNumber: numeric(9)
extension: numeric(5)
anyText: char(199)
Person
surname: char(50)
givenName: char(30)
secondAndFurtherGivenNamesOrInitialsThereof: char(30)
suffix: char(20)
PersonIdentifier
id: char(15)
idType: char(6)
namespaceId: char(20)
PersonAlternateName
typeCode: char(1)
surname: char(50)
givenName: char(30)
secondAndFurtherGivenNamesOrInitialsThereof: char(30)
suffix: char(20)
PatientRelationship
text: char(199)
contactRoleIdentifier: char(20)
contactRoleText: char(199)
livingArrangement: char(2)
PatientRace
text: char(199) PatientEthnicGroup
text: char(199)
0..*
1
1..*
1
1..*
1
0..1
1
0..*
1
0..*
1
0..* 1..* 0..*1..*
0..*
1
0..* 11..* 1

Regional System to Segment Profile Mapping
Path
LINK
SDIR
VAXTRACK
CCIR
BARR
RIDE
INNC
SFT
CVIIS
Imperial
ProfileUsage
COMMENT
PID PID
PID.1 SetID-PID Y Y N Y Y N Y Y Y N Y
PID.3 PatientIdentifierList
PID.3.1 ID Y Y N Y Y Y Y Y Y Y Y
PID.3.4 assigningauthority
PID.3.4.1 namespaceID Y Y N Y Y Y Y Y Y N Y
PID.5 PatientName
PID.5.1 familyname
PID.5.1.1 surname Y Y Y Y Y Y Y Y Y Y Y
PID.5.2 givenname Y Y Y Y Y Y Y Y Y Y Y
PID.5.3 secondandfurthergivennamesorinitialsthereof Y Y Y Y Y Y Y Y Y Y Y
PID.5.4 suffix(e.g.,JRorIII) Y Y Y Y Y Y Y Y Y N Y
PID.6 Mother'sMaidenName
PID.6.1 familyname
PID.6.1.1 surname Y Y Y Y Y Y Y Y Y Y Y
PID.7 Date/TimeOfBirth
PID.7.1 Date/Time Y Y Y Y Y Y Y Y Y Y Y
PID.8 AdministrativeSex Y Y Y Y Y Y Y Y Y Y Y
PID.9 PatientAlias
PID.9.1 familyname
PID.9.1.1 surname N N Y N Y Y Y/Y Y Y Y Y
PID.9.2 givenname N N Y N Y Y Y/Y Y Y Y Y
PID.9.3 secondandfurthergivennamesorinitialsthereof N N Y N Y N Y/Y Y Y Y Y
PID.9.4 suffix(e.g.,JRorIII) N N Y N Y N Y/Y N Y N Y
PID.10 Race
PID.10.1 identifier Y Y Y Y Y Y Y Y Y Y Y
PID.10.2 text Y N Y Y Y N Y Y Y Y Y
PID.10.3 nameofcodingsystem Y Y Y Y Y N Y Y Y N Y
PID.11 PatientAddress
PID.11.1 streetaddress(SAD)
PID.11.1.1 streetormailingaddress Y Y Y Y Y Y Y Y Y Y Y
PID.11.1.2 streetname N N N N N N N N N Y N
PID.11.1.3 dwellingnumber N N N N N N N N N Y N
PID.11.3 city Y Y Y Y Y Y Y Y Y Y Y
PID.11.4 stateorprovince Y Y Y Y Y Y Y Y Y Y Y
PID.11.5 ziporpostalcode Y Y Y Y Y Y Y Y Y Y Y
PID.11.7 addresstype Y Y Y Y Y N Y Y Y Y Y
PID.11.9 county/parishcode Y Y Y Y Y Y Y Y Y Y Y
Element Name

Final Segment Level Profile
Message Tree Seq ETyp DTyp Usage Min Max Table
PID 009 Segment R 1 1 0396
Set ID - PID 001 Field SI R 1 1
Patient Identifier List 003 Field CX R 1 *
ID number 001 Component ST R 1 1
assigning authority 004 Component HD R 1 1
namespace ID 001 SubComponent IS R 1 1 0363
identifier type code 005 Component ID R 1 1 0203
Patient Name 005 Field XPN R 1 1
family name 001 Component FN R 1 1
surname 001 SubComponent ST R 1 1
given name 002 Component ST RE 0 1
second and further given names or initials thereof 003 Component ST RE 0 1
suffix (e.g., JR or III) 004 Component ST RE 0 1
name type code 007 Component ID R 1 1 0200
Mother_s Maiden Name 006 Field XPN RE 0 1
Date/Time of Birth 007 Field TS R 1 1
time 001 Component DTM R 1 1
Administrative Sex 008 Field IS R 1 1 0001
Patient Alias 009 Field XPN RE 0 *
given name 002 Component ST RE 0 1
second and further given names or initials thereof 003 Component ST RE 0 1
suffix (e.g., JR or III) 004 Component ST RE 0 1
Race 010 Field CE RE 0 1
identifier 001 Component ST R 1 1 0005
text 002 Component ST RE 0 1
name of coding system 003 Component ID R 1 1 0396
alternate identifier 004 Component ST RE 0 1
alternate text 005 Component ST RE 0 1
name of alternate coding system 006 Component ID RE 0 1 0396

SIIS SIP Logical Data Model
cd Logical Model Patient Demographics
Facility
*PK idNumber: int
FK providerOrganizationIdNumber: int
addressLine1Text: char(120)
cityName: char(50)
statePostalCode: char(50)
postalCode: char(12)
countryCode: char(3)
addressTypeCode: char(3)
FK
+ FK_Facility_ProviderOrganization(int)
PK
+ PK_Facility(int)
Patient
*PK idNumber: int
FK facilityIdNumber: int
* birthDate: datetime
birthStateCode: char(60)
multipleBirthIndicator: char(1)
* sexCode: char(1)
deathIndicator: char(1)
* raceCode: char(20)
* ethnicityCode: char(20)
* allowableReminderTypeCode: char(20)
* primaryLanguageCode: char(20)
recordSharingConsentIndicator: char(1)
immunizationRegistryStatusCode: char(1)
FK
+ FK_Patient_Facility(int)
PK
+ PK_Patient(int)
PersonPostalAddress
*PK idNumber: int
*FK personIdNumber: int
cityName: char(50)
stateCode: char(50)
postalCode: char(12)
addressTypeCode: char(3)
countyCode: char(20)
FK
+ FK_PersonPostalAddress_Person(int)
PK
+ PK_PersonPostalAddress(int)
PersonTelecommunicationAddress
*PK idNumber: int
telecommunicationUseCode: char(3)
areaCode: numeric(5)
* phoneNumber: numeric(9)
extensionNumber: numeric(5)
concatenatedTelecomNumber: char(199)
FK
+ FK_PersonTelecommunicationAddress_Person(int)
Person
*PK idNumber: int
surname: char(50)
givenName: char(30)
middleName: char(30)
nameSuffix: char(20)
PK
+ PK_Person(int)
PersonIdentifier
*PK idNumber: int
FK organizationIdNumber: int
* idCode: char(15)
idTypeCode: char(6)
* idAssigningAuthority: char(20)
* statusCode: char(2)
FK
+ FK_PersonIdentifier_Organization(int)
+ FK_PersonIdentifier_Person(int)
PersonAlternateName
*PK idNumber: int
* typeCode: char(1)
* surname: char(50)
givenName: char(30)
middleName: char(30)
nameSuffix: char(20)
FK
+ FK_PersonAlternateName_Person(int)
PatientRelationship
*PK idNumber: int
*FK patientIdNumber: int
* typeCode: char(20)
* effectiveDate: datetime
FK
+ FK_PatientRelationship_Patient(int)
+ FK_PatientRelationship_Person(int)
PK
+ PK_PatientRelationship(int)
Organization
*PK idNumber: int
idCode: char(20)
* assigningAuthorityIdCode: char(20)
* name: char(50)
PK
+ PK_ProvderOrganization(int)
FacilityAlternateIdentifier
*PK facilityAlternateId: char(20)
*pfK FacilityIdNumber: int
FK identifierAssigningAuthority: int
identifierTypeCode: bigint
FK
+ FK_FacilityAlternateIdentifier_Facility(int)
+ FK_FacilityAlternateIdentifier_Organization(int)
PK
+ PK_FacilityAlternateIdentifier(char, int)
TreatmentRefusal
*PK reasonIdCode: char(20)
*pfK vaccineAdministrationIdNumber: int
FK
+ FK_TreatmentRefusal_VaccineAdministration(int)
PK
+ PK_TreatmentRefusal(char, int)
VaccineAdministration
FK administeringProvideridNumber: int
*PK idNumber: int
*FK FacilityIdNumber: int
* doseSequenceNumber: numeric(4)
* substanceIdCode: char(20)
* startDateTime: datetime
* endDateTime: datetime
* substanceAdministeredAmount: numeric(20)
* routeIdCode: char(20)
* substanceUnitOfMeasureCode: char(20)
* siteIdCode: char(20)
substanceLotNumber: char(20)
* substanceDosageFormIdCode: char(20)
* substanceManufacturerIdCode: char(20)
* systemEntryDateTime: datetime
FK
+ FK_VaccineAdministration_Facility(int)
+ FK_VaccineAdministration_Patient(int)
+ FK_VaccineAdministration_Person(int)
PK
+ PK_VaccineAdministration(int)
0..*
1
0..*
(identifierAssigningAuthority = idNumber)
0..1
0..*
(personIdNumber = idNumber)
1
0..*
(organizationIdNumber = idNumber)
1
0..*
(providerOrganizationIdNumber
= idNumber)
0..1
1..*
(patientIdNumber =
idNumber)
1
0..*
(patientIdNumber = idNumber)
1
0..*
1
0..*
(administeringProvideridNumber = idNumber)
1
0..*
1
0..*
1
0..*
(vaccineAdministrationIdNumber = idNumber)
1
0..*
normally receives
care at
1
0..*
(FacilityIdNumber = idNumber)
1
0..*
(patientIdNumber =
idNumber)
1

SIIS SIP Message Level Profiles
 HL7 defines a message profile as “an unambiguous specification of one or
more standard HL7 messages that have been analyzed for a particular use
case”. It prescribes a set of precise constraints upon one or more standard
HL7 messages.
 A message profile eliminates ambiguity in a HL7 message specification by
declaring static and semantic constraints for constituent elements of a
message and the expected dynamic behavior of conformant application
systems.
 The SIIS SIP HL7 message profile is an extension to the NIP Implementation
Guide. The profile is based upon version 2.1 of the guide published in
September 2002.
 The profile extends the specifications included in the guide. The profiles do
not conflict with the guide; however, they are more constrained than the
guide.
 Messages that conform to the profile are conformant with the guide as well;
although the converse may not be true.
 A message profile has dynamic definition and a static definition.

HL7 Message Profile Dynamic Definition
 The dynamic definition describes the supported use
cases, interactions, and acknowledgement requirements.
 Use Case Model
The use case portion of the message profile dynamic definition documents the scope
and requirements for an HL7 message profile or set of message profiles. The use
case model documents the purpose for each message exchange; defines the actors,
including the sending and receiving applications; and document the situations in which
the exchange of a particular HL7 message profile is required
 Interaction Model
The Interaction Model illustrates the sequence of trigger events and resulting message
flows between 2 or more systems. It may be in literal or graphical form. Graphical form
should be a UML activity diagram.
 Acknowledgement Requirements
The specific HL7 acknowledgments required and/or allowed for use with the specified
static definition of the HL7 message profile is defined. Specifically, the dynamic
definition identifies whether accept and application level acknowledgments are allowed
or required. For any one static definition there may be one or more dynamic
definitions. The dynamic definition defines the conditions under which accept and
application level acknowledgments are expected. Allowed conditions include: Always,
Never, Only on success, and Only on error.

HL7 Message Profile Static Definition
 The static definition describes usage rules, cardinalities,
and code systems.
 Usage Rules
Usage refers to the circumstances under which an element appears in a message instance. Some elements
must always be present, others may never be present, and others may only be present in certain
circumstances. HL7 has defined a set of codes to clearly identify the rules governing the presence of a
particular element. These usage codes expand/clarify the optionality codes defined in the HL7 standard.
 Cardinality
Cardinality identifies the minimum and maximum number of occurrences for a particular element (Segment
Group, Segment or Field). Cardinalities are expressed as a minimum-maximum pair of non-negative integers.
A conformant application must always send at least the minimum number of occurrences, and may never
send more than the maximum number of occurrences.
 Vocabulary Specification
Vocabulary specifications declare an organized set of code systems and code system terms. Code system
terms are coded concepts including concept codes, concept names, and concept relationships. Code system
terms are collected into value sets declared as code tables associated with segment fields and data type
components. The static definition declares the value sets for tables associated with coded message
elements. Some of the value sets are HL7 defined, third party defined, or user defined.

SIIS SIP Use Case Diagram
ud Use Case Model
Local Registry User
1.0 Immunization
History Query
2.0 Patient
Demographic
Update
3.0 Vaccine
Record Update Provider Organization
SIIS Registry
Administration
4.0 Immunization
Statistical Analysis
Trusted Third PartiesLocal Registry
Administration
SIIS Analysis Report SIIS Analysis Report
Update Confirmation
Update Confirmation
Query Response
Vaccine Record Update
Patient Information Update
Immunization History Request

SIIS SIP Activity Model
ad InteractionActivityModel
Requesting Registry System SIIS SIP Immunization Information Exchange System Responding Registry System
1.1 Request Immunization
Data
«message»
M.01 Immunization Data
Request (VXQ)
2.2 Validate Immunization
Data Request Message
«message»
M.02 Request Error Message
(ACK)
2.3 Route Immunization
Data Request Message2.4 Notify System
Administrator
«message»
M.03 Immunization
Data Request (VXQ)
3.1 Retrive Requested
Immunization Data
«datastore»
D.04 Immunization
Registry
3.2 Retrival
Result?
3.2.1 Return "No Matching
Record" Response
3.2.2 Return "Multiple
Matching Records"
Response
3.2.3 Return Requested
Immunization Data
«message»
M.04 No Matching
Record Response (QCK)
«message»
Records Response (VXX)
«message»
M.06 Requested
Immunization Data (VXR)
4.2 Validate Response
Message
«message»
M.07 Response Message
Error (ACK)
4.3 Route Response
Message
4.4 Notify System
Administrator
«message»
M.08 No Matching Record
Message (QCK)
«message»
Record Message (VXX)
«message»
M.10 Requested Immunization
Data Message (VXR)
5.1 Refine Demographic
Data
5.2 Select Desired Record
5.3 Merge Immunization
Data with existing data
«datastore»
D.01 Immunization
Registry
[Valid Message]
[Invalid Message]
[Valid Message]
[No Matching Record]
[Desired Record Not Present]
[Multiple Matching Records]
[Single Matching Record]
[Desired Record Selected]
[Invalid Message]
1
2 3
4
6
5

SIIP SIP Interaction Model
sd Interactions
Requesting Registry
System
SIIS SIP Immunization
Information Exchange
System
Responding Registry
System
Vaccination Record Query (VXQ)
[Invalid VXQ Message]: General Acknowledgement (ACK)
[Valid VXR Message]: Vaccination Record Query (VXQ)
[No Matching Record]: Query Acknowledgement (QCK)
[Invalid QCK Message]: General Acknowledgement (ACK)
[Valid QCK Message]: Query Acknowledgement (QCK)
[Multiple Matching Records]: Vaccination Query Response (VXX)
[Invalid VXX Message]: General Acknowledgement (ACK)
[Valid VXX Message]: Vaccination Query Response (VXX)
[Single Matching Record]: Vaccination Query Response (VXR)
[Invalid VXR Message]: General Acknowledgement (ACK)
[Valid VXR Message]: Vaccination Query Response (VXR)

SIIS SIP Acknowledgement Requirements
Message Source Destination Acknowledgment
• Vaccination Record Query (VXQ) Requester IIES Only on error
• General Acknowledgement (ACK) IIES Requester Never
• Vaccination Record Query (VXQ) IIES Responder Never
• Query Acknowledgement (QCK) Responder IIES Only on error
• Query Acknowledgement (QCK) IIES Requester Never
• Vaccination Query Response (VXX) Responder IIES Only on error
• Vaccination Query Response (VXX) IIES Requester Never
• Vaccination Query Response (VXR) Responder IIES Only on error
• Vaccination Query Response (VXR) IIES Requester Never

SIIS SIP Message
Profile Static
Definitions
 The static definition portion of
the message profile declares the
usage and cardinality constraints
for the constituent message
elements of the SIIS SIP HL7
messages.
 There is a static definition for
each message type (VXQ, VXX,
VXR, QCK, and ACK).
 Each static definition includes a
message level, segment level,
and field level definition.
 The static definition also
includes a supported elements
definition.
 The supported elements
definition is a field level definition
containing supported message
elements only.

SIIS SIP Message
Profile Static
Definitions
messages.
VXR, QCK, and ACK).
definition.
elements only.

SIIS SIP Message Profile
 The Health Level Seven (HL7) message
profile vocabulary specification is a
companion document to the California
State Immunization Information System
System Interface Project HL7 message
profiles.
 The specification contains the value
sets for supported coded message
elements identified in the profile.
 The values presented in this
specification are the primary code
values to be used for coded message
elements in the SIIS SIP message
profile.
 Fields with a data type of CE may
include an equivalent code drawn from
an alternate coding system. However,
the values included in this specification
must be used as the primary code.

SIIS SIP Message Profile
 The Health Level Seven (HL7)
message profile vocabulary
specification is a companion
document to the California State
Immunization Information System
System Interface Project HL7
message profiles.
 The specification contains the value
sets for supported coded message
elements identified in the profile.
 The values presented in this
specification are the primary code
values to be used for coded message
elements in the SIIS SIP message
profile.
 Fields with a data type of CE may
include an equivalent code drawn
from an alternate coding system.
However, the values included in this
specification must be used as the
primary code.

Conformance Validation

Conformance Profile Authoring Tools
 Message Workbench (MWB)
 Model Driven Health Tools (MDHT)
 ART-DECOR
 Trifolia Workbench
 MS Word

Messaging Workbench

The Messaging Workbench (MWB)
 For those who:
 Design HL7 2.x messages
 Manage specification repositories
 Collaborate on varied messaging projects within and outside of their
organizations
 Free of charge from HL7 Web site (www.hl7.org)
 Current version supports up to HL7 v2.6
 NIST is working on the future plans
 First level support provided by Mayo Clinic volunteer

Model Driven Health Tools (MDHT) is an open source
framework that enables community authoring.

What is ART-DECOR?
 DECOR (Data Elements, Codes, OIDs and Rules) is a methodology to record the
information model used by health professionals.
 DECOR uses this model to generate various artifacts: documentation, XML- and test-
tooling, etc.
 With DECOR it is possible to improve the recorded information model by generating
and resolving issues per item.
 DECOR registers (amongst others) datasets, datatypes, valuesets, codes,
identifications, and business rules.
 The underlying data-format is XML. Generation of HTML-documentation and XML-
materials is possible through transformations with stylesheets.
 DECOR consists of two parts:
 DECOR methodology: a framework to model artifacts (including documentation)
 DECOR software: XML-schemas, XML-schematrons, XML-stylesheets.
 ART (Advanced Requirement Tooling) is the DECOR user interface to create and
adapt DECOR files, and to generate artifacts from DECOR files.
 ART is based on the eXist-db XML database, XQuery and Orbeon XForms.

Trifolia Workbench

Instance Validation Technologies
 HL7 v2 Schema Specification
 MWB Profile Validation
 CDA Schema Specification
 MDHT Generated Java Objects
 Trifolia Generated Schematron Logic

Instance Validation Services
 NIST HL7 v2 and v3 CDA Validation
 SMART C-CDA Collaborative
 CDC PHIN Message Quality Framework
 Lantana Consulting Group CDA Validator
 IHE Gazelle HL7 Validator

NIST Standards and Testing

NIST CDA Guideline Validation

SMART C-CDA Collaborative

CDC PHIN MQF

Lantana Consulting Group CDA Validator

IHE Gazelle HL7 Validator

Instance Validation Commercial Products
 Middleware Vendor Products
 Interface Engine Product Adapters
 Hi3 Solutions Standards Conformance Validator

Middleware Vendor Products

Interface Engine Adapters
 Interface engine adapters take advantage of public
APIs made available by leading interface engine
vendors.
 Interface engine adapters are typically product
specific and provide capabilities not otherwise
available in the base product.
 The CDC’s PHIN Messaging System takes
advantage of the APIs provided by Orion Health
Rhapsody.
 Caristix has developed adapters that facilitate the
reverse engineering of message instances into HL7
message profiles that are compatible with many of
the leading interface engines APIs.

PHIN Messaging System

Caristix HL7 Message Profiler

Hi3 Solutions Standards
Conformance Validator

Healthcare Information Integration Infrastructure
Healthcare Quality and Performance Monitoring
Health Information Integration
Health Information Transformation
Health Information Standards Compliance
Inbound
Information
Processing
Inbound
Information
Processing
Standard Compliance and
Standard Compliance and
Outbound
Information
Processing
Outbound
Information
Processing
Source
Information System
Source
Information System
Receiving
Information System
Receiving
Information System
Information
Transformation
Services
Information
Transformation
Services
Analysis,
Visualization,
and Reporting
Analysis,
Visualization,
and Reporting
Integrated Data
Repository
& Decision
Support Services
Health Information
Exchange Standards
Health Information
Exchange Standards
Controlled Clinical
Terminology Services
Controlled Clinical
Terminology Services
HL7 Reference
Information Model

 Hi3 Solutions’ STANDARDS CONFORMANCE VALIDATOR™ (SCV) is a
comprehensive suite of application services that validates
compliance with healthcare information exchange standard
specifications and conformance with related implementation guides
and profiles.

 Hi3 Solutions’ HEALTH INFORMATION INTEGRATOR™ (HII) is a
comprehensive suite of application and database services that
facilitate the transformation of data structures, translation of clinical
terminologies, and integration of health information.
Health Information Transformation
Inbound
Information
Processing
Inbound
Information
Processing
Outbound
Information
Processing
Outbound
Information
Processing
Source
Information System
Source
Information System
Receiving
Information System
Receiving
Information System
Information
Transformation
Services
Information
Transformation
Services
Integrated Data
Repository
HL7 Reference
Information Model

Healthcare Quality and Performance Measurement
 Hi3 Solutions’ HEALTHCARE QUALITY MONITOR™ (HQM) is a
comprehensive suite of data warehousing and business intelligence
solutions geared specifically toward monitoring quality and
performance in healthcare in accordance with established
measurement standards.
Healthcare Quality and Performance Monitoring
Inbound
Information
Processing
Inbound
Information
Processing
Source
Information System
Source
Information System
Information
Transformation
Services
Information
Transformation
Services
Analysis,
Visualization,
and Reporting
Analysis,
Visualization,
and Reporting
Integrated Data
Repository
& Decision
Support Services
HL7 Reference
Information Model

Hi3 Solutions Product Suite

Standards Conformance Validator
 Syntax Compliance
 Verification of adherence
to the syntax rules
specified in standards.
 Structural Conformance
to the element usage
rules specified in profiles.
 Semantic Conformance
to value constraints for
coded data elements.

Standards Conformance Validation

SCV: Syntax Compliance
 Verification of adherence to
the syntax rules specified in
standards.
 Supported SDOs include:
 Health Level Seven
 ASC X12
 ISO/TC 215
 Supported standards
include:
 HL7 v2, v3, and CDA
 X12 v5010 (834, 835,
837)
 ISO Datatypes and RIM

SCV: Structural Conformance
the element usage rules
specified in profiles.
 Supported communities of
users include:
 Integrating the Healthcare
Enterprise (IHE)
 Public Health Information
Network (PHIN)
 Biomedical Research
Integrated Domain Group
(BRIDG)
 HL7 Clinical Interoperability
Council (CIC)

SCV: Semantic Conformance
value constraints for coded
data elements.
 Supported Vocabulary
Servers:
 PHIN VADS
 NCI EVS
 LexGrid
 Supported Code Systems
include:
 LOINC
 Snomed
 RxNorm
 ICD 9 & 10

Hi3 Solutions SCV Targeted Standards
Standards / Terminologies Profiles / Guides
 Exchange Structures
 HL7 v2.x
 HL7 v3 Messages
 HL7 v3 CDA Documents
 ASC X12 v5010
 Code Systems
 SNOMED CT
 LOINC
 RxNorm
 ICD 9 & 10
 HL7
 Birth and Fetal Death
Reporting
 Laboratory Results Reporting
 Immunization Reporting
 Consolidated CDA
 X12
 834 Benefit Enrollment
 837 Health Care Claim
 835 Health Care Claim
Payment

Standards Conformance Validation

Hi3 Solutions Product Suite

 SPECIFICATION CONFORMANCE PROFILING
 PURPOSE AND GOAL OF CONFORMANCE PROFILING
 HL7 V2 MESSAGE CONFORMANCE PROFILING
 USE CASES OF MESSAGE CONFORMANCE
PROFILING
 CONFORMANCE VALIDATION
 HI3 SOLUTIONS CONFORMANCE VALIDATOR

Questions

Hi3 Solutions
300
Burbank, CA 91505
6520

July 14, 2015
HL7 v3 Retrospective

HL7 Version 3 Topics
 HL7 v3 History and Rationale
 HL7 v3 Development Frameworks and Architectures
 HL7 v3 Messaging Artifacts
 HL7 v3 Clinical Document Architecture
 HL7 Standards Compliance and Profile Conformance

HL7 V3 HISTORY AND RATIONALE

International
National
Inter-Enterprise
Enterprise
Institution
Ever-Increasing Circles
Source: Gartner

HL7 Version 3.0: What and Why
 Version 3.0 is a fundamental shift in the methodology HL7
uses to develop its standards specifications.
 Version 3.0 is a model-driven methodology based upon the
Object Management Group’s Unified Modeling Language
(UML).
 Version 3.0 uses datatype specifications, vocabulary
specifications, and a Reference Information Model (RIM), to
derive the information component of V3 message
specifications.
 Version 3.0 reduces optionality, maximizes reuse, and
increases consistency in HL7 message specifications.
 Version 3.0 improves the quality of HL7 message
specifications and includes support for conformance
validation.
 Version 3.0 enables HL7 implementers to leverage emerging

HL7 v3 Development Frameworks
and Architectures

The MDF Methodology Overview

HL7 V3 Message Development Framework
Use Case Modeling
Interaction Modeling
Message Design
Information Modeling
RIM
Restrict
R-MIM
Serialize
HMD
Restrict
Message
Type
Example
Storyboard
Storyboard
Example
D-MIM
Derive
Application
Role
Sender Receiver
Trigger
Event
Triggers
Content
Interaction
References

Initiate
Project
Project
Charter
Specify
Requirements
Reference
Models
Requirement
Specification
Design Models
Specification
Design Models
Prepare
Specification
Approve
Specification
Approved
Specification
Publish
Approved
Specification
Published
Specification
Profiles
Specification
Profile
Conformance
Statement
Proposed
Specification
adjusted.

Data Type
Specification
Vocabulary
Specification

HL7 v3 Messaging Artifacts

Reference
Information
Model
Datatype
Specification
Vocabulary
Specification
Foundational
Models
(CIM)
Dynamic
Model
Constrained
Information
Model
Common
Message Type
Model
Design
Models
(PIM)
Hierarchical
Message
Definition
Message
Type
Definition
Implementation
Technology
Specification
Message
Specifications
(PSM)

Reference
Information
Model
Datatype
Specification
Vocabulary
Specification

Normative R6 RIM Class Diagram
Version 2.44 11/22/2013

Entity
classCode : CS
determinerCode: CS
code: CE
statusCode : CS
id : II
Role
classCode : CS
code: CE
statusCode : CS
id : II
Participation
typeCode : CS
time : IVL<TS>
statusCode : CS
Act
classCode : CS
moodCode: CS
code: CD
statusCode : CS
effectiveTime : GTS
id : II
0..1
0..*
1
0..*
1
0..*
Role Link
typeCode : CS
Act Relationship
typeCode : CS
RIM Core Classes
0..1
0..*
plays
scopes
1 1
0..* 0..*
1 1
0..* 0..*

Datatype Class Diagram
T
Sequence : LIST
T
Set : SET
T
Bag : BAG
Quantity : QTY
IntegerNumber : INT
RealNumber : REAL
MonetaryAmount : MO
Ratio : RTO
PointInTime : TS
Boolean : BL
CodedValue : CV
T
Interval : IVL
DataValue : ANY
BinaryData : BIN
<<extends>>
<<extends>>
ConceptRole : CR
<<restricts>>
<<extends>>
AddressPart : ADXP
PersonNameType : PN
T
T
Set_of_TS : SET<TS>
<<extends>>
T : T
T
Annotated : ANT
T
History_item : HXIT
T
History : HIST
T
<<extends>>
T
T
T
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<restricts>>
<<restricts>>
<<restricts>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<restricts>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>

Metamodel
ParentConcept
VocabularyDomain
name : String
CodedConcept
0..*0..*
ValueSet
name : String
0..*
0..*
0..*
0..*
0..*
0..*
0..*
0..*
includes
CodeSystem
identifier : OID
name : String
0..*0..*
0..*
0..1
0..*
0..1
based on
ValueSetContext

ParentConcept
VocabularyDomain
name : String
CodedConcept
0..*0..*
ValueSet
name : String
0..*
0..*
0..*
0..*
0..*
0..*
0..*
0..*
includes
CodeSystem
identifier : OID
name : String
0..*0..*
0..*
0..1
0..*
0..1
based on
ValueSetContext
T
Sequence : LIST
T
Set : SET
T
Bag : BAG
Quantity : QTY
IntegerNumber : INT
RealNumber : REAL
MonetaryAmount : MO
Ratio : RTO
PointInTime : TS
Boolean : BL
CodedValue : CV
T
Interval : IVL
DataValue : ANY
BinaryData : BIN
<<extends>>
<<extends>>
ConceptRole : CR
<<restricts>>
<<extends>>
AddressPart : ADXP
PersonNameType : PN
T
T
Set_of_TS : SET<TS>
<<extends>>
T : T
T
Annotated : ANT
T
History_item : HXIT
T
History : HIST
T
<<extends>>
T
T
T
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<restricts>>
<<restricts>>
<<restricts>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<restricts>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>

A Dynamic Model is a specification of information
exchanges within a particular domain as described in
storyboards and storyboard examples.
A Design Information Model is an information
structure that represents the information content for a
set of messages within a particular domain area.
A Common Message Type Model is a definition of a set
of common message components that can be
referenced in various message specifications.
Dynamic
Model
Design
Information
Model
Common
Message Type
Model

StaticModel
DynamicModel
RIM
Restrict
R-MIM
Serialize
HMD
Restrict
Message
Type
Example
Storyboard
Storyboard
Example
D-MIM
Derive
Application
Role
Sender Receiver
Trigger
Event
Triggers
Content
Interaction
References

Application Roles
Interactions

V3 Constrained Information Model
(COCT_RM420000UV)
classCode*: = "OBS"
moodCode*: = "EVN"
typeCode*: = "OUTC"
outcome
AssessmentException
classCode*: = "OBS"
moodCode*: = "EVN"
AbnormalityGrade
classCode*: = "OBS"
moodCode*: = "EVN"
AssessmentOutcome
typeCode*: = "APND"
appendageOf
classCode*: = "OBS"
moodCode*: = "EVN"
Model Components
 Entry Point(s)
 Clones
• Focal Class
• Traversal Path
• Choice Structure
 Attributes
• Datatype
• Cardinality
• Terminology Binding

CMET Reference
Accession
classCode*: <= ACSN
moodCode*: <= EVN
id*: II [1..1]
CMET: (AGNT)
R_Responsible
[universal]
(COCT_MT040000)
0..1 roleName
1..1 agent *
typeCode*: <= AUT
author
CMET
R-MIM

An Hierarchical Message Definition is a specification
of message elements including a specification of their
grouping, sequence, optionality, and cardinality.
A Message Type Definition is a specification of a
collection of message elements and a set of rules for
constructing a message instance.
The Implementation Technology Specification, or ITS,
defines how to represent RIM objects for transmission
in messages.
Hierarchical
Message
Definition
Message
Type
Definition
Implementation
Technology
Specification

HMD Components
InformationModelMapping
CommonConstraints

HL7 Vocabulary
Specification
HL7 Data Type
Specification
HL7 XML
Schema
Generator
Definition
XML Schema
Specification

HL7 Vocabulary
Specification
HL7 Data Type
Specification
HL7 XML
Schema
Generator
XML Schema
Specification
Refined Message
Information Model
Datatype.XSD
Voc.XSD

Rational
Rose
Reference
Model
Repository
RoseTree
R-MIM
Designer
Schema
Generator
RIM RIM
R-MIM
RIM
R-MIM
HMD HMD
XSD
R-MIM

HL7 v3 Clinical Document
Architecture

Clinical Document Architecture RMIM
Clinical Document
Participating
Entities
Structured
Document Sections
Section Entries and
Sub-Entries

508

Collaborative Work Product
 This guide was produced and developed through the joint efforts of Health
Level Seven (HL7), Integrating the Healthcare Environment (IHE), the Health
Story Project, and the Office of the National Coordinator (ONC) within the
US Department of Health and Human Services (HHS).
 The project was carried out within the ONC’s Standards and Interoperability
(S&I) Framework as the Clinical Document Architecture (CDA) Consolidation
Project with a number of goals, one of which is providing a set of
harmonized CDA templates for the US Realm.

HL7 Standards Compliance and
Profile Conformance

Reveal Assumptions
Message Profiles are an effective means of documenting our assumptions
about message structures
Do you
use
HL7?
MSH
EVN
PID
[PD1]
[ { NK1 } ]
Yes, I
use
HL7.
MSH
EVN
PID
[ NK1 ]
OBX

Conceptual Overview
Message Profile = Static Profile + Dynamic Profile
Critical Care Unit
ADT System
Acknowledgement Message
Initiating Message
Initiating Message
Clinical Data Repository

Dynamic Interaction
Vectra
XU
5/90C
BED1OFF
BED1OFF
BED1OFF
BED1OFF
BED1OFF
BED1OFF
BED1OFF
BED1OFF
BED1OFF
BED1OFF
POTASSIUM3.5-5.0
BED1OFF
POTASSIUM3.5-5.0
POTASSIUM3.5-5.0
POTASSIUM3.5-5.0
BED1OFF
POTASSIUM3.5-5.0
BED1OFF BED1OFF
BED1OFF
BED1OFFBED1OFF
Critical Care Unit
HIS/CIS
Vectra
XU
5/90C
BED1OFF
BED1OFF
BED1OFF
BED1OFF
BED1OFF
BED1OFF
BED1OFF
BED1OFF
BED1OFF
BED1OFF
POTASSIUM3.5-5.0
BED1OFF
POTASSIUM3.5-5.0
POTASSIUM3.5-5.0
POTASSIUM3.5-5.0
BED1OFF
POTASSIUM3.5-5.0
BED1OFF BED1OFF
BED1OFF
BED1OFFBED1OFF
Clinical Data
Repository
A/D/T System
Order Filling Application
Accept Ack
Accept + App ACK
MSH-15,16
No ACK

Static Definition Example
...
...
...
NK1
MSH
EVN
PID
NK1 NK1 NK1 NK1
PV1
PV2
OBX
AL1
HL7 Message Structure
...
NK1
MSH
EVN
PID
NK1 NK1 NK1 NK1
PV1
PV2
OBX
AL1
Message Profile
Segments/Segment Groups:
•Usage (Optionality)
•Cardinality (min, max)
Fields/Components:
- Usage (Optionality)
- Cardinality (min, max)
- Value Sets/Coding system
- Descriptions

[{ ROL }] Role X [0..0] 12
Parties
RE [0..3] 3
Info.
RE [0..1] 3
[{ ROL }] Role X [0..0] 12
[{ X [0..0]
[{ ROL }] Role X [0..0] 12
}]
[{ X [0..0]
Cert.
X [0..0] 6
[{ ROL }] Role X [0..0] 12
}]

Parties
RE [0..3] 3
Info.
RE [0..1] 3

How it all ties together
Static Definition – Field Level
Vocabulary
2 20 CX RE [1..1] 00105 Patient ID
7 26 TS RE 00110 Date/Time of Birth
8 1 IS RE 0001 00111 Sex
10 80 CE X 0005 00113 Race
17 80 CE X 0006 00120 Religion
19 16 ST RE 00122 SSN Number - Patient
23 60 ST RE 00126 Birth Place
: ADT Sy stem : ADT Notification
Recip ient
ADTÂ01
ACK Â01
Interaction Model
Segment ADT Message Usage Cardinality Chapter
[{ ROL }] Role X [0..0] 12
Parties
RE [0..3] 3
Info.
RE [0..1] 3
[{ ROL }] Role X [0..0] 12
[{ X [0..0]
[{ ROL
}]
Role X [0..0] 12
}]
[{ X [0..0]
[{ IN3
}]
Insurance Additional Info -
Cert.
X [0..0] 6
[{ ROL
}]
Role X [0..0] 12
}]
Dynamic Definition
Static Definition – Segment Level
P at ie nt
P hy s ic ian
A D T No tific at ion
Re c ipien t
A D T S y s tem
A dm it/ V is it Notific ation
is s u b jec t of
autho riz es
rec e ives notific ations en ds no tific at ion
Reg is trar
trig gers
Use Case Model
Static Definition – Message Level
1 Use Case Model
1.1 Use Case: Admit/Visit Notification
2. Dynamic Interaction Model
3 Dynamic Definition: ADT/ACK (Event A01)
3.1 ADTÂ01
3.2 ACKÂ01
4 Static Definition: - Message Level -
ADT/ACK (event A01)
4.1 ADTÂ01
4.2 ACKÂ01
5 Static Defintiion - Segment Level
5.1 MSH – Message Header Segment Definition
5.2 EVN - Event Type Segment Definition
5.3 PID (Y) - Patient Demographics Segment
Definition
5.4 PD1 – Patient Additional Demographic
Segment Definition
5.5 NK1 - Next of kin Segment Definition
5.6 PV1 (2) - Admit Visit Info Segment
Definition
5.7 AL1 - Allergy Segment Definition
5.8 MSA - Message Acknowledgment Segment
Definition
5.9 ERR - Error Segment Definition
6 Static Definition - Field Level
6.1 Table 0001 – Sex
6.2 Table 0002 – Marital Status
6.3 Table 0003 – Event Type Code
6.4 Table 0004 – Patient Class
6.5 Table 0005 – Race
6.6 Table 0006 – Religion
6.7 Table 0007 – Admission Type
6.8 Table 0008 – Acknowledgement Code
6.9 Table 0009 – Ambulatory Status

Middleware Vendor Products

 Hi3 Solutions’ STANDARDS CONFORMANCE VALIDATOR™ (SCV) is a
comprehensive suite of application services that validates
compliance with healthcare information exchange standard
specifications and conformance with related implementation guides
and profiles.

HL7 Version 3 Topics
 HL7 v3 History and Rationale
 HL7 v3 Development Frameworks and Architectures
 HL7 v3 Messaging Artifacts
 HL7 v3 Clinical Document Architecture
 HL7 Standards Compliance and Profile Conformance

Course Topics
HL7 v2 Messaging HL7 v3 Messaging
HL7 Clinical
Document
Architecture
HL7 Family of
Standards
HL7 Compliance
and Conformance

Q&A

Thank You!
Peace...AMS
Abdul-Malik Shakir
President and Chief Informatics Scientist
Hi3 Solutions
3500 West Olive Ave, Suite # 300, Burbank, CA 91505
Skype: +1 9098334661  Mobile: (626) 644-4491
Email: abdulmalik.shakir@hi3Solutions.com

Introduction to hl7 v3

More Related Content

What's hot (20)

Viewers also liked (12)

Similar to Introduction to hl7 v3 (20)

More from Abdul-Malik Shakir (16)

Recently uploaded (20)

Introduction to hl7 v3