Hl7 reference information model
-
Upload
abdul-malik-shakir -
Category
Technology
-
view
1.511 -
download
2
description
Transcript of Hl7 reference information model
Health Level Seven Reference Information Model
AbdulMalik Shakir
President and Chief Informatics Scientist
Your Healthcare Standards Conformance Partner
© 2014 All Rights ReservedSlide Number: 2
Health Information Integration Infrastructure
Solutions
Hi3 Solutions is a privately owned Health Information Technology vendor
headquartered in Los Angeles, California.
We provide health information technology products, education, and consulting
services that enable our clients to engage effectively in health information
exchange, health data integration, and health care quality measurement .
Our mission is to accelerate the adoption and application of standards-based
health information exchange as a mean’s of improving healthcare outcomes
and facilitating compliance with evidence-based best practices in healthcare.
© 2014 All Rights ReservedSlide Number: 3
Electronic Health Information Exchange
Pharmacies
Physicians
Testing OrganizationsLab/Images
Hospitals
Payors
Employers
County/Community Entities
Patients/ConsumersGovernmentMedicare/Medicaid
Lab results
Patient Data
Orders
Results
Images
Eligibility
Referral Process
Claim Status
Claims/Prescriptions
Referral Process
Claim/Status
Health Information
Insurance Updates
Eligibility
Medical Records
Enrollment
Mental Health
Family Planning
Medical Society
Public Health
© 2014 All Rights ReservedSlide Number: 4
Instructor
• AbdulMalik Shakir, President and Chief Informatics Scientist for Hi3 Solutions.
• I have been an active HL7 member since 1991 and I’ve made significant contributions to the development and adoption of the HL7 standard.
• I am co-chair of the HL7 Modeling and Methodology work group, former member of the HL7 Board of Directors, and an active participant in many HL7 foundation and domain expert work groups.
• I am the author of the original RIM and provided oversight for its maintenance from inception through its first publication as an ANSI and then ISO standard.
© 2014 All Rights ReservedSlide Number: 5
Session Overview
• In this tutorial participants will learn the history of the RIM, the method by which the RIM is maintained, and key characteristics of the RIM that make it the premier information model in healthcare.
• Topics Covered:– Introduction to HL7: who, what, and why
– Introduction to HL7 v3: what and why
– History of the HL7 Reference Information Model
– HL7 RIM Subjects, Core Classes, and Structural Attributes
– State Machines of RIM Core Classes
– HL7 v3 Datatypes
– HL7 v3 Vocabulary
• This tutorial will assist in preparation for the HL7 v3 Certification exam.
© 2014 All Rights ReservedSlide Number: 6
Health Level SevenWho, What, and Why
© 2014 All Rights ReservedSlide Number: 7
Health Level Seven: Who
• Health Level Seven (HL7) is a Standards Developing Organization accredited by the American National Standards Institute (ANSI).
• The mission of HL7 is to provide a comprehensive framework and related standards for the exchange, integration, storage, and retrieval of health information that support clinical practices and the management, delivery and evaluation of health services.
© 2014 All Rights ReservedSlide Number: 8
7 Application 7 Application
What does the name “HL7” stand for?
“Level Seven” refers to the highest level of the International Standards Organization’s communication model for Open Systems Interconnection - the application level.
ISO-OSI Communication Architecture Model
1 Physical 2 Data Link 3 Network 4 Transport
Communication
5 Session 6 PresentationFunction
© 2014 All Rights ReservedSlide Number: 9
Canada
NewZealand
Finland Germany
Netherlands
Japan
United States
United Kingdom
India
Taiwan
China
Czech Republic
Mexico
France
Argentina
Brazil
Australia
Denmark Greece
Ireland
Italy
SpainSwedenSwitzerland
SouthKorea
Turkey
Uruguay
Singapore
Romania
CroatiaAustriaColombiaChile
HL7 International Affiliates
© 2014 All Rights ReservedSlide Number: 10
HL7 Workgroups
1. Affiliates Council 2. Anatomic Pathology 3. Architectural Review Board 4. Arden Syntax 5. Attachments 6. Child Health 7. Clinical Context Object Workgroup 8. Clinical Decision Support 9. Clinical Genomics 10. Clinical Interoperability Council 11. Clinical Statement 12. Common Message Element Types 13. Community Based Collaborative Care14. Domain Experts Steering Division 15. Dynamic Model 16. Education 17. Electronic Health Records 18. Electronic Services 19. Emergency Care20. Financial Management 21. Foundation and Technology Steering Division 22. Generation of Anesthesia Standards23. Governance and Operations Government
Projects 24. Health Care Devices 25. Imaging Integration 26. Implementable Technology Specifications27. Implementation / Conformance
28. Infrastructure and Messaging 29. International Mentoring Committee 30. Marketing Modeling and Methodology 31. Orders and Observations 32. Outreach Committee for Clinical Research33. Patient Administration 34. Patient Care 35. Patient Safety 36. Pharmacy 37. Process Improvement 38. Project Services 39. Public Health and Emergency Response 40. Publishing 41. Regulated Clinical Research Information Management 42. RIMBAA 43. Scheduling and Logistics 44. Security 45. Services Oriented Architecture 46. Structure and Semantic Design Steering Division 47. Structured Documents 48. Technical and Support Services Steering Division 49. Technical Steering Committee 50. Templates 51. Terminfo Project 52. Tooling 53. Vocabulary
© 2014 All Rights ReservedSlide Number: 11
Data Exchange Scenario: Why
User InterfaceUser InterfaceProgram
Module
ProgramModuleDataset
Dataset
User InterfaceUser Interface Program
Module
ProgramModule Dataset
Dataset
Message Creation
Message Creation
Message Parsing
Message Parsing
A to BTransformation
A to BTransformation
Message Parsing
Message Parsing
Message Creation
Message Creation
B to ATransformation
B to ATransformation
Order Entry Application
System
Laboratory Application
System
Lab
Ord
er
Tr a
ns a
c tio
n
Order Entry Application
System
Laboratory Application
System
Lab
Res
ult
T
ran
sact
ion
© 2014 All Rights ReservedSlide Number: 12
Reaching the Limits of Application Interfaces
LabLab
Order EntryOrder Entry ADTADT
PharmacyPharmacy RadiologyRadiology
DecisionSupport
DecisionSupport
ElectronicHealth Record
ElectronicHealth Record
AdministrativeSystems
AdministrativeSystems
?
EnterpriseSystems
EnterpriseSystems
?ExternalSystems
ExternalSystems
?
© 2014 All Rights ReservedSlide Number: 13
Health Level Seven: Why
• The number of interfaces between N systems is given by the formula I = (N2-N)/2.
• Linking systems needs ?? Interfaces:
• Linking 6 systems needs as many as 15 interfaces, (62 – 6) / 2 = 15
• The benefits of using the HL7 standard increase rapidly with the number of systems involved. I = N
3 (32 - 3) / 2 = 3 2 (22 - 2) / 2 = 1 4 (42 - 4) / 2 = 6
© 2014 All Rights ReservedSlide Number: 14
Health Level Seven: WhyInterfaces Required
0
20
40
60
80
100
120
Systems
Inte
rfac
es
W/O HL7 1 3 6 10 15 21 28 36 45 55 66 78 91 105
With HL7 2 3 4 5 6 7 8 9 10 11 12 13 14 15
2 3 4 5 6 7 8 9 10 11 12 13 14 15
Tolerable Painful Intolerable
© 2014 All Rights ReservedSlide Number: 15
Divide and Conquer / Component Reuse
DATA
Next of Kin (NK1)
Insurance (IN1)
Patient Visit (PV1) Patient
Demographics (PID)
Guarantor(GT1)
NK1
IN1
PV1
PID
GT1OBR
OBX
Next of KIN(NK1)
Patient Visit(PV1)
Patient Demographics
(PID)
© 2014 All Rights ReservedSlide Number: 16
Health Level Seven Version 3.0What and Why
© 2014 All Rights ReservedSlide Number: 17
International
National
Inter-Enterprise
Enterprise
Institution
Standards in Ever-Increasing Circles
Source: Gartner
© 2014 All Rights ReservedSlide Number: 18
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.
© 2014 All Rights ReservedSlide Number: 19
Health Level Seven Version 3 Reference Models
The HL7 reference models are the foundational artifacts of HL7 version 3.0.
© 2014 All Rights ReservedSlide Number: 20
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.
© 2014 All Rights ReservedSlide Number: 21
HL7 Version 3.0 Reference Models
Reference Information ModelReference Information Model
Data TypeSpecification
Data TypeSpecification
VocabularySpecification
VocabularySpecification
© 2014 All Rights ReservedSlide Number: 22
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.
© 2014 All Rights ReservedSlide Number: 23
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.
© 2014 All Rights ReservedSlide Number: 24
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.
© 2014 All Rights ReservedSlide Number: 25
RIM Development ProcessB
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
© 2014 All Rights ReservedSlide Number: 26
Contributing Data Models• 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 AdministrationKaiser Foundation Health Plan, Inc.
One Kaiser Plaza, Oakland, CA 94612
v: (510) 271-6856 f: (510) 271-6859
Email: [email protected]
© 2014 All Rights ReservedSlide Number: 27
© 2014 All Rights ReservedSlide Number: 28
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
© 2014 All Rights ReservedSlide Number: 29
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.
© 2014 All Rights ReservedSlide Number: 30
USAM
© 2014 All Rights ReservedSlide Number: 31
The RIM Prior to USAM
from November 1
999
© 2014 All Rights ReservedSlide Number: 32
The Unified Service Action Model
© 2014 All Rights ReservedSlide Number: 33
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
© 2014 All Rights ReservedSlide Number: 34
Normative R6 RIM Class DiagramVersion 2.44 11/22/2013
Entity and Act
• Entitya physical thing or an organization/group of physical things capable of participating in Acts. This includes living subjects, organizations, material, and places.
• Acta discernible action of interest in the healthcare domain. An instance of Act is a record of that action. Acts definitions (master files), orders, plans, and performance records (events) are all represented by an instance of Act.
Entity Act
© 2014 All Rights ReservedSlide Number: 36
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..*
© 2014 All Rights ReservedSlide Number: 37
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
© 2014 All Rights ReservedSlide Number: 38
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..*
© 2014 All Rights ReservedSlide Number: 39
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
© 2014 All Rights ReservedSlide Number: 40
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
© 2014 All Rights ReservedSlide Number: 41
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
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..*
• Role Link – An association between two Roles. It is used to capture relationships that exists between Entities other than the scoping relationships. A
© 2014 All Rights ReservedSlide Number: 42
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.
© 2014 All Rights ReservedSlide Number: 43
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..*
© 2014 All Rights ReservedSlide Number: 44
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
© 2014 All Rights ReservedSlide Number: 45
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
1
0..*1
0..*
1
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
© 2014 All Rights ReservedSlide Number: 46
HL7 RIM Class Diagram
Entity
classCode : CCdeterminerCode : CSstatusCode : CScode: CE
Role
classCode : CSeffectiveTime : IVL<TS>code: CE
Participation
typeCode : CStime : IVL<TS>statusCode : CS
Act
classCode : CCmoodCode : CSstatusCode : CScode: CDeffectiveTime : GTS
0..1
0..* 1
0..*
1
0..*
0..1
0..*
plays
scopes
© 2014 All Rights ReservedSlide Number: 47
Entity
classCode : CCdeterminerCode : CSstatusCode : CScode: CE
Role
classCode : CSeffectiveTime : IVL<TS>code: CE
Participation
typeCode : CStime : IVL<TS>statusCode : CS
Act
classCode : CCmoodCode : 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
© 2014 All Rights ReservedSlide Number: 48
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.
© 2014 All Rights ReservedSlide Number: 49
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
© 2014 All Rights ReservedSlide Number: 50
Act.classCode
3.1.1.1 Act.classCode :: CS (1..1) Mandatory
Vocabulary domain: ActClass (CNE)
Attribute description:
A code specifying the major type of Act that this Act-instance represents.
Constraints:
The classCode domain is a tightly controlled vocabulary, not an external or user-defined vocabulary.
Every Act-instance must have a classCode. If the act class is not further specified, the most general Act.classCode (ACT) is used.
The Act.classCode must be a generalization of the specific Act concept (e.g., as expressed in Act.code), in other words, the Act concepts conveyed in an Act must be specializations of the Act.classCode. Especially, the classCode is not a "modifier" or the Act.code that can alter the meaning of a class code. (See Act.code for contrast.)
Name DatatypeCardinalityUsageValue Domain Coding Strength
© 2014 All Rights ReservedSlide Number: 51
Act.moodCode
3.1.1.2 Act.moodCode :: CS (1..1) Mandatory
Vocabulary 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
© 2014 All Rights ReservedSlide Number: 52
Act.code
3.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.
© 2014 All Rights ReservedSlide Number: 53
ActRelationship.typeCode
3.1.2.1 ActRelationship.typeCode :: CS (1..1) Mandatory
Vocabulary 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".
© 2014 All Rights ReservedSlide Number: 54
Participation.typeCode
3.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.
© 2014 All Rights ReservedSlide Number: 55
Entity.classCode
3.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.
© 2014 All Rights ReservedSlide Number: 56
Entity.determinerCode
3.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.
© 2014 All Rights ReservedSlide Number: 57
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.
© 2014 All Rights ReservedSlide Number: 58
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.
© 2014 All Rights ReservedSlide Number: 59
Role.code
3.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.
© 2014 All Rights ReservedSlide Number: 60
RoleLink.typeCode
3.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.
© 2014 All Rights ReservedSlide Number: 61
Accessing the RIM
http://www.hl7.org/participate/toolsandresources.cfm?ref=nav
© 2014 All Rights ReservedSlide Number: 62
RoseTree
© 2014 All Rights ReservedSlide Number: 63
Model Browsing Tree - AttributesPackages (AKA Subject Areas)
Classes
Attributes
Datatype
Datatype Components(AKA Properties)
DescriptiveText
© 2014 All Rights ReservedSlide Number: 64
Model Browsing Tree - Relationships
Source Class (AKA Focal Class)
Relationships
Distal Class
DescriptiveText
© 2014 All Rights ReservedSlide Number: 65
Model Browsing Tree - States
States
Transitions
DescriptiveText
© 2014 All Rights ReservedSlide Number: 66
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.
• When a class transitions from one state to another sometimes triggers an interactions.
© 2014 All Rights ReservedSlide Number: 67
Entity State Machine
normal
active inactivenull
active inactivecreate
revise revise
reactivate
inactivate
nullified
nullify
© 2014 All Rights ReservedSlide Number: 68
Role State Machine
© 2014 All Rights ReservedSlide Number: 69
Managed Participation State Machine
normal
pending active completed
cancelled
pending active completed
null
revise revise revisecomplete
reactivate
activate
nullified
nullify
cancelled
cancel
createcreatecreate
© 2014 All Rights ReservedSlide Number: 70
Act State Machine
© 2014 All Rights ReservedSlide Number: 71
HL7 RIM Class Diagram
© 2014 All Rights ReservedSlide Number: 72
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
© 2014 All Rights ReservedSlide Number: 73
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
© 2014 All Rights ReservedSlide Number: 74
HL7 Version 3.0 Data Type Specification
The HL7 v3 Abstract Datatype Specification defines the structural format of the data carried in an attribute and influences the set of allowable values an attribute may assume.
© 2014 All Rights ReservedSlide Number: 75
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.
© 2014 All Rights ReservedSlide Number: 76
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
© 2014 All Rights ReservedSlide Number: 77
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>>
© 2014 All Rights ReservedSlide Number: 78
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
© 2014 All Rights ReservedSlide Number: 79
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".
© 2014 All Rights ReservedSlide Number: 80
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.
© 2014 All Rights ReservedSlide Number: 81
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."
© 2014 All Rights ReservedSlide Number: 82
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.
© 2014 All Rights ReservedSlide Number: 83
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.
© 2014 All Rights ReservedSlide Number: 84
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
© 2014 All Rights ReservedSlide Number: 85
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
© 2014 All Rights ReservedSlide Number: 86
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.)
© 2014 All Rights ReservedSlide Number: 87
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.
© 2014 All Rights ReservedSlide Number: 88
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
© 2014 All Rights ReservedSlide Number: 89
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
ENXP: Entity Name Part
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.
Entity Name Specializations:TN: Trivial NamePN: Person NameON: Organization Name
© 2014 All Rights ReservedSlide Number: 90
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.
© 2014 All Rights ReservedSlide Number: 91
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.
© 2014 All Rights ReservedSlide Number: 92
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
© 2014 All Rights ReservedSlide Number: 93
Additional Datatypes and Aggregates
• 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
© 2014 All Rights ReservedSlide Number: 94
HL7 Version 3.0 Vocabulary Specification
The HL7 Vocabulary Specification defines the set of all concepts that can be taken as valid values in an instance of a coded attribute or message element.
© 2014 All Rights ReservedSlide Number: 95
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.
© 2014 All Rights ReservedSlide Number: 96
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
© 2014 All Rights ReservedSlide Number: 97
ActCode
© 2014 All Rights ReservedSlide Number: 98
EntityCode
© 2014 All Rights ReservedSlide Number: 99
RoleCode
© 2014 All Rights ReservedSlide Number: 100
ParticipationType
© 2014 All Rights ReservedSlide Number: 101
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
© 2014 All Rights ReservedSlide Number: 102
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
© 2014 All Rights ReservedSlide Number: 103
HL7 Version 3.0 Reference Models
Reference Information ModelReference Information Model
Data TypeSpecification
Data TypeSpecification
VocabularySpecification
VocabularySpecification
© 2014 All Rights ReservedSlide Number: 104
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>>
© 2014 All Rights ReservedSlide Number: 105
Questions
© 2014 All Rights ReservedSlide Number: 106
References
• Health Level Seven– http://www.hl7.org/index.cfm
• HL7 Reference Information Model– http://www.hl7.org/implement/standards/rim.cf
m?ref=common
• HL7 V3 Normative Edition– http://www.hl7.org/memonly/downloads/v3edit
ion.cfm#V32011
• HL7 Controlled Terminology Service – http://www.hl7.org/documentcenter/private/sta
ndards/CTS/R1/HL7_CTS_R1_FINAL.zip
© 2014 All Rights ReservedSlide Number: 107
Thank You
AbdulMalik ShakirPresident and Chief Informatics Scientist
Hi3 Solutions | your healthcare standards conformance partner3500 West Olive Ave, Suite # 300, Burbank, CA 91505.
Direct: +1 626 644 4491 | Toll Free: +1 800 918 6520
www.hi3solutions.com | [email protected]