Download - 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
July 13, 2015 Page: 3 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 4 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 6 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
HL7 V3 HISTORY AND RATIONALE
July 14, 2015 Page: 7 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
International
National
Inter-Enterprise
Enterprise
Institution
Ever-Increasing Circles
Source: Gartner
July 14, 2015 Page: 8 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 9 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 10 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 11 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 12 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 13 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 14 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Questions
July 14, 2015 Page: 15 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Hi3 Solutions 3500 W. Olive Ave, Suite
300Burbank, CA 91505
ww.hi3solutions.com +1 800 918-6520
July 14, 2015 Page: 16 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
HL7 v3 Development Frameworks and Architectures
July 14, 2015 Page: 17 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
SESSION OVERVIEW
HL7 V3 MESSAGE DEVELOPMENT
FRAMEWORK (MDF)
HL7 DEVELOPMENT FRAMEWORK (HDF)
SERVICES AWARE INTEROPERABILITY
FRAMEWORK (SAIF)
HL7 V3 REFERENCE MODELS
July 14, 2015 Page: 18 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
HL7 v3 Message Development Framework
July 14, 2015 Page: 19 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
The MDF Methodology Overview
July 14, 2015 Page: 20 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 21 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 22 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 23 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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?
July 14, 2015 Page: 24 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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
typeCode*: <= PERTpertinentInformation7
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
typeCode*: <= PERTpertinentInformation2
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
pertinentInformation
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
typeCode*: <= PERTpertinentInformation5
HospitalVisitRelatedObservationclassCode*: <= OBSmoodCode*: <= EVNcode: CV CWE <= ExternallyDefinedActCodesvalue: [0..1]
0..* pertinentHospitalVisitRelatedObservation
typeCode*: <= PERT
pertinentInformation
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
0..1 healthCareMedicalStaffPerson
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
1..1 owningVehicleProvider
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)
InjuryclassCode*: <= ACTmoodCode*: <= EVNactivityTime: TS (InjuryDate)
0..1 pertinentInjury
typeCode*: <= PERTpertinentInformation1
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
PatientIncidentRelatedObservationclassCode*: <= OBSmoodCode*: <= EVNcode: <= ActCodereasonCode: CV CWE [0..1] <= ActReasonvalue: ANY [0..1]
0..* pertinentPatientIncidentRelatedObservation
typeCode*: <= PERT
pertinentInformation2
component
0..* patientIncidentRelatedObservation
typeCode*: <= COMP
July 14, 2015 Page: 25 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
HL7 XML Schema GeneratorHL7 Vocabulary Specification
HL7 Data Type Specification
HL7 XML SchemaGenerator
Hierarchical MessageDefinitionAndCMET Specifications
XML SchemaSpecification
July 14, 2015 Page: 26 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
HL7 V3 Message Implementation Technology
HL7-ConformantApplication
Data
HL7MessageCreation
HL7-ConformantApplication
HL7MessageParsing Data
MessageInstance
XML SchemaSpecification
Hierarchical MessageDefinition
July 14, 2015 Page: 27 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
HL7 Development Framework
July 14, 2015 Page: 28 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 29 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 30 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 31 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 32 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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
SpecificationDesign Models
1. Build design models of static information views
2. Construct design models of behavioral views
3. Define reusable design model components
4. Construct design models of collaboration and interaction
5. Harmonize design models with HL7 Reference Models
RequirementsSpecification
July 14, 2015 Page: 33 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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
ProposedSpecification
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
SpecificationDesign Models
July 14, 2015 Page: 34 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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
ApprovedSpecification
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
ProposedSpecification
July 14, 2015 Page: 35 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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
PublishedSpecification
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
ApprovedSpecification
July 14, 2015 Page: 36 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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
PublishedSpecification
July 14, 2015 Page: 37 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
SAIF Canonical Definition
July 14, 2015 Page: 38 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 39 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 40 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 41 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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..
July 14, 2015 Page: 42 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
ECCF Specification Stack
ECCF SPECIFICATION
STACK
July 14, 2015 Page: 43 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 44 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 45 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 46 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
Health Level Seven Version 3 Reference Models
The HL7 reference models are the foundational artifacts of HL7 version 3.0.
July 14, 2015 Page: 47 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
HL7 v3.0 Foundational Artifacts
ReferenceInformation
Model
ReferenceInformation
Model
DatatypeSpecification
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.
July 14, 2015 Page: 48 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
HL7 Version 3.0 Reference Models
Reference Information ModelReference Information Model
Data TypeSpecification
Data TypeSpecification
VocabularySpecification
VocabularySpecification
July 14, 2015 Page: 49 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
SESSION RETROSPECTIVE
HL7 V3 MESSAGE DEVELOPMENT
FRAMEWORK (MDF)
HL7 DEVELOPMENT FRAMEWORK (HDF)
SERVICES AWARE INTEROPERABILITY
FRAMEWORK (SAIF)
HL7 V3 REFERENCE MODELS
July 14, 2015 Page: 50 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
Hi3 Solutions 3500 W. Olive Ave, Suite
300Burbank, CA 91505
ww.hi3solutions.com +1 800 918-6520
July 14, 2015 Page: 51 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
HL7 v3 Messaging Artifacts
July 14, 2015
July 14, 2015 Page: 52 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
SESSION OVERVIEW
Messaging Artifacts ECCF Foundational Artifacts Design Artifacts Specification Artifacts
HL7 v3 Message Design Example HL7 v3 Development Tools
July 14, 2015 Page: 53 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
ECCF Specification Stack
ECCF SPECIFICATION
STACK
July 14, 2015 Page: 54 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
HL7 v3.0 Messaging Artifacts
ReferenceInformation
Model
ReferenceInformation
Model
DatatypeSpecification
DatatypeSpecification
VocabularySpecificationVocabulary
Specification
FoundationalModels
(CIM)
DynamicModel
DynamicModel
ConstrainedInformation
Model
ConstrainedInformation
Model
CommonMessage Type
Model
CommonMessage Type
Model
DesignModels
(PIM)
HierarchicalMessage
Definition
HierarchicalMessage
Definition
MessageType
Definition
MessageType
Definition
ImplementationTechnology
Specification
ImplementationTechnology
Specification
MessageSpecifications
(PSM)
July 14, 2015 Page: 55 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
HL7 v3.0 Messaging Artifacts
ReferenceInformation
Model
ReferenceInformation
Model
DatatypeSpecification
DatatypeSpecification
VocabularySpecificationVocabulary
SpecificationFoundational
Models
DynamicModel
DynamicModel
ConstrainedInformation
Model
ConstrainedInformation
Model
CommonMessage Type
Model
CommonMessage Type
Model
DesignModels
HierarchicalMessage
Definition
HierarchicalMessage
Definition
MessageType
Definition
MessageType
Definition
ImplementationTechnology
Specification
ImplementationTechnology
Specification
MessageSpecifications
July 14, 2015 Page: 56 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Health Level Seven Version 3 Reference Models
The HL7 reference models are the foundational artifacts of HL7 version 3.0.
July 14, 2015 Page: 57 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
HL7 v3.0 Foundational Artifacts
ReferenceInformation
Model
ReferenceInformation
Model
DatatypeSpecification
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.
July 14, 2015 Page: 58 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
HL7 Version 3.0 Reference Models
Reference Information ModelReference Information Model
Data TypeSpecification
Data TypeSpecification
VocabularySpecification
VocabularySpecification
July 14, 2015 Page: 59 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
HL7 v3.0 Foundational Artifacts
ReferenceInformation
Model
ReferenceInformation
Model
DatatypeSpecification
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.
July 14, 2015 Page: 60 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 61 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 62 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 63 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 64 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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]
July 14, 2015 Page: 65 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
July 14, 2015 Page: 66 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 67 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 68 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
USAM
July 14, 2015 Page: 69 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
The RIM Prior to USAM
from November 1
999
July 14, 2015 Page: 70 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
The Unified Service Action Model
July 14, 2015 Page: 71 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Observation
value : ANYinterpretationCode : SET<CE>methodCode : SET<CE>targetSiteCode : SET<CD>
SubstanceAdministration
routeCode : CEapproachSiteCode : SET<CD>doseQuantity : IVL<PQ>rateQuantity : IVL<PQ>doseCheckQuantity : SET<RTO>maxDoseQuantity : SET<RTO>
Procedure
methodCode : SET<CE>approachSiteCode : SET<CD>targetSiteCode : SET<CD>
Supply
quantity : PQexpectedUseTime : IVL<TS>
Diet
energyQuantity : PQcarbohydrateQuantity : PQ
Document
setId : IIversionNumber : INTcompletionCode : CEstorageCode : CEcopyTime : TS
Container
capacityQuantity : PQheightQuantity : PQdiameterQuantity : PQcapTypeCode : CEseparatorTypeCode : CEbarrierDeltaQuantity : PQbottomDeltaQuantity : PQ
Access
approachSiteCode : CDtargetSiteCode : CDgaugeQuantity : PQ
Device
manufacturerModelName : SCsoftwareName : SClocalRemoteControlStateCode : CEalertLevelCode : CElastCalibrationTime : TS
Employee
jobCode : CEjobTitleName : SCjobClassCode : CEsalaryTypeCode : CEsalaryQuantity : MOhazardExposureText : EDprotectiveEquipmentText : ED
LivingSubject
administrativeGenderCode : CEbirthTime : TSdeceasedInd : BLdeceasedTime : TSmultipleBirthInd : BLmultipleBirthOrderNumber : INTorganDonorInd : BL
Material
formCode : CE
LicensedEntity
recertificationTime : TSPlace
mobileInd : BLaddr : ADdirectionsText : EDpositionText : EDgpsText : ST
ManufacturedMaterial
lotNumberText : STexpirationTime : IVL<TS>stabilityTime : IVL<TS>
NonPersonLivingSubject
strainText : EDgenderStatusCode : CE
Patient
confidentialityCode : CEveryImportantPersonCode : CE
Organization
addr : BAG<AD>standardIndustryClassCode : CE
Account
name : STbalanceAmt : MOcurrencyCode : CEinterestRateQuantity : RTO<MO,PQ>allowedBalanceQuantity : IVL<MO>
Person
addr : BAG<AD>maritalStatusCode : CEeducationLevelCode : CEraceCode : SET<CE>disabilityCode : SET<CE>livingArrangementCode : CEreligiousAffiliationCode : CEethnicGroupCode : SET<CE>
WorkingList
ownershipLevelCode : CE
PublicHealthCase
detectionMethodCode : CEtransmissionModeCode : CEdiseaseImportedCode : CE
PatientEncounter
preAdmitTestInd : BLadmissionReferralSourceCode : CElengthOfStayQuantity : PQdischargeDispositionCode : CEspecialCourtesiesCode : SET<CE>specialAccommodationCode : SET<CE>acuityLevelCode : CE
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
subjectOrientationCode : CE
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
FinancialTransaction
amt : MOcreditExchangeRateQuantity : REALdebitExchangeRateQuantity : REAL
InvoiceElement
modifierCode : SET<CE>unitQuantity : RTO<PQ,PQ>unitPriceAmt : RTO<MO,PQ>netAmt : MOfactorNumber : REALpointsNumber : REAL
FinancialContract
paymentTermsCode : CE
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
parameterValue : LIST<ANY>
ManagedParticipation
id : SET<II>statusCode : SET<CS>
ActHeir
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..n1
inboundRelationship
0..n
target
10..n1
outboundRelationship
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
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..n1
0..n1
0..n1
outboundLink
0..n
source
1 0..n1
inboundLink
0..n
target
1
LanguageCommunication
languageCode : CEmodeCode : CEproficiencyLevelCode : CEpreferenceInd : BL
AttentionLine
keyWordText : SCvalue : ST
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
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
July 14, 2015 Page: 72 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Normative R6 RIM Class DiagramVersion 2.44 11/22/2013
July 14, 2015 Page: 73 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 74 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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..*
July 14, 2015 Page: 75 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Entity
classCode : CSdeterminerCode: CScode: CEstatusCode : CSid : II
Role
classCode : CScode: CEeffectiveTime : IVL<TS>statusCode : CSid : II
Act
classCode : CSmoodCode: CScode: CDstatusCode : CSeffectiveTime : GTSid : II
RIM Core Classes
0..* 0..*1 0..*plays
July 14, 2015 Page: 76 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
0..10..*
0..10..*
plays
scopes
Entity
classCode : CSdeterminerCode: CScode: CEstatusCode : CSid : II
Role
classCode : CScode: CEeffectiveTime : IVL<TS>statusCode : CSid : II
Act
classCode : CSmoodCode: CScode: CDstatusCode : CSeffectiveTime : GTSid : II
RIM Core Classes
Role – a classification/specialization of an Entity defined by the relationship of the playing Entity to a scoping Entity. An example of Role is “Employee”. An employee is a classification attributed to a person which has an employment relationship with an organization (Employer).
0..* 0..*
July 14, 2015 Page: 77 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Entity
classCode : CSdeterminerCode: CScode: CEstatusCode : CSid : II
Role
classCode : CScode: CEeffectiveTime : IVL<TS>statusCode : CSid : II
Participation
typeCode : CStime : IVL<TS>statusCode : CS
Act
classCode : CSmoodCode: CScode: CDstatusCode : CSeffectiveTime : GTSid : II
0..1
0..* 1
0..*
1
0..*
RIM Core Classes
Participation – an association between a Role and an Act representing the function assumed by the Role within the context of the Act. A single Role may participate in multiple Acts and a single Act may have multiple participating Roles. A single Participation is always an association between a particular Role and a particular Act.
0..1
0..*
plays
scopes
July 14, 2015 Page: 78 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Entity
classCode : CSdeterminerCode: CScode: CEstatusCode : CSid : II
Role
classCode : CScode: CEeffectiveTime : IVL<TS>statusCode : CSid : II
Participation
typeCode : CStime : IVL<TS>statusCode : CS
Act
classCode : CSmoodCode: CScode: CDstatusCode : CSeffectiveTime : GTSid : II
0..1
0..*1
0..*
1
0..*
Act Relationship
typeCode : CS
1 1
0..* 0..*
RIM Core Classes
Act relationship – an association between two Acts. This includes Act to Act associations such as collector/component, predecessor/successor, and cause/outcome. The semantics of the association is captured by the Act Relationship attributes.
0..1
0..*
plays
scopes
July 14, 2015 Page: 79 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Entity
classCode : CSdeterminerCode: CScode: CEstatusCode : CSid : II
Role
classCode : CScode: CEeffectiveTime : IVL<TS>statusCode : CSid : II
Participation
typeCode : CStime : IVL<TS>statusCode : CS
Act
classCode : CSmoodCode: CScode: CDstatusCode : CSeffectiveTime : GTSid : II
0..1
0..*1
0..*
1
0..*
Role Link
typeCode : CSeffectiveTime : IVL<TS>
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..*
July 14, 2015 Page: 80 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 81 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Entity
classCode : CSdeterminerCode: CScode: CEstatusCode : CSid : II
Role
classCode : CScode: CEeffectiveTime : IVL<TS>statusCode : CSid : II
Participation
typeCode : CStime : IVL<TS>statusCode : CS
Act
classCode : CSmoodCode: CScode: CDstatusCode : CSeffectiveTime : GTSid : II
0..1
0..*1
0..*
1
0..*
Role Link
typeCode : CSeffectiveTime : IVL<TS>
Act Relationship
typeCode : CS
RIM Backbone Classes
0..1
0..*
plays
scopes
1 1
0..* 0..*
1 1
0..* 0..*
July 14, 2015 Page: 82 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
RIM Backbone Classes
Entity
classCode : CSdeterminerCode: CScode: CEstatusCode : CSid : II
Role
classCode : CScode: CEeffectiveTime : IVL<TS>statusCode : CSid : II
Participation
typeCode : CStime : IVL<TS>statusCode : CS
Act
classCode : CSmoodCode: CScode: CDstatusCode : CSeffectiveTime : GTSid : II
0..1
0..*1
0..*
1
0..*
0..1
0..*
plays
scopes
July 14, 2015 Page: 83 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
RIM Backbone Classes
Entity
classCode : CSdeterminerCode: CScode: CEstatusCode : CSid : II
Role
classCode : CScode: CEeffectiveTime : IVL<TS>statusCode : CSid : II
Participation
typeCode : CStime : IVL<TS>statusCode : CS
Act
classCode : CSmoodCode: CScode: CDstatusCode : CSeffectiveTime : GTSid : II
0..1
0..*1
0..*
1
0..*
0..1
0..*
plays
scopes
Living Subject
Place
Organization
Material
Licensed Entity
Patient
Access
Employee
Managed Participation
Observation
Supply
Patient Encounter
Procedure
Device Task
Substance Administration
Financial Transaction
Invoice Element
Financial Contract
Account
Working List
Control Act
July 14, 2015 Page: 84 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
HL7 RIM Class Diagram
July 14, 2015 Page: 85 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Entity
classCode : CSdeterminerCode : CSstatusCode : CScode: CE
Role
classCode : CSeffectiveTime : IVL<TS>code: CE
Participation
typeCode : CStime : IVL<TS>statusCode : CS
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
July 14, 2015 Page: 86 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 87 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 88 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 89 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 90 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 91 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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".
July 14, 2015 Page: 92 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 93 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Entity.classCode3.2.1.1 Entity.classCode :: CS (1..1) Mandatory
Vocabulary domain: EntityClass (CNE)
Attribute description:
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.
July 14, 2015 Page: 94 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Entity.determinerCode3.2.1.2 Entity.determinerCode :: CS (1..1) Mandatory
Vocabulary domain: EntityDeterminer (CNE)
Attribute description:
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.
July 14, 2015 Page: 95 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Entity.code
3.2.1.4 Entity.code :: CE (0..1)
Vocabulary domain: EntityCode (CWE)
Attribute description:
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.
July 14, 2015 Page: 96 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Role.classCode
3.3.1.1 Role.classCode :: CS (1..1) Mandatory
Vocabulary domain: RoleClass (CNE)
Attribute description:
A code specifying the major category of a Role as defined by HL7 vocabulary.
July 14, 2015 Page: 97 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Role.code3.3.1.3 Role.code :: CE (0..1)
Vocabulary domain: RoleCode (CWE)
Attribute description:
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.
July 14, 2015 Page: 98 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
RoleLink.typeCode3.3.2.1 RoleLink.typeCode :: CS (1..1) Mandatory
Vocabulary domain: RoleLinkType (CNE)
Attribute description:
A code specifying the kind of connection represented by this RoleLink, e.g., has-part, has-authority.
July 14, 2015 Page: 99 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Accessing the RIM
http://www.hl7.org/participate/toolsandresources.cfm?ref=nav
July 14, 2015 Page: 100 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
RoseTree
July 14, 2015 Page: 101 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Model Browsing Tree - Attributes
Packages (AKA Subject Areas)
Classes
Attributes
Datatype
Datatype Components(AKA Properties)
DescriptiveText
July 14, 2015 Page: 102 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Model Browsing Tree - Relationships
Source Class (AKA Focal Class)
Relationships
Distal Class
DescriptiveText
July 14, 2015 Page: 103 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Model Browsing Tree - States
States
Transitions
DescriptiveText
July 14, 2015 Page: 104 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 105 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Entity State Machine
normal
active inactivenull
active inactivecreate
revise revise
reactivate
inactivate
nullified
nullify
July 14, 2015 Page: 106 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Role State Machine
July 14, 2015 Page: 107 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Managed Participation State Machine
normal
pending active completed
cancelled
pending active completed
null
revise revise revisecomplete
reactivate
activate
nullified
nullify
cancelled
cancel
createcreatecreate
July 14, 2015 Page: 108 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Act State Machine
July 14, 2015 Page: 109 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
HL7 RIM Class Diagram
July 14, 2015 Page: 110 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 111 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 112 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
HL7 v3.0 Foundational Artifacts
ReferenceInformation
Model
ReferenceInformation
Model
DatatypeSpecification
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.
July 14, 2015 Page: 113 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
HL7 v3.0 Foundational Artifacts
ReferenceInformation
Model
ReferenceInformation
Model
DatatypeSpecification
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.
July 14, 2015 Page: 114 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 115 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 116 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 117 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Datatype Class Diagram
T
Sequence : LIST
T
Set : SET
T
Bag : BAG
Quantity : QTY
IntegerNumber : INT
RealNumber : REAL
PhysicalQuantity : PQ
MonetaryAmount : MO
Ratio : RTO
PointInTime : TS
Boolean : BL
CharacterString : ST
ConceptDescriptor : CD
CodedValue : CV
InstanceIdentifier : II
TelecommunicationAddress : TEL
T
Interval : IVL
DataValue : ANY
BinaryData : BIN
List_of_Boolean : LIST<BL>
<<extends>>
EncapsulatedData : ED
<<extends>>
ConceptRole : CR
CodedSimpleValue : CS
<<restricts>>
CodedWithEquivalents : CE
ISO_object_identifier : OID
List_ADXP : LIST<ADXP>
PostalAndResidentialAddress : AD
<<extends>>
AddressPart : ADXP
PersonNameType : PN
List_ENXP : LIST<ENXP>
EntityNamePart : ENXP
T
PeriodicIntervalOfTime : PIVL
T
EventRelatedPeriodicIntervalOfTime : EIVL
GeneralTimingSpecification : GTS
Set_of_TS : SET<TS>
<<extends>>
T : T
T
Annotated : ANT
T
History_item : HXIT
T
History : HIST
Set_of_HXIT : SET<HXIT<T>>
T
UncertainValueNarrative : UVN
<<extends>>
T
UncertainValueProbabilistic : UVP
T
NonParametricProbabilityDistribution : NPPD
Set_UVP : SET<UVP<T>>
T
ParametricProbabilityDistribution : PPD
UniversalResourceLocator : URL
<<extends>>
OrganizationName : ON
<<extends>>
<<extends>><<extends>>
<<extends>><<extends>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<restricts>>
<<restricts>>
<<restricts>>
<<extends>>
<<extends>>
<<extends>><<extends>>
<<extends>><<extends>>
<<extends>><<extends>>
<<extends>><<extends>>
<<restricts>>
<<extends>>
<<extends>><<extends>>
<<extends>> <<extends>>
<<extends>>
July 14, 2015 Page: 118 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 119 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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".
July 14, 2015 Page: 120 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Basic Datatype Descriptions
Name Symbol Description
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.
July 14, 2015 Page: 121 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Basic Datatype Descriptions
Name Symbol Description
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."
July 14, 2015 Page: 122 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 123 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
ST: Character String
Name Type Status Definition
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.
July 14, 2015 Page: 124 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 125 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Concept Descriptor Datatypes
Name Type Status
code ST mandatory
displayName ST optional
Name Type Status
code ST mandatory
displayName ST optional
codeSystem OID mandatory
codeSystemName ST optional
codeSystemVersion ST optional
originalText ST optional
Name Type Status
code ST mandatory
displayName ST optional
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
July 14, 2015 Page: 126 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
II: Instance Identifier
Name Type Status Definition
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.)
July 14, 2015 Page: 127 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Tel: Telecommunication Address
Name Type Status Definition
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.
July 14, 2015 Page: 128 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
AD: Postal Address
Name Type Status Definition
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.
Name Type Status Definition
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
July 14, 2015 Page: 129 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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
Name Type Status Default Constraint Definition
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
July 14, 2015 Page: 130 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
RTO: Ratio
Name Type Status Definition
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.
July 14, 2015 Page: 131 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
PQ: Physical Quantity
Name Type Status Definition
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.
July 14, 2015 Page: 132 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
MO: Monetary Amount
Name Type Status Default Constraint Definition
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
July 14, 2015 Page: 133 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 134 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
HL7 v3.0 Foundational Artifacts
ReferenceInformation
Model
ReferenceInformation
Model
DatatypeSpecification
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.
July 14, 2015 Page: 135 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
HL7 v3.0 Foundational Artifacts
ReferenceInformation
Model
ReferenceInformation
Model
DatatypeSpecification
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.
July 14, 2015 Page: 136 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 137 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 138 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 139 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
ActCode
July 14, 2015 Page: 140 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
EntityCode
July 14, 2015 Page: 141 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
RoleCode
July 14, 2015 Page: 142 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
ParticipationType
July 14, 2015 Page: 143 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 144 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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
HL7 v3.0 Messaging Artifacts
ReferenceInformation
Model
ReferenceInformation
Model
DatatypeSpecification
DatatypeSpecification
VocabularySpecificationVocabulary
Specification
FoundationalModels
(CIM)
DynamicModel
DynamicModel
ConstrainedInformation
Model
ConstrainedInformation
Model
CommonMessage Type
Model
CommonMessage Type
Model
DesignModels
(PIM)
HierarchicalMessage
Definition
HierarchicalMessage
Definition
MessageType
Definition
MessageType
Definition
ImplementationTechnology
Specification
ImplementationTechnology
Specification
MessageSpecifications
(PSM)
July 14, 2015 Page: 147 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
HL7 Version 3.0 Reference Models
Reference Information ModelReference Information Model
Data TypeSpecification
Data TypeSpecification
VocabularySpecification
VocabularySpecification
July 14, 2015 Page: 148 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
HL7 Version 3.0 Reference Models
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
T
Sequence : LIST
T
Set : SET
T
Bag : BAG
Quantity : QTY
IntegerNumber : INT
RealNumber : REAL
PhysicalQuantity : PQ
MonetaryAmount : MO
Ratio : RTO
PointInTime : TS
Boolean : BL
CharacterString : ST
ConceptDescriptor : CD
CodedValue : CV
InstanceIdentifier : II
TelecommunicationAddress : TEL
T
Interval : IVL
DataValue : ANY
BinaryData : BIN
List_of_Boolean : LIST<BL>
<<extends>>
EncapsulatedData : ED
<<extends>>
ConceptRole : CR
CodedSimpleValue : CS
<<restricts>>
CodedWithEquivalents : CE
ISO_object_identifier : OID
List_ADXP : LIST<ADXP>
PostalAndResidentialAddress : AD
<<extends>>
AddressPart : ADXP
PersonNameType : PN
List_ENXP : LIST<ENXP>
EntityNamePart : ENXP
T
PeriodicIntervalOfTime : PIVL
T
EventRelatedPeriodicIntervalOfTime : EIVL
GeneralTimingSpecification : GTS
Set_of_TS : SET<TS>
<<extends>>
T : T
T
Annotated : ANT
T
History_item : HXIT
T
History : HIST
Set_of_HXIT : SET<HXIT<T>>
T
UncertainValueNarrative : UVN
<<extends>>
T
UncertainValueProbabilistic : UVP
T
NonParametricProbabilityDistribution : NPPD
Set_UVP : SET<UVP<T>>
T
ParametricProbabilityDistribution : PPD
UniversalResourceLocator : URL
<<extends>>
OrganizationName : ON
<<extends>>
<<extends>><<extends>>
<<extends>><<extends>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<restricts>>
<<restricts>>
<<restricts>>
<<extends>>
<<extends>>
<<extends>><<extends>>
<<extends>><<extends>>
<<extends>><<extends>>
<<extends>><<extends>>
<<restricts>>
<<extends>>
<<extends>><<extends>>
<<extends>> <<extends>>
<<extends>>
July 14, 2015 Page: 149 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
HL7 v3.0 Messaging Artifacts
ReferenceInformation
Model
ReferenceInformation
Model
DatatypeSpecification
DatatypeSpecification
VocabularySpecificationVocabulary
SpecificationFoundational
Models
DynamicModel
DynamicModel
ConstrainedInformation
Model
ConstrainedInformation
Model
CommonMessage Type
Model
CommonMessage Type
Model
DesignModels
HierarchicalMessage
Definition
HierarchicalMessage
Definition
MessageType
Definition
MessageType
Definition
ImplementationTechnology
Specification
ImplementationTechnology
Specification
MessageSpecifications
July 14, 2015 Page: 150 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
HL7 v3.0 Messaging Artifacts
ReferenceInformation
Model
ReferenceInformation
Model
DatatypeSpecification
DatatypeSpecification
VocabularySpecificationVocabulary
SpecificationFoundational
Models
DynamicModel
DynamicModel
ConstrainedInformation
Model
ConstrainedInformation
Model
CommonMessage Type
Model
CommonMessage Type
Model
DesignModels
HierarchicalMessage
Definition
HierarchicalMessage
Definition
MessageType
Definition
MessageType
Definition
ImplementationTechnology
Specification
ImplementationTechnology
Specification
MessageSpecifications
July 14, 2015 Page: 151 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
HL7 v3.0 Messaging Artifacts
ReferenceInformation
Model
ReferenceInformation
Model
DatatypeSpecification
DatatypeSpecification
VocabularySpecificationVocabulary
SpecificationFoundational
Models
DynamicModel
DynamicModel
ConstrainedInformation
Model
ConstrainedInformation
Model
CommonMessage Type
Model
CommonMessage Type
Model
DesignModels
HierarchicalMessage
Definition
HierarchicalMessage
Definition
MessageType
Definition
MessageType
Definition
ImplementationTechnology
Specification
ImplementationTechnology
Specification
MessageSpecifications
July 14, 2015 Page: 152 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 154 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 155 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Dynam
ic M
odel
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
July 14, 2015 Page: 156 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
v3 Dynamic Model
Example
Storyboard
StoryboardExample
ApplicationRole
Sender Receiver
TriggerEvent
Triggers
Interaction
References
July 14, 2015 Page: 157 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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
::TriggerEventartifactIDnamedescriptiontypestructuredName
UserRequestBasedTriggerEvent
::TriggerEventartifactIDnamedescriptiontypestructuredName
«ConstrainedInformationMod...StaticModel
artifactIDnametype
ReceiverResponsibility
reason
«SoftwareUnit»Application
ConformanceStatement
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
July 14, 2015 Page: 158 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 159 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
An example Interaction Diagram
Application Roles
Interactions
July 14, 2015 Page: 160 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
v3 Dynamic Model
Example
Storyboard
StoryboardExample
ApplicationRole
Sender Receiver
TriggerEvent
Triggers
Interaction
References
July 14, 2015 Page: 161 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
v3 Dynamic Model - Interaction
Example
Storyboard
StoryboardExample
ApplicationRole
Sender Receiver
TriggerEvent
Triggers
Interaction
References
July 14, 2015 Page: 162 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 163 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Example Interaction Specification
July 14, 2015 Page: 164 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Example Interaction w/Receiver Responsibilities
July 14, 2015 Page: 165 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
An example Interaction Diagram
July 14, 2015 Page: 166 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
v3 Dynamic Model
Example
Storyboard
StoryboardExample
ApplicationRole
Sender Receiver
TriggerEvent
Triggers
Interaction
References
July 14, 2015 Page: 167 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
v3 Dynamic Model - Storyboard
Example
Storyboard
StoryboardExample
ApplicationRole
Sender Receiver
TriggerEvent
Triggers
Interaction
References
July 14, 2015 Page: 168 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 169 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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).
July 14, 2015 Page: 170 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
v3 Dynamic Model
Example
Storyboard
StoryboardExample
ApplicationRole
Sender Receiver
TriggerEvent
Triggers
Interaction
References
July 14, 2015 Page: 171 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
v3 Dynamic Model – Application Role
Example
Storyboard
StoryboardExample
ApplicationRole
Sender Receiver
TriggerEvent
Triggers
Interaction
References
July 14, 2015 Page: 172 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 173 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Example Application Roles
July 14, 2015 Page: 174 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 175 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 176 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
An example Interaction Diagram
July 14, 2015 Page: 177 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Receiver Responsibility
July 14, 2015 Page: 178 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
v3 Dynamic Model
Example
Storyboard
StoryboardExample
ApplicationRole
Sender Receiver
TriggerEvent
Triggers
Interaction
References
July 14, 2015 Page: 179 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
v3 Dynamic Model – Trigger Event
Example
Storyboard
StoryboardExample
ApplicationRole
Sender Receiver
TriggerEvent
Triggers
Interaction
References
July 14, 2015 Page: 180 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 181 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Example Trigger Event
July 14, 2015 Page: 182 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 183 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Act State Machine
July 14, 2015 Page: 184 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 185 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 187 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
v3 Dynamic Model
Example
Storyboard
StoryboardExample
ApplicationRole
Sender Receiver
TriggerEvent
Triggers
Interaction
References
July 14, 2015 Page: 188 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 189 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Sta
tic
Model
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
July 14, 2015 Page: 190 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Sta
tic
Model
v3 Dynamic Model - Message Type
MessageType
Example
Storyboard
StoryboardExample
ApplicationRole
Sender Receiver
TriggerEvent
Triggers
Content
Interaction
References
July 14, 2015 Page: 191 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Example Interaction
July 14, 2015 Page: 192 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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
CompositeMessageStructure
TriggerEvent
Interaction
ReceiverResponsibility
ApplicationRole
InterfaceHealthcareApplication
ConformanceSpecification
July 14, 2015 Page: 193 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
v3 Dynamic Model – Composite Message Structure
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
CompositeMessageStructure
TriggerEvent
Interaction
ReceiverResponsibility
ApplicationRole
InterfaceHealthcareApplication
ConformanceSpecification
July 14, 2015 Page: 194 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
v3 Dynamic Model – Composite Message Structure
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
Control Message Type
Content Message Type
Content Message Type
July 14, 2015 Page: 195 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 196 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Transport Message Type
Optional Elements: SecurityText VersionCode ProfileId SequenceNumber AttachmentText RespondTo AttentionLine ControlActProcess
Mandatory Elements: ID CreationTime InteractionId ProcessingCode ProcessingModeCode AcceptAckCode Receiver Sender
July 14, 2015 Page: 197 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
v3 Dynamic Model – Composite Message Structure
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
CompositeMessageStructure
TriggerEvent
Interaction
ReceiverResponsibility
ApplicationRole
InterfaceHealthcareApplication
ConformanceSpecification
July 14, 2015 Page: 198 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Control Message Type
The Control Message Type, also known as the control act wrapper, provides interaction metadata required to establish message context and facilitate appropriate processing by the receiving application.
It also contains data that are useful to facilitate overall message management and audit capabilities.
In some exceptional cases there is no need for such information to be included in the exchange. Therefore, the Control Message Type is an optional component of the complex message structure.
The control act wrapper in v3 is similar in function to the EVN segment in v2.
July 14, 2015 Page: 199 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Control Message Type Elements
Id Code Text EffectiveTime PriorityCode ReasonCode LanguageCode
Overseer authorOrPerformer DataEnterer InformationRecipient Subject ReasonOf
July 14, 2015 Page: 200 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
v3 Dynamic Model – Composite Message Structure
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
CompositeMessageStructure
TriggerEvent
Interaction
ReceiverResponsibility
ApplicationRole
InterfaceHealthcareApplication
ConformanceSpecification
July 14, 2015 Page: 201 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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"/>
July 14, 2015 Page: 202 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
v3 Dynamic Model – Composite Message Structure
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
CompositeMessageStructure
TriggerEvent
Interaction
ReceiverResponsibility
ApplicationRole
InterfaceHealthcareApplication
ConformanceSpecification
July 14, 2015 Page: 203 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
v3 Dynamic Model – Composite Message Structure
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
CompositeMessageStructure
TriggerEvent
Interaction
ReceiverResponsibility
ApplicationRole
InterfaceHealthcareApplication
ConformanceSpecification
July 14, 2015 Page: 204 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
v3 Dynamic Model - Message Type
MessageType
Example
Storyboard
StoryboardExample
ApplicationRole
Sender Receiver
TriggerEvent
Triggers
Content
Interaction
References
July 14, 2015 Page: 205 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
HL7 v3.0 Messaging Artifacts
ReferenceInformation
Model
ReferenceInformation
Model
DatatypeSpecification
DatatypeSpecification
VocabularySpecificationVocabulary
SpecificationFoundational
Models
DynamicModel
DynamicModel
ConstrainedInformation
Model
ConstrainedInformation
Model
CommonMessage Type
Model
CommonMessage Type
Model
DesignModels
HierarchicalMessage
Definition
HierarchicalMessage
Definition
MessageType
Definition
MessageType
Definition
ImplementationTechnology
Specification
ImplementationTechnology
Specification
MessageSpecifications
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.
July 14, 2015 Page: 207 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Sta
tic
Model
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
July 14, 2015 Page: 208 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Sta
tic
Model
V3 Static Models
RIM
Restrict
R-MIM
Serialize
HMD
Restrict
MessageType
D-MIM
Derive
July 14, 2015 Page: 209 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 210 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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 : CE
NonPersonLivingSubject
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
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)
InjuryclassCode*: <= ACTmoodCode*: <= EVNactivityTime: TS (InjuryDate)
0..1 pertinentInjury
typeCode*: <= PERT
pertinentInformation1
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*: <= SBJ
subject
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
typeCode*: <= PERT
pertinentInformation7
0..1 medicalStaff
typeCode*: <= PRF
performer
MedicalStaffclassCode*: <= PROVid: II [0..1] (MedicalStaffID)
0..1 procedureLocation
typeCode*: <= LOC
locationProcedureLocationclassCode*: <= SDLOCcode: <= RoleCode (ProcedLocateID)
PatientIncidentRelatedObservationclassCode*: <= OBSmoodCode*: <= EVNcode: <= ActCodereasonCode: CV CWE [0..1] <= ActReasonvalue: ANY [0..1]
0..* pertinentPatientIncidentRelatedObservation
typeCode*: <= PERT
pertinentInformation2
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
pertinentInformation
1..1 transferVehicle
typeCode*: <= VIA
via
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
typeCode*: <= PERT
pertinentInformation5
HospitalVisitRelatedObservationclassCode*: <= OBSmoodCode*: <= EVNcode: CV CWE <= ExternallyDefinedActCodesvalue: [0..1]
0..* pertinentHospitalVisitRelatedObservation
typeCode*: <= PERT
pertinentInformation
1..1 admittingProvider
typeCode*: <= ADM
admitter
0..1 healthCareMedicalStaffPerson
AdmittingProviderclassCode*: <= PROVid: II [0..1] (ADMITMEDICASTAFFID)code: CV CWE <= RoleCode (StaffTypeID)
0..* hospitalVisitPhysician
typeCode*: <= RESPtime: TS
responsibleParty
0..1 healthCareMedicalStaffPerson
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
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*: <= PERT
pertinentInformation
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
pertinentInformation
1..1 preHospitalVehicle
typeCode*: <= ParticipationType
participant
1..1 owningVehicleProvider
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)
InjuryclassCode*: <= ACTmoodCode*: <= EVNactivityTime: TS (InjuryDate)
0..1 pertinentInjury
typeCode*: <= PERTpertinentInformation1
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
PatientIncidentRelatedObservationclassCode*: <= OBSmoodCode*: <= EVNcode: <= ActCodereasonCode: CV CWE [0..1] <= ActReasonvalue: ANY [0..1]
0..* pertinentPatientIncidentRelatedObservation
typeCode*: <= PERT
pertinentInformation2
component
0..* patientIncidentRelatedObservation
typeCode*: <= COMP
Constrained Information Models
July 14, 2015 Page: 211 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Constrained Information Models
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.
July 14, 2015 Page: 212 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 213 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 214 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Discovery of the underlying meta-model
A_AbnormalityAssessment(COCT_RM420000UV)
Description: assessment of clinical findings, including lab test results,for indications of the presence and severity of abnormal conditions
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
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
«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
July 14, 2015 Page: 215 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
HL7 CIM Clones, Attributes, and Traversals
«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: 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
July 14, 2015 Page: 216 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
HL7 CIM Terminology and Datatype
«clone»Attribute
businessName: chardatatype: DataTypecardinality: Cardinalityconformance: Conformancecomment: AnnotationinitialValue: charinitialValueRole: ValueRolemaximumLength: int
«RIM»Attribute
name: chardatatype: DataTypecardinality: CardinalitymandatoryInclusionIndicator: booleandescription: Annotation
ControllingAttribute
constraints{datatype = CS}{cardinality = (1..1)}{conformance = Mandatory}{codingStrength = CNE}{terminologyReference = CodeSystem}
«RIM»TerminologyBinding
codingStrength: CodingStrength
«clone»TerminologyBinding
codingStrength: CodingStrength
TerminologyReference{abstract}
name: chardescription: Annotation
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
codingStrength: CodingStrength
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
July 14, 2015 Page: 217 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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)
July 14, 2015 Page: 218 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Constrained Information Models
V3 Constrained Information Models
RIM
Restrict
R-MIM
Serialize
HMD
Restrict
MessageType
D-MIM
Derive
July 14, 2015 Page: 219 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
HL7 v3.0 Messaging Artifacts
ReferenceInformation
Model
ReferenceInformation
Model
DatatypeSpecification
DatatypeSpecification
VocabularySpecificationVocabulary
SpecificationFoundational
Models
DynamicModel
DynamicModel
ConstrainedInformation
Model
ConstrainedInformation
Model
CommonMessage Type
Model
CommonMessage Type
Model
DesignModels
HierarchicalMessage
Definition
HierarchicalMessage
Definition
MessageType
Definition
MessageType
Definition
ImplementationTechnology
Specification
ImplementationTechnology
Specification
MessageSpecifications
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.
July 14, 2015 Page: 221 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 222 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 223 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 224 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
HL7 v3.0 Messaging Artifacts
ReferenceInformation
Model
ReferenceInformation
Model
DatatypeSpecification
DatatypeSpecification
VocabularySpecificationVocabulary
SpecificationFoundational
Models
DynamicModel
DynamicModel
ConstrainedInformation
Model
ConstrainedInformation
Model
CommonMessage Type
Model
CommonMessage Type
Model
DesignModels
HierarchicalMessage
Definition
HierarchicalMessage
Definition
MessageType
Definition
MessageType
Definition
ImplementationTechnology
Specification
ImplementationTechnology
Specification
MessageSpecifications
July 14, 2015 Page: 225 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
HL7 v3.0 Messaging Artifacts
ReferenceInformation
Model
ReferenceInformation
Model
DatatypeSpecification
DatatypeSpecification
VocabularySpecificationVocabulary
SpecificationFoundational
Models
DynamicModel
DynamicModel
ConstrainedInformation
Model
ConstrainedInformation
Model
CommonMessage Type
Model
CommonMessage Type
Model
DesignModels
HierarchicalMessage
Definition
HierarchicalMessage
Definition
MessageType
Definition
MessageType
Definition
ImplementationTechnology
Specification
ImplementationTechnology
Specification
MessageSpecifications
July 14, 2015 Page: 226 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
HL7 v3.0 Messaging Design Models
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
ImplementationTechnology
Specification
ImplementationTechnology
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.
July 14, 2015 Page: 228 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 229 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Hierarchical Message Definition
July 14, 2015 Page: 230 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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)
July 14, 2015 Page: 231 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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)
July 14, 2015 Page: 232 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
HMD Columns
July 14, 2015 Page: 233 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 234 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 235 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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".
July 14, 2015 Page: 236 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 237 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
HL7 v3.0 Messaging Artifacts
ReferenceInformation
Model
ReferenceInformation
Model
DatatypeSpecification
DatatypeSpecification
VocabularySpecificationVocabulary
SpecificationFoundational
Models
DynamicModel
DynamicModel
ConstrainedInformation
Model
ConstrainedInformation
Model
CommonMessage Type
Model
CommonMessage Type
Model
DesignModels
HierarchicalMessage
Definition
HierarchicalMessage
Definition
MessageType
Definition
MessageType
Definition
ImplementationTechnology
Specification
ImplementationTechnology
Specification
MessageSpecifications
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.
July 14, 2015 Page: 239 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 240 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
HL7 v3.0 Messaging Artifacts
ReferenceInformation
Model
ReferenceInformation
Model
DatatypeSpecification
DatatypeSpecification
VocabularySpecificationVocabulary
SpecificationFoundational
Models
DynamicModel
DynamicModel
ConstrainedInformation
Model
ConstrainedInformation
Model
CommonMessage Type
Model
CommonMessage Type
Model
DesignModels
HierarchicalMessage
Definition
HierarchicalMessage
Definition
MessageType
Definition
MessageType
Definition
ImplementationTechnology
Specification
ImplementationTechnology
Specification
MessageSpecifications
ImplementationTechnology SpecificationThe Implementation Technology
Specification, or ITS, defines how to represent RIM objects for transmission in messages.
July 14, 2015 Page: 242 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 243 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
XML Implementation Technology Specification
July 14, 2015 Page: 244 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 245 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
HL7 XML Schema Generator
HL7 Vocabulary Specification
HL7 Data Type Specification
HL7 XML Schema
Generator
Hierarchical MessageDefinition
XML SchemaSpecification
July 14, 2015 Page: 246 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
HL7 v3.0 Messaging Artifacts
ReferenceInformation
Model
ReferenceInformation
Model
DatatypeSpecification
DatatypeSpecification
VocabularySpecificationVocabulary
SpecificationFoundational
Models
DynamicModel
DynamicModel
ConstrainedInformation
Model
ConstrainedInformation
Model
CommonMessage Type
Model
CommonMessage Type
Model
DesignModels
HierarchicalMessage
Definition
HierarchicalMessage
Definition
MessageType
Definition
MessageType
Definition
ImplementationTechnology
Specification
ImplementationTechnology
Specification
MessageSpecifications
HL7 V3 Message Specification Design Example
Pharmacy OTC Sales Data
July 14, 2015 Page: 248 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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 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
July 14, 2015 Page: 249 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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 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
July 14, 2015 Page: 250 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 251 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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
pertinentInformation
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
pertinentInformation
PromotionclassCode *: <= CONDmoodCode *: <= EVNvalue*: BL [1..1] (PromotionIndicator)
July 14, 2015 Page: 252 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 253 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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>
July 14, 2015 Page: 254 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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>
July 14, 2015 Page: 255 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
HL7 V3 Modeling Tools
July 14, 2015 Page: 256 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
HL7 V3 Modeling Tools
RationalRose
RationalRose
ReferenceModel
Repository
RoseTreeRoseTree
R-MIMDesigner
R-MIMDesigner
SchemaGenerator
SchemaGenerator
RIM RIM
R-MIMRIMR-MIM
HMD HMD
XSD
July 14, 2015 Page: 257 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
V3 RMIM Design Tool
July 14, 2015 Page: 258 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
MS-Visio R-MIM Designer
July 14, 2015 Page: 259 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
HL7 R-MIM Designer Stencil
July 14, 2015 Page: 260 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
IDPH-TRE R-MIM
July 14, 2015 Page: 261 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Clone Properties
July 14, 2015 Page: 262 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Attribute Properties
July 14, 2015 Page: 263 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Save RMIM to MIF Repository
July 14, 2015 Page: 264 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
V3 RoseTree (Model Browser)
July 14, 2015 Page: 265 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
RoseTree RMIM Browser
July 14, 2015 Page: 266 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
RoseTree HMD Generator
July 14, 2015 Page: 267 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Generated HMD
July 14, 2015 Page: 268 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Multiple Message Types
July 14, 2015 Page: 269 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
RoseTree HMD Export
July 14, 2015 Page: 270 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
MS-Excel HMD
July 14, 2015 Page: 271 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
V3 Schema Generator
July 14, 2015 Page: 272 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
HL7 XML Schema Generator
HL7 Vocabulary Specification
HL7 Data Type Specification
HL7 XML Schema
Generator
Hierarchical MessageDefinition
XML SchemaSpecification
July 14, 2015 Page: 273 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
HL7 V3 Modeling Tools
RationalRose
RationalRose
ReferenceModel
Repository
RoseTreeRoseTree
R-MIMDesigner
R-MIMDesigner
SchemaGenerator
SchemaGenerator
RIM RIM
R-MIMRIMR-MIM
HMD HMD
XSD
R-MIM
July 14, 2015 Page: 274 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
HL7 XML Schema Generator
HL7 Vocabulary Specification
HL7 Data Type Specification
HL7 XML Schema
Generator
XML SchemaSpecification
Refined Message Information ModelHierarchical Message
Definition
HL7 V3 Message Specification Core Schema
July 14, 2015 Page: 276 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 277 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
InfrastructureRoot.xsd
July 14, 2015 Page: 278 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Datatype.xsd
July 14, 2015 Page: 279 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Datatype-base.xsd
July 14, 2015 Page: 280 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Voc.xsd
July 14, 2015 Page: 281 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Core Schema
OurSchema
InfrastructureRoot.XSD
Datatype.XSD
Datatype-base.XSD
Voc.XSD
Include Include
Include Include Include
Include
Core Schema
July 14, 2015 Page: 282 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
HL7 XML Schema Generator
HL7 Vocabulary Specification
HL7 Data Type Specification
HL7 XML Schema
Generator
XML SchemaSpecification
Refined Message Information Model
Datatype.XSD
Voc.XSD
July 14, 2015 Page: 283 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
HL7 V3 Modeling Tools
RationalRose
RationalRose
ReferenceModel
Repository
RoseTreeRoseTree
R-MIMDesigner
R-MIMDesigner
SchemaGenerator
SchemaGenerator
RIM RIM
R-MIMRIMR-MIM
HMD HMD
XSD
R-MIM
July 14, 2015 Page: 284 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
V3 Design Tools
July 14, 2015 Page: 285 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Electronic Services and Tools Workgroup
July 14, 2015 Page: 286 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
SESSION OVERVIEW
Messaging Artifacts ECCF Foundational Artifacts Design Artifacts Specification Artifacts
HL7 v3 Message Design Example HL7 v3 Development Tools
July 14, 2015 Page: 287 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Hi3 Solutions 3500 W. Olive Ave, Suite
300Burbank, CA 91505
ww.hi3solutions.com +1 800 918-6520
July 14, 2015 Page: 288 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
History, Rationale, and Future
HL7 v3 Clinical Document Architecture
July 14, 2015 Page: 289 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 290 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 291 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 292 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 293 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 294 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 295 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
CDA SPECIFICATION FRAMEWORK
July 14, 2015 Page: 296 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 297 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Clinical Document Architecture RMIM
Clinical Document
Participating Entities
Structured Document Sections
Section Entries and Sub-Entries
July 14, 2015 Page: 298 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
TEMPLATED CDA AND IMPLEMENTATION GUIDES
July 14, 2015 Page: 299 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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).
July 14, 2015 Page: 300 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Segment of the CDA affected by the Age Observation template
Clinical Document
Participating Entities
Structured Document Sections
Section Entries and Sub-Entries
July 14, 2015 Page: 301 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Segment of the CDA affected by the Age Observation template
July 14, 2015 Page: 302 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 303 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 304 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 305 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
SAMPLE HL7 V3 CDA ARTIFACTS
July 14, 2015 Page: 306 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
From Data Dict. to CDA Guide
July 14, 2015 Page: 307 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
From Data Dict. to CDA Guide
July 14, 2015 Page: 308 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
From Data Dict. to CDA Guide
July 14, 2015 Page: 309 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
From Data Dict. to CDA Guide
July 14, 2015 Page: 310 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
From Data Dict. to CDA Guide
July 14, 2015 Page: 311 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Implementation Guide Development
311
July 14, 2015 Page: 312 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 313 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 314 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 315 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 316 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Organization of CIM Classes
InjuryEv entSection
+ InjuryEventSection
+ StructuredBodyInjuryEventComponent
+ InjuryEventDetailEntry
(from TraumaRegistrySubmissionDocument)
TraumaRegistrySubmissionDocument
+ HealthcareFacil i ty
+ RegistryParticipant
+ StructuredBodyComponent
+ StucturedBody
+ Submitter
+ TraumaRegistrySubmissionDocument
+ Patient
+ InjuryEventSection
+ PreHospital Encounter Section
+ Hospital Care Episode Section
+ EntryPoint
Patient
+ RecordTarget
+ Patient
+ PatientRole
+ PatientDetailSection
(from TraumaRegistrySubmissionDocument)
PreHospital Encounter Section
+ PreHospitalEncounterSection
+ StructoredBodyPreHospitalEncounterComponent
+ PreHospitalEncounterDetail
(from TraumaRegistrySubmissionDocument)
Hospital Care Episode Section
+ HospitalCareEpisodeSection
+ StructuredBodyHospitalCareEpisodeComponent
+ HospitalCareEpisodeActivityDetail
(from TraumaRegistrySubmissionDocument)
July 14, 2015 Page: 317 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 318 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
IG: Dictionary elements represented as templated CDA constraints
3
CDA RMIM
ConstrainedInformation Model
NTDBImplementation Guide
EMSImplementation Guide
318
July 14, 2015 Page: 319 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Organization of IG Templates
July 14, 2015 Page: 320 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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
PatientDetailSection
+ PatientDetailSection
+ StucturedBodyPatientDetailComponent
+ PatientDemographicObservation
+ PatientEmploymentObservation
(from Patient)
InjuryEv entSection::InjuryEv entSection PreHospital Encounter Section::PreHospitalEncounterSection
Hospital Care Episode Section::HospitalCareEpisodeSection
InjuryEv entSection
+ InjuryEventSection
+ 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
July 14, 2015 Page: 321 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 322 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Trauma Registry Data Submission IG
July 14, 2015 Page: 323 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Introduction and Specification Overview
July 14, 2015 Page: 324 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Scope
July 14, 2015 Page: 325 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Templates
July 14, 2015 Page: 326 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Document Template
July 14, 2015 Page: 327 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Section Templates
July 14, 2015 Page: 328 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Entry Templates
July 14, 2015 Page: 329 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Subentry Templates
July 14, 2015 Page: 330 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Vocabulary Tables
July 14, 2015 Page: 331 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Implementation Guide Development
July 14, 2015 Page: 332 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
From Data Dict. to CDA Impl. Guide
July 14, 2015 Page: 333 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Consolidated CDA Implementation Guide
July 14, 2015 Page: 334 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Consolidated CDA
July 14, 2015 Page: 335 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 336 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 337 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 338 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 339 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
CCD Contained Templates
July 14, 2015 Page: 340 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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).
July 14, 2015 Page: 341 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Consultation Notes Contained Templates
July 14, 2015 Page: 342 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 343 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Discharge Summary Contained Templates
July 14, 2015 Page: 344 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
14 Document Level Templates
July 14, 2015 Page: 345 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
52 Section Level Templates
July 14, 2015 Page: 346 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
88 Entry Level Templates
July 14, 2015 Page: 347 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Required and Optional Sections by Document Type
July 14, 2015 Page: 348 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
CDA Implementation Guides
July 14, 2015 Page: 349 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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)
July 14, 2015 Page: 350 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 351 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
SESSION RETROSPECTIVE
• 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
July 14, 2015 Page: 352 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Questions
July 14, 2015 Page: 353 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Hi3 Solutions 3500 W. Olive Ave, Suite
300Burbank, CA 91505
ww.hi3solutions.com +1 800 918-6520
July 14, 2015 Page: 354 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
Specification and validation
HL7 Compliance and Conformance
July 14, 2015 Page: 355 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 356 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 357 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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
PublishedSpecification
July 14, 2015 Page: 358 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
Purpose and goals for conformance profiling
July 14, 2015 Page: 359 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
Reveal Assumptions
Revealing assumptions is an essential component of effective communication.
Yes, I doplay
football.
Do youplay
football?
July 14, 2015 Page: 360 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 361 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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
MSHEVNPID [PD1][ { NK1 } ]
July 14, 2015 Page: 362 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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 [PD1][ { NK1 } ]
MSHEVNPID[ NK1 ]OBX
July 14, 2015 Page: 363 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
Consolidate Viewpoints
Message Profile Message Profile Message Profile
MSHEVNPID [PD1][ { NK1 } ]
MSHEVNPID[ NK1 ]OBX
MSHEVN{ PID } [PD1][ { GT1 } ]
MSHEVN{ PID } [PD1][ { NK1 } ][ { GT1 } ][ OBX ]
July 14, 2015 Page: 364 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
Value of Profiling
Reveal Assumptions
Reduce Ambiguity
Highlight Conflicts
Consolidate Viewpoints
July 14, 2015 Page: 365 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 366 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 367 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
HL7 v2 Conformance Profiling
July 14, 2015 Page: 368 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
Conceptual Overview
Message Profile = Static Profile + Dynamic Profile
Critical Care Unit
ADT System
Acknowledgement Message
Initiating Message
Initiating Message
Clinical Data Repository
July 14, 2015 Page: 369 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
Message conformance profile dynamic definition
July 14, 2015 Page: 370 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 371 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 372 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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
Clinical Data Repository
A/D/T System
Order Filling Application
Accept Ack
Accept + App ACK
Receiver ResponsibilityMSH-15,16
No ACK
July 14, 2015 Page: 373 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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 SIIS Analysis Report
Update Confirmation
Update Confirmation
Query Response
Vaccine Record Update
Patient Information Update
Immunization History Request
July 14, 2015 Page: 374 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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»
M.03 Immunization Data Request (VXQ)
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»
D.01 Immunization Registry
[Valid Message][Invalid Message]
[Valid Message]
[No Matching Record]
[Desired Record Not Present]
[Multiple Matching Records]
[Single Matching Record]
[Desired Record Selected]
[Invalid Message]
1
2 3
4
6
5
July 14, 2015 Page: 375 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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)
July 14, 2015 Page: 376 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
SIIS SIP Acknowledgement RequirementsMessage Source Destinat
ionAcknowledg
ment
• Vaccination Record Query (VXQ)
Requester IIES Only on error
• General Acknowledgement (ACK)
IIES Requester
Never
• Vaccination Record Query (VXQ)
IIES Responder
Never
• Query Acknowledgement (QCK) Responder IIES Only on error
• General Acknowledgement (ACK)
IIES Responder
Never
• Query Acknowledgement (QCK) IIES Requester
Never
• Vaccination Query Response (VXX)
Responder IIES Only on error
• General Acknowledgement (ACK)
IIES Responder
Never
• Vaccination Query Response (VXX)
IIES Requester
Never
• Vaccination Query Response (VXR)
Responder IIES Only on error
• General Acknowledgement (ACK)
IIES Responder
Never
• Vaccination Query Response (VXR)
IIES Requester
Never
July 14, 2015 Page: 377 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
Message conformance profile static definition
July 14, 2015 Page: 378 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 379 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 380 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
Profiling Concepts
Profile Types HL7 Standard Constrainable Implementable
Generic term ‘message element’ used Segment groups Segments Fields Components Sub-components
Cardinality Usage
July 14, 2015 Page: 381 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 382 of 521 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 14, 2015 Page: 383 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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 ‘*’)
July 14, 2015 Page: 384 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 385 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 386 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 387 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 388 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 389 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 390 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 391 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 392 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 393 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 394 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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
PV1 Patient Visit R [1..1] 3 [ PV2 ] Patient Visit - Additional
Info. RE [0..1] 3
[{ AL1 }] Allergy Information RE [0..*] 3
July 14, 2015 Page: 395 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
Message Level Profile Example 2 ADT^A01^ADT_A01 ADT Message Usage Cardinality Chapter
MSH Message Header R [1..1] 2 EVN Event Type R [1..1] 3 PID Patient Identification R [1..1] 3 [ PD1 ] Additional Demographics X [0..0] 3 [{ ROL }] Role X [0..0] 12 [{ NK1 }] Next of Kin / Associated
Parties RE [0..10] 3
PV1 Patient Visit R [1..1] 3 [ PV2 ] Patient Visit - Additional
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
July 14, 2015 Page: 396 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
Message Level Profile Example 2
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..10] 3
PV1 Patient Visit R [1..1] 3 [ PV2 ] Patient Visit - Additional
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
July 14, 2015 Page: 397 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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)
July 14, 2015 Page: 398 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 399 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 400 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 401 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 402 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
How it all ties together
Static Definition – Field Level
Vocabulary
SEQ LEN DT Usage Cardinality TBL# ITEM# ELEMENT NAM E
1 4 SI X 00104 Set ID - PID
2 20 CX RE [1..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 [1..*] 00109 Mother’s Maiden Name
7 26 TS RE 00110 Date/Tim e of Birth
8 1 IS RE 0001 00111 Sex
9 48 XPN X 00112 Patient Alias
10 80 CE X 0005 00113 Race
11 106 XAD RE [1..3] 00114 Patient Address
12 4 IS X 0289 00115 County Code
13 40 XTN RE [1..3] 00116 Phone Number - Home
14 40 XTN RE [1..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 Relig ion
18 20 CX X 00121 Patient Account Number
19 16 ST RE 00122 SSN Number - Patient
20 25 DLN X 00123 Driver's L icense Number - Patient
21 20 CX X 00124 Mother's Identifier
22 80 CE X 0189 00125 Ethnic Group
23 60 ST RE 00126 Birth Place
24 1 ID X 0136 00127 Multip le 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
: A DT S y stem : A DT Notifi ca tion Recip ient
A DT^A 01
A CK ^A 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
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
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^A013.2 ACK^A01
4 Static Definition: - Message Level -ADT/ACK (event A01)
4.1 ADT^A014.2 ACK^A01
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
July 14, 2015 Page: 403 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 404 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 405 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
Use Cases of Message Conformance Profiling
July 14, 2015 Page: 406 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
California Department of Health Services
Electronic Laboratory Reporting Project
July 14, 2015 Page: 407 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 408 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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
CanonicalMessage Profile
LaboratoryMessage Object
Model
Extract,Transform,and Load
LaboratoryDatamart
BusinessIntelligenceApplication
BusinessIntelligenceApplication
BusinessIntelligenceApplication
OutboundMessage Profile
Extract,Transform,and Load
Additional DataSources
July 14, 2015 Page: 409 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
Inbound Message Processing Outbound Message Processing
Data PersistenceBusiness Intelligence
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
CanonicalMessage Profile
LaboratoryMessage Object
Model
Extract,Transform,and Load
LaboratoryDatamart
BusinessIntelligenceApplication
BusinessIntelligenceApplication
BusinessIntelligenceApplication
OutboundMessage Profile
Extract,Transform,and Load
Additional DataSources
July 14, 2015 Page: 410 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
InboundLaboratoryMessage
InboundMessage Profile
Transform
Translate
InboundMessage Mapping
CanonicalLaboratoryMessage
CanonicalMessage Profile
Transform
Translate
OutboundMessage Mapping
OutboundLaboratoryMessage
Outbound
Lab MessageSupplier
Lab MessageConsumer
KnowledgeManagement
Service
KnowledgeManagement
Service
Object GraphGeneration
LaboratoryMessageObjects
ObjectRelationalMapping
LaboratoryMessage
Repository
Object RelationalMap
ELR DatabaseDesign Model
CA Public HealthLogical Data
Model
HL7 RIM &CDC PHLDM
CanonicalMessage Profile
LaboratoryMessage Object
Model
Extract,Transform,and Load
LaboratoryDatamart
BusinessIntelligenceApplication
BusinessIntelligenceApplication
BusinessIntelligenceApplication
Message Profile
Extract,Transform,and Load
Additional DataSources
July 14, 2015 Page: 411 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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
InboundLaboratoryMessage
InboundMessage Profile
Transform
Translate
InboundMessage Mapping
CanonicalLaboratoryMessage
CanonicalMessage Profile
Transform
Translate
OutboundMessage Mapping
OutboundLaboratoryMessage
OutboundMessage Profile
July 14, 2015 Page: 412 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
California State Immunization Information System
System Interface Project
July 14, 2015 Page: 413 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 414 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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)
July 14, 2015 Page: 415 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 416 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 417 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 418 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 419 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 420 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 421 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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
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
July 14, 2015 Page: 422 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 423 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 424 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
SIIS SIP Logical Data Model
cd Logical Model Patient Demographics
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)
PersonTelecommunicationAddress
*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..*
(personIdNumber = idNumber)
1
0..*
(administeringProvideridNumber = idNumber)
1
0..*
(personIdNumber = idNumber)
1
0..*
(personIdNumber = idNumber)
1
0..*
(vaccineAdministrationIdNumber = idNumber)
1
0..*
normally receivescare at
1
0..*
(FacilityIdNumber = idNumber)
1
0..*
(patientIdNumber =idNumber)
1
July 14, 2015 Page: 425 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 426 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 427 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 428 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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 SIIS Analysis Report
Update Confirmation
Update Confirmation
Query Response
Vaccine Record Update
Patient Information Update
Immunization History Request
July 14, 2015 Page: 429 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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»
M.03 Immunization Data Request (VXQ)
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»
D.01 Immunization Registry
[Valid Message][Invalid Message]
[Valid Message]
[No Matching Record]
[Desired Record Not Present]
[Multiple Matching Records]
[Single Matching Record]
[Desired Record Selected]
[Invalid Message]
1
2 3
4
6
5
July 14, 2015 Page: 430 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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)
July 14, 2015 Page: 431 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
SIIS SIP Acknowledgement Requirements
Message Source Destination
Acknowledgment
• Vaccination Record Query (VXQ)
Requester IIES Only on error
• General Acknowledgement (ACK)
IIES Requester
Never
• Vaccination Record Query (VXQ)
IIES Responder
Never
• Query Acknowledgement (QCK) Responder IIES Only on error
• General Acknowledgement (ACK)
IIES Responder
Never
• Query Acknowledgement (QCK) IIES Requester
Never
• Vaccination Query Response (VXX)
Responder IIES Only on error
• General Acknowledgement (ACK)
IIES Responder
Never
• Vaccination Query Response (VXX)
IIES Requester
Never
• Vaccination Query Response (VXR)
Responder IIES Only on error
• General Acknowledgement (ACK)
IIES Responder
Never
• Vaccination Query Response (VXR)
IIES Requester
Never
July 14, 2015 Page: 432 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 433 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 434 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 435 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 436 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 437 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
Conformance Validation
July 14, 2015 Page: 438 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
Conformance Profile Authoring Tools
Message Workbench (MWB)
Model Driven Health Tools (MDHT)
ART-DECOR
Trifolia Workbench
MS Word
July 14, 2015 Page: 439 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
Messaging Workbench
July 14, 2015 Page: 440 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 441 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
Model Driven Health Tools (MDHT) is an open source framework that enables community authoring.
July 14, 2015 Page: 442 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
July 14, 2015 Page: 443 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 444 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
July 14, 2015 Page: 445 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
Trifolia Workbench
July 14, 2015 Page: 446 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
Instance Validation Technologies
HL7 v2 Schema Specification
MWB Profile Validation
CDA Schema Specification
MDHT Generated Java Objects
Trifolia Generated Schematron Logic
July 14, 2015 Page: 447 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 448 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
NIST Standards and Testing
July 14, 2015 Page: 449 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
NIST CDA Guideline Validation
July 14, 2015 Page: 450 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
SMART C-CDA Collaborative
July 14, 2015 Page: 451 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
CDC PHIN MQF
July 14, 2015 Page: 452 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
Lantana Consulting Group CDA Validator
July 14, 2015 Page: 453 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
IHE Gazelle HL7 Validator
July 14, 2015 Page: 454 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
Instance Validation Commercial Products
Middleware Vendor Products
Interface Engine Product Adapters
Hi3 Solutions Standards Conformance
Validator
July 14, 2015 Page: 455 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Middleware Vendor Products
July 14, 2015 Page: 456 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 457 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
PHIN Messaging System
July 14, 2015 Page: 458 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
Caristix HL7 Message Profiler
July 14, 2015 Page: 459 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
Hi3 Solutions Standards Conformance Validator
July 14, 2015 Page: 460 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
Healthcare Information Integration Infrastructure
Healthcare Quality and Performance Monitoring
Health Information Integration
Health Information Transformation
Health Information Standards Compliance
InboundInformationProcessing
InboundInformationProcessing
Standard Compliance andConformance Validation
Standard Compliance andConformance Validation
OutboundInformationProcessing
OutboundInformationProcessing
SourceInformation System
SourceInformation System Receiving
Information SystemReceiving
Information System
Information Transformation
Services
Information Transformation
Services
Analysis, Visualization,and Reporting
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
July 14, 2015 Page: 461 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Health Information Standards Compliance
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.
July 14, 2015 Page: 462 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Health Information Integration
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 Integration
Health Information Transformation
InboundInformationProcessing
InboundInformationProcessing
OutboundInformationProcessing
OutboundInformationProcessing
SourceInformation System
SourceInformation System Receiving
Information SystemReceiving
Information System
Information Transformation
Services
Information Transformation
Services
Integrated Data Repository
HL7 ReferenceInformation Model
July 14, 2015 Page: 463 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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
InboundInformationProcessing
InboundInformationProcessing
SourceInformation System
SourceInformation System
Information Transformation
Services
Information Transformation
Services
Analysis, Visualization,and Reporting
Analysis, Visualization,and Reporting
Integrated Data Repository
Business Intelligence& Decision
Support Services
HL7 ReferenceInformation Model
July 14, 2015 Page: 464 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
Hi3 Solutions Product Suite
July 14, 2015 Page: 465 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 466 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
Standards Conformance Validation
July 14, 2015 Page: 467 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 468 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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)
July 14, 2015 Page: 469 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 470 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 471 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
Standards Conformance Validation
July 14, 2015 Page: 472 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
Hi3 Solutions Product Suite
July 14, 2015 Page: 473 of 521 Hi3 Solutions ~ Your healthcare standards conformance Partner
SESSION RETROSPECTIVE
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
July 14, 2015 Page: 474 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Questions
July 14, 2015 Page: 475 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Hi3 Solutions 3500 W. Olive Ave, Suite
300Burbank, CA 91505
ww.hi3solutions.com +1 800 918-6520
July 14, 2015 Page: 476 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
July 14, 2015
HL7 v3 Retrospective
July 14, 2015 Page: 477 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
HL7 Version 3 Topics
HL7 v3 History and Rationale
HL7 v3 Development Frameworks and
Architectures
HL7 v3 Messaging Artifacts
HL7 v3 Clinical Document Architecture
HL7 Standards Compliance and Profile
Conformance
July 14, 2015 Page: 478 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
HL7 V3 HISTORY AND RATIONALE
July 14, 2015 Page: 479 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
International
National
Inter-Enterprise
Enterprise
Institution
Ever-Increasing Circles
Source: Gartner
July 14, 2015 Page: 480 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 481 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
HL7 v3 Development Frameworks and Architectures
July 14, 2015 Page: 482 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
The MDF Methodology Overview
July 14, 2015 Page: 483 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 484 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 485 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
ECCF Specification Stack
ECCF SPECIFICATION
STACK
July 14, 2015 Page: 486 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
HL7 Version 3.0 Reference Models
Reference Information ModelReference Information Model
Data TypeSpecification
Data TypeSpecification
VocabularySpecification
VocabularySpecification
July 14, 2015 Page: 487 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
HL7 v3 Messaging Artifacts
July 14, 2015 Page: 488 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
HL7 v3.0 Messaging Artifacts
ReferenceInformation
Model
ReferenceInformation
Model
DatatypeSpecification
DatatypeSpecification
VocabularySpecificationVocabulary
Specification
FoundationalModels
(CIM)
DynamicModel
DynamicModel
ConstrainedInformation
Model
ConstrainedInformation
Model
CommonMessage Type
Model
CommonMessage Type
Model
DesignModels
(PIM)
HierarchicalMessage
Definition
HierarchicalMessage
Definition
MessageType
Definition
MessageType
Definition
ImplementationTechnology
Specification
ImplementationTechnology
Specification
MessageSpecifications
(PSM)
July 14, 2015 Page: 489 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
HL7 v3.0 Foundational Artifacts
ReferenceInformation
Model
ReferenceInformation
Model
DatatypeSpecification
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.
July 14, 2015 Page: 490 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Normative R6 RIM Class DiagramVersion 2.44 11/22/2013
July 14, 2015 Page: 491 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Entity
classCode : CSdeterminerCode: CScode: CEstatusCode : CSid : II
Role
classCode : CScode: CEeffectiveTime : IVL<TS>statusCode : CSid : II
Participation
typeCode : CStime : IVL<TS>statusCode : CS
Act
classCode : CSmoodCode: CScode: CDstatusCode : CSeffectiveTime : GTSid : II
0..1
0..*1
0..*
1
0..*
Role Link
typeCode : CSeffectiveTime : IVL<TS>
Act Relationship
typeCode : CS
RIM Core Classes
0..1
0..*
plays
scopes
1 1
0..* 0..*
1 1
0..* 0..*
July 14, 2015 Page: 492 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Datatype Class Diagram
T
Sequence : LIST
T
Set : SET
T
Bag : BAG
Quantity : QTY
IntegerNumber : INT
RealNumber : REAL
PhysicalQuantity : PQ
MonetaryAmount : MO
Ratio : RTO
PointInTime : TS
Boolean : BL
CharacterString : ST
ConceptDescriptor : CD
CodedValue : CV
InstanceIdentifier : II
TelecommunicationAddress : TEL
T
Interval : IVL
DataValue : ANY
BinaryData : BIN
List_of_Boolean : LIST<BL>
<<extends>>
EncapsulatedData : ED
<<extends>>
ConceptRole : CR
CodedSimpleValue : CS
<<restricts>>
CodedWithEquivalents : CE
ISO_object_identifier : OID
List_ADXP : LIST<ADXP>
PostalAndResidentialAddress : AD
<<extends>>
AddressPart : ADXP
PersonNameType : PN
List_ENXP : LIST<ENXP>
EntityNamePart : ENXP
T
PeriodicIntervalOfTime : PIVL
T
EventRelatedPeriodicIntervalOfTime : EIVL
GeneralTimingSpecification : GTS
Set_of_TS : SET<TS>
<<extends>>
T : T
T
Annotated : ANT
T
History_item : HXIT
T
History : HIST
Set_of_HXIT : SET<HXIT<T>>
T
UncertainValueNarrative : UVN
<<extends>>
T
UncertainValueProbabilistic : UVP
T
NonParametricProbabilityDistribution : NPPD
Set_UVP : SET<UVP<T>>
T
ParametricProbabilityDistribution : PPD
UniversalResourceLocator : URL
<<extends>>
OrganizationName : ON
<<extends>>
<<extends>><<extends>>
<<extends>><<extends>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<restricts>>
<<restricts>>
<<restricts>>
<<extends>>
<<extends>>
<<extends>><<extends>>
<<extends>><<extends>>
<<extends>><<extends>>
<<extends>><<extends>>
<<restricts>>
<<extends>>
<<extends>><<extends>>
<<extends>> <<extends>>
<<extends>>
July 14, 2015 Page: 493 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 494 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
HL7 Version 3.0 Reference Models
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
T
Sequence : LIST
T
Set : SET
T
Bag : BAG
Quantity : QTY
IntegerNumber : INT
RealNumber : REAL
PhysicalQuantity : PQ
MonetaryAmount : MO
Ratio : RTO
PointInTime : TS
Boolean : BL
CharacterString : ST
ConceptDescriptor : CD
CodedValue : CV
InstanceIdentifier : II
TelecommunicationAddress : TEL
T
Interval : IVL
DataValue : ANY
BinaryData : BIN
List_of_Boolean : LIST<BL>
<<extends>>
EncapsulatedData : ED
<<extends>>
ConceptRole : CR
CodedSimpleValue : CS
<<restricts>>
CodedWithEquivalents : CE
ISO_object_identifier : OID
List_ADXP : LIST<ADXP>
PostalAndResidentialAddress : AD
<<extends>>
AddressPart : ADXP
PersonNameType : PN
List_ENXP : LIST<ENXP>
EntityNamePart : ENXP
T
PeriodicIntervalOfTime : PIVL
T
EventRelatedPeriodicIntervalOfTime : EIVL
GeneralTimingSpecification : GTS
Set_of_TS : SET<TS>
<<extends>>
T : T
T
Annotated : ANT
T
History_item : HXIT
T
History : HIST
Set_of_HXIT : SET<HXIT<T>>
T
UncertainValueNarrative : UVN
<<extends>>
T
UncertainValueProbabilistic : UVP
T
NonParametricProbabilityDistribution : NPPD
Set_UVP : SET<UVP<T>>
T
ParametricProbabilityDistribution : PPD
UniversalResourceLocator : URL
<<extends>>
OrganizationName : ON
<<extends>>
<<extends>><<extends>>
<<extends>><<extends>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<restricts>>
<<restricts>>
<<restricts>>
<<extends>>
<<extends>>
<<extends>><<extends>>
<<extends>><<extends>>
<<extends>><<extends>>
<<extends>><<extends>>
<<restricts>>
<<extends>>
<<extends>><<extends>>
<<extends>> <<extends>>
<<extends>>
July 14, 2015 Page: 495 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 496 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Sta
tic
Model
Dynam
ic M
odel
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
July 14, 2015 Page: 497 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
An example Interaction Diagram
Application Roles
Interactions
July 14, 2015 Page: 498 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
An example Interaction Diagram
July 14, 2015 Page: 499 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 500 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 501 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
HL7 v3.0 Messaging Design Models
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
ImplementationTechnology
Specification
ImplementationTechnology
Specification
July 14, 2015 Page: 502 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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)
July 14, 2015 Page: 503 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
HL7 XML Schema Generator
HL7 Vocabulary Specification
HL7 Data Type Specification
HL7 XML Schema
Generator
Hierarchical MessageDefinition
XML SchemaSpecification
July 14, 2015 Page: 504 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
HL7 XML Schema Generator
HL7 Vocabulary Specification
HL7 Data Type Specification
HL7 XML Schema
Generator
XML SchemaSpecification
Refined Message Information Model
Datatype.XSD
Voc.XSD
July 14, 2015 Page: 505 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
HL7 V3 Modeling Tools
RationalRose
RationalRose
ReferenceModel
Repository
RoseTreeRoseTree
R-MIMDesigner
R-MIMDesigner
SchemaGenerator
SchemaGenerator
RIM RIM
R-MIMRIMR-MIM
HMD HMD
XSD
R-MIM
July 14, 2015 Page: 506 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
HL7 v3 Clinical DocumentArchitecture
July 14, 2015 Page: 507 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Clinical Document Architecture RMIM
Clinical Document
Participating Entities
Structured Document Sections
Section Entries and Sub-Entries
July 14, 2015 Page: 508 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Implementation Guide Development
508
July 14, 2015 Page: 509 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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.
July 14, 2015 Page: 510 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
HL7 Standards Compliance and Profile Conformance
July 14, 2015 Page: 511 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 512 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Conceptual Overview
Message Profile = Static Profile + Dynamic Profile
Critical Care Unit
ADT System
Acknowledgement Message
Initiating Message
Initiating Message
Clinical Data Repository
July 14, 2015 Page: 513 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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
Clinical Data Repository
A/D/T System
Order Filling Application
Accept Ack
Accept + App ACK
Receiver ResponsibilityMSH-15,16
No ACK
July 14, 2015 Page: 514 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 515 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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
July 14, 2015 Page: 516 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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
PV1 Patient Visit R [1..1] 3 [ PV2 ] Patient Visit - Additional
Info. RE [0..1] 3
[{ AL1 }] Allergy Information RE [0..*] 3
July 14, 2015 Page: 517 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
How it all ties together
Static Definition – Field Level
Vocabulary
SEQ LEN DT Usage Cardinality TBL# ITEM# ELEMENT NAM E
1 4 SI X 00104 Set ID - PID
2 20 CX RE [1..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 [1..*] 00109 Mother’s Maiden Name
7 26 TS RE 00110 Date/Tim e of Birth
8 1 IS RE 0001 00111 Sex
9 48 XPN X 00112 Patient Alias
10 80 CE X 0005 00113 Race
11 106 XAD RE [1..3] 00114 Patient Address
12 4 IS X 0289 00115 County Code
13 40 XTN RE [1..3] 00116 Phone Number - Home
14 40 XTN RE [1..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 Relig ion
18 20 CX X 00121 Patient Account Number
19 16 ST RE 00122 SSN Number - Patient
20 25 DLN X 00123 Driver's L icense Number - Patient
21 20 CX X 00124 Mother's Identifier
22 80 CE X 0189 00125 Ethnic Group
23 60 ST RE 00126 Birth Place
24 1 ID X 0136 00127 Multip le 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
: A DT S y stem : A DT Notifi ca tion Recip ient
A DT^A 01
A CK ^A 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
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
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^A013.2 ACK^A01
4 Static Definition: - Message Level -ADT/ACK (event A01)
4.1 ADT^A014.2 ACK^A01
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
July 14, 2015 Page: 518 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Middleware Vendor Products
July 14, 2015 Page: 519 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Health Information Standards Compliance
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.
July 14, 2015 Page: 520 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
HL7 Version 3 Topics
HL7 v3 History and Rationale
HL7 v3 Development Frameworks and
Architectures
HL7 v3 Messaging Artifacts
HL7 v3 Clinical Document Architecture
HL7 Standards Compliance and Profile
Conformance
July 14, 2015 Page: 521 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Course Topics
HL7 v2 Messaging HL7 v3 Messaging
HL7 Clinical Document
ArchitectureHL7 Family of Standards
HL7 Compliance and Conformance
July 14, 2015 Page: 522 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
Q&A
July 14, 2015 Page: 523 of 521Hi3 Solutions ~ Your healthcare standards conformance Partner
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]