Rim derived and influenced hl7 standards

Your Healthcare Standards Conformance Partner

RIM Derived
and Influenced HL7 Standards
AbdulMalik Shakir
President and Chief Informatics Scientist

Health
Information Integration Infrastructure
Solutions
Hi3 Solutions is a privately owned Health Information Technology vendor
headquartered in Los Angeles, California.
We provide health information technology products, education, and consulting
services that enable our clients to engage effectively in health information
exchange, health data integration, and health care quality measurement .
Our mission is to accelerate the adoption and application of standards-based
health information exchange as a mean’s of improving healthcare outcomes
and facilitating compliance with evidence-based best practices in healthcare.

Slide Number: 2

© 2014 All Rights Reserved

Electronic Health Information Exchange
Claims/Prescriptions
Referral Process

Eligibility
Claim Status
Referral Process

Eligibility
Claim/Status

Payors

Pharmacies

Physicians

Public Health
Medical Records

Medical Society

Patient Data

Family Planning

Lab results

Mental Health

Hospitals

County/Community
Entities
Enrollment

Orders

Insurance Updates
Health Information

Results
Images

Testing Organizations
Lab/Images

Slide Number: 3

Employers
Government
Medicare/Medicaid

Patients/Consumers


Instructor
• AbdulMalik Shakir, President and Chief Informatics
Scientist for Hi3 Solutions.
• I have been an active HL7 member since 1991 and I’ve
made significant contributions to the development and
adoption of the HL7 standard.
• I am co-chair of the HL7 Modeling and Methodology
work group, former member of the HL7 Board of
Directors, and an active participant in many HL7
foundation and domain expert work groups.
• I am the author of the original RIM and provided
oversight for its maintenance from inception through its
first publication as an ANSI and then ISO standard.
Slide Number: 4


Session Overview
• This tutorial provides an introduction to the major
HL7 RIM derived and RIM influenced standards. The
student will also learn key aspects of the HL7 V3
Development Framework (HDF).
• Topics Covered:
– HL7 Development Framework
– HDF Methodology
– HL7 V3 Development Artifacts

– Sample V3 Clients and Projects

• This tutorial will assist in preparation for the HL7 v3
Certification exam.
Slide Number: 5


HL7 Development
Framework
Slide Number: 6


HDF Introduction
• The Health Level Seven Development Framework (HDF)
defines the processes, policies, and artifacts associated
with development of HL7 specifications and standards.
• The HL7 Development Framework (HDF):
– Expands HL7’s modeled-based approach for standards
development beyond messaging to its other standards such as
structured documents, context management, and standards
related to electronic health records;
– Facilitates increased participation of HL7 members, subject
matter experts, and implementers in the development of HL7
standards.
– Enables HL7 to remain the industry leader in model-driven
development of comprehensive standards for application
interoperability in the Health industry.
Slide Number: 7


HDF Background – Health Level Seven
• The mission of HL7 is to provide a comprehensive framework and
related standards for the exchange, integration, storage, and
retrieval of health information that support clinical practices and the
management, delivery and evaluation of health services.
• HL7 began developing standards in 1987 with the publication of its
messaging specification - the Application Protocol for Electronic
Data Exchange in Healthcare Environments.
• In the years since its founding, HL7 has evolved beyond traditional
messaging protocols to include clinical document architectures,
medical logic modules, service component specifications, and
standards, guidelines, and related services for the management of
electronic health records.

Slide Number: 8


The Family of HL7 Standards
•
•
•
•
•
•
•
•
•
•
Slide Number: 9

Standardization of knowledge representation (Arden / GELLO)
Virtual Medical Record for Clinical Decision Support (vMR-CDS)
Specification of components for context management (CMA)
Standardization of clinical document structures (CDA)
Electronic Health Record System Functional Model (EHR-S)
Application protocol for electronic data exchange in healthcare
environments (messages)
Support for use of healthcare services in a Service Oriented
Architecture (SOA)
Fast Healthcare Interoperability Resources (FHIR)
Specification of robust vocabulary definitions for use in clinical
messages and documents
Work in the area of security, privacy, confidentiality, and
accountability

HDF Background – HL7 V3 Methodology
• In 1992 HL7 made a fundamental shift in the method it
uses to develop its specifications and standards.
• The new methodology, referred to as HL7 Version 3.0
(or V3), is a model-driven standards development
methodology based upon object-oriented software
development practices.
• In January 1996, the HL7 Technical Steering Committee
adopted the model-driven approach and the Modeling
and Methodology Technical Committee assumed
primary responsibility for ongoing development of the V3
methodology.
Slide Number: 10


Slide Number: 11


HL7 Message Development Framework
• The HL7 Message Development Framework (MDF)
defines the HL7 V3 message development process.
• It identifies the phases, activities, and models used in the
process of developing HL7 message specifications.
• The HL7 MDF was first published in 1997. It has
undergone two major revisions since then; once in 1998
and again in 1999.
• The current version of the MDF (v3.3), published in
December 1999, has not been maintained.
• The HDF is a replacement for and an extension to the
HL7 Message Development Framework (MDF)
Slide Number: 12


HL7 V3 Methodology: What and How
Application
Role

Trigger
Event
Information Modeling

Storyboard

Sender

RIM
Derive

D-MIM

Receiver

Triggers

Restrict

References

R-MIM

Interaction
Example

Serialize

Interaction Modeling

HMD
Message Design

Storyboard
Example
Slide Number: 13

Content

Use Case Modeling

Restrict

Message
Type

HL7 V3 Design Models
RIM

RIM
Reference Information Model
(1)
Define a
D-MIM

D-MIM

D-MIM

Domain Message Information Model
(2)
Define a
R-MIM

R-MIM

R-MIM

Refined Message Information Model
(3)
Create
an HMD

HMD

HMD

Hierarchical Message Definition
Slide Number: 14


HL7
Development Framework
Methodology
Slide Number: 15


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
Slide Number: 16


HDF Workflow Diagram
Initiate
Project

Project
Charter

Specify
Requirements

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.

Requirement
Specification

Reference
Models

Prepare Specification
Design Models

Specification
Design Models

Approve
Specification

Prepare
Specification

Pre-Approval
Specification
Conformance
Statement

Approved
Specification

Slide Number: 17

Publish
Approved
Specification

Published
Specification

Profiles

Specification
Profile


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

Slide Number: 18


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.

Project
Charter

Requirements
Documentation

Requirements
Specification

1.
2.

Capture Process Flow: UML Activity Diagram

3.

Capture Structure: Domain Analysis Model and Glossary

4.

Capture Business Rules: Relationships, Triggers, and Constraints

5.

Slide Number: 19

Document Business Process: Dynamic Behavior and Static Structure

Harmonize the Domain Analysis Model with HL7 Reference Models


Specification Modeling
During specification modeling reference models are constrained into design
models through a process of iterative refinement driven by requirements
specifications and following specification design rules, conventions, and
guidelines. The primary deliverable produced during specification modeling
is a set of specification design models.

Requirements
Specification

Specification
Modeling

Specification
Design Models

1.
2.

Construct design models of behavioral views

3.

Define reusable design model components

4.

Construct design models of collaboration and interaction

5.
Slide Number: 20

Build design models of static information views

Harmonize design models with HL7 Reference Models

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 pre-approval specification.

Specification
Design Models

Specification
Documentation

Pre-Approval
Specification

1.
2.

Compose explanatory text, examples, and design rationale

3.

Update design models and requirement specifications

4.

Assemble a pre-approval specification package

5.

Slide Number: 21

Organize design model elements into logical packages

Submit specification for approval


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.
Pre-Approval
Specification

Specification
Approval

Approved
Specification

1.
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.

Slide Number: 22

Obtain TSC and Board approval to ballot specification

Resolve negative ballot responses and if necessary reballot


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.

Approved
Specification

Specification
Publication

Published
Specification

1.
2.

Prepare specification for publication

3.

Submit publication to standards authorities (ANSI/ISO)

4.

Render the specification in various forms of publication media

5.

Slide Number: 23

Obtain TSC and Board approval to publish specification

Post and distribute approved specifications


Specification Profiling
During specification profiling specification models are further refined and specifications
furthered constrained following the same set of design rules, conventions, and guidelines
used in the development of the specification to produce a profile of the specification for
use in a particular environment by a defined community of users. The primary
deliverable produced during specification profiling is a set of specification profiles and
conformance statements.

Published
Specification

Specification
Profiling

Specification
Profiles and
Conformance
Statements

1.
2.

Further refine and constrain specification design models

3.

Document exceptions, extensions, and annotations to specifications

4.

Prepare and publish specification profile

5.
Slide Number: 24

Identify community of uses for published specification

Prepare and publish conformance statements

HDF Workflow Diagram
Initiate
Project

Project
Charter

Specify
Requirements

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.

Requirement
Specification

Reference
Models

Design Models

Specification
Design Models

Approve
Specification

Prepare
Specification

Pre-Approval
Specification
Conformance
Statement

Approved
Specification

Slide Number: 25

Publish
Approved
Specification

Published
Specification

Profiles

Specification
Profile


HL7 Version 3.0
Development Artifacts
Slide Number: 26


HL7 v3.0 Development Artifacts
Reference
Models

Reference
Information
Model

Datatype
Specification

Vocabulary
Specification

Design
Models

Interaction
Model

Design
Information
Model

Common
Message Type
Model

Content
Specifications

Hierarchical
Message
Definition

Message
Type
Definition

Implementation
Technology
Specification

Implementation
Profiles

Message
Profile
Specification

Localized
Message
Specification

Message
Conformance
Statements

Slide Number: 27


Reference Models

Reference
Information
Model

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

Datatype
Specification

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.

Vocabulary
Specification

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 message element.

Slide Number: 28


Design Models

Interaction
Model

An Interaction Model is a specification of information
exchanges within a particular domain as described in
storyboards and storyboard examples.

Design
Information
Model

A Domain Information Model is an information
structure that represents the information content for a
set of messages within a particular domain area.

Common
Message Type
Model
Slide Number: 29

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

HL7 v3.0 Messaging Artifacts
Message Specifications

Hierarchical
Message
Definition

Message
Type
Definition

Implementation
Technology
Specification
Slide Number: 30

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.

An Implementation Technology Specification is a
specification that describes how to construct HL7
messages using a specific implementation technology.

Implementation Profiles

Localized
Message
Specification

Message
Profile
Specification

A Message Profile Specification is a description of a
particular or desired implementation of an HL7
Message standard or Localized Message specification.

Message
Conformance
Statement
Slide Number: 31

A Localized Message Specification is a refinement of a
HL7 message specification standard that is specified
and balloted by an HL7 International Affiliate.

A Message Conformance Statement is a comparison of
a particular messaging implementation and an HL7
message standard, localization, or profile.

HL7 V3 Message Design Models
TraumaRegistryExport
PreHosptialRelatedObservation (IDPH_RM00001)
classCode*: <= OBS
moodCode*: <= EVN
code: <= ExternallyDefinedActCodes
value: ANY [0..1]

VehicleProvider

Data content of HL7
messages used to export
data from the IDPH Trauma
Registry.

pertinentInformation 0..* pertinentPreHosptialRelatedObservation

1..1 owningVehicleProvider

typeCode*: <= PERT

Organization
addr : BAG<AD>
standardIndustryClassCode : CE

Patient
Place
confidentialityCode : CE
mobileInd : BL
veryImportantPersonCode : CE
addr : AD
directionsText : ED
Access
LicensedEntity
positionText : ED
approachSiteCode : CD
recertificationTime : TS
gpsText : ST
targetSiteCode : CD
gaugeQuantity : PQ

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

PreHospitalVehicle

ManagedParticipation
id : SET<II>

PublicHealthCase
PatientEncounter
detectionMethodCode : CE
preAdmitTestInd : BL
transmissionModeCode : CE
admissionReferralSourceCode : CE
diseaseImportedCode : CE
lengthOfStayQuantity : PQ
dischargeDispositionCode : CE
specialCourtesiesCode : SET<CE>
specialAccommodationCode : SET<CE>
acuityLevelCode : CE

Supply
quantity : PQ
expectedUseTime : IVL<TS>

Diet
energyQuantity : PQ
carbohydrateQuantity : PQ

Account
name : ST
balanceAmt : MO
currencyCode : CE
interestRateQuantity : RTO<MO,PQ>
allowedBalanceQuantity : IVL<MO>
FinancialTransaction
amt : MO
creditExchangeRateQuantity : REAL
debitExchangeRateQuantity : REAL

classCode*: <= OWN
1..1 preHospitalVehicle
id: II [0..1] (VehiclNum)
participant
code: <= RoleCode (VehiclLevelID)
typeCode*: <= ParticipationType

InjuryLocation
classCode*: <= PLC
determinerCode*: <= INSTANCE
0..1 playingInjuryLocation
code: CV CWE [0..1] <= EntityCode (InjuryPlaceID)
addr: AD [0..1] (AddressScene)

MedicalStaffPerson

PreHospitalEncounter

MedicalStaff

classCode*: <= ENC
moodCode*: <= EVN
id: II [0..1] (crashNum)
activityTime: IVL<TS>

Role

classCode*: <= PROV
id: II [0..1] (MedicalStaffID)

performer

classCode*: <= ROL

predecessor

0..1 priorPreHospitalEncounter

0..1 medicalStaff

typeCode*: <= PRF

typeCode*: <= PREV
1..1 participant
location
Procedure
0..1 procedureLocation ProcedureLocation
typeCode*: <= LOC
classCode*: <= PROC
location
InjuryRelatedObservation
classCode*: <= SDLOC
moodCode*: <= EVN
0..* pertinentInjuryRelatedObservation
classCode*: <= OBS
0..* pertinentProcedure code: CV CWE <= ActCode (ICDCodeID) typeCode*: <= LOC code: <= RoleCode (ProcedLocateID)
Injury
pertinentInformation
moodCode*: <= EVN
PatientIncident
pertinentInformation7
activityTime: TS (ProcedDate)
classCode*: <= ACT
0..1 pertinentInjury
typeCode*: <= PERT
classCode*: <= ENC
typeCode*: <= PERT
moodCode*: <= EVN
pertinentInformation1 moodCode*: <= EVN
priorityCode: CV CWE [0..1] <= ActPriority sequenceNumber: INT [0..1] (InjurySequen)
activityTime: TS (InjuryDate)
component
typeCode*: <= PERT
value: [0..1]
TraumaParticipant
id: [1..*] (RegistNum)
typeCode*: <= COMP
code: CV CNE [0..1] <= ExternallyDefinedActCodes (PatientType)
statusCode: LIST<CS> CNE <= ActStatus (IDPHStatus)
0..* pertinentPatientIncidentRelatedObservation PatientIncidentRelatedObservation
PatientPerson
activityTime: TS (EDDate)
1..1 patient
classCode*: <= OBS
classCode*: <= PSN
Patient
subject
moodCode*: <= EVN
0..1 playingTraumaParticipant
typeCode*: <= PERT
0..* patientIncidentRelatedObservation
classCode*: <= PAT
typeCode*: <= SBJ
code: <= ActCode
name: PN [0..1] (*Name)
id: II [0..1] (MedicaRecordNum)
reasonCode: CV CWE [0..1] <= ActReason
existenceTime: (Age)
Choice
1..1 patientPatientPerson
value: ANY [0..1]
administrativeGenderCode: CV CWE <= AdministrativeGender
Facility
(GenderID)
1..1 providerTraumaParticipant
classCode*: <= ORG
birthTime: (DateOfBirth)
0..* aRole aRole
VehicleProvider
addr: AD [0..1] (AddressHome)
TraumaParticipant
classCode*: <= ROL
origin
1..1 arrivalPatientTransfer
id:
raceCode: CV CWE [0..1] <= Race (RaceID)
classCode*: <= ORG
PatientTransfer
classCode*: <= ORG
typeCode*: <= ORG
code*: CS CNE <= EntityCode "FAC"
ethnicGroupCode: CV CWE [0..1] <= Ethnicity (EthnicID)
arrivedBy
classCode*: <= TRNS
1..1 owningVehicleProvider id: II [0..1] (VehiclProvide)
name:
typeCode*: <= ARR
id: [1..1] (HospitNum)
moodCode*: <= EVN
1..1 transferVehicle
code: <= EntityCode (MaxVehiclLevelID)
0..1 subjectChoice
code: CV CWE [0..1] <= EntityCode
activityTime: IVL<TS> (DischaDate to ArriveDate)
via
name: ON [0..1] (VehiclProvidName)
TransferVehicle
name: ON [0..1] (HospitName)
Hospital
reasonCode: CV CWE [0..1] <= TransferActReason (REASONTRANSFID) typeCode*: <= VIA
statusCode: CS CNE [0..1] <= EntityStatus (ActiveFacili)
classCode*: <= OWN
classCode*: <= ORG
addr: AD [0..1] (HospitCity)
id: II [0..1] (VehiclNum)
typeCode*: <= PERT
code: <= RoleCode (VehiclLevelID)
id:
1..* pertinentTransferRelatedObservation
LicensedEntity 0..1 licensedEntity
1..1 pertinentHospitalVisit
code*: CS CNE <= EntityCode "HOSP"
typeCode*: <= PERT
destination
classCode*: <= LIC
name:
TransferRelatedObservation
typeCode*: <= DST
id: II [0..1]
HospitalVisit
typeCode*: <= PERT
classCode*: <= OBS
classCode*: <= ENC
moodCode*: <= EVN
1..1 admittingProvider
moodCode*: <= EVN
AdmittingProvider
code: CV CWE <= ExternallyDefinedActCodes
code: CV CWE <= ActCode (AdmitServicID)
admitter
classCode*: <= PROV
value: PQ [0..1]
activityTime: TS (DischaDate)
id: II [0..1] (ADMITMEDICASTAFFID)
typeCode*: <= ADM
methodCode: CV CWE [0..1] <= ObservationMethod
dischargeDispositionCode: CV CWE [0..1]
code: CV CWE <= RoleCode (StaffTypeID)
0..* hospitalVisitPhysician
<= EncounterDischargeDisposition

responsibleParty

HospitalVisitPhysician
typeCode*: <= RESP
classCode*: <= PROV
time: TS
id: II [0..1]
code: CV CWE <= RoleCode (StaffTypeID)

EmergencyDepartmentRelatedObservation
0..1 pertinentEmergencyDepartmentEncounter
classCode*: <= OBS
moodCode*: <= EVN
0..* pertinentEmergencyDepartmentRelatedObservation
classCode*: <= ENC
text:
moodCode*: <= EVN
typeCode*: <= PERT
activityTime: TS
reasonCode: <= ActReason
dischargeDispositionCode: CV CWE <= EncounterDischargeDisposition
value: [0..1]
methodCode: CV CWE [0..1] <= ObservationMethod
component
targetSiteCode: CV CWE [0..1] <= HumanActSite
typeCode*: <= COMP

typeCode*: <= PERT

EmergencyDepartmentEncounter

0..* pertinentHospitalVisitRelatedObservation

HospitalVisitRelatedObservation

0..1 healthCareMedicalStaffPerson

MedicalStaffPerson

classCode*: <= OBS
moodCode*: <= EVN
value: [0..1]

0..1 healthCareMedicalStaffPerson classCode*: <= PSN
determinerCode*: <= INSTANCE 0..1 healthCareMedicalStaffPerson
name: PN [0..1] (MedicaStaffName)

RIM

0..* emergencyDepartmentPhysicianAct

EmergencyDepartmentPhysician 0..* emergencyDepartmentPhysician
classCode*: <= PROV
performer
id: II [0..1]
typeCode*: <= PRF
code: CE CWE [0..1] <= RoleCode (StaffTypeID)

EmergencyDepartmentPhysicianAct
classCode*: <= ACT
moodCode*: <= EVN
code: CS CNE [0..1] <= ExternallyDefinedActCodes
activityTime*: TS [0..1]

D-MIM

Design Information Model
component
typeCode*: <= COMP

PatientIncidentRelatedObservation
InjuryLocation
classCode*: <= PLC
0..1 playingInjuryLocation
code: CV CWE [0..1] <= EntityCode (InjuryPlaceID)
addr: AD [0..1] (AddressScene)

classCode*: <= ROL

location

1..1 participant

typeCode*: <= LOC

InjuryRelatedObservation
0..* pertinentInjuryRelatedObservation
classCode*: <= OBS
moodCode*: <= EVN
typeCode*: <= PERT
priorityCode: CV CWE [0..1] <= ActPriority sequenceNumber: INT [0..1] (InjurySequen)
value: [0..1]

PatientPerson

classCode*: <= OBS
moodCode*: <= EVN
code: <= ActCode
reasonCode: CV CWE [0..1] <= ActReason
value: ANY [0..1]

Role

Injury

0..* patientIncidentRelatedObservation

pertinentInformation2 0..* pertinentPatientIncidentRelatedObservation
typeCode*: <= PERT

PatientIncident

classCode*: <= ACT
0..1 pertinentInjury
classCode*: <= ENC
moodCode*: <= EVN
pertinentInformation1 moodCode*: <= EVN
activityTime: TS (InjuryDate)
typeCode*: <= PERT
id: [1..*] (RegistNum)
code: CV CNE <= ExternallyDefinedActCodes (PatientType)
statusCode: LIST<CS> CNE <= ActStatus (IDPHStatus)
activityTime: TS (EDDate)
1..1 patient

classCode*: <= PSN
Patient
subject
classCode*: <= PAT
typeCode*: <= SBJ
name: PN [0..1] (*Name)
id: II [0..1] (MedicaRecordNum)
existenceTime: (Age)
1..1 patientPatientPerson
administrativeGenderCode: CV CWE <= AdministrativeGender
(GenderID)
1..1 providerTraumaParticipant
birthTime: (DateOfBirth)
addr: AD [0..1] (AddressHome)
TraumaParticipant
raceCode: CV CWE [0..1] <= Race (RaceID)
classCode*: <= ORG
ethnicGroupCode: CV CWE [0..1] <= Ethnicity (EthnicID)
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)

R-MIM

Slide Number: 32

HMD


Design Information Model
Description
• Domain Message Information Models (D-MIMs) and
Refined Message Information Models (R-MIMs) are types
of Design Information Models.
• Design 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 design information model.
• Each class clone in a design information model is
assigned a unique name.
Slide Number: 33


Sample R-MIM Design Information Model
Laboratory Observation Order

(POLB_RM002100)

Common entry point for laboratory order
communication. This includes single one-time
typeCode*: <= COMP
orders as well as recurring orders. This is
contextControlCode*: [1..1]
Note:
used for recurring orders only if the filler
<= ContextControlNonPropagating "AN"
Includes both
splits recurring orders into their occurrences.
contextConductionInd*: [1..1] "true"
patient and the
sequenceNumber:
institution.
priorityNumber:
pauseQuantity:
0..1 patient *
0..1 roleName
CMET: (PAT)
splitCode:
ObservationOrder
recordTarget
ManufacturedProduct1
Organization
R_Patient
joinCode:
classCode*: <= OBS
typeCode*: <= RCT
classCode*: <= MANU
[universal]
seperatableInd: [1..1] "true"
classCode*: <= ORG
0..* observationOrder1
moodCode*: <= ORD
(COCT_MT050000)
id*: II [1..1]
<= ContextControlPropagating "OP"
0..1 manufacturerOrganization name*: ON [1..1]
code: CE CWE <= ObservationType (e.g. LOINC code)
1..1 manufacturedProduct *
0..* specimen *
consumable
0..* observationOrder2 * negationInd: [1..1] "false"
CMET: (SPEC)
subject
typeCode*: <= CSM
0..* substanceAdministrationStep *
derivationExpr:
R_Specimen
typeCode*: <= SBJ
text:
component2
SubstanceAdministrationStep
[universal]
statusCode*: CS CNE [1..1] <= ActStatus "active"
(COCT_MT080000)
typeCode*: <= COMP
classCode*: <= SBADM
effectiveTime: ("physiologically relevant time" aimed for)
moodCode*: <= x_ActMoodOrdPrmsEvn
Note:
id*: II [1..1]
priorityCode: CE CWE [0..1] <= ActPriority "R"
For clinical observations that are made directly on the patient
code*: CE CWE <= SubstanceAdministrationActCode
confidentialityCode*: [1..*] <= Confidentiality "N"
instead of on some specimen.
sequenceNumber*: [1..1]
text*:
repeatNumber:
priorityNumber:
statusCode*: CS CNE [0..1]
0..1 roleName
1..1 assignedEntity *
interruptibleInd: "true"
CMET: (ASSIGNED)
pauseQuantity:
effectiveTime*: IVL<TS>
independentInd: "true"
author
R_Assigned
splitCode:
routeCode: <= RouteOfAdministration
methodCode: <= ObservationMethod
typeCode*: <= AUT
[universal]
joinCode:
doseQuantity: PQ
(COCT_MT090000)
targetSiteCode: <= ActSite
seperatableInd*: [1..1] "false"
rateQuantity: PQ
noteText: ST
Note:
time*: TS [1..1] (time of signature)
CMET: (ENC)
Includes both, the
componentOf1
modeCode*: CE CNE [1..1] <= ParticipationMode
A_Encounter
individual and the
typeCode*: <= COMP
signatureCode*: CS CNE [1..1]
[universal]
contextControlCode*: [1..1] <= ContextControlPropagating "OP"
signatureText:
provider organization.
(COCT_MT010000) contextConductionInd*: [1..1] "false"
0..1 encounter *
0..* assignedEntity

Drug

classCode*: <= MMAT
code*: [1..1] <= DrugEntity (Drug code)
quantity:
desc:
1..1 manufacturedDrug *

CMET: (AGNT)
R_Responsible
[universal]

Note:
This is the general almost completely unconstrained
ActRelationship. Its use includes composition (COMP),
occurrences (OCCR), master file references (INST),
fulfillment (FLFS) and replacement (RPLC) as well as
normal ranges (REFV), decision ranges (COND) and
goals. In the DMIM this is left unconstrained, in the
RMIMs these might be more constrained.

componentOf2

Accession

1..1 agent *

classCode*: <= ACSN
moodCode*: <= EVN
typeCode*: <= AUT id*: II [1..1]

author

(COCT_MT040000)

0..1 roleName

Note:
For Advanced Beneficiary Notices
or whenconsents are required for
testing (e.g., HIV related tests.)

CMET: (CONS)
A_Consent
[universal]
(COCT_MT470000)

Note:
The author of an ORDer is commonly
know as the "placer", the author of an
ordered promise or event is commonly
known as the "filler". The author owns
his Act, meaning that direct status
canges on this act can only be issued
by the Author.

typeCode*: <= COMP
contextConductionInd*: [1..1] "false"
0..* accession

subjectOf
typeCode*: <= SUBJ
0..* consent
0..* pertinentObservationSupporting

CMET: (OBS)
A_ObservationSupporting
[universal]
Note:
Identifies the "master"
or "service catalog"
entry of the
observation service
being performed. Use
this alone or in addition
to an observation
code to specify what
is being observed or
what is to be observed.

component1 / componentOf3

(COCT_MT120200)

0..1 assignedEntity
typeCode*: <= ENT
noteText: ST
time: TS (time entered into)
modeCode*: [1..1] <= "ELECTRONIC"

typeCode*: <= PERT
0..1 observationDefinition *

definition

classCode*: <= OBS
moodCode*: <= DEF
id: II [1..1]

typeCode*: <= INST

typeCode*: <= VRF
contextControlCode*: [1..1] <= ContextControl "OP"
noteText: ST
time*: TS [1..1] (time of signature)
modeCode*: [1..1] <= ParticipationMode
signatureCode*: [1..1] <= ParticipationSignature
signatureText:

dataEnterer


ObservationDefinition

verifier

0..1 assignedEntity

notificationContact
Note:
For orders: the designated performer, if known
and desired at time of ordering. For intents, the
promises and events, the "filler." For individual subtasks, used for the technician, etc.

typeCode*: <= NOT
0..* assignedEntity *

performer
typeCode*: <= PRF
0..* participant

consumable
typeCode*: <= CSM
<= ContextControlNonPropagating "ON"

0..*

CMET: (ROL)
R_Reagent
[universal]
(COCT_MT250000)

0..* orderOptions

controlVariable
typeCode*: <= CTRLV

CMET: (ACT)
A_OrderOptions
[universal]
(COCT_MT210000)

0..* priorObservation

replacementOf
typeCode*: <= RPLC
<= ContextControlNonPropagating "ON"

Slide Number: 34


Design Information Model Diagram

Drug
classCode*: <= MMAT
code*: [1..1] <= DrugEntity (Drug code)
quantity:
desc:
1..1 manufacturedDrug *

ManufacturedProduct1
classCode*: <= MANU

consumable

classCode*: <= ORG
0..1 manufacturerOrganization name*: ON [1..1]
1..1 manufacturedProduct *

typeCode*: <= CSM

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

Slide Number: 35

Organization

• A Design Information Model
diagrams used a variety of
visual tools to document the
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.

HL7 V3 Modeling Tools

Slide Number: 36


HL7 V3 Modeling Tools
RIM

RIM

Rational
Rose

RIM
R-MIM

R-MIM
Designer

Reference
Model
Repository

RoseTree
HMD

HMD

R-MIM

Schema
Generator

XSD
Slide Number: 37


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

Slide Number: 38


Hierarchical Message Definition

Slide Number: 39


Slide Number: 40

Message Type Specification(S)

Common Constraints

Message Element Specifications

Information Model Mapping

HMD Components


Slide Number: 41

Message Type Specification(S)

Common Constraints

Message Element Specifications

Mapping to the Information Model

HMD Components


HL7 XML Schema Generator
HL7 Vocabulary
Specification

Definition

HL7 XML
Schema
Generator

XML Schema
Specification

HL7 Data Type
Specification

Slide Number: 42


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

outcome
typeCode*: = "OUTC"
contextConductionInd*: BL [1..1] ="true"
1..* assessmentOutcome *

AssessmentOutcome
AssessmentException
classCode*: = "OBS"
moodCode*: = "EVN"
code*: CD CWE [1..1] <= V:ObservationType ("ASSERTION")
value*: SC CWE [1..1] <= V:AssessmentExceptionValue

appendageOf

AbnormalityGrade

typeCode*: = "APND"
contextConductionInd*: BL [1..1] ="true"
0..* assessmentOutcomeAnnotation

AssessmentOutcomeAnnotation
classCode*: = "OBS"
moodCode*: = "EVN"
code*: CD CWE [1..1] <= V:ObservationType ("ASSERTION")
value*: SC CWE [1..1] <= V:AssessmentOutcomeAnnotationValue

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

Slide Number: 43


Example Schema Specification

Slide Number: 44


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 specification include no domain content. They are
present only to facilitate interpretation of datatypes and validation of
structural vocabulary.
Core Schema
Our
Schema

Include

Datatype.XSD

Include

Include

Voc.XSD

Slide Number: 45

Infrastructure
Root.XSD

Include

Include

Include

Datatypebase.XSD


HL7 V3 Message Implementation Technology

XML Schema
Specification

Data

Definition

HL7
Message
Creation
HL7-Conformant
Application

Slide Number: 46

Message
Instance

HL7
Message
Parsing

Data

HL7-Conformant
Application


Questions / Discussion

Slide Number: 47


The Family of HL7 Standards
•
•
•
•
•
•
•
•
•
•
Slide Number: 48

Architecture (SOA)
accountability

RIM Derived and Influenced HL7 Standards
•

•

•

•

•
•
Slide Number: 49

Architecture (SOA)
accountability

Sample HL7 V3 Clients and Projects
Clinical Trial Registration
and Results
Message Specification

Clinical Trial Registration and Results
UMTS Project Consolidated
Dictionary and IHE Content
Profile
Slide Number: 50


Clinical Trial Registration and Results

Slide Number: 51


CTRR Development Artifacts

Slide Number: 52


Document Identifiers and Keywords

Study Protocol
Document, Study
Description, Features,
and Overall Status

Study Outcome Measures and
Objectives

Study
Participants

Planned Activities,
Study Arms, and
References

Regulatory
Authorities, Application
Submissions and
Authorizations

Slide Number: 53

Study
Enrollment
Stratification
and Targets

Target Research
Products
(devices and
substances)

Study Sites and Study
Site Recruitment
Activities


RMIM to XSD

Slide Number: 54


Traversing the CTRR RMIM
Entry Point

Slide Number: 55


HMD – the RMIM serialized

Slide Number: 56


Study Protocol Document
XSD

Slide Number: 57


Subject XSD

Slide Number: 58


Clinical Trial Intent XSD

Slide Number: 59


National Trauma Registry Submission
CDA Document Specification

Slide Number: 60


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.
Slide Number: 61


Clinical Document Architecture
RMIM

Participating
Entities
Slide Number: 62

Clinical
Document

Structured
Document
Sections

Section Entries

NTDB CDA RMIM Subset
Patient

+recordTarget

EntryRelationship

ClinicalDocument
isSubjectOf

1..*

1
1
0..*

1

0..*

1 +target

1

communicates

+nested
0..*

+informer
Organization

0..*

1..*

DocumentSection

+source

+clinicalStatement
0..*

+nesting
0..1

SectionEntry
1..*

0..1
Act

Slide Number: 63

Observ ation

Encounter

Procedure

Organizer


From Data Dict. to CDA Impl. Guide

Slide Number: 64


Scope

Slide Number: 65


Implementation Guide Development

Slide Number: 66


DAM: a UML representation of
dictionary elements
2.0 Submission::
RegistrySubmissionTransaction

0..1
PreHospitalEcounter
+

arrivalDateTime :TS [0..1]
departureDateTime :TS [0..1]
dispatchDateTime :TS [0..1]
preHospitalTransportationMethodCode :TransportationMethod [0..*]

0..1

0..1
PreHospitalCirculatorySystemObserv ation

PreHospitalRespiratorySystemObserv ation

+
+

+
+

heartRateAmount :PQ
systolicBloodPressureAmount :PQ

arterialOxygenSaturationAmount :PQ
respiratoryRateAmount :PQ

0..1
PreHospitalNerv ousSystemObserv ation
+
+
+
+

Slide Number: 67

glasgowComaEyeResponseValue :INT
glasgowComaMotorResponseValue :INT
glasgowComaScoreValue :INT
glasgowComaVerbalResponseCode :INT


Organization of DAM Classes
1.0 Patients
+ Patient

3.0 Inj ury Ev ents

2.0 Submission
+ RegistrySubmissionTransaction

4.0 PreHospital Encounters

5.0 Hospital Care Episodes

+ InjuryEvent

+ PreHospitalCirculatorySystemObservation

+ HospitalCareEpisode

+ InjurySeverityObservation

+ PreHospitalEcounter

+ HospitalCirculatorySystemObservation

+ PreHospitalNervousSystemObservation

+ HospitalNervousSystemObservation

+ PreHospitalRespiratorySystemObservation

+ HospitalPhysiologicalObservation
+ HospitalRespiratorySystemObservation
+ 5.1 Emergency Hospital Encounters
+ 5.2 InpatientHospitalEncounters

Slide Number: 68


Dictionary to DAM
Element ID

D_01
D_02
D_03
D_04
D_05
D_06
D_07
D_08
D_09
D_10
D_11
D_12
DG_01
DG_02
DG_03
ED_01
ED_02
ED_03
ED_043
ED_05
ED_06
ED_07
ED_08
ED_09

NTDB Dictionary Element

D_01: PATIENT’S HOME ZIP CODE
D_02: PATIENT’S HOME COUNTRY
D_03: PATIENT’S HOME STATE
D_04: PATIENT’S HOME COUNTY
D_05: PATIENT’S HOME CITY
D_06: ALTERNATE HOME RESIDENCE
D_07: DATE OF BIRTH
D_08: AGE
D_09: AGE UNITS
D_10: RACE
D_11: ETHNICITY
D_12: SEX
DG_01: CO-MORBID CONDITIONS
DG_02: ICD-9 INJURY DIAGNOSES
ED_01: ED/HOSPITAL ARRIVAL DATE
ED_02: ED/HOSPITAL ARRIVAL TIME
ED_03: INITIAL ED/HOSPITAL SYSTOLIC BLOOD PRESSURE
ED_043: INITIAL ED/HOSPITAL PULSE RATE
ED_05: INITIAL ED/HOSPITAL TEMPERATURE
ED_06: INITIAL ED/HOSPITAL RESPIRATORY RATE
ED_07: INITIAL ED/HOSPITAL RESPIRATORY ASSISTANCE
ED_08: INITIAL ED/HOSPITAL OXYGEN SATURATION
ED_09: INITIAL ED/HOSPITAL SUPPLEMENTAL OXYGEN

Slide Number: 69

DAM Package

2.0 Patients
2.0 Patients
2.0 Patients
2.0 Patients
2.0 Patients
2.0 Patients
2.0 Patients
2.0 Patients
2.0 Patients
2.0 Patients
2.0 Patients
2.0 Patients

DAM Class

Patient
Patient
Patient
Patient
Patient
Patient
Patient
Patient
Patient
Patient
Patient
Patient
HospitalCareEpisode
HospitalCareEpisode
HospitalCareEpisode
HospitalCareEpisode
HospitalCareEpisode
HospitalCirculatorySystemObservation
HospitalCirculatorySystemObservation
HospitalPhysiologicalObservation
HospitalRespiratorySystemObservation

DAM Attribute

postalAddress
postalAddress
postalAddress
postalAddress
postalAddress
residenceStatusCode
birthDate
eventRelatedAgeQuantity
raceCode
ethnicCode
genderCode
coMorbidConditionCode
injuryDiagnosisCode
injuryDiagnosisCode
arrivalDateTime
arrivalDateTime
systolicBloodPressureAmount
heartRateAmount
temperatureAmount
respiratoryRateAmount
respiratoryAssistanceIndicator
arterialOxygenSaturationAmount
supplementalOxygenIndicator


CIM: a CDA influenced UML
representation of dictionary elements
PreHospitalEncounterDetail::

1

CDA RMIM

RespiratorySystemEntryRelationship
+
+

typeCode :CS = x_ActRelationsh...
contextConductionInd :BL = "true"

0..*
RespiratorySystemObserv ation

2

Domain Analysis
Model

+
+

classCode :CS = "OBS"
moodCode :CS = "EVN"

Constrained
Information Model

ArterialOxygenSaturationObserv ation
+
-

code :CD = ObservationType
value :PQ

::RespiratorySystemObservation
+ classCode :CS = "OBS"
+ moodCode :CS = "EVN"

Slide Number: 70

RespiratoryRateObserv ation
+
-

code :CD = ObservationType
value :PQ

::RespiratorySystemObservation
+ classCode :CS = "OBS"
+ moodCode :CS = "EVN"


Organization of CIM Classes
TraumaRegistrySubmissionDocument
+ HealthcareFacility
Patient
+ RecordTarget
+ Patient
+ PatientRole
+ PatientDetailSection

+ RegistryParticipant
+ StructuredBodyComponent
+ StucturedBody
+ Submitter
+ TraumaRegistrySubmissionDocument
+ Patient
+ InjuryEventSection

(from TraumaRegistrySubmissionDocument)

+ PreHospital Encounter Section
+ Hospital Care Episode Section
+ EntryPoint

Inj uryEv entSection

PreHospital Encounter Section

Hospital Care Episode Section


+ PreHospitalEncounterSection

+ HospitalCareEpisodeSection

+ StructuredBodyInjuryEventComponent

+ StructoredBodyPreHospitalEncounterComponent

+ StructuredBodyHospitalCareEpisodeComponent

+ InjuryEventDetailEntry

+ PreHospitalEncounterDetail

+ HospitalCareEpisodeActivityDetail


Slide Number: 71




DAM to CIM

DAM Class

Patient
Patient
Patient
Patient
Patient
Patient
Patient
Patient
Patient
InjuryEvent
InjuryEvent
InjuryEvent
InjuryEvent
InjuryEvent
InjuryEvent
InjuryEvent
InjuryEvent
InjuryEvent
InjuryEvent
InjuryEvent
PreHospitalCirculatorySystemObservation
PreHospitalCirculatorySystemObservation

Slide Number: 72

DAM Attribute

birthDate
ethnicCode
genderCode
industryCode
occupationCode
postalAddress
raceCode
residenceStatusCode
abbreviatedInjuryCode
airbagDeploymentCode
bodyInjuryRegionCode
injurySeverityScoreValue
locationTypeCode
occurenceDateTime
postalAddress
primaryInjuryCauseCode
safetyEquipmentUsedCode
supplementalInjuryCauseCode
workRelatedEventInd
heartRateAmount
systolicBloodPressureAmount
arrivalDateTime
departureDateTime

CIM Class

Patient
Patient
PatientAgeObservation
Patient
PatientIndustryObservation
PatientOccupationObservation
PatientRole
Patient
PatientResidenceStatusObservation
AbreviatedInjuryObservation
AirbagDeploymentObservation
BodyInjuryObservation
SeverityScoreObservation
LocationTypeObservation
InjuryEventAct
PostalAddressObservation
PrimaryInjuryCauseObservation
SafetyEquipmentUsedObservation
SupplementalInjuryCauseObservation
WorkRelatedObservation
HeartRateObservation
SystolicBloodPressureObservation

CIM Attribute

birthTime
ethnicGroupCode
value
administrativeGenderCode
value
value
addr
raceCode
value
value
value
value
value
value
effectiveTime
value
value
value
value
value
value
value
effectiveTime
effectiveTime


IG: Dictionary elements represented
as templated CDA constraints

CDA RMIM

3

Constrained
Information Model

NTDB
Implementation Guide

EMS
Implementation Guide

Slide Number: 73


Organization of IG Templates

Slide Number: 74


Organization of IG Templates
Name:
Author:
Version:
Created:
Updated:

Salimah Shakir
1.0
2/7/2013 9:30:31 PM
6/14/2013 12:01:15 AM

Legend

HEADER

EntryPoint


Patient::PatientRole
1..1

Act
Entity

1

Role

+
+
+
+
-

classCode :CS = "DOCCLIN"
id :II
code :CE = DocumentType
effectiveTime :TS

RegistryParticipant
+

classCode :CS = "ASSIGNED"

1..1

1

Participation

1

1

ActRelationship

Submitter

StructuredBodyComponent
Foriegn Class

+
+

+
+

typeCode :CS = "COMP"
contextConductionInd :BL = "true"

typeCode :CS = "INF"
contextControlCode :CS = "OP"

1..1
Patient

1..1
HealthcareFacility

StucturedBody

+ RecordTarget

+
+

+ Patient

+
+
-

classCode :CS = "DOCBODY"

+ PatientRole

classCode :CS = "ORG"
determinerCode :CS = "INSTANCE"
id :II

1

1

1

1

BODY
1..1
1..1
PatientDetailSection::PatientDetailSection

PatientDetailSection

Inj uryEv entSection::Inj uryEv entSection

Inj uryEv entSection

0..1
PreHospital Encounter Section::
PreHospitalEncounterSection

PreHospital Encounter Section

1..1
Hospital Care Episode Section::
HospitalCareEpisodeSection

Hospital Care Episode Section



+ PreHospitalEncounterSection

+ HospitalCareEpisodeSection

+ StucturedBodyPatientDetailComponent

+ StructuredBodyInjuryEventComponent

+ StructoredBodyPreHospitalEncounterComponent

+ StructuredBodyHospitalCareEpisodeComponent

+ PatientDemographicObservation

+ InjuryEventDetailEntry

+ PreHospitalEncounterDetail

+ HospitalCareEpisodeActivityDetail

+ PatientEmploymentObservation
(from Patient)

Slide Number: 75

ENTRIES

Dict to DAM to CIM to IG
NTDB Dictionary Element

D_01: PATIENT’S HOME ZIP CODE
D_02: PATIENT’S HOME COUNTRY
D_03: PATIENT’S HOME STATE
D_04: PATIENT’S HOME COUNTY
D_05: PATIENT’S HOME CITY
D_06: ALTERNATE HOME RESIDENCE
D_07: DATE OF BIRTH
D_08: AGE
D_09: AGE UNITS
D_10: RACE
D_11: ETHNICITY
D_12: SEX
DG_01: CO-MORBID CONDITIONS
ED_01: ED/HOSPITAL ARRIVAL DATE
ED_02: ED/HOSPITAL ARRIVAL TIME
ED_03: INITIAL ED/HOSPITAL SYSTOLIC BLOOD PRESSURE
ED_043: INITIAL ED/HOSPITAL PULSE RATE
ED_05: INITIAL ED/HOSPITAL TEMPERATURE
ED_06: INITIAL ED/HOSPITAL RESPIRATORY RATE
ED_07: INITIAL ED/HOSPITAL RESPIRATORY ASSISTANCE
ED_08: INITIAL ED/HOSPITAL OXYGEN SATURATION
ED_09: INITIAL ED/HOSPITAL SUPPLEMENTAL OXYGEN

Slide Number: 76

CDA Template

3.1 Trauma Registry Submission Document
5.3 Patient Demographic Observations Organizer
6.5 Hospital Care Episode Observation Organizer
5.1 Hospital Care Episode Encounter
5.1 Hospital Care Episode Encounter
6.1 Circulatory System Observation Entry
6.1 Circulatory System Observation Entry
6.7 Hospital Care Physiological Observation
6.16 Respiratory System Observation Entry
6.15 Respiratory System Observation
6.16 Respiratory System Observation Entry
6.15 Respiratory System Observation

CDA ITEM CDA Clone

8.c.111
8.c.111
8.c.111
8.c.111
8.c.111
42.c.iv
8.c.iv.4
43.c.iv
43.c.iv.1
44.c.iv
8.c.iv.5
8.c.iv.3
84.c.iv
85.c.iv
85.c.iv
31
31
63.c.iv
62.c.iv
100.c.iv
145.c.iv
140.c.iv
144.c.iv
141.c.iv

patientRole
patientRole
patientRole
patientRole
patientRole
observation
patient
observation
observation
observation
patient
patient
observation
observation
observation
encounter
encounter
observation
observation
observation
observation
observation
observation
observation

CDA Attribute

CDA CONF

addr
addr
addr
addr
addr
value
birthTime
value
value@unit
value
ethnicGroupCode
administrativeGenderCode
value
value
value
effectiveTime
effectiveTime
value
value
value
value
value
value
value

27773
27773
27773
27773
27773
30000
27776
30008
30455
30508
27778
27775
30385
30397
30397
30341
30341
29639
29633
30431
30092
30437
30085
30441


Trauma Registry Data
Submission IG

Slide Number: 77


Front Matter:
Introduction and Specification Overview
78

Slide Number: 78


Conformance Verbs
79

• 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.
Slide Number: 79


Cardinality
80

• 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.
Slide Number: 80


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.

Slide Number: 81


Templates

Slide Number: 82


Document Template
83

Slide Number: 83


Section Templates

Slide Number: 84


Entry Templates

Slide Number: 85


Subentry Templates

Slide Number: 86


Vocabulary Tables

Slide Number: 87


Implementation Guide Development

Slide Number: 88


From Data Dict. to CDA Impl. Guide

Slide Number: 89


UMTS Project
Consolidated Dictionary and
IHE Content Profile Development

Slide Number: 90


UMTS Project Activities
Registry Elements

Semantic Analysis

1

00069 Dose Amount
00147 Duration
00070 Start Date Time
00306 Stop Date Time

MedicationTypeCode

Consolidated Dictionary

Initial Bolus
00776 Route

00307 Medication

2

DEI

Dictionary Element

00112

REI

Cardiac Arrest Indicator

Registry Element Name

Action.4135

RE Section

Coding Instructions

Context

Timing

Action.4140

Cardiac Arrest Pre-Hospital

Action.4145

Cardiac Arrest Outside Facility


Action.9035

Cardiac Arrest

H. In-Hospital Clinical Events

Indicate if the patient experienced an
episode of cardiac arrest in your facility.


CathPCI.5065 Cardiac Arrest w/in 24 Hours

D. Cath Lab Visit

Indicate if the patient has had an episode
of cardiac arrest within 24 hours of
procedure.


ICD.4080

Cardiac Arrest Pre-Hospital

C. History and Risk Factors

Indicate if the patient experienced
cardiac arrest due to arrhythmia.

History and Risk Factors

VTach/VFib Arrest Indicator ICD.4090

VTach/VFib Arrest


Indicate if the cardiac arrest was a result
of ventricular tachycardia or ventricular
fibrillation.


Bradycardia Arrest Indicator ICD.4095

Bradycardia Arrest


Indicate if the cardiac arrest was a result
of bradycardia.


00112


ICD.8005

Cardiac Arrest

H. Intra or Post Procedure Events

Indicate if the patient experienced
cardiac arrest.

Intra or Post Procedure

00112


Impact.8000 Cardiac Arrest

L. Intra and Post-Procedure Events

Indicate if there was a cardiac arrest event
that required CPR.

Intra or Post Procedure

00112

q24hr

Within 2 weeks

Cause

Cardiac Arrest at First Medical Contact C. Cardiac Status on First Medical Contact Indicate if the patient has had an episode First Medical Contact
of cardiac arrest.


00102

00238 Frequency

MedicationAdministration


00112

00800

q12hr

00112

00112

Initial Infusion

00112

00112

MedicationClassCode

Standard Clinical Code Systems

Location

C. Cardiac Status on First Medical Contact Indicate if the patient’s cardiac arrest was First Medical Contact
prior to arrival at the outside facility
and/or occurred during transfer from the
outside facility to this facility.
C. Cardiac Status on First Medical Contact Indicate if the patient’s cardiac arrest
First Medical Contact
occurred at the outside facility.


TVT.5035

D. Pre-Procedure Status

Indicate if the patient has had an episode of
cardiac arrest within 24 hours of the
procedure.

within 24 hours
of the procedure

First 24 Hours

PreHospital

Outside Facility

In Hospital

within 24 hours
of procedure

Pre-Hospital

Administered
Pre-Encounter
Timing

Intra-Encounter

00423 Status

Not Administered

Blinded

00303 Dose Code

Pre-Procedure

Intra-Procedure

ventricular tachycardia
or ventricular fibrillation

bradycardia

Contraindicated

At Discharge

Full

Reduced

Cardiac Arrest w/in 24 Hours

Other

During Follow-up

3

Conceptual Data Model

HL7 Reference Models
01.0 Submissions::ParticipantIdentifier
+

01.0 Submissions::SourceSystem

identifierValue :ST
identifierTypeCode :ParticipantIdentifier

-

versionIdentifier :ST

-

1

identifies

originates from
01.0 Submissions::Submission

01.0 Submissions::Participant
-

submited by

name :ST

-

1..* +
+

trialTypeCode :CD
researchStudyName :ST

1

identifier :ST
submissionTimePeriod :TS.DATE (IVL) 1..*
submissionDateTime :TS

01.0 Submissions::Registry

submited to
1 -

05.0 Ev ents::Ev entEv entRelation

identifier :ST {id}
versionIdentifier :ST {id}

+

Name:
Author:
Version:
Created:
Updated:

has target
0..*

+
0..* +
1

is part of

1

-

0..*

1

Procedure

has subject
name :EN.PN
birthDate :TS.DATE
sexCode :CD
hispanicIndicator :BL = No
ethnicityDetailCode :CD [0..*] (SET)
postalZoneIdentifier :II
residenceCountryCode :CD

indicationCode :CD [0..1]
abortedReasonCode :CD [0..*]

+

::Event
- methodCode :CD [0..*] (SET)
+ classificationCode :Clasification
+ contextCode :Context
- eventDateTime :TS [0..1] (IVL)
- statusCode :CD = Completed
- eventDuration :PQ.TIME [0..1]

is a type of

::Event

1

1

1..*

InvoiceElement
modifierCode : SET<CE>
unitQuantity : RTO<PQ,PQ>
unitPriceAmt : RTO<MO,PQ>
netAmt : MO
factorNumber : REAL
pointsNumber : REAL

is part of
0..*

1 -

identifier :II
typeCode :CD
manufacturerName :EN.ON
deviceName :ST
universalDeviceIdentifier :II [0..1]

0..1

is part of

administers

-

deviceCounter :INT

is part of
0..*

06.0 Lesions::LesionTreatmentDetail

-

1..*

0..*

-

identifierValue :II
identifierTypeCode :PatientIdentifier

::ObservationEvent
+ observationTypeCode :CD

10.0 Medication Administration Ev ents::
Medication

02.0 Patients::PatientRace

02.0 Patients::PatientIdentifier
+

raceCode :CD
raceDetailCode :CD [0..*] (SET)

+
-

09.0 Procedures::ProcedureVascularAssessment

previouslyTreatedIndicator :BL = No
culpritLesionIndicator :BL = No

-

vesselNotAvailableIndicator :BL = No

09.0 Procedures::ArterialAccess

09.0 Procedures::ArterialClosure
is part of

::Event

::Event

0..1

1

0..*

::ObservationEvent

::ObservationEvent

::Event

medicationCode :CD
name :ST

-

siteCounter :INT
directionalityTypeCode :CD [0..1]
vesselCode :CD

1..* {ordered} -

arterialClosureCounter :INT {id}
methodCode :CD [0..1]
undocumentedIndicator :BL = No

0..*

0..*

0..*

has target
is part of

is treatment of

1

06.0 Lesions::LesionTreatmentDev ice

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

1

1

06.0 Lesions::Lesion

06.0 Lesions::LesionAffectedVesselSegment

deviceCounter :INT

-

lesionCounter :INT {id}

0..*
04.0 Observ ations::Inv olv edAnatomicSite

is located in
0..* -

1

lesionLocationCode :CD
segmentCounter :INT

involved
1 -

0..*

typeCode :CD
lateralityCode :CD

1

0..*

is a type
of

+

involvementTypeCode :InvolvementType

is a type
of

is a type
of

Refers to (1..1)
07.0 Devices :: Device

1

08.0 AnatomicSites::AnatomicSite

affecting
-

0..*
06.0 Lesions::LesionDescriptor

08.0 AnatomicSites::VesselSegment

Primary Class

FinancialTransaction
amt : MO
creditExchangeRateQuantity : REAL
debitExchangeRateQuantity : REAL

-

::ObservationEvent

-

is part of

::AnatomicSite
- typeCode :CD
- lateralityCode :CD

::Event

Dependant Classes
Value Sets

08.0 AnatomicSites::AnatomicRegion

cardiovascularVesselCode :CD {id}
vesselTypeCode :CD

is part of

::AnatomicSite
- typeCode :CD

0..*

anotomicRegionCode :CD

0..1

::AnatomicSite
- typeCode :CD

0..*

+subsection
0..*

graftTypeCode :CD

4

Constrained Information Model
(Observ ation)
ParticipantIdentifierObserv ation

(Section)
RegistryParticipantDetailSection

(Patient)
Patient
+
+
+
+

#

classCode :CS = "PSN"
(Patient.name) name :EN.PN
(Patient.sexCode) administrativeGenderCode :CD
(Patient.birthDate) birthTime :TS.DATE
(Patient.hispanicIndicator) ethnicGroupCode :CD

classCode :CS = "DOCSECT"
code :CE = "RegistryPartic...

#
+

1..*

1

(ParticipantIdentifier.typeCode) code :CD
(ParticipantIdentifier.identifierValue) value :CD

(Entry)
ParticipantIdentifierObserv ationEntry

1..1
-

ii. This observationThe entryRelationship, one [1..1] @moodCode="EVN"
b. SHALL contain exactly if present, SHALL contain exactly one [1..1]
(CONF:31970). @contextConductionInd="true" (CONF:31967).

(CONF:31969).
ii. This observation SHALL contain exactly one [1..1] @moodCode="EVN"
(CONF:31970).

iii. This observation SHALL contain exactly one [1..1] code (CONF:31971).

contextConductionIndicator :BL = "true"

5


iv. This observation SHALL contain exactly one [1..1] value with @xsi:type="CD"
(CONF:31972).

::CardiovascularVessel
- cardiovascularVesselCode :CD {id}
- vesselTypeCode :CD
::AnatomicSite
- typeCode :CD

HL7 Clinical Document Architecture RMIM

iii. This observationThe entryRelationship, one [1..1] code (CONF:31971). one [1..1] observation
c. SHALL contain exactly if present, SHALL contain exactly
iv. This observation(CONF:31968). exactly one [1..1] value with @xsi:type="CD"
SHALL contain
(CONF:31972).
i. This observation SHALL contain exactly one [1..1] @classCode="OBS"

(CONF:31970).

08.0 AnatomicSites::Cardiov ascularGraft
-

Contains:

6. SHALL contain zeroSHALL containeffectiveTime (CONF:31963).
Table 1: ClincalEventObservationSubEntry Contexts
1. or one [0..1] exactly one [1..1] @classCode="OBS" (CONF:31958).
7. SHALL contain exactly one [1..1] value (CONF:31964).
2. SHALL containContained By:
exactly one [1..1] @moodCode="EVN" (CONF:31959).
Contains:
8. MAY contain zero or more [0..*] zero or one [0..1] @negationInd (CONF:31960).
3. MAY contain entryRelationship (CONF:31965).
a. The entryRelationship, if present,one [1..1] templateId="2.16.840.1.113883.3.2898.10.9999"
4. SHALL contain exactly SHALL contain exactly one [1..1]
This
@typeCode="OPTN" (CONF:31966). template is used to collect clinical event observations made within the scope of the
(CONF:31961).
encounter. Observations may be modified by observational semantic qualifiers.
b. The entryRelationship, if present,one [1..1] code exactly one [1..1]
5. SHALL contain exactly SHALL contain (CONF:31962).
@contextConductionInd="true" SHALL contain exactly one [1..1] @classCode="OBS" (CONF:31958).
1. (CONF:31967).
6. SHALL contain zero or one [0..1] effectiveTime (CONF:31963).
c. The entryRelationship, if present,one [1..1] valueexactlyone [1..1] observation
2. SHALL contain (CONF:31964).
7. SHALL contain exactly SHALL contain exactly one [1..1] @moodCode="EVN" (CONF:31959).
(CONF:31968).
3. MAY contain zero or one [0..1] @negationInd
8. MAY contain zero or more [0..*] entryRelationship (CONF:31965). (CONF:31960).
4. SHALL if present, SHALL contain exactly one [1..1]
a. The entryRelationship, contain exactly one [1..1] templateId="2.16.840.1.113883.3.2898.10.9999"
(CONF:31969).
(CONF:31961).
@typeCode="OPTN" (CONF:31966).
b. The entryRelationship, contain exactly one [1..1] code (CONF:31962).
(CONF:31970).
@contextConductionInd="true" (CONF:31967).
c. The entryRelationship, contain exactly one [1..1] value (CONF:31964).
if present, SHALL contain exactly one [1..1] observation
7. SHALL
(CONF:31968). MAY contain zero or more [0..*] entryRelationship (CONF:31965).
8.
(CONF:31972).
i. This observationThe entryRelationship, one [1..1] @classCode="OBS"
a. SHALL contain exactly if present, SHALL contain exactly one [1..1]
(CONF:31969). @typeCode="OPTN" (CONF:31966).

(CONF:31969).

is grouped by

is a type
of

Foreign Classes

08.0 AnatomicSites::Cardiov ascularVessel

vesselSegmentCode :CD {id}

Contained By:

SHALL contain
(CONF:31972).

0..*

is treated by

Contains:

1

3. MAY contain zero or one [0..1] @negationInd (CONF:31960).

4. SHALL contain exactly one [1..1] templateId="2.16.840.1.113883.3.2898.10.9999"
1.1 ClincalEventObservationSubEntry
(CONF:31961).This template is used to collect clinical event observations made within the scope of the
[observation: templateId 2.16.840.1.113883.3.2898.10.9999 (closed)]
5. SHALL contain exactly one [1..1] code (CONF:31962).

Contains:

Contains:
This
(CONF:31961).
1. (CONF:31967).
(CONF:31968).
(CONF:31969).
(CONF:31961).
(CONF:31970).
7. SHALL if present, SHALL contain exactly one [1..1] observation
8.
(CONF:31972).

1

0..*

Legend

Diet
energyQuantity : PQ
carbohydrateQuantity : PQ

is use of

0..* ::Event

1

09.0 Procedures::ArterialClosureDev ice
identifies


SUBENTRY

1. SHALL contain exactly one [1..1] @classCode="OBS" (CONF:31958).
2. SHALL contain exactly one [1..1] @moodCode="EVN" R Y
S U B E N T (CONF:31959).

1


07.0 Dev ices::Dev ice

::ObservationEvent

is use by

::Event
1

is part of

Supply
quantity : PQ
expectedUseTime : IVL<TS>

procedureTypeCode :CD

::Intervention
- indicationCode :CD [0..1]
- abortedReasonCode :CD [0..*]

is a type
of

deviceCounter :INT {id}
statusCode :CD
abortedReasonCode :CD [0..1]

is use of

1 +

has subject
1..*

-

::Intervention
- indicationCode :CD [0..1]
- abortedReasonCode :CD [0..*]

02.0 Patients::Patient

0..1

0..*

09.0 Procedures::ProcedureDev iceUse
09.0 Procedures::Procedure
-

1

This template is used to collect clinical event observations made within the scope of the



Contained By:

involving

0..*

02.0 Patients::ResearchStudyEnrollment


Contained By:

Contains:


0..*

is part of

0..*

enrolledIndicator :BL = No

SUBENTRY


::Event

is referred to by (0..*)
06.0 Lesions :: LesionTreatmentDevice

1

-

1


1

05.0 Events::Intervention

0..*

DiagnosticImage
subjectOrientationCode : CE

Contained By:

observationResultTypeCode :CD
conditionOnsetDateTime :TS [0..1]
+child
estimatedOnsiteDateIndicator :BL = No
0..*
missingOnsetTimeIndicator :BL = No
observationValue :ANY
observationValueNegationIndicator :BL = No

07.0 Dev ices::Dev iceDescriptor
::ObservationEvent

::Event

09.0 Procedures::ProcedureLesion

Observation
value : ANY
interpretationCode : SET<CE>

0..* +

is part of

::ObservationEvent

10.0 Medication Administration Ev ents::
MedicationAdministrationEv ent

SUBENTRY
ClincalEventObservationSubEntry

is grouped by
+parent
0..1
04.0 Observ ations::Observ ationResult

04.0 Observ ations::
Observ ationEv ent
observationTypeCode :CD

0..*

relationshipTypeCode :RelationshipType

is a type
of

1

1
1.1


name :EN.PN
identifier :II
isCertifiedIndicator :BL = No
0..*

+

::Event

is a type
of

09.0 Procedures::ProcedureDescriptor
0..*

03.0 CareEpisodes::Ev entEpisodeRelation
+

SUBENTRY

performed by

0..*

methodCode :CD [0..*] (SET)
classificationCode :Clasification
contextCode :Context
eventDateTime :TS [0..1] (IVL)
statusCode :CD = Completed
eventDuration :PQ.TIME [0..1]

has source
has target

within context of

1

SubstanceAdministration
routeCode : CE
doseQuantity : IVL<PQ>
rateQuantity : IVL<PQ>
doseCheckQuantity : SET<RTO>
maxDoseQuantity : SET<RTO>
substitutionCode : CE

PublicHealthCase
PatientEncounter
detectionMethodCode : CE
preAdmitTestInd : BL
transmissionModeCode : CE
admissionReferralSourceCode : CE
diseaseImportedCode : CE
lengthOfStayQuantity : PQ
dischargeDispositionCode : CE
specialCourtesiesCode : SET<CE>
specialAccommodationCode : SET<CE>
acuityLevelCode : CE

1.1

NCDR DAM Classes
Salimah Shakir
1.0
11/12/2012 7:02:00 PM
8/26/2013 1:05:44 PM

1

05.0 Ev ents::Ev ent

arrivalDateTime :TS
dischargeDate :TS.DATE
payorTypeCode :CD [1..*] (SET)
admissionSourceCode :CD
dischargeDispositionCode :CD
1

has source

is grouped by

0..*

-

05.0 Ev ents::Ev entPerformer

relationshipTypeCode :RelationshipType

0..*
03.0 CareEpisodes::CareEpisode
02.0 Patients::ClinicalTrial

Registry Specific Business Rules

identifier :ST {id}

is used by

salaryTypeCode : CE
salaryQuantity : MO
hazardExposureText : ED
protectiveEquipmentText : ED

0..n
LanguageCommunication
languageCode : CE
modeCode : CE
proficiencyLevelCode : CE
preferenceInd : BL

1

has subject

formCode : CE

ManufacturedMaterial
lotNumberText : ST
expirationTime : IVL<TS>
stabilityTime : IVL<TS>

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

HL7 & IHE Content Profiles

01.0 Submissions::SourceSystemProv ider

provided by

1..*

1

is part of

ActRelationship
typeCode : CS
inversionInd : BL
outboundRelationship contextControlCode : CS
Access
LicensedEntity
0..n contextConductionInd : BL
approachSiteCode : CD
recertificationTime : TS
targetSiteCode : CD
1 source
priorityNumber : INT
gaugeQuantity : PQ
pauseQuantity : PQ
Act
Participation
checkpointCode : CS
classCode : CS
Entity
typeCode : CS
Role
splitCode : CS
moodCode : CS
functionCode : CD
classCode : CS
player
joinCode : CS
classCode : CS
id : SET<II>
contextControlCode : CS
determinerCode : CS
negationInd : BL
0..1
code : CD
0..n id : SET<II>
id : SET<II>
0..n
conjunctionCode : CS
negationInd : BL
1
playedRolecode : CE
negationInd : BL
code : CE
localVariableName : ST
negationInd : BL
1 derivationExpr : ST
quantity : SET<PQ>
0..n noteText : ED
seperatableInd : BL
addr : BAG<AD>
text : ED
time : IVL<TS>
name : BAG<EN>
telecom : BAG<TEL>
0..n
modeCode : CE
desc : ED
effectiveTime : GTS
inboundRelationship
awarenessCode : CE
scopedRole
activityTime : GTS
signatureCode : CE
existenceTime : IVL<TS>
0..n certificateText : ED
target
availabilityTime : TS
signatureText : ED
telecom : BAG<TEL>
quantity : RTO
0..1
priorityCode : SET<CE>
performInd : BL
riskCode : CE
1
positionNumber : LIST<INT>
scoper
substitutionConditionCode : CE confidentialityCode : SET<CE>
...
handlingCode : CE
repeatNumber : IVL<INT>
DeviceTask
1 target 1source
interruptibleInd : BL
1
parameterValue : LIST<ANY>
levelCode : CE
inboundLink
WorkingList
0..n
outboundLink 0..n
independentInd : BL
Employee
ownershipLevelCode : CE
RoleLink
uncertaintyCode : CE
FinancialContract
jobCode : CE
typeCode : CS
reasonCode : SET<CE>
paymentTermsCode : CE
jobTitleName : SC
languageCode : CE
jobClassCode : CE
Material

treated

NonPersonLivingSubject
strainText : ED
genderStatusCode : CE

ManagedParticipation
id : SET<II>

assigns

LivingSubject
administrativeGenderCode : CE
birthTime : TS
deceasedInd : BL
deceasedTime : TS
multipleBirthInd : BL
multipleBirthOrderNumber : INT
organDonorInd : BL

Patient
confidentialityCode : CE
veryImportantPersonCode : CE

is a trait of

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

1..*

1

0..*

Organization
addr : BAG<AD>
standardIndustryClassCode : CE

(CONF:31972).

UMTS CDA Template Library

6

Registry Specific Content Profiles
1

SUBENTRY

1.1


1
(StructuredBodyComponent)
RegistryParticipantDetailComponent

Entry Point
(ClinicalDocumentComponent)
DocumentComponent

(RecordTarget)
RecordTarget
-

isPlayedBy

classCode :CS = "PAT"
(PatientIdentifier.identifierValue) id :II

-

typeCode :CS = "RCT"

-



(Entry)
PatientIdentifierObserv ationEntry


-

Contained By:


(ClinicalDocument)
CathPCIRegistryDocument

1..1

1

+
#
+

classCode :CS = "DOCCLIN"
id :II
code :CE = "CATHPCI"
effectiveTime :TS

-

1..1

(Observ ation)
PatientIdentifierObserv ation

(Section)
PatientDetailSection

(StructuredBody)
DocumentBody
1

classCode :CS = "DOCBODY"

1..1

1

#

code :CE = "PatientDetail"

1

0..*

#
+

(PatientIdentifier.typeCode) code :CD
(PatientIdentifier.identifierValue) value :CD

1

1
1
PatientDetailComponent

SubmissionDetailComponent

(Custodian)
Custodian
-

-

typeCode :CS = "CST"

-


(Entry)
PatientRaceObserv ationEntry


-

1..1


1..1

1..1
(CustodianOrganization)
Participant
+
+

(ParticipantIdentifier.identifierValue) id :II
(Participant.name) name :EN.ON

(Section)
SubmissionDetailSection

(AssignedCustodian)
ParticipantRole

isScopedBy
1

1..1

-

#

classCode :CS = "ASSIGNED"

(Observ ation)
PatientRaceObserv ation

code :CE = "SubmissionDetail"

#
+

1

code :CD = "PatientRace"
(PatientRace.raceCode) value :CD [1..*] (SET)

(Entry)
SubmissionActEntry
-

1..1
(Act)
SubmissionAct
+
+

classCode :CS = "ACT"
(Submission.identifier) id :II
(Submission.submissionTimePeriod) effectiveTime :TS (IVL)

(ParticipantRole)
TargetRegistry
1

1..1

-

classCode :CS = "MMAT"
1..1

1

(ClinicalStatementParticipant)
Author
-

(ClinicalStatementParticipant)
Receiv er

typeCode :CS = "AUT"

-

isPlayedBy

typeCode :CS = "RCV"

1..1
1

(Dev ice)
DataCollectionSystem
+

classCode :CS = "DEV"
(SourceSystem.versionIdentifier) id :II

(ParticipantRole)
SourceSystem

isPlayedBy
1

1..1

-

1

SUBENTRY

Contains:


1

1..1
(PatientRole)
PatientRole
+

(Dev ice)
RegistrySystem

classCode :CS = "MMAT"
+
+
isScopedBy

classCode :CS = "DEV"
(Registry.identifier) id.root :II.root
(RegistryVersionIdentifier) id.extension :II.extension


1

Contained By:

Contains:


Contains:
This
(CONF:31961).
1. (CONF:31967).
(CONF:31968).
(CONF:31969).
(CONF:31961).
(CONF:31970).
7. SHALL if present, SHALL contain exactly one [1..1] observation
8.
(CONF:31972).
SHALL contain
(CONF:31972).
(CONF:31969).
(CONF:31970).
(CONF:31972).

(Entity)
SourceSystemProv ider
+

Slide Number: 91

(SourceSystemProvider.identifier) id :II


1. Semantic Analysis
Registry Elements

Topic Area Mind Map
00069 Dose Amount
00147 Duration
00070 Start Date Time
00306 Stop Date Time

MedicationTypeCode

Initial Bolus
00776 Route

MedicationClassCode

00307 Medication

Initial Infusion

q12hr

00238 Frequency

MedicationAdministration

q24hr

Within 2 weeks

First 24 Hours
Administered
Pre-Encounter

Intra-Encounter

Timing

00423 Status

Intra-Procedure

At Discharge

Not Administered

Blinded

00303 Dose Code

Pre-Procedure

Contraindicated

Full

Reduced

Other

During Follow-up

Decompose composite registry elements
Into interrelated atomic concepts

Slide Number: 92


Rim derived and influenced hl7 standards

Rim derived and influenced hl7 standards

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (17)

Semelhante a Rim derived and influenced hl7 standards

Semelhante a Rim derived and influenced hl7 standards (20)

Último

Último (20)

Rim derived and influenced hl7 standards