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

July 14, 2015 Page: 2 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner

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 ShakirPresident and Chief Informatics

ScientistHi3 Solutions | your healthcare standards

conformance partner3500 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 web services standards, conventions, and technologies.


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

300Burbank, CA 91505

ww.hi3solutions.com +1 800 918-6520

http://www.hi3solutions.com/


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

MessageType

Example

Storyboard

StoryboardExample

D-MIM

Derive

ApplicationRole

Sender Receiver

TriggerEvent

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 : STbalanceAmt : MOcurrencyCode : CEinterestRateQuantity : RTO<MO,PQ>allowedBalanceQuantity : IVL<MO>

DeviceTask

parameterValue : LIST<ANY>

DiagnosticImage

subjectOrientationCode : CE

Diet

energyQuantity : PQcarbohydrateQuantity : PQ

FinancialContract

paymentTermsCode : CE

FinancialTransaction

amt : MOcreditExchangeRateQuantity : REALdebitExchangeRateQuantity : REAL

InvoiceElement

modifierCode : SET<CE>unitQuantity : RTO<PQ,PQ>unitPriceAmt : RTO<MO,PQ>netAmt : MOfactorNumber : REALpointsNumber : REAL

ManagedParticipation

id : SET<II>statusCode : SET<CS>

Observation

value : ANYinterpretationCode : SET<CE>methodCode : SET<CE>targetSiteCode : SET<CD>

PatientEncounter

preAdmitTestInd : BLadmissionReferralSourceCode : CElengthOfStayQuantity : PQdischargeDispositionCode : CEspecialCourtesiesCode : SET<CE>specialAccommodationCode : SET<CE>acuityLevelCode : CE

Procedure

methodCode : SET<CE>approachSiteCode : SET<CD>targetSiteCode : SET<CD>

PublicHealthCase

detectionMethodCode : CEtransmissionModeCode : CEdiseaseImportedCode : CE

SubstanceAdministration

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

Supply

quantity : PQexpectedUseTime : IVL<TS>

WorkingList

ownershipLevelCode : CE

Container

capacityQuantity : PQheightQuantity : PQdiameterQuantity : PQcapTypeCode : CEseparatorTypeCode : CEbarrierDeltaQuantity : PQbottomDeltaQuantity : PQ

Device

manufacturerModelName : SCsoftwareName : SClocalRemoteControlStateCode : CE...alertLevelCode : CElastCalibrationTime : TS

LivingSubject

administrativeGenderCode : CEbirthTime : TSdeceasedInd : BLdeceasedTime : TSmultipleBirthInd : BLmultipleBirthOrderNumber : INTorganDonorInd : BL

ManufacturedMaterial

lotNumberText : STexpirationTime : IVL<TS>stabilityTime : IVL<TS>

Material

formCode : CENonPersonLivingSubject

strainText : EDgenderStatusCode : CE

Organization

addr : BAG<AD>standardIndustryClassCode : CE

Person

addr : BAG<AD>maritalStatusCode : CEeducationLevelCode : CEraceCode : SET<CE>disabilityCode : SET<CE>livingArrangementCode : CEreligiousAffiliationCode : CEethnicGroupCode : SET<CE>

Place

mobileInd : BLaddr : ADdirectionsText : EDpositionText : EDgpsText : ST

Access

approachSiteCode : CDtargetSiteCode : CDgaugeQuantity : PQ

Employee

jobCode : CEjobTitleName : SCjobClassCode : CEsalaryTypeCode : CEsalaryQuantity : MOhazardExposureText : EDprotectiveEquipmentText : ED

LicensedEntity

recertificationTime : TS

Patient

confidentialityCode : CEveryImportantPersonCode : CE

ActRelationship

typeCode : CSinversionInd : BLcontextControlCode : CScontextConductionInd : BLsequenceNumber : INTpriorityNumber : INTpauseQuantity : PQcheckpointCode : CSsplitCode : CSjoinCode : CSnegationInd : BLconjunctionCode : CSlocalVariableName : STseperatableInd : BL

Act

classCode : CSmoodCode : CSid : SET<II>code : CDnegationInd : BLderivationExpr : STtext : EDstatusCode : SET<CS>effectiveTime : GTSactivityTime : GTSavailabilityTime : TSpriorityCode : SET<CE>confidentialityCode : SET<CE>repeatNumber : IVL<INT>interruptibleInd : BLlevelCode : CEindependentInd : BLuncertaintyCode : CEreasonCode : SET<CE>languageCode : CE

0..n

1

outboundRelationship

0..n

source1

0..n

1

inboundRelationship

0..n

target

1

LanguageCommunication

languageCode : CEmodeCode : CEproficiencyLevelCode : CEpreferenceInd : BL

Participation

typeCode : CSfunctionCode : CDcontextControlCode : CSsequenceNumber : INTnegationInd : BLnoteText : EDtime : IVL<TS>modeCode : CEawarenessCode : CEsignatureCode : CEsignatureText : EDperformInd : BLsubstitutionConditionCode : CE...

0..n

1

0..n

1

Entity

classCode : CSdeterminerCode : CSid : SET<II>code : CEquantity : SET<PQ>name : BAG<EN>desc : EDstatusCode : SET<CS>existenceTime : IVL<TS>telecom : BAG<TEL>riskCode : CEhandlingCode : CE

1

0..n

1

0..n

RoleLink

typeCode : CSeffectiveTime : IVL<TS>

Role

classCode : CSid : SET<II>code : CEnegationInd : BLaddr : BAG<AD>telecom : BAG<TEL>statusCode : SET<CS>effectiveTime : IVL<TS>certificateText : EDquantity : RTOpositionNumber : LIST<INT>

0..n

1

0..n

10..n0..1

playedRole0..n

player

0..1

0..n0..1

scopedRole

0..n

scoper

0..1

0..n

1

outboundLink 0..n

source1

0..n

1

inboundLink0..n

target1

HMD

D-MIM

PatientIncidentclassCode*: <= ENCmoodCode*: <= EVNid: [1..*] (RegistNum)code: CV CNE [0..1] <= ExternallyDefinedActCodes (PatientType)statusCode: LIST<CS> CNE <= ActStatus (IDPHStatus)activityTime: TS (EDDate)

InjuryclassCode*: <= ACTmoodCode*: <= EVNactivityTime: TS (InjuryDate)

0..1 pertinentInjury

typeCode*: <= PERTpertinentInformation1

TraumaRegistryExport(IDPH_RM00001)

Data content of HL7messages used to exportdata from the IDPH TraumaRegistry.

PatientPersonclassCode*: <= PSNdeterminerCode*: <= INSTANCEname: 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

PatientclassCode*: <= PATid: II [0..1] (MedicaRecordNum)

TraumaParticipantclassCode*: <= ORGdeterminerCode*: <= INSTANCEid: [1..1] (HospitNum)code: CV CWE [0..1] <= EntityCodename: ON [0..1] (HospitName)statusCode: CS CNE [0..1] <= EntityStatus (ActiveFacili)addr: AD [0..1] (HospitCity)

1..1 patient

typeCode*: <= SBJsubject

InjuryLocationclassCode*: <= PLCdeterminerCode*: <= INSTANCEcode: CV CWE [0..1] <= EntityCode (InjuryPlaceID)addr: AD [0..1] (AddressScene)

0..1 playingInjuryLocation

RoleclassCode*: <= ROL

1..1 participant

typeCode*: <= LOC

location

InjuryRelatedObservationclassCode*: <= OBSmoodCode*: <= EVNcode: <= ExternallyDefinedActCodespriorityCode: CV CWE [0..1] <= ActPriorityvalue: [0..1]

0..* pertinentInjuryRelatedObservation

typeCode*: <= PERTsequenceNumber: INT [0..1] (InjurySequen)

pertinentInformation

ProcedureclassCode*: <= PROCmoodCode*: <= EVNcode: CV CWE <= ActCode (ICDCodeID)activityTime: TS (ProcedDate)

0..* pertinentProcedure


0..1 medicalStaff

typeCode*: <= PRFperformer

MedicalStaffclassCode*: <= PROVid: II [0..1] (MedicalStaffID)

0..1 procedureLocation

typeCode*: <= LOClocation

ProcedureLocationclassCode*: <= SDLOCcode: <= RoleCode (ProcedLocateID)

PatientIncidentRelatedObservationclassCode*: <= OBSmoodCode*: <= EVNcode: <= ActCodereasonCode: CV CWE [0..1] <= ActReasonvalue: ANY [0..1]

0..* pertinentPatientIncidentRelatedObservation


PatientTransferclassCode*: <= TRNSmoodCode*: <= EVNactivityTime: IVL<TS> (DischaDate to ArriveDate)reasonCode: CV CWE [0..1] <= TransferActReason (REASONTRANSFID)

1..1 arrivalPatientTransfer

typeCode*: <= ARRarrivedBy

0..* aRole

typeCode*: <= ORGorigin

0..1 playingTraumaParticipant

aRoleclassCode*: <= ROL

TransferRelatedObservationclassCode*: <= OBSmoodCode*: <= EVNcode: CV CWE <= ExternallyDefinedActCodesvalue: PQ [0..1]methodCode: CV CWE [0..1] <= ObservationMethod

1..* pertinentTransferRelatedObservationtypeCode*: <= PERT


1..1 transferVehicle

typeCode*: <= VIAvia

1..1 owningVehicleProvider

TransferVehicleclassCode*: <= OWNid: II [0..1] (VehiclNum)code: <= RoleCode (VehiclLevelID)

VehicleProviderclassCode*: <= ORGdeterminerCode*: <= INSTANCEid: II [0..1] (VehiclProvide)code: <= EntityCode (MaxVehiclLevelID)name: ON [0..1] (VehiclProvidName)

HospitalVisitclassCode*: <= ENCmoodCode*: <= EVNcode: CV CWE <= ActCode (AdmitServicID)activityTime: TS (DischaDate)dischargeDispositionCode: CV CWE [0..1] <= EncounterDischargeDisposition

1..1 pertinentHospitalVisit


HospitalVisitRelatedObservationclassCode*: <= OBSmoodCode*: <= EVNcode: CV CWE <= ExternallyDefinedActCodesvalue: [0..1]

0..* pertinentHospitalVisitRelatedObservation

typeCode*: <= PERT


1..1 admittingProvider

typeCode*: <= ADMadmitter

0..1 healthCareMedicalStaffPerson

AdmittingProviderclassCode*: <= PROVid: II [0..1] (ADMITMEDICASTAFFID)code: CV CWE <= RoleCode (StaffTypeID)

0..* hospitalVisitPhysician

typeCode*: <= RESPtime: TS

responsibleParty


HospitalVisitPhysicianclassCode*: <= PROVid: II [0..1]code: CV CWE <= RoleCode (StaffTypeID)

MedicalStaffPersonclassCode*: <= PSNdeterminerCode*: <= INSTANCEname: PN [0..1] (MedicaStaffName)

0..1 licensedEntity

typeCode*: <= DSTdestination

0..1 subjectChoice

LicensedEntityclassCode*: <= LICid: II [0..1]

Choice

FacilityclassCode*: <= ORGdeterminerCode*: <= INSTANCEid:code*: CS CNE <= EntityCode "FAC"name:

HospitalclassCode*: <= ORGdeterminerCode*: <= INSTANCEid:code*: CS CNE <= EntityCode "HOSP"name:

EmergencyDepartmentEncounterclassCode*: <= ENCmoodCode*: <= EVNactivityTime: IVL<TS>dischargeDispositionCode: CV CWE <= EncounterDischargeDisposition

0..1 pertinentEmergencyDepartmentEncounter

typeCode*: <= PERT

pertinentInformation3

EmergencyDepartmentRelatedObservationclassCode*: <= OBSmoodCode*: <= EVNcode: CV CWE <= ExternallyDefinedActCodestext:activityTime: TSreasonCode: <= ActReasonvalue: [0..1]methodCode: CV CWE [0..1] <= ObservationMethodtargetSiteCode: CV CWE [0..1] <= HumanActSite

0..* pertinentEmergencyDepartmentRelatedObservation

typeCode*: <= PERTpertinentInformation

0..* emergencyDepartmentPhysician

typeCode*: <= PRFperformer

0..1 healthCareMedicalStaffPerson EmergencyDepartmentPhysicianclassCode*: <= PROVid: II [0..1]code: CE CWE [0..1] <= RoleCode (StaffTypeID)

PreHospitalEncounterclassCode*: <= ENCmoodCode*: <= EVNid: II [0..1] (crashNum)activityTime: IVL<TS>

0..1 priorPreHospitalEncounter

typeCode*: <= PREV

predecessor

PreHosptialRelatedObservationclassCode*: <= OBSmoodCode*: <= EVNcode: <= ExternallyDefinedActCodesvalue: ANY [0..1]

0..* pertinentPreHosptialRelatedObservation

typeCode*: <= PERTpertinentInformation

1..1 preHospitalVehicle

typeCode*: <= ParticipationTypeparticipant


PreHospitalVehicleclassCode*: <= OWNid: II [0..1] (VehiclNum)code: <= RoleCode (VehiclLevelID)

0..* emergencyDepartmentPhysicianActtypeCode*: <= COMP

component

EmergencyDepartmentPhysicianActclassCode*: <= ACTmoodCode*: <= EVNcode: CS CNE [0..1] <= ExternallyDefinedActCodesactivityTime*: TS [0..1]

component

0..* patientIncidentRelatedObservation

typeCode*: <= COMP

VehicleProvider

MedicalStaffPerson

TraumaParticipant

R-MIM

PatientIncidentclassCode*: <= ENCmoodCode*: <= EVNid: [1..*] (RegistNum)code: CV CNE <= ExternallyDefinedActCodes (PatientType)statusCode: LIST<CS> CNE <= ActStatus (IDPHStatus)activityTime: TS (EDDate)









1..1 patient





1..1 participant

typeCode*: <= LOC

location







typeCode*: <= PERT


component


typeCode*: <= COMP


HL7 XML Schema GeneratorHL7 Vocabulary Specification

HL7 Data Type Specification

HL7 XML SchemaGenerator

Hierarchical MessageDefinitionAndCMET Specifications

XML SchemaSpecification


HL7 V3 Message Implementation Technology

HL7-ConformantApplication

Data

HL7MessageCreation

HL7-ConformantApplication

HL7MessageParsing Data

MessageInstance


Hierarchical MessageDefinition


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 DiagramInitiateProject

ProjectCharter

SpecifyRequirements

ReferenceModels

RequirementSpecification

Prepare SpecificationDesign Models

SpecificationDesign Models

PrepareSpecification

ApproveSpecification

ApprovedSpecification

PublishApproved

Specification

PublishedSpecification

Prepare SpecificationProfiles

SpecificationProfile

ConformanceStatement

ProposedSpecification

The HDF workflow is not a waterfall methodology.Each phase builds upon the prior and may causeprior activities to be revisited and their deliverablesadjusted.


Project initiationDuring 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.

ProjectInitiation

ProjectCharter

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

RequirementsDocumentation

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

ProjectCharter


Specification ModelingDuring 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.

SpecificationModeling


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

RequirementsSpecification


Specification DocumentationDuring 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.

SpecificationDocumentation


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

SpecificationApproval


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



Specification PublicationDuring specification publication the approved specification is prepared for prepared for publication and distribution. The primary deliverable produced during specification publication is a published specification.

SpecificationPublication


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



Specification ProfilingDuring 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.

SpecificationProfiling

SpecificationConstraints

and ConformanceStatements

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



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

ReferenceInformation

Model


Model

DatatypeSpecification


VocabularySpecificationVocabulary

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 ModelReference Information Model

Data TypeSpecification


VocabularySpecification



SESSION RETROSPECTIVE

HL7 V3 MESSAGE DEVELOPMENT

FRAMEWORK (MDF)

HL7 DEVELOPMENT FRAMEWORK (HDF)

SERVICES AWARE INTEROPERABILITY

FRAMEWORK (SAIF)

HL7 V3 REFERENCE MODELS


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



ECCF SPECIFICATION

STACK


HL7 v3.0 Messaging Artifacts


Model


Model




Specification

FoundationalModels

(CIM)

DynamicModel

DynamicModel

ConstrainedInformation

Model


Model

CommonMessage Type

Model

CommonMessage Type

Model

DesignModels

(PIM)

HierarchicalMessage

Definition

HierarchicalMessage

Definition

MessageType

Definition

MessageType

Definition

ImplementationTechnology

Specification


Specification

MessageSpecifications

(PSM)




Model


Model




SpecificationFoundational

Models

DynamicModel

DynamicModel


Model


Model

CommonMessage Type

Model

CommonMessage Type

Model

DesignModels

HierarchicalMessage

Definition

HierarchicalMessage

Definition

MessageType

Definition

MessageType

Definition


Specification


Specification



Health Level Seven Version 3 Reference Models

The HL7 reference models are the foundational artifacts of HL7 version 3.0.




Model


Model




Specification





HL7 Version 3.0 Reference

Information ModelThe 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: [email protected]


RIM Harmonization ProcessChange Proposal Preparation

Prepare RIMChange Proposal

Prepare RIMChange Proposal

Review RIMChange Proposal

w/ Stewards

Review RIMChange Proposal

w/ Stewards

Document Rationalefor not supporting

RIM change proposal

Document Rationalefor not supporting

RIM change proposal

Revise or WithdrawRIM Proposal

Revise or WithdrawRIM Proposal

Post RIM Change Proposals

SubmitRIM Change

Proposal

SubmitRIM Change

Proposal

Post RIMChange Proposal

Post RIMChange Proposal

Notify HL7 Membersof RIM ChangeProposal Posting

Notify HL7 Membersof RIM ChangeProposal Posting

Provide Commenton RIM Change

Proposals

Provide Commenton RIM Change

Proposals

Harmonization Meeting

Discuss the RIMChange ProposalDiscuss the RIMChange Proposal

Revise, withdraw,or Table RIM

Change Proposal

Revise, withdraw,or Table RIM

Change Proposal

Vote on RIMChange Proposal

Vote on RIMChange Proposal

Apply ApprovedChanges to RIMApply ApprovedChanges to RIM

Apply TechnicalCorrections

Apply TechnicalCorrections

Post Harmonization Meeting Review

Present RIMHarmonization Report

to TSC

Present RIMHarmonization Report

to TSC

Hold TSC and/orBoard AppealsHold TSC and/orBoard Appeals

FinalizeRevised RIM

FinalizeRevised RIM


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 of the model (patient administration, finance, scheduling). Like the unified service action model, this proposal involved the combined effort of multiple technical committees.


USAM


The RIM Prior to USAM

from November 1

999


The Unified Service Action Model


Observation



routeCode : CEapproachSiteCode : SET<CD>doseQuantity : IVL<PQ>rateQuantity : IVL<PQ>doseCheckQuantity : SET<RTO>maxDoseQuantity : SET<RTO>

Procedure


Supply


Diet


Document

setId : IIversionNumber : INTcompletionCode : CEstorageCode : CEcopyTime : TS

Container


Access


Device

manufacturerModelName : SCsoftwareName : SClocalRemoteControlStateCode : CEalertLevelCode : CElastCalibrationTime : TS

Employee


LivingSubject


Material

formCode : CE

LicensedEntity

recertificationTime : TSPlace




NonPersonLivingSubject


Patient


Organization


Account


Person


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 : CSresultTotalQuantity : INTresultCurrentQuantity : INTresultRemainingQuantity : INT

QueryContinuation

startResultNumber : INTcontinuationQuantity : INT

Table

summary : STwidth : STrules : CScellspacing : STcellpadding : STborder : INTframe : CS

TableStructure

char : STcharoff : SThalign : CSvalign : CS

TableColumnStructure

span : INTwidth : ST

TableCell

scope : CSabbr : STaxis : STcolspan : INTheaders : SET<ED>rowspan : INT

LocalAttr

name : STvalue : ST

LocalMarkup

descriptor : STrender : STignoreCode : CS

LinkHtml

href : EDname : STrel : SET<CE>rev : SET<CE>title : ST

ContextStructure

localId : ST

Infrastructure (Structured documents)

Infrastructure (Communications)

Enitites

Message Control



InvoiceElement


FinancialContract


RoleHeir

EntityHeir

SortControl

sequenceNumber : INTelementName : SCdirectionCode : CS

QuerySpec

modifyCode : CSresponseElementGroupId : SET<II>responseModalityCode : CSresponsePriorityCode : CSinitialQuantity : INTinitialQuantityCode : CEexecutionAndDeliveryTime : TS

0..n

1

0..n

1

RelationalExpression

elementName : SCrelationalOperatorCode : CSvalue : ST

QueryBySelectionSelectionExpression

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 : ANYsemanticsText : ST

DeviceTask




ActHeir

ActRelationship


Act


0..n1

inboundRelationship

0..n

target

10..n1


0..n

source

1

Participation

typeCode : CSfunctionCode : CDcontextControlCode : CSsequenceNumber : INTnegationInd : BLnoteText : EDtime : IVL<TS>modeCode : CEawarenessCode : CEsignatureCode : CEsignatureText : EDperformInd : BLsubstitutionConditionCode : CE

0..n 10..n 1

RoleLink


Role


0..n1

0..n1

0..n1

outboundLink

0..n

source

1 0..n1

inboundLink

0..n

target

1



AttentionLine

keyWordText : SCvalue : ST

Entity


0..n0..1

playedRole

0..n

player

0..1

0..n0..1

scopedRole

0..n

scoper

0..1

10..n 10..n

Transmission

id : IIcreationTime : TSsecurityText : ST

0..n

1

0..n

1

CommunicationFunction

typeCode : CStelecom : 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 : IIstatusCode : CS

ControlAct

0..1

1

0..1

1

Message

versionCode : CSinteractionId : IIprofileId : SET<II>processingCode : CSprocessingModeCode : CSacceptAckCode : CSattachmentText : SET<ED>responseCode : CSsequenceNumber : INT

0..1

0..n

0..1

payload

0..n

Acknowledgement

typeCode : CSmessageWaitingNumber : INTmessageWaitingPriorityCode : CEexpectedSequenceNumber : INT

0..n

1

acknowledgedBy0..n

acknowledges1

0..1

1

conveyedAcknowledgement 0..1

conveyingMessage1

AcknowledgementDetail

typeCode : CScode : CEtext : EDlocation : SET<ST>

1

0..n

1

0..n

Batch

referenceControlId : IIname : SCbatchComment : SET<ST>transmissionQuantity : INTbatchTotalNumber : SET<INT>

0..1

0..n

0..1

0..n

RoleEntity

Participation

Acts

The RIM After USAMVersion 1.25 06/30/2003

Infrastructure


Normative R6 RIM Class DiagramVersion 2.44 11/22/2013


Entity and Act

Entitya physical thing or an organization/group of physical things capable of participating in Acts. This includes living subjects, organizations, material, and places.

Acta 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 : CSdeterminerCode: CScode: CEstatusCode : CSid : II

Act

classCode : CSmoodCode: CScode: CDstatusCode : CSeffectiveTime : GTSid : 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


Role

classCode : CScode: CEeffectiveTime : IVL<TS>statusCode : CSid : II

Act


RIM Core Classes

0..* 0..*1 0..*plays


0..10..*

0..10..*

plays

scopes

Entity


Role


Act


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


Role


Participation

typeCode : CStime : IVL<TS>statusCode : CS

Act


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


Role


Participation


Act


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


Role


Participation


Act


0..1

0..*1

0..*

1

0..*

Role Link


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


Role


Participation


Act


0..1

0..*1

0..*

1

0..*

Role Link


Act Relationship

typeCode : CS

RIM Backbone Classes

0..1

0..*

plays

scopes

1 1

0..* 0..*

1 1

0..* 0..*



Entity


Role


Participation


Act


0..1

0..*1

0..*

1

0..*

0..1

0..*

plays

scopes



Entity


Role


Participation


Act


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 : CSdeterminerCode : CSstatusCode : CScode: CE

Role

classCode : CSeffectiveTime : IVL<TS>code: CE

Participation


Act

classCode : CSmoodCode : CSstatusCode : CScode: CDeffectiveTime : GTS

0..1

0..* 1

0..*

1

0..*

RIM Core Attribute Value Sets

EntityClass Code

• Living Subject• Person• Organization• Material• Place• ...

RoleClass Code

• Patient• Provider• Employee• Specimen• Certified Practitioner• ...

ParticipationType Code

• Performer• Author• Witness• Subject• Destination• ...

ActMood Code

• Definition• Intent• Order• Event• Criterion• ...

ActClass Code

• Observation

• Procedure• Supply• Substance Admin• Financial• ...

EntityDeterminerCode

• 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) MandatoryVocabulary 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 DatatypeCardinali

ty UsageValue

DomainCoding Strength


Act.moodCode3.1.1.2 Act.moodCode :: CS (1..1) MandatoryVocabulary domain: ActMood (CNE)Attribute description:

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.code3.1.1.4 Act.code :: CD (0..1)Vocabulary domain: ActCode (CWE)Attribute description:

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.typeCode3.1.2.1 ActRelationship.typeCode :: CS (1..1) MandatoryVocabulary domain: ActRelationshipType (CNE)Attribute description:

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.typeCode3.1.3.1 Participation.typeCode :: CS (1..1) Mandatory

Vocabulary domain: ParticipationType (CNE)

Attribute description:

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.classCode3.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.determinerCode3.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.code3.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.typeCode3.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

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)

DescriptiveText


Model Browsing Tree - Relationships

Source Class (AKA Focal Class)

Relationships

Distal Class

DescriptiveText


Model Browsing Tree - States

States

Transitions

DescriptiveText


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 inactivenull

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 revisecomplete

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 Reference Information Model 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




Model


Model




Specification





HL7 Version 3.0 Data Type

SpecificationThe 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>>

<<restricts>>

<<restricts>>

<<restricts>>

<<extends>>

<<extends>>





<<restricts>>

<<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> optionalA 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 optionalIdentifies 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 NamePN: Person NameON: Organization Name


RTO: Ratio


numerator QTY mandatory The numerator of the ratio.

denominator QTY mandatoryThe denominator of the ratioThe 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




Model


Model




Specification





HL7 Version 3.0 Vocabulary

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


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.


HL7 V3 Vocabulary Specification Metamodel

ParentConcept

VocabularyDomain

name : Stringdescription : String

CodedConcept

conceptCode : StringconceptDesignation : String

0..*0..*

ValueSet

name : Stringdescription : StringdefiningExpression : String

0..*

0..*

0..*

0..*0..*

0..*0..*

0..*

includes

CodeSystem

identifier : OIDname : Stringdescription : 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 CodedConcept

CodeSystem

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 211 Hi3 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 211 Hi3 Solutions ~ Your healthcare standards conformance Partner



Model


Model




Specification

FoundationalModels

(CIM)

DynamicModel

DynamicModel


Model


Model

CommonMessage Type

Model

CommonMessage Type

Model

DesignModels

(PIM)

HierarchicalMessage

Definition

HierarchicalMessage

Definition

MessageType

Definition

MessageType

Definition


Specification


Specification


(PSM)



ParentConcept

VocabularyDomain


CodedConcept


0..*0..*

ValueSet


0..*

0..*

0..*

0..*0..*

0..*0..*

0..*

includes

CodeSystem


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

<<restricts>>

<<restricts>>

<<restricts>>

<<extends>>

<<extends>>





<<restricts>>

<<extends>>



<<extends>>




Model


Model





Models

DynamicModel

DynamicModel


Model


Model

CommonMessage Type

Model

CommonMessage Type

Model

DesignModels

HierarchicalMessage

Definition

HierarchicalMessage

Definition

MessageType

Definition

MessageType

Definition


Specification


Specification



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.

DynamicModel

DynamicModel

DesignInformation

Model

DesignInformation

Model

CommonMessage Type

Model

CommonMessage 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

MessageType

Example

Storyboard

StoryboardExample

D-MIM

Derive

ApplicationRole

Sender Receiver

TriggerEvent

Triggers

Content

Interaction

References


Dynam

ic M

odel


RIM

Restrict

R-MIM

Serialize

HMD

Restrict

MessageType

Example

Storyboard

StoryboardExample

D-MIM

Derive

ApplicationRole

Sender Receiver

TriggerEvent

Triggers

Content

Interaction

References


v3 Dynamic Model

Example

Storyboard

StoryboardExample

ApplicationRole

Sender Receiver

TriggerEvent

Triggers

Interaction

References


SAIF View of v3 Dynamic Model

«Interaction»Storyboard

artifactIdnamenarrative

«Exchange»Interaction

artifactIDnamenarrativestructuredNameinteractionType

«InterchangePoint»ApplicationRole

artifactIDnamedescriptionstructuredName

«ProviderInterchangePoi...SendingApplicationRole

::ApplicationRoleartifactIDnamedescriptionstructuredName

«ConsumerInterchangePoint»Reciev ingApplicationRole

::ApplicationRoleartifactIDnamedescriptionstructuredName

TriggerEvent

artifactIDnamedescriptiontypestructuredName

InteractionBasedTriggerEvent

::TriggerEventartifactIDnamedescriptiontypestructuredName

StateTransitionBasedTriggerEvent


UserRequestBasedTriggerEvent


«ConstrainedInformationMod...StaticModel

artifactIDnametype

ReceiverResponsibility

reason

«SoftwareUnit»Application


StoryboardExample

narrative

«ImplementableInformationModel»InformationStructure

disjoint = false

1..*

1..*

sendssender 1

1..*

receives

receiver 1

1..* {ordered} 0..*contains1

0..*

0..*

0..*

0..*

fulfi l ls

1

0..*

invokes

0..1

0..*

invokes

0..1

0..*

fulfi l ls

0..*

0..*

0..*

intiates

1

Name:Package:Version:Author:

Behavioral ModelBehavioral Modelv01r04AbdulMalik 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. Interactions2. Storyboards and Storyboard Examples3. Sender and Receiver Application Roles4. 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

StoryboardExample

ApplicationRole

Sender Receiver

TriggerEvent

Triggers

Interaction

References


v3 Dynamic Model - Interaction

Example

Storyboard

StoryboardExample

ApplicationRole

Sender Receiver

TriggerEvent

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

StoryboardExample

ApplicationRole

Sender Receiver

TriggerEvent

Triggers

Interaction

References


v3 Dynamic Model - Storyboard

Example

Storyboard

StoryboardExample

ApplicationRole

Sender Receiver

TriggerEvent

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

StoryboardExample

ApplicationRole

Sender Receiver

TriggerEvent

Triggers

Interaction

References


v3 Dynamic Model – Application Role

Example

Storyboard

StoryboardExample

ApplicationRole

Sender Receiver

TriggerEvent

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

StoryboardExample

ApplicationRole

Sender Receiver

TriggerEvent

Triggers

Interaction

References


v3 Dynamic Model – Trigger Event

Example

Storyboard

StoryboardExample

ApplicationRole

Sender Receiver

TriggerEvent

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 MachineResult 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

StoryboardExample

ApplicationRole

Sender Receiver

TriggerEvent

Triggers

Interaction

References



RIM

Restrict

R-MIM

Serialize

HMD

Restrict

MessageType

Example

Storyboard

StoryboardExample

D-MIM

Derive

ApplicationRole

Sender Receiver

TriggerEvent

Triggers

Content

Interaction

References


Sta

tic

Model


RIM

Restrict

R-MIM

Serialize

HMD

Restrict

MessageType

Example

Storyboard

StoryboardExample

D-MIM

Derive

ApplicationRole

Sender Receiver

TriggerEvent

Triggers

Content

Interaction

References


Sta

tic

Model

v3 Dynamic Model - Message Type

MessageType

Example

Storyboard

StoryboardExample

ApplicationRole

Sender Receiver

TriggerEvent

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

TransportMessage

Type

ControlMessage

Type

ContentMessage

Type


TriggerEvent

Interaction


ApplicationRole

InterfaceHealthcareApplication



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

TransportMessage

Type

ControlMessage

Type

ContentMessage

Type


TriggerEvent

Interaction


ApplicationRole





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 TypeTransport

Message Type

Control Message Type


Content 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

TransportMessage

Type

ControlMessage

Type

ContentMessage

Type


TriggerEvent

Interaction


ApplicationRole





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

TransportMessage

Type

ControlMessage

Type

ContentMessage

Type


TriggerEvent

Interaction


ApplicationRole




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

TransportMessage

Type

ControlMessage

Type

ContentMessage

Type


TriggerEvent

Interaction


ApplicationRole




v3 Dynamic Model - Message Type

MessageType

Example

Storyboard

StoryboardExample

ApplicationRole

Sender Receiver

TriggerEvent

Triggers

Content

Interaction

References




Model


Model





Models

DynamicModel

DynamicModel


Model


Model

CommonMessage Type

Model

CommonMessage Type

Model

DesignModels

HierarchicalMessage

Definition

HierarchicalMessage

Definition

MessageType

Definition

MessageType

Definition


Specification


Specification


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.


Sta

tic

Model


RIM

Restrict

R-MIM

Serialize

HMD

Restrict

MessageType

Example

Storyboard

StoryboardExample

D-MIM

Derive

ApplicationRole

Sender Receiver

TriggerEvent

Triggers

Content

Interaction

References


Sta

tic

Model

V3 Static Models

RIM

Restrict

R-MIM

Serialize

HMD

Restrict

MessageType

D-MIM

Derive


Implementable Information Models

Constrained Information Models

Reference Information Model

V3 Static Models

RIM

Restrict

R-MIM

Serialize

HMD

Restrict

MessageType

D-MIM

Derive

CIM

PIM

PSM


RIM

Account


DeviceTask


DiagnosticImage


Diet


FinancialContract




InvoiceElement




Observation


PatientEncounter


Procedure


PublicHealthCase



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

Supply


WorkingList


Container


Device

manufacturerModelName : SCsoftwareName : SClocalRemoteControlStateCode : CE...alertLevelCode : CElastCalibrationTime : TS

LivingSubject




Material

formCode : CE

NonPersonLivingSubject


Organization


Person


Place


Access


Employee


LicensedEntity

recertificationTime : TS

Patient


ActRelationship


Act


0..n

1


0..n

source1

0..n

1

inboundRelationship

0..n

target

1



Participation

typeCode : CSfunctionCode : CDcontextControlCode : CSsequenceNumber : INTnegationInd : BLnoteText : EDtime : IVL<TS>modeCode : CEawarenessCode : CEsignatureCode : CEsignatureText : EDperformInd : BLsubstitutionConditionCode : CE...

0..n

1

0..n

1

Entity


1

0..n

1

0..n

RoleLink


Role


0..n

1

0..n

10..n0..1

playedRole0..n

player

0..1

0..n0..1

scopedRole

0..n

scoper

0..1

0..n

1

outboundLink 0..n

source1

0..n

1

inboundLink0..n

target1

HMD

Constrained Information Model

D-MIM

PatientIncidentclassCode*: <= ENCmoodCode*: <= EVNid: [1..*] (RegistNum)code: CV CNE [0..1] <= ExternallyDefinedActCodes (PatientType)statusCode: LIST<CS> CNE <= ActStatus (IDPHStatus)activityTime: TS (EDDate)



typeCode*: <= PERT


TraumaRegistryExport(IDPH_RM00001)

Data content of HL7messages used to exportdata from the IDPH TraumaRegistry.






1..1 patient

typeCode*: <= SBJ

subject




1..1 participant

typeCode*: <= LOC

location





ProcedureclassCode*: <= PROCmoodCode*: <= EVNcode: CV CWE <= ActCode (ICDCodeID)activityTime: TS (ProcedDate)

0..* pertinentProcedure

typeCode*: <= PERT


0..1 medicalStaff

typeCode*: <= PRF

performer

MedicalStaffclassCode*: <= PROVid: II [0..1] (MedicalStaffID)

0..1 procedureLocation

typeCode*: <= LOC

locationProcedureLocationclassCode*: <= SDLOCcode: <= RoleCode (ProcedLocateID)



typeCode*: <= PERT


PatientTransferclassCode*: <= TRNSmoodCode*: <= EVNactivityTime: IVL<TS> (DischaDate to ArriveDate)reasonCode: CV CWE [0..1] <= TransferActReason (REASONTRANSFID)

1..1 arrivalPatientTransfer

typeCode*: <= ARR

arrivedBy

0..* aRole

typeCode*: <= ORG

origin

0..1 playingTraumaParticipant

aRoleclassCode*: <= ROL

TransferRelatedObservationclassCode*: <= OBSmoodCode*: <= EVNcode: CV CWE <= ExternallyDefinedActCodesvalue: PQ [0..1]methodCode: CV CWE [0..1] <= ObservationMethod

1..* pertinentTransferRelatedObservationtypeCode*: <= PERT


1..1 transferVehicle

typeCode*: <= VIA

via


TransferVehicleclassCode*: <= OWNid: II [0..1] (VehiclNum)code: <= RoleCode (VehiclLevelID)

VehicleProviderclassCode*: <= ORGdeterminerCode*: <= INSTANCEid: II [0..1] (VehiclProvide)code: <= EntityCode (MaxVehiclLevelID)name: ON [0..1] (VehiclProvidName)

HospitalVisitclassCode*: <= ENCmoodCode*: <= EVNcode: CV CWE <= ActCode (AdmitServicID)activityTime: TS (DischaDate)dischargeDispositionCode: CV CWE [0..1] <= EncounterDischargeDisposition

1..1 pertinentHospitalVisit

typeCode*: <= PERT


HospitalVisitRelatedObservationclassCode*: <= OBSmoodCode*: <= EVNcode: CV CWE <= ExternallyDefinedActCodesvalue: [0..1]

0..* pertinentHospitalVisitRelatedObservation

typeCode*: <= PERT


1..1 admittingProvider

typeCode*: <= ADM

admitter


AdmittingProviderclassCode*: <= PROVid: II [0..1] (ADMITMEDICASTAFFID)code: CV CWE <= RoleCode (StaffTypeID)

0..* hospitalVisitPhysician

typeCode*: <= RESPtime: TS

responsibleParty


HospitalVisitPhysicianclassCode*: <= PROVid: II [0..1]code: CV CWE <= RoleCode (StaffTypeID)

MedicalStaffPersonclassCode*: <= PSNdeterminerCode*: <= INSTANCEname: PN [0..1] (MedicaStaffName)

0..1 licensedEntity

typeCode*: <= DST

destination

0..1 subjectChoice

LicensedEntityclassCode*: <= LICid: II [0..1]

Choice

FacilityclassCode*: <= ORGdeterminerCode*: <= INSTANCEid:code*: CS CNE <= EntityCode "FAC"name:

HospitalclassCode*: <= ORGdeterminerCode*: <= INSTANCEid:code*: CS CNE <= EntityCode "HOSP"name:

EmergencyDepartmentEncounterclassCode*: <= ENCmoodCode*: <= EVNactivityTime: IVL<TS>dischargeDispositionCode: CV CWE <= EncounterDischargeDisposition

0..1 pertinentEmergencyDepartmentEncounter

typeCode*: <= PERT


EmergencyDepartmentRelatedObservationclassCode*: <= OBSmoodCode*: <= EVNcode: CV CWE <= ExternallyDefinedActCodestext:activityTime: TSreasonCode: <= ActReasonvalue: [0..1]methodCode: CV CWE [0..1] <= ObservationMethodtargetSiteCode: CV CWE [0..1] <= HumanActSite

0..* pertinentEmergencyDepartmentRelatedObservation

typeCode*: <= PERT


0..* emergencyDepartmentPhysician

typeCode*: <= PRF

performer

0..1 healthCareMedicalStaffPerson EmergencyDepartmentPhysicianclassCode*: <= PROVid: II [0..1]code: CE CWE [0..1] <= RoleCode (StaffTypeID)

PreHospitalEncounterclassCode*: <= ENCmoodCode*: <= EVNid: II [0..1] (crashNum)activityTime: IVL<TS>

0..1 priorPreHospitalEncounter

typeCode*: <= PREV

predecessor

PreHosptialRelatedObservationclassCode*: <= OBSmoodCode*: <= EVNcode: <= ExternallyDefinedActCodesvalue: ANY [0..1]

0..* pertinentPreHosptialRelatedObservation

typeCode*: <= PERT


1..1 preHospitalVehicle

typeCode*: <= ParticipationType

participant


PreHospitalVehicleclassCode*: <= OWNid: II [0..1] (VehiclNum)code: <= RoleCode (VehiclLevelID)

0..* emergencyDepartmentPhysicianActtypeCode*: <= COMP

component

EmergencyDepartmentPhysicianActclassCode*: <= ACTmoodCode*: <= EVNcode: CS CNE [0..1] <= ExternallyDefinedActCodesactivityTime*: TS [0..1]

component


typeCode*: <= COMP

VehicleProvider

MedicalStaffPerson

TraumaParticipant

R-MIM

PatientIncidentclassCode*: <= ENCmoodCode*: <= EVNid: [1..*] (RegistNum)code: CV CNE <= ExternallyDefinedActCodes (PatientType)statusCode: LIST<CS> CNE <= ActStatus (IDPHStatus)activityTime: TS (EDDate)









1..1 patient





1..1 participant

typeCode*: <= LOC

location







typeCode*: <= PERT


component


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

SubstanceAdministrationStepclassCode*: <= SBADMmoodCode*: <= x_ActMoodOrdPrmsEvnid*: II [1..1]code*: CE CWE <= SubstanceAdministrationActCodetext*:statusCode*: CS CNE [0..1]effectiveTime*: IVL<TS>routeCode: <= RouteOfAdministrationdoseQuantity: PQrateQuantity: PQ

1..1 manufacturedProduct *

typeCode*: <= CSM

consumable

1..1 manufacturedDrug *

0..1 manufacturerOrganization

ManufacturedProduct1classCode*: <= MANU

OrganizationclassCode*: <= ORGdeterminerCode*: <= INSTANCEname*: ON [1..1]

DrugclassCode*: <= MMATdeterminerCode*: <= INSTANCEcode*: [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:ActStatusAbortedCancelledCompletedactivityTime*: TS.DATETIME [1..1]value: CD CWE [0..1] <= V:AbnormalityAssessmentValuemethodCode: 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:ActUncertaintyvalue*: CD CWE [1..1] <= V:AbnormalityGradeValue

AssessmentOutcome

0..* assessmentOutcomeAnnotation

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

appendageOf

AssessmentOutcomeAnnotation

classCode*: = "OBS"moodCode*: = "EVN"code*: CD CWE [1..1] <= V:ObservationType ("ASSERTION")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



AbnormalityAssessmentclassCode*: = "OBS"moodCode*: = "EVN"code*: CD CWE [1..1] <= V:ObservationType ("ADVERSE_REACTION")statusCode*: CS CNE [1..1] <= V:ActStatusAbortedCancelledCompletedactivityTime*: TS.DATETIME [1..1]value: CD CWE [0..1] <= V:AbnormalityAssessmentValuemethodCode: SET<CE> CWE [0..*] <= V:AbnormalityAssessmentMethod



outcome

AssessmentException


AbnormalityGrade


AssessmentOutcome



appendageOf



«clone»Class

localName: charfixedName: charbusinessName: charcomment: AnnotationisEntryPointIndicator: booleanisStubIndicator: boolean

«RIM»Class

name: chardescription: Annotation

«clone»Attribute

businessName: chardatatype: DataTypecardinality: Cardinalityconformance: Conformancecomment: AnnotationinitialValue: charinitialValueRole: ValueRolemaximumLength: int

«RIM»Attribute

name: chardatatype: DataTypecardinality: CardinalitymandatoryInclusionIndicator: booleandescription: Annotation

«RIM»Relationship

name: charrelationshipType: RelationshipType

«clone»Relationship

ConstrainedInformationModel

name: chardescription: AnnotationmodelType: ModelType

ControllingAttribute

constraints{datatype = CS}{cardinality = (1..1)}{conformance = Mandatory}{codingStrength = CNE}{terminologyReference = CodeSystem}

«RIM»AssociationEnd

roleName: charmultiplicity: CardinalitynavigabilityIndicator: boolean

«clone»TraversalPath

name: charenabledIndicator: booleanrequiredIndicator: booleanmandatoryIndicator: booleanmultiplicity: Cardinality

«enumeration»Cardinality

0..10..n0..*11..11..n1..*n..mn..*

«enumeration»RelationshipType

GeneralizationAssociationCompositionAggregation

«clone»Choice

name: charnameExtension: char

«enumeration»Conformance

OptionalRequiredMandatory

«enumeration»ValueRole

FixedDefault

«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..10..*

isDerivedFrom

1

2

0,2


HL7 CIM Clones, Attributes, and Traversals

«clone»Class

localName: charfixedName: charbusinessName: charcomment: AnnotationisEntryPointIndicator: booleanisStubIndicator: boolean

«RIM»Class


«clone»Attribute


«RIM»Attribute


«RIM»Relationship

name: charrelationshipType: RelationshipType

«clone»Relationship

ConstrainedInformationModel

name: chardescription: AnnotationmodelType: ModelType



«RIM»AssociationEnd

roleName: charmultiplicity: Cardinalitynavigabil ityIndicator: boolean

«clone»Trav ersalPath

name: charenabledIndicator: booleanrequiredIndicator: booleanmandatoryIndicator: booleanmultiplicity: Cardinality

«enumeration»Cardinality

0..10..n0..*11..11..n1..*n..mn..*

«enumeration»RelationshipType

GeneralizationAssociationCompositionAggregation

«clone»Choice

name: charnameExtension: char

«enumeration»Conformance

OptionalRequiredMandatory

«enumeration»ValueRole

FixedDefault

«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..10..*

isDerivedFrom

1

2

2


HL7 CIM Terminology and Datatype

«clone»Attribute


«RIM»Attribute




«RIM»TerminologyBinding

codingStrength: CodingStrength

«clone»TerminologyBinding


TerminologyReference{abstract}


VocabularyDomain

ValueSet

conceptIdentifier: char

CodeSystem

objectIdentifier: charreleaseIdentifier: charisExternalIndicator: boolean

CodeSystemTerm

code: char [0..1]designation: chardescription: AnnotationinternalIdentifier: char

DataType

longName: charshortName: chardescription: Annotation

DatatypeAttribute

name: chardatatype: DataTypedescription: Annotation

ParentDatatype

«datatype»TerminologyBinding


Annotation{abstract}

«enumeration»CodingStrength

CNECWE

ParentCodeSystemTerm

AnnotationSection

sectionRole: AnnotationSectionRolesectionText: char

«enumeration»AnnotationSectionRole

DescriptionRationaleDesign CommentIssueImplementation NoteHistoryMapping

0..*

binds

1

0..1

binds

1

0..1

binds

1

0..*

isDerivedFrom

1

«restrict»

0..*

isDerivedFrom

10..*

binds

1

1..*

subkind1..*

0..*

0..*

binds

1

0..1

binds

1

0..*

0..*

isBoundTo

1

member

1..*0..*

1..*

subkind1..*

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

MessageType

D-MIM

Derive




Model


Model





Models

DynamicModel

DynamicModel


Model


Model

CommonMessage Type

Model

CommonMessage Type

Model

DesignModels

HierarchicalMessage

Definition

HierarchicalMessage

Definition

MessageType

Definition

MessageType

Definition


Specification


Specification


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 ReferenceAccessionclassCode*: <= ACSNmoodCode*: <= EVNid*: II [1..1]

CMET: (AGNT) R_Responsible

[universal](COCT_MT040000)

0..1 roleName

1..1 agent *

typeCode*: <= AUTauthor

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.




Model


Model





Models

DynamicModel

DynamicModel


Model


Model

CommonMessage Type

Model

CommonMessage Type

Model

DesignModels

HierarchicalMessage

Definition

HierarchicalMessage

Definition

MessageType

Definition

MessageType

Definition


Specification


Specification




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.

HierarchicalMessage

Definition

HierarchicalMessage

Definition

MessageType

Definition

MessageType

Definition


Specification


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

Info

rmati

on

Mod

el M

ap

pin

g

Messag

e E

lem

en

t S

pecifi

cati

on

s

Com

mon

Con

str

ain

ts

Messag

e T

yp

e S

pecifi

cati

on

(S)


HMD Components

Map

pin

g t

o t

he

Info

rmat

ion

Mo

del

Mes

sag

e E

lem

ent

Sp

ecif

icat

ion

s

Co

mm

on

Co

nst

rain

ts

Mes

sag

e Ty

pe

Sp

ecif

icat

ion

(S)


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.




Model


Model





Models

DynamicModel

DynamicModel


Model


Model

CommonMessage Type

Model

CommonMessage Type

Model

DesignModels

HierarchicalMessage

Definition

HierarchicalMessage

Definition

MessageType

Definition

MessageType

Definition


Specification


Specification


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.




Model


Model





Models

DynamicModel

DynamicModel


Model


Model

CommonMessage Type

Model

CommonMessage Type

Model

DesignModels

HierarchicalMessage

Definition

HierarchicalMessage

Definition

MessageType

Definition

MessageType

Definition


Specification


Specification


ImplementationTechnology SpecificationThe 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 XML Schema Generator

HL7 Vocabulary Specification


HL7 XML Schema

Generator






Model


Model





Models

DynamicModel

DynamicModel


Model


Model

CommonMessage Type

Model

CommonMessage Type

Model

DesignModels

HierarchicalMessage

Definition

HierarchicalMessage

Definition

MessageType

Definition

MessageType

Definition


Specification


Specification


HL7 V3 Message Specification Design Example

Pharmacy OTC Sales Data



Purchase date Units Category Promotion Zipcode County State Reporting stores Participating stores20040109 5 Cough/Cold N 88019 Some County XX 1 120040109 1 Thermometers N 88019 Some County XX 1 120040110 1 Cough/Cold N 88001 Some County XX 1 120040110 1 Cough/Cold N 88059 Some County XX 1 120040110 1 Cough/Cold N 88210 Some County XX 1 220040110 68 Cough/Cold N 88245 Some County XX 1 120040110 1 Cough/Cold N 88723 Some County XX 1 120040110 27 Cough/Cold Y 88245 Some County XX 1 120040110 1 Thermometers N 88245 Some County XX 1 120040110 1 Baby/Child Electrolytes N 88245 Some County XX 1 120040110 1 Baby/Child Electrolytes N 88806 Some County XX 1 220040110 1 Baby/Child Electrolytes N 88331 Some County XX 1 220040111 37 Cough/Cold N 88004 Some County XX 1 120040111 1 Cough/Cold N 88019 Some County XX 1 120040111 72 Cough/Cold N 88020 Some County XX 1 220040111 2 Cough/Cold N 88024 Some County XX 1 120040111 46 Cough/Cold N 88029 Some County XX 1 120040111 55 Cough/Cold N 88038 Some County XX 1 120040111 25 Cough/Cold N 88046 Some County XX 1 120040111 1 Cough/Cold N 88059 Some County XX 1 120040111 1 Cough/Cold N 88066 Some County XX 1 120040111 28 Cough/Cold N 88210 Some County XX 1 220040111 3 Cough/Cold N 88241 Some County XX 1 120040111 70 Cough/Cold N 88245 Some County XX 1 120040111 1 Cough/Cold N 88250 Some County XX 1 120040111 4 Cough/Cold N 88288 Some County XX 1 120040111 10 Cough/Cold N 88403 Some County XX 1 320040111 3 Cough/Cold N 88602 Some County XX 1 220040111 1 Cough/Cold N 88731 Some County XX 1 120040111 9 Cough/Cold N 88806 Some County XX 1 220040111 10 Cough/Cold N 88807 Some County XX 1 220040111 25 Cough/Cold N 88815 Some County XX 1 4






• Purchase Date

• Units

• Product Category

• Promotion Indicator

• Postal Zone

• County

• State

• Reporting Stores

• Participating Stores

• 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 : String1 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 Model3/30/2004

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 : String1 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 Model3/30/2004


Pharmacy OTC Sales R-MIM

OTCSaleEventclassCode *: <= SPLYmoodCode *: <= EVNactivityTime *: TS [1..1] (PurchaseDate)quantity*: PQ [1..1] (UnitsSold)

1..1 retailedProduct *

typeCode *: <= SBJsubject

1..1 retailedManufacturedMaterialKind *

1..1 retailerReportingPharmacy *

RetailedProductclassCode *: <= RET

ManufacturedMaterialKindclassCode *: <= MMATdeterminerCode *: <= KINDcode *: CS CNE [1..1] <= ProductEntityType (Category )

ReportingPharmacyclassCode *: <= ORGdeterminerCode *: <= QUANTIFIED_KINDquantity *: PQ [0..1] (Count)

PostalAreaclassCode *: <= PLCdeterminerCode *: <= INSTANCEid*: II [1..1] (PostalZone)

1..1 location *

ReportingPharamacyLocation 1..1 playedReportingPharamacyLocation *

classCode *: <= LOCE

ParticipatingPharmacyclassCode *: <= ORGdeterminerCode *: <= QUANTIFIED_KINDquantity *: PQ [1..1] (Count)

1..1 locatedParticipatingPharmacy *

ParticipatingPharmacyLocation

0..1 scopedParticipatingPharmacy LocationclassCode *: <= LOCE

OTCSalesEventData(PHIM_RM000001)

DescriptionOv er-the-counter pharmacy productsale data.

OTC Pharmacy Product Sales Events

RM000001v5

3/30/04

CountyclassCode *: <= COUNTYdeterminerCode *: <= INSTANCEname *: TN [1..1] (County Name)

StateclassCode *: <= PROVINCEdeterminerCode *: <= INSTANCEname *: TN [1..1] (StateName)

1..1 wholeCounty

PartOfCounty

1..1 playedPartOfCounty *classCode *: <= PART

1..1 wholeState

PartOfState 1..1 playedPartOfState *

classCode *: <= PART

1..1 pertinentPromotion *

typeCode *: <= PERT


PromotionclassCode *: <= CONDmoodCode *: <= EVNvalue*: BL [1..1] (PromotionIndicator)

OTCSaleEventclassCode *: <= SPLYmoodCode *: <= EVNactivityTime *: TS [1..1] (PurchaseDate)quantity*: PQ [1..1] (UnitsSold)

1..1 retailedProduct *

typeCode *: <= SBJsubject

1..1 retailedManufacturedMaterialKind *

1..1 retailerReportingPharmacy *

RetailedProductclassCode *: <= RET

ManufacturedMaterialKindclassCode *: <= MMATdeterminerCode *: <= KINDcode *: CS CNE [1..1] <= ProductEntityType (Category )

ReportingPharmacyclassCode *: <= ORGdeterminerCode *: <= QUANTIFIED_KINDquantity *: PQ [0..1] (Count)

PostalAreaclassCode *: <= PLCdeterminerCode *: <= INSTANCEid*: II [1..1] (PostalZone)

1..1 location *

ReportingPharamacyLocation 1..1 playedReportingPharamacyLocation *

classCode *: <= LOCE

ParticipatingPharmacyclassCode *: <= ORGdeterminerCode *: <= QUANTIFIED_KINDquantity *: PQ [1..1] (Count)

1..1 locatedParticipatingPharmacy *

ParticipatingPharmacyLocation

0..1 scopedParticipatingPharmacy LocationclassCode *: <= LOCE

OTCSalesEventData(PHIM_RM000001)

DescriptionOv er-the-counter pharmacy productsale data.

OTC Pharmacy Product Sales Events

RM000001v5

3/30/04

CountyclassCode *: <= COUNTYdeterminerCode *: <= INSTANCEname *: TN [1..1] (County Name)

StateclassCode *: <= PROVINCEdeterminerCode *: <= INSTANCEname *: TN [1..1] (StateName)

1..1 wholeCounty

PartOfCounty

1..1 playedPartOfCounty *classCode *: <= PART

1..1 wholeState

PartOfState 1..1 playedPartOfState *

classCode *: <= PART

1..1 pertinentPromotion *

typeCode *: <= PERT


PromotionclassCode *: <= CONDmoodCode *: <= EVNvalue*: 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 OTCSaleEvent2 classCode Act CS SPLY CNE3 moodCode Act CS EVN CNE4 activityTime Act TS DesignNote: PurchaseDate5 quantity Supply PQ DesignNote: UnitsSold6 subject Act Subject7 typeCode Participation CS SBJ CNE8 retailedProduct Participation RetailedProduct9 classCode Role CS RET CNE10 retailedManufacturedMaterialKind Role ManufacturedMaterialKind11 classCode Entity CS MMAT CNE12 determinerCode Entity CS KIND CNE13 code Entity CS ProductEntityType CNE DesignNote: Category14 retailerReportingPharmacy Role ReportingPharmacy15 classCode Entity CS ORG CNE16 determinerCode Entity CS QUANTIFIED_KIND CNE17 quantity Entity PQ DesignNote: Count18 playedReportingPharamacyLocation Entity ReportingPharamacyLocation19 classCode Role CS LOCE CNE20 location Role PostalArea21 classCode Entity CS PLC CNE22 determinerCode Entity CS INSTANCE CNE23 id Entity II DesignNote: PostalZone24 playedPartOfCounty Entity PartOfCounty25 classCode Role CS PART CNE26 wholeCounty Role County27 classCode Entity CS COUNTY CNE28 determinerCode Entity CS INSTANCE CNE29 name Entity TN DesignNote: CountyName30 playedPartOfState Entity PartOfState31 classCode Role CS PART CNE32 wholeState Role State33 classCode Entity CS PROVINCE CNE34 determinerCode Entity CS INSTANCE CNE35 name Entity TN DesignNote: StateName36 scopedParticipatingPharmacyLocation Entity ParticipatingPharmacyLocation37 classCode Role CS LOCE CNE38 locatedParticipatingPharmacy Role ParticipatingPharmacy39 classCode Entity CS ORG CNE40 determinerCode Entity CS QUANTIFIED_KIND CNE41 quantity Entity PQ DesignNote: Count42 pertinentInformation Act PertinentInformation43 typeCode ActRelationship CS PERT CNE44 pertinentPromotion ActRelationship Promotion45 classCode Act CS COND CNE46 moodCode Act CS EVN CNE47 value Observation BL DesignNote: PromotionIndicator

No Element Name Rim Source of Message Element Type Domain CS Nt

(Link to tabular view)

OTCSalesEventData

1 OTCSaleEvent Supply OTCSaleEvent2 classCode Act CS SPLY CNE3 moodCode Act CS EVN CNE4 activityTime Act TS DesignNote: PurchaseDate5 quantity Supply PQ DesignNote: UnitsSold6 subject Act Subject7 typeCode Participation CS SBJ CNE8 retailedProduct Participation RetailedProduct9 classCode Role CS RET CNE10 retailedManufacturedMaterialKind Role ManufacturedMaterialKind11 classCode Entity CS MMAT CNE12 determinerCode Entity CS KIND CNE13 code Entity CS ProductEntityType CNE DesignNote: Category14 retailerReportingPharmacy Role ReportingPharmacy15 classCode Entity CS ORG CNE16 determinerCode Entity CS QUANTIFIED_KIND CNE17 quantity Entity PQ DesignNote: Count18 playedReportingPharamacyLocation Entity ReportingPharamacyLocation19 classCode Role CS LOCE CNE20 location Role PostalArea21 classCode Entity CS PLC CNE22 determinerCode Entity CS INSTANCE CNE23 id Entity II DesignNote: PostalZone24 playedPartOfCounty Entity PartOfCounty25 classCode Role CS PART CNE26 wholeCounty Role County27 classCode Entity CS COUNTY CNE28 determinerCode Entity CS INSTANCE CNE29 name Entity TN DesignNote: CountyName30 playedPartOfState Entity PartOfState31 classCode Role CS PART CNE32 wholeState Role State33 classCode Entity CS PROVINCE CNE34 determinerCode Entity CS INSTANCE CNE35 name Entity TN DesignNote: StateName36 scopedParticipatingPharmacyLocation Entity ParticipatingPharmacyLocation37 classCode Role CS LOCE CNE38 locatedParticipatingPharmacy Role ParticipatingPharmacy39 classCode Entity CS ORG CNE40 determinerCode Entity CS QUANTIFIED_KIND CNE41 quantity Entity PQ DesignNote: Count42 pertinentInformation Act PertinentInformation43 typeCode ActRelationship CS PERT CNE44 pertinentPromotion ActRelationship Promotion45 classCode Act CS COND CNE46 moodCode Act CS EVN CNE47 value Observation BL DesignNote: PromotionIndicator


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="pertinentI nformation" /> </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" /> <xs:attribute name="classCode" type="RoleClass" /> </xs:complexType>

<?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="pertinentI nformation" /> </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" /> <xs:attribute name="classCode" type="RoleClass" /> </xs:complexType>


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> <quantity value="1" unit="" /> - <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> <quantity value="1" unit="" /> </ locatedParticipatingPharmacy> </scopedParticipatingPharmacyLocation> </ location> </playedReportingPharamacyLocation> </retailerReportingPharmacy> </retailedProduct> </subject>

- <pertinentInformation> - <pertinentPromotion> <value value="false" /> </pertinentPromotion> </pertinentInformation> </OTCSaleEvent>

<?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> <quantity value="1" unit="" /> - <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> <quantity value="1" unit="" /> </ locatedParticipatingPharmacy> </scopedParticipatingPharmacyLocation> </ location> </playedReportingPharamacyLocation> </retailerReportingPharmacy> </retailedProduct> </subject>

- <pertinentInformation> - <pertinentPromotion> <value value="false" /> </pertinentPromotion> </pertinentInformation> </OTCSaleEvent>


HL7 V3 Modeling Tools



RationalRose

RationalRose

ReferenceModel

Repository

RoseTreeRoseTree

R-MIMDesigner

R-MIMDesigner

SchemaGenerator

SchemaGenerator

RIM RIM

R-MIMRIMR-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 XML Schema

Generator





RationalRose

RationalRose

ReferenceModel

Repository

RoseTreeRoseTree

R-MIMDesigner

R-MIMDesigner

SchemaGenerator

SchemaGenerator

RIM RIM

R-MIMRIMR-MIM

HMD HMD

XSD

R-MIM





HL7 XML Schema

Generator


Refined Message Information ModelHierarchical Message

Definition

HL7 V3 Message Specification Core Schema


Core Schema

OurSchema

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

OurSchema

InfrastructureRoot.XSD

Datatype.XSD

Datatype-base.XSD

Voc.XSD

Include Include

Include Include Include

Include

Core Schema





HL7 XML Schema

Generator


Refined Message Information Model

Datatype.XSD

Voc.XSD



RationalRose

RationalRose

ReferenceModel

Repository

RoseTreeRoseTree

R-MIMDesigner

R-MIMDesigner

SchemaGenerator

SchemaGenerator

RIM RIM

R-MIMRIMR-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


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 Implementation Guide

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


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





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..*]

PreHospitalNerv ousSystemObserv ation

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

PreHospitalCirculatorySystemObserv ation

+ heartRateAmount :PQ+ systol icBloodPressureAmount :PQ

PreHospitalRespiratorySystemObserv ation

+ 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 Ev ents

+ 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 postalAddressD_02 D_02: PATIENT’S HOME COUNTRY 2.0 Patients Patient postalAddressD_03 D_03: PATIENT’S HOME STATE 2.0 Patients Patient postalAddressD_04 D_04: PATIENT’S HOME COUNTY 2.0 Patients Patient postalAddressD_05 D_05: PATIENT’S HOME CITY 2.0 Patients Patient postalAddressD_06 D_06: ALTERNATE HOME RESIDENCE 2.0 Patients Patient residenceStatusCodeD_07 D_07: DATE OF BIRTH 2.0 Patients Patient birthDateD_08 D_08: AGE 2.0 Patients Patient eventRelatedAgeQuantityD_09 D_09: AGE UNITS 2.0 Patients Patient eventRelatedAgeQuantityD_10 D_10: RACE 2.0 Patients Patient raceCodeD_11 D_11: ETHNICITY 2.0 Patients Patient ethnicCodeD_12 D_12: SEX 2.0 Patients Patient genderCodeDG_01 DG_01: CO-MORBID CONDITIONS 5.0 Hospital Care Episodes HospitalCareEpisode coMorbidConditionCodeDG_02 DG_02: ICD-9 INJURY DIAGNOSES 5.0 Hospital Care Episodes HospitalCareEpisode injuryDiagnosisCodeDG_03 DG_03: ICD-10 INJURY DIAGNOSES 5.0 Hospital Care Episodes HospitalCareEpisode injuryDiagnosisCodeED_01 ED_01: ED/HOSPITAL ARRIVAL DATE 5.0 Hospital Care Episodes HospitalCareEpisode arrivalDateTimeED_02 ED_02: ED/HOSPITAL ARRIVAL TIME 5.0 Hospital Care Episodes HospitalCareEpisode arrivalDateTimeED_03 ED_03: INITIAL ED/HOSPITAL SYSTOLIC BLOOD PRESSURE 5.0 Hospital Care Episodes HospitalCirculatorySystemObservation systolicBloodPressureAmountED_043 ED_043: INITIAL ED/HOSPITAL PULSE RATE 5.0 Hospital Care Episodes HospitalCirculatorySystemObservation heartRateAmountED_05 ED_05: INITIAL ED/HOSPITAL TEMPERATURE 5.0 Hospital Care Episodes HospitalPhysiologicalObservation temperatureAmountED_06 ED_06: INITIAL ED/HOSPITAL RESPIRATORY RATE 5.0 Hospital Care Episodes HospitalRespiratorySystemObservation respiratoryRateAmountED_07 ED_07: INITIAL ED/HOSPITAL RESPIRATORY ASSISTANCE 5.0 Hospital Care Episodes HospitalRespiratorySystemObservation respiratoryAssistanceIndicatorED_08 ED_08: INITIAL ED/HOSPITAL OXYGEN SATURATION 5.0 Hospital Care Episodes HospitalRespiratorySystemObservation arterialOxygenSaturationAmountED_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 AnalysisModel

2

CDA RMIM

ConstrainedInformation Model

ArterialOxygenSaturationObserv ation

+ code :CD = ObservationType- value :PQ

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

RespiratoryRateObserv ation

+ code :CD = ObservationType- value :PQ

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

RespiratorySystemObserv ation

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

PreHospitalEncounterDetail::PreHospitalEncounter

RespiratorySystemEntryRelationship

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

0..*

1

315


Organization of CIM Classes

InjuryEv entSection

+ InjuryEventSection

+ StructuredBodyInjuryEventComponent

+ InjuryEventDetailEntry

(from TraumaRegistrySubmissionDocument)

TraumaRegistrySubmissionDocument

+ HealthcareFacil i ty

+ 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 birthTimePatient ethnicCode Patient ethnicGroupCodePatient eventRelatedAgeQuantity PatientAgeObservation valuePatient genderCode Patient administrativeGenderCodePatient industryCode PatientIndustryObservation valuePatient occupationCode PatientOccupationObservation valuePatient postalAddress PatientRole addrPatient raceCode Patient raceCodePatient residenceStatusCode PatientResidenceStatusObservation valueInjuryEvent abbreviatedInjuryCode AbreviatedInjuryObservation valueInjuryEvent airbagDeploymentCode AirbagDeploymentObservation valueInjuryEvent bodyInjuryRegionCode BodyInjuryObservation valueInjuryEvent injurySeverityScoreValue SeverityScoreObservation valueInjuryEvent locationTypeCode LocationTypeObservation valueInjuryEvent occurenceDateTime InjuryEventAct effectiveTimeInjuryEvent postalAddress PostalAddressObservation valueInjuryEvent primaryInjuryCauseCode PrimaryInjuryCauseObservation valueInjuryEvent safetyEquipmentUsedCode SafetyEquipmentUsedObservation valueInjuryEvent supplementalInjuryCauseCode SupplementalInjuryCauseObservation valueInjuryEvent workRelatedEventInd WorkRelatedObservation valuePreHospitalCirculatorySystemObservation heartRateAmount HeartRateObservation valuePreHospitalCirculatorySystemObservation systolicBloodPressureAmount SystolicBloodPressureObservation valuePreHospitalEncounter arrivalDateTime PreHospitalEncounter effectiveTimePreHospitalEncounter departureDateTime PreHospitalEncounter effectiveTime


IG: Dictionary elements represented as templated CDA constraints

3

CDA RMIM

ConstrainedInformation Model

NTDBImplementation Guide

EMSImplementation Guide

318


Organization of IG Templates


Organization of IG Templates

StucturedBody

+ classCode :CS = "DOCBODY"+ moodCode :CS = "EVN"

StructuredBodyComponent

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

TraumaRegistrySubmissionDocument

+ classCode :CS = "DOCCLIN"+ moodCode :CS = "EVN"+ 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)

InjuryEv entSection::InjuryEv entSection PreHospital Encounter Section::PreHospitalEncounterSection

Hospital Care Episode Section::HospitalCareEpisodeSection

InjuryEv entSection


+ StructuredBodyInjuryEventComponent

+ InjuryEventDetailEntry

PreHospital Encounter Section

+ PreHospitalEncounterSection

+ StructoredBodyPreHospitalEncounterComponent

+ PreHospitalEncounterDetail

Hospital Care Episode Section

+ HospitalCareEpisodeSection

+ StructuredBodyHospitalCareEpisodeComponent

+ HospitalCareEpisodeActivityDetail

Name: TraumaRegistrySubmissionDocumentAuthor: Salimah ShakirVersion: 1.0Created: 2/7/2013 9:30:31 PMUpdated: 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 IGNTDB 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 27773D_02: PATIENT’S HOME COUNTRY 3.1 Trauma Registry Submission Document 8.c.111 patientRole addr 27773D_03: PATIENT’S HOME STATE 3.1 Trauma Registry Submission Document 8.c.111 patientRole addr 27773D_04: PATIENT’S HOME COUNTY 3.1 Trauma Registry Submission Document 8.c.111 patientRole addr 27773D_05: PATIENT’S HOME CITY 3.1 Trauma Registry Submission Document 8.c.111 patientRole addr 27773D_06: ALTERNATE HOME RESIDENCE 5.3 Patient Demographic Observations Organizer 42.c.iv observation value 30000D_07: DATE OF BIRTH 3.1 Trauma Registry Submission Document 8.c.iv.4 patient birthTime 27776D_08: AGE 5.3 Patient Demographic Observations Organizer 43.c.iv observation value 30008D_09: AGE UNITS 5.3 Patient Demographic Observations Organizer 43.c.iv.1 observation value@unit 30455D_10: RACE 5.3 Patient Demographic Observations Organizer 44.c.iv observation value 30508D_11: ETHNICITY 3.1 Trauma Registry Submission Document 8.c.iv.5 patient ethnicGroupCode 27778D_12: SEX 3.1 Trauma Registry Submission Document 8.c.iv.3 patient administrativeGenderCode 27775DG_01: CO-MORBID CONDITIONS 6.5 Hospital Care Episode Observation Organizer 84.c.iv observation value 30385DG_02: ICD-9 INJURY DIAGNOSES 6.5 Hospital Care Episode Observation Organizer 85.c.iv observation value 30397DG_03: ICD-10 INJURY DIAGNOSES 6.5 Hospital Care Episode Observation Organizer 85.c.iv observation value 30397ED_01: ED/HOSPITAL ARRIVAL DATE 5.1 Hospital Care Episode Encounter 31 encounter effectiveTime 30341ED_02: ED/HOSPITAL ARRIVAL TIME 5.1 Hospital Care Episode Encounter 31 encounter effectiveTime 30341ED_03: INITIAL ED/HOSPITAL SYSTOLIC BLOOD PRESSURE 6.1 Circulatory System Observation Entry 63.c.iv observation value 29639ED_043: INITIAL ED/HOSPITAL PULSE RATE 6.1 Circulatory System Observation Entry 62.c.iv observation value 29633ED_05: INITIAL ED/HOSPITAL TEMPERATURE 6.7 Hospital Care Physiological Observation 100.c.iv observation value 30431ED_06: INITIAL ED/HOSPITAL RESPIRATORY RATE 6.16 Respiratory System Observation Entry 145.c.iv observation value 30092ED_07: INITIAL ED/HOSPITAL RESPIRATORY ASSISTANCE 6.15 Respiratory System Observation 140.c.iv observation value 30437ED_08: INITIAL ED/HOSPITAL OXYGEN SATURATION 6.16 Respiratory System Observation Entry 144.c.iv observation value 30085ED_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 Implementation 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 12. Personal Healthcare Monitoring Report3. Patient Generated Document Header

Template, Release 14. Plan-to-Plan Personal Health Record (PHR)

Data Transfer, Release 15. 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 Realm9. CDA Framework for Questionnaire

Assessments, DSTU Release 210. Digital Signatures and Delegation of Rights,

Release 111. Exchange of Clinical Trial Subject Data;

Patient Narratives, Release 1 - US Realm12. Genetic Testing Reports, Release 113. 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 118. Quality Reporting Document Architecture -

Category III (QRDA III), DSTU Release 119. Questionnaire Form Definition Document,

Release 120. Questionnaire Response Document, Release

121. Reference Profile for EHR Interoperability,

Release 122. Trauma Registry Data Submission, Release 123. Consent Directives, Release 124. Procedure Note, Release 125. greenCDA Modules for CCD®, Release 126. Imaging Integration; Basic Imaging Reports in

CDA and DICOM, Release 127. Specification and Use of Reusable Information

Constraint Templates, Release 128. Neonatal Care Reports (NCR), R129. 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


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



ProjectCharter

SpecifyRequirements

ReferenceModels







PublishApproved

Specification








Specification ProfilingDuring 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.

SpecificationProfiling

SpecificationConstraints

and ConformanceStatements

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



Purpose and goals for conformance profiling


Reveal Assumptions

Revealing assumptions is an essential component of effective communication.

Yes, I doplay

football.

Do youplay

football?


Reveal Assumptions

Message Profiles are an effective means of documenting our assumptionsabout message structures

Do you use

HL7?

MSHEVNPID [PD1][ { NK1 } ]

Yes, Iuse

HL7.

MSHEVNPID[ 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



Highlight Conflicts

Sharing message profiles provides an opportunity to identify and reconcile conflicts in our understanding

and to validate our assumptions about message structures.


MSHEVNPID[ NK1 ]OBX


Consolidate Viewpoints

Message Profile Message Profile Message Profile


MSHEVNPID[ NK1 ]OBX

MSHEVN{ PID } [PD1][ { GT1 } ]

MSHEVN{ 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

BED 1 OFF

BED 1 OFF

BED 1 OFF

BED 1 OFF

BED 1 OFF

BED 1 OFF

BED 1 OFF

BED 1 OFF

BED 1 OFF

BED 1 OFF

POTASSIUM 3.5-5.0

BED 1 OFF

POTASSIUM 3.5-5.0

POTASSIUM 3.5-5.0

POTASSIUM 3.5-5.0

BED 1 OFF

POTASSIUM 3.5-5.0

BED 1 OFF BED 1 OFF

BED 1 OFF

BED 1 OFFBED 1 OFF

Critical Care Unit HIS/CIS

Vectra

XU

5/90C

BED 1 OFF

BED 1 OFF

BED 1 OFF

BED 1 OFF

BED 1 OFF

BED 1 OFF

BED 1 OFF

BED 1 OFF

BED 1 OFF

BED 1 OFF

POTASSIUM 3.5-5.0

BED 1 OFF

POTASSIUM 3.5-5.0

POTASSIUM 3.5-5.0

POTASSIUM 3.5-5.0

BED 1 OFF

POTASSIUM 3.5-5.0

BED 1 OFF BED 1 OFF

BED 1 OFF

BED 1 OFFBED 1 OFF


A/D/T System

Order Filling Application

Accept Ack

Accept + App ACK

Receiver ResponsibilityMSH-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 Modelad InteractionActiv ityModel

Requesting Registry System SIIS SIP Immunization Information Exchange System Responding Registry System

1.1 Request ImmunizationData

«message»

M.01 Immunization Data Request (VXQ)

2.2 Validate ImmunizationData Request Message

«message»

M.02 Request Error Message (ACK)

2.3 Route ImmunizationData Request Message2.4 Notify System

Administrator

«message»


3.1 Retriv e RequestedImmunization Data

«datastore»

D.04 Immunization Registry

3.2 RetrivalResult?

3.2.1 Return "No MatchingRecord" Response

3.2.2 Return "MultipleMatching Records"

Response

3.2.3 Return RequestedImmunization 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 ResponseMessage

«message»

M.07 Response Message Error (ACK)

4.3 Route ResponseMessage

4.4 Notify SystemAdministrator

«message»

M.08 No Matching Record Message (QCK)

«message»

M.09 Multiple Matching Record Message (VXX)

«message»

M.10 Requested Immunization Data Message (VXR)

5.1 Refine DemographicData

5.2 Select Desired Record

5.3 Merge ImmunizationData with existing data

«datastore»


[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 RegistrySystem

SIIS SIP ImmunizationInformation Exchange

System

Responding RegistrySystem

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 RequirementsMessage Source Destinat

ionAcknowledg

ment

• Vaccination Record Query (VXQ)

Requester IIES Only on error

• General Acknowledgement (ACK)

IIES Requester

Never


IIES Responder

Never

• Query Acknowledgement (QCK) Responder IIES Only on error


IIES Responder

Never

• Query Acknowledgement (QCK) IIES Requester

Never

• Vaccination Query Response (VXX)

Responder IIES Only on error


IIES Responder

Never


IIES Requester

Never

• Vaccination Query Response (VXR)



IIES Responder

Never


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 ExampleADT^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


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 [{ NK1 }] Next of Kin / Associated

Parties RE [0..3] 3


Info. RE [0..1] 3

[{ AL1 }] Allergy Information RE [0..*] 3


Message Level Profile Example 2 ADT^A01^ADT_A01 ADT Message Usage Cardinality Chapter


Parties RE [0..10] 3


Info. R [1..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 [{ RE [0..3] IN1 Insurance R [1..1] 6 [ IN2 ] Insurance Additional Info. RE [0..1] 6 [{ IN3 }] Insurance Additional Info -

Cert. X [0..0] 6

[{ ROL }] Role X [0..0] 12 }] [ ACC ] Accident Information RE [0..1] 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


Message Level Profile Example 2



Parties RE [0..10] 3


Info. R [1..1] 3

[{ AL1 }] Allergy Information RE [0..*] 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)

SEQ LEN DT Usage Cardinality TBL# ITEM# ELEMENT NAME


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

20 25 DLN X 00123 Driver's License Number - Patient



23 60 ST RE [0..1] 00126 Birth Place

24 1 ID X 0136 00127 Multiple Birth Indicator








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

SEQ LEN DT Usage Cardinality TBL# ITEM# ELEMENT NAM E


2 20 CX RE [1..1] 00105 Patient ID





7 26 TS RE 00110 Date/Tim e of Birth

8 1 IS RE 0001 00111 Sex


10 80 CE X 0005 00113 Race







17 80 CE X 0006 00120 Relig ion


19 16 ST RE 00122 SSN Number - Patient

20 25 DLN X 00123 Driver's L icense Number - Patient



23 60 ST RE 00126 Birth Place

24 1 ID X 0136 00127 Multip le Birth Indicator







: A DT S y stem : A DT Notifi ca tion Recip ient

A DTÂ 01

A CK Â 01

Interaction Model

Segment 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


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

Dynamic Definition

Static Definition – Segment Level

P a t ie n t

P hy s ic ian

A D T No t ific a t ion Re c ip ien t

A D T S y s tem

A dm it / V is it No t ific a t ion

is s u b jec t o fau tho rizes

rec e ives no t if ic a t ions en ds no t if ic a t ion

Reg is t ra rt rig ge rs

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Â013.2 ACKÂ01

4 Static Definition: - Message Level -ADT/ACK (event A01)

4.1 ADTÂ014.2 ACKÂ01

5 Static Defintiion - Segment Level

5.1 MSH – Message Header Segment Definition5.2 EVN - Event Type Segment Definition5.3 PID (Y) - Patient Demographics Segment Definition5.4 PD1 – Patient Additional Demographic Segment Definition5.5 NK1 - Next of kin Segment Definition5.6 PV1 (2) - Admit Visit Info Segment Definition5.7 AL1 - Allergy Segment Definition5.8 MSA - Message Acknowledgment Segment Definition5.9 ERR - Error Segment Definition

6 Static Definition - Field Level

6.1 Table 0001 – Sex6.2 Table 0002 – Marital Status6.3 Table 0003 – Event Type Code6.4 Table 0004 – Patient Class6.5 Table 0005 – Race6.6 Table 0006 – Religion6.7 Table 0007 – Admission Type6.8 Table 0008 – Acknowledgement Code6.9 Table 0009 – Ambulatory Status


Compliance and Conformance

ComplianceMessages that adhere to the rules and conventions for constructing of a specific version of a standard are compliant to that version of the standard.

ConformanceMessages 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

Receiv ing Public Health Agency

Accountable Public Health Agency

ELR HUB

ELR Repository

Business Analysts and Statisticians


Lab MessageSupplier

InboundLaboratoryMessage

InboundMessage Profile

Transform

Translate

InboundMessage Mapping

CanonicalLaboratoryMessage

CanonicalMessage Profile

Transform

Translate

OutboundMessage Mapping

OutboundLaboratoryMessage

Lab MessageConsumer

KnowledgeManagement

Service

KnowledgeManagement

Service

Object GraphGeneration

LaboratoryMessageObjects

ObjectRelationalMapping

LaboratoryMessage

Respository

Object RelationalMap

ELR DatabaseDesign Model

CA Public HealthLogical Data

Model

HL7 RIM &CDC PHLDM


LaboratoryMessage Object

Model

Extract,Transform,and Load

LaboratoryDatamart

BusinessIntelligenceApplication



OutboundMessage Profile


Additional DataSources


Inbound Message Processing Outbound Message Processing

Data PersistenceBusiness Intelligence

Lab MessageSupplier



Transform

Translate




Transform

Translate



Lab MessageConsumer

KnowledgeManagement

Service

KnowledgeManagement

Service




LaboratoryMessage

Respository




Model

HL7 RIM &CDC PHLDM



Model


LaboratoryDatamart










Transform

Translate




Transform

Translate



Outbound

Lab MessageSupplier

Lab MessageConsumer

KnowledgeManagement

Service

KnowledgeManagement

Service




LaboratoryMessage

Repository




Model

HL7 RIM &CDC PHLDM



Model


LaboratoryDatamart




Message Profile




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



Transform

Translate




Transform

Translate





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 PreliminarySegment Lev el Profile

Preliminary Segment Lev el Profile

Prepare SIIS SIPConceptual Data Model

SIIS SIP Conceptual Data Model

Map Profile to RegionalSystems

Regional System to Profile Mapping

Prepare Final SegmentLev el Profile

Final Segment Lev el Profile

Prepare SIIS SIP LogicalData Model

SIIS SIP Logical Data Model

Prepare SIIS SIP Phase IMessage Lev el Profiles

SIIS SIP Phase I Message Lev el Profiles

Prepare SIIS SIPVocabulary Specification

SIIS SIP Vocabulary Specification

Prepare IZ ImplementationGuide

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 ProfileMessage Tree Seq ETyp DTyp Usage Min Max Table Len ReferencePID 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

Message Tree Seq ETyp DTyp Usage Min Max Table Len ReferencePID 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

identifier: char(20) 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

identifier: char(20) text: char(199) contactRoleIdentifier: char(20) contactRoleText: char(199) l ivingArrangement: char(2)

PatientRace

identifier: char(20) text: char(199) PatientEthnicGroup

identifier: char(20) 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


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

identifier: char(20) text: char(199) preferenceIndicator: char(1)


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

identifier: char(20) text: char(199) contactRoleIdentifier: char(20) contactRoleText: char(199) l ivingArrangement: char(2)

PatientRace

identifier: char(20) text: char(199) PatientEthnicGroup

identifier: char(20) 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

LIN

K

SD

IR

VA

XT

RA

CK

CC

IR

BA

RR

RID

E

INN

C

SF

T

CV

IIS

Imp

eria

l

Pro

file

Usa

ge

CO

MM

EN

T

PID PIDPID.1 SetID-PID Y Y N Y Y N Y Y Y N YPID.3 PatientIdentifierListPID.3.1 ID Y Y N Y Y Y Y Y Y Y YPID.3.4 assigningauthorityPID.3.4.1 namespaceID Y Y N Y Y Y Y Y Y N YPID.5 PatientNamePID.5.1 familynamePID.5.1.1 surname Y Y Y Y Y Y Y Y Y Y YPID.5.2 givenname Y Y Y Y Y Y Y Y Y Y YPID.5.3 secondandfurthergivennamesorinitialsthereof Y Y Y Y Y Y Y Y Y Y YPID.5.4 suffix(e.g.,JRorIII) Y Y Y Y Y Y Y Y Y N YPID.6 Mother'sMaidenNamePID.6.1 familynamePID.6.1.1 surname Y Y Y Y Y Y Y Y Y Y YPID.7 Date/TimeOfBirthPID.7.1 Date/Time Y Y Y Y Y Y Y Y Y Y YPID.8 AdministrativeSex Y Y Y Y Y Y Y Y Y Y YPID.9 PatientAliasPID.9.1 familynamePID.9.1.1 surname N N Y N Y Y Y/Y Y Y Y YPID.9.2 givenname N N Y N Y Y Y/Y Y Y Y YPID.9.3 secondandfurthergivennamesorinitialsthereof N N Y N Y N Y/Y Y Y Y YPID.9.4 suffix(e.g.,JRorIII) N N Y N Y N Y/Y N Y N YPID.10 RacePID.10.1 identifier Y Y Y Y Y Y Y Y Y Y YPID.10.2 text Y N Y Y Y N Y Y Y Y YPID.10.3 nameofcodingsystem Y Y Y Y Y N Y Y Y N YPID.11 PatientAddressPID.11.1 streetaddress(SAD)PID.11.1.1 streetormailingaddress Y Y Y Y Y Y Y Y Y Y YPID.11.1.2 streetname N N N N N N N N N Y NPID.11.1.3 dwellingnumber N N N N N N N N N Y NPID.11.3 city Y Y Y Y Y Y Y Y Y Y YPID.11.4 stateorprovince Y Y Y Y Y Y Y Y Y Y YPID.11.5 ziporpostalcode Y Y Y Y Y Y Y Y Y Y YPID.11.7 addresstype Y Y Y Y Y N Y Y Y Y YPID.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 TablePID 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 family name 001 Component FN R 1 1 surname 001 SubComponent ST R 1 1 name type code 007 Component ID R 1 1 0200 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 * 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 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


Facility

*PK idNumber: int FK providerOrganizationIdNumber: int addressLine1Text: char(120) addressLine2Text: 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 addressLine1Text: char(120) addressLine2Text: char(120) cityName: char(50) stateCode: char(50) postalCode: char(12) addressTypeCode: char(3) countyCode: char(20)

FK+ FK_PersonPostalAddress_Person(int)PK+ PK_PersonPostalAddress(int)


*PK idNumber: int*FK personIdNumber: 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)*FK personIdNumber: int idTypeCode: char(6)* idAssigningAuthority: char(20)* statusCode: char(2)

FK+ FK_PersonIdentifier_Organization(int)+ FK_PersonIdentifier_Person(int)

PersonAlternateName

*PK idNumber: int*FK personIdNumber: 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)*FK patientIdNumber: int*FK personIdNumber: int* 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*FK patientIdNumber: 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 receivescare 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 ModelThe 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 RequirementsThe 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.

CardinalityCardinality 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 SpecificationVocabulary 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 Prov ider 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 Modelad InteractionActiv ityModel

Requesting Registry System SIIS SIP Immunization Information Exchange System Responding Registry System

1.1 Request ImmunizationData

«message»


2.2 Validate ImmunizationData Request Message

«message»

M.02 Request Error Message (ACK)

2.3 Route ImmunizationData Request Message2.4 Notify System

Administrator

«message»


3.1 Retriv e RequestedImmunization Data

«datastore»


3.2 RetrivalResult?

3.2.1 Return "No MatchingRecord" Response

3.2.2 Return "MultipleMatching Records"

Response

3.2.3 Return RequestedImmunization 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 ResponseMessage

«message»

M.07 Response Message Error (ACK)

4.3 Route ResponseMessage

4.4 Notify SystemAdministrator

«message»

M.08 No Matching Record Message (QCK)

«message»

M.09 Multiple Matching Record Message (VXX)

«message»

M.10 Requested Immunization Data Message (VXR)

5.1 Refine DemographicData

5.2 Select Desired Record

5.3 Merge ImmunizationData with existing data

«datastore»


[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 Modelsd Interactions

Requesting RegistrySystem

SIIS SIP ImmunizationInformation Exchange

System

Responding RegistrySystem

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


Requester IIES Only on error


IIES Requester

Never


IIES Responder

Never

• Query Acknowledgement (QCK) Responder IIES Only on error


IIES Responder

Never

• Query Acknowledgement (QCK) IIES Requester

Never




IIES Responder

Never


IIES Requester

Never




IIES Responder

Never


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 Vocabulary Specification

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

http://www.hl7.org/


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


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

InboundInformationProcessing


Standard Compliance andConformance Validation

Standard Compliance andConformance Validation

OutboundInformationProcessing


SourceInformation System

SourceInformation System Receiving

Information SystemReceiving

Information System

Information Transformation

Services


Services

Analysis, Visualization,and Reporting


Integrated Data Repository

Business Intelligence& Decision

Support Services

Health InformationExchange StandardsHealth InformationExchange Standards

Controlled ClinicalTerminology Services

Controlled ClinicalTerminology Services

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






SourceInformation System Receiving

Information SystemReceiving

Information System


Services


Services




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






Services


Services




Business Intelligence& Decision

Support Services



Hi3 Solutions Product Suite


Standards Conformance Validator

Syntax Compliance Verification of adherence

to the syntax rules specified in standards.

Structural Conformance Verification of adherence

to the element usage rules specified in profiles.

Semantic Conformance Verification of adherence

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

Verification of adherence to 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 Verification of adherence to

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


July 14, 2015

HL7 v3 Retrospective


HL7 Version 3 Topics


HL7 v3 Development Frameworks and

Architectures



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 web services standards, conventions, and technologies.


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

MessageType

Example

Storyboard

StoryboardExample

D-MIM

Derive

ApplicationRole

Sender Receiver

TriggerEvent

Triggers

Content

Interaction

References



ProjectCharter

SpecifyRequirements

ReferenceModels







PublishApproved

Specification









ECCF SPECIFICATION

STACK




Model


Model




Specification

FoundationalModels

(CIM)

DynamicModel

DynamicModel


Model


Model

CommonMessage Type

Model

CommonMessage Type

Model

DesignModels

(PIM)

HierarchicalMessage

Definition

HierarchicalMessage

Definition

MessageType

Definition

MessageType

Definition


Specification


Specification


(PSM)




Model


Model




Specification





Normative R6 RIM Class DiagramVersion 2.44 11/22/2013


Entity


Role


Participation


Act


0..1

0..*1

0..*

1

0..*

Role Link


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

<<restricts>>

<<restricts>>

<<restricts>>

<<extends>>

<<extends>>





<<restricts>>

<<extends>>



<<extends>>


HL7 V3 Vocabulary Specification Metamodel

ParentConcept

VocabularyDomain


CodedConcept


0..*0..*

ValueSet


0..*

0..*

0..*

0..*0..*

0..*0..*

0..*

includes

CodeSystem


0..*0..*

0..*

0..1

0..*

0..1

based on

ValueSetContext




ParentConcept

VocabularyDomain


CodedConcept


0..*0..*

ValueSet


0..*

0..*

0..*

0..*0..*

0..*0..*

0..*

includes

CodeSystem


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

<<restricts>>

<<restricts>>

<<restricts>>

<<extends>>

<<extends>>





<<restricts>>

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

DynamicModel

DynamicModel

DesignInformation

Model

DesignInformation

Model

CommonMessage Type

Model

CommonMessage Type

Model


Sta

tic

Model

Dynam

ic M

odel


RIM

Restrict

R-MIM

Serialize

HMD

Restrict

MessageType

Example

Storyboard

StoryboardExample

D-MIM

Derive

ApplicationRole

Sender Receiver

TriggerEvent

Triggers

Content

Interaction

References



Application Roles

Interactions


V3 Constrained Information Model



AbnormalityAssessment

classCode*: = "OBS"moodCode*: = "EVN"code*: CD CWE [1..1] <= V:ObservationType ("ADVERSE_REACTION")statusCode*: CS CNE [1..1] <= V:ActStatusAbortedCancelledCompletedactivityTime*: TS.DATETIME [1..1]value: CD CWE [0..1] <= V:AbnormalityAssessmentValuemethodCode: SET<CE> CWE [0..*] <= V:AbnormalityAssessmentMethod



outcome

AssessmentException


AbnormalityGrade


AssessmentOutcome



appendageOf



Model Components Entry Point(s) Clones

• Focal Class• Traversal Path• Choice Structure

Attributes• Datatype• Cardinality• Terminology Binding


CMET ReferenceAccessionclassCode*: <= ACSNmoodCode*: <= EVNid*: II [1..1]

CMET: (AGNT) R_Responsible

[universal](COCT_MT040000)

0..1 roleName

1..1 agent *

typeCode*: <= AUTauthor

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.

HierarchicalMessage

Definition

HierarchicalMessage

Definition

MessageType

Definition

MessageType

Definition


Specification


Specification


HMD Components

Info

rmati

on

Mod

el M

ap

pin

g

Messag

e E

lem

en

t S

pecifi

cati

on

s

Com

mon

Con

str

ain

ts

Messag

e T

yp

e S

pecifi

cati

on

(S)





HL7 XML Schema

Generator







HL7 XML Schema

Generator


Refined Message Information Model

Datatype.XSD

Voc.XSD



RationalRose

RationalRose

ReferenceModel

Repository

RoseTreeRoseTree

R-MIMDesigner

R-MIMDesigner

SchemaGenerator

SchemaGenerator

RIM RIM

R-MIMRIMR-MIM

HMD HMD

XSD

R-MIM


HL7 v3 Clinical DocumentArchitecture


Clinical Document Architecture RMIM

Clinical Document






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 assumptionsabout message structures

Do you use

HL7?


Yes, Iuse

HL7.

MSHEVNPID[ NK1 ]OBX


Conceptual Overview

Message Profile = Static Profile + Dynamic Profile

Critical Care Unit

ADT System

Acknowledgement Message

Initiating Message

Initiating Message



Dynamic Interaction

Vectra

XU

5/90C

BED 1 OFF

BED 1 OFF

BED 1 OFF

BED 1 OFF

BED 1 OFF

BED 1 OFF

BED 1 OFF

BED 1 OFF

BED 1 OFF

BED 1 OFF

POTASSIUM 3.5-5.0

BED 1 OFF

POTASSIUM 3.5-5.0

POTASSIUM 3.5-5.0

POTASSIUM 3.5-5.0

BED 1 OFF

POTASSIUM 3.5-5.0

BED 1 OFF BED 1 OFF

BED 1 OFF

BED 1 OFFBED 1 OFF

Critical Care Unit HIS/CIS

Vectra

XU

5/90C

BED 1 OFF

BED 1 OFF

BED 1 OFF

BED 1 OFF

BED 1 OFF

BED 1 OFF

BED 1 OFF

BED 1 OFF

BED 1 OFF

BED 1 OFF

POTASSIUM 3.5-5.0

BED 1 OFF

POTASSIUM 3.5-5.0

POTASSIUM 3.5-5.0

POTASSIUM 3.5-5.0

BED 1 OFF

POTASSIUM 3.5-5.0

BED 1 OFF BED 1 OFF

BED 1 OFF

BED 1 OFFBED 1 OFF


A/D/T System

Order Filling Application

Accept Ack

Accept + App ACK

Receiver ResponsibilityMSH-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


Message Level Profile ExampleADT^A01^ADT_A01 ADT Message Usage Cardinality Chapter


Parties RE [0..3] 3


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


Message Level Profile Example



Parties RE [0..3] 3


Info. RE [0..1] 3

[{ AL1 }] Allergy Information RE [0..*] 3


How it all ties together

Static Definition – Field Level

Vocabulary

SEQ LEN DT Usage Cardinality TBL# ITEM# ELEMENT NAM E


2 20 CX RE [1..1] 00105 Patient ID





7 26 TS RE 00110 Date/Tim e of Birth

8 1 IS RE 0001 00111 Sex


10 80 CE X 0005 00113 Race







17 80 CE X 0006 00120 Relig ion


19 16 ST RE 00122 SSN Number - Patient

20 25 DLN X 00123 Driver's L icense Number - Patient



23 60 ST RE 00126 Birth Place

24 1 ID X 0136 00127 Multip le Birth Indicator







: A DT S y stem : A DT Notifi ca tion Recip ient

A DTÂ 01

A CK Â 01

Interaction Model

Segment 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


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

Dynamic Definition

Static Definition – Segment Level

P a t ie n t

P hy s ic ian

A D T No t ific a t ion Re c ip ien t

A D T S y s tem

A dm it / V is it No t ific a t ion

is s u b jec t o fau tho rizes

rec e ives no t if ic a t ions en ds no t if ic a t ion

Reg is t ra rt rig ge rs

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Â013.2 ACKÂ01

4 Static Definition: - Message Level -ADT/ACK (event A01)

4.1 ADTÂ014.2 ACKÂ01

5 Static Defintiion - Segment Level

5.1 MSH – Message Header Segment Definition5.2 EVN - Event Type Segment Definition5.3 PID (Y) - Patient Demographics Segment Definition5.4 PD1 – Patient Additional Demographic Segment Definition5.5 NK1 - Next of kin Segment Definition5.6 PV1 (2) - Admit Visit Info Segment Definition5.7 AL1 - Allergy Segment Definition5.8 MSA - Message Acknowledgment Segment Definition5.9 ERR - Error Segment Definition

6 Static Definition - Field Level

6.1 Table 0001 – Sex6.2 Table 0002 – Marital Status6.3 Table 0003 – Event Type Code6.4 Table 0004 – Patient Class6.5 Table 0005 – Race6.6 Table 0006 – Religion6.7 Table 0007 – Admission Type6.8 Table 0008 – Acknowledgement Code6.9 Table 0009 – Ambulatory Status



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 Development Frameworks and

Architectures



HL7 Standards Compliance and Profile

Conformance


Course Topics

HL7 v2 Messaging HL7 v3 Messaging

HL7 Clinical Document

ArchitectureHL7 Family of Standards

HL7 Compliance and Conformance


Q&A


Thank You!

Peace...AMS

Abdul-Malik ShakirPresident and Chief Informatics Scientist

Hi3 Solutions 3500 West Olive Ave, Suite # 300, Burbank, CA 91505

Skype: +1 9098334661 Mobile: (626) 644-4491Email: [email protected]

Introduction to hl7 v3

Technology

Transcript of Introduction to hl7 v3