Rim Based Relational Database Design Tutorial September 2008
-
Upload
abdulmalik-shakir -
Category
Technology
-
view
4.554 -
download
3
description
Transcript of Rim Based Relational Database Design Tutorial September 2008
Reference Information Model-Based Reference Information Model-Based Relational Database DesignRelational Database Design
Abdul-Malik ShakirPrincipal Consultant, Shakir Consulting
HL7 Working Group Meeting, Vancouver, BC
September 2008
September 2008 HL7 RIM-Based Database Design 2 of 115
About Me
Abdul-Malik ShakirPrincipal Consultant, Shakir Consulting, La Verne, CA
HL7 Member since 1991
• Principal Consultant with Shakir Consulting
• Chief Technical Architect with Cal2Cal Corporation
• Co-Chair of the HL7 Education Committee
• Member of the HL7 Architectural Review Board
• Member of the HL7 Public Health and Emergency Response Committee
• Member of the HL7 Regulated Clinical Research Information Management Committee
• Member of the HL7 Modeling and Methodology Committee
September 2008 HL7 RIM-Based Database Design 3 of 116
Session Outline
Part I
• Session Overview
Focus and Premises
Definitions and Axioms
• HL7 V3 Reference Models
Reference Information Model
Datatype Specification
Structural Vocabulary
Part II
• Database Design Steps
Subset Data Model
Logical Data Model
Physical Data Model
• Questions and Discussion
• Characteristics of a Useful Model
September 2008 HL7 RIM-Based Database Design 4 of 115
Session Overview – Focus and Premises
• The objective of this tutorial is to present solutions to the set of issues to be considered when designing a relational database structure based upon the HL7 Reference Information Model.
• The tutorial is primarily focused on the design process.
• The resulting example models and model fragments are merely examples and represent just one of many possible, equally valid designs.
• The premise behind this tutorial is that the relational database design effort is driven by application requirements and technical architecture constraints.
• A second premise behind the tutorial is that “all models are wrong, but some models are useful”.
• A useful relational database design model is one that fulfills predetermined application requirements and technical architecture constraints.
September 2008 HL7 RIM-Based Database Design 5 of 115
Session Overview – Definitions and Axioms
• A RIM-Based model is an information model whose content and structure is a conformant constrained view of the RIM.
• A RIM conformant model is an information model whose semantics do not contradict the semantics of the RIM.
• Models that are structurally different can still be semantically similar so that the semantics of one is not contradicted by the other.
• A RIM constrained model is an information model whose semantics do not extend the semantics of the RIM.
• The RIM may be constrained by three primary means: model element exclusion, datatype specialization, and vocabulary binding.
September 2008 HL7 RIM-Based Database Design 6 of 115
Structural Variance and Semantic Consistency
Person
- lastName: char- firstName: char- birthDate: dateTime- homePhone: char- workPhone: char
Model One Person
- name: PersonName- birthDate: dateTime- phone: PersonPhone [0..2] (list)
constraints{PersonPhone(1) is Home Phone}{PersonPhone(2) is Work Phone}
«datatype»PersonName
- lastName: char- firstName: char
«datatype»PersonPhone
- phoneKind: PhoneKind- phoneText: char
«enumeration»PhoneKind
«enum» Home Work
Model Two
Person
- birthDate: dateTime
PersonName
- personNameKind: PersonNameKind- personNameText: char
constraints{PersonNameKind is Unique}
PersonPhone
- phoneKind: PersonPhoneKind- phoneText: char
constraints{PersonPhoneKind is Unique}
«enumeration»PersonPhoneKind
«enum» Home Work
«enumeration»PersonNameKind
«enum» lastName firstName
0..2
0..2
Model Three
September 2008 HL7 RIM-Based Database Design 7 of 115
Database Design Modeling Steps
• Select a Subset of RIM Model Elements
• Resolve Inheritance Anomalies
• Specialize Attribute Datatypes
• Resolve Collection Datatypes
• Resolve Complex Datatypes
• Transform Classes into Tables
• Define Data Integrity Rules
• Assign Primary, Foreign, and Alternate Keys
• Optimize the Database Design Model
• Generate Database Definition Language
• Document Departures from the RIM
September 2008 HL7 RIM-Based Database Design 8 of 115
HL7 Version 3.0 Reference Models
The HL7 Reference Models (RIM, Datatype, and Vocabulary) are the foundation of the HL7 Version 3.0 development methodology and specifications. All HL7 v3 specifications (messages, documents, and services) are a refinement and constrained view of these foundational models.
September 2008 HL7 RIM-Based Database Design 9 of 115
HL7 v3.0 Reference Models
ReferenceInformation
Model
ReferenceInformation
Model
DatatypeSpecification
DatatypeSpecification
VocabularySpecificationVocabulary
Specification
Reference Models
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 message element.
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.
September 2008 HL7 RIM-Based Database Design 10 of 115
HL7 RIM Class Diagram
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
September 2008 HL7 RIM-Based Database Design 11 of 115
Entity
class_cd : CScd: CEdeterminer_cd : CSstatus_cd : CSid : II
Act
class_cd : CScd: CDmood_cd : CSstatus_cd : CSeffective_time : 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..*
September 2008 HL7 RIM-Based Database Design 12 of 115
Entity
class_cd : CScd: CEdeterminer_cd : CSstatus_cd : CSid : II
Role
class_cd : CScd: CEeffective_time : IVL<TS>status_cd : CSid : II
Act
class_cd : CScd: CDmood_cd : CSstatus_cd : CSeffective_time : GTSid : II
RIM Core Classes
0..* 0..*1 0..*plays
September 2008 HL7 RIM-Based Database Design 13 of 115
0..10..*
0..10..*
plays
scopes
Entity
class_cd : CScd: CEdeterminer_cd : CSstatus_cd : CSid : II
Role
class_cd : CScd: CEeffective_time : IVL<TS>status_cd : CSid : II
Act
class_cd : CScd: CDmood_cd : CSstatus_cd : CSeffective_time : 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..*
September 2008 HL7 RIM-Based Database Design 14 of 115
Entity
class_cd : CScd: CEdeterminer_cd : CSstatus_cd : CSid : II
Role
class_cd : CScd: CEeffective_time : IVL<TS>status_cd : CSid : II
Participation
type_cd : CStime : IVL<TS>status_cd : CS
Act
class_cd : CScd: CDmood_cd : CSstatus_cd : CSeffective_time : 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
September 2008 HL7 RIM-Based Database Design 15 of 115
Entity
class_cd : CScd: CEdeterminer_cd : CSstatus_cd : CSid : II
Role
class_cd : CScd: CEeffective_time : IVL<TS>status_cd : CSid : II
Participation
type_cd : CStime : IVL<TS>status_cd : CS
Act
class_cd : CScd: CDmood_cd : CSstatus_cd : CSeffective_time : GTSid : II
0..1
0..*1
0..*
1
0..*
Act Relationship
type_cd : 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
September 2008 HL7 RIM-Based Database Design 16 of 115
• Role Link – An association between two Roles. It is used to capture relationships that exists between Entities other than the scoping relationships. A
Entity
class_cd : CScd: CEdeterminer_cd : CSstatus_cd : CSid : II
Role
class_cd : CScd: CEeffective_time : IVL<TS>status_cd : CSid : II
Participation
type_cd : CStime : IVL<TS>status_cd : CS
Act
class_cd : CScd: CDmood_cd : CSstatus_cd : CSeffective_time : GTSid : II
0..1
0..*1
0..*
1
0..*
Role Link
type_cd : CSeffective_time : IVL<TS>
Act Relationship
type_cd : 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..*
September 2008 HL7 RIM-Based Database Design 17 of 115
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.
September 2008 HL7 RIM-Based Database Design 18 of 115
HL7 RIM Normative Specification
September 2008 HL7 RIM-Based Database Design 19 of 115
HL7 Version 3.0 Data Type Specification
The HL7 Datatype Specification defines the structural format of the data carried in an attribute and influences the set of allowable values an attribute may assume.
September 2008 HL7 RIM-Based Database Design 20 of 115
HL7 Version 3.0 Data Types
• HL7 data types define the structure and constrain the allowable values of attributes in the RIM.
• The HL7 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.
September 2008 HL7 RIM-Based Database Design 21 of 115
HL7 Version 3.0 Data Types
• 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
September 2008 HL7 RIM-Based Database Design 22 of 115
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>>
September 2008 HL7 RIM-Based Database Design 23 of 115
v3.0 Ballot Datatype Categories
• Basic DatatypesBoolean (BL) Character String (ST)
Concept Descriptor (CD) Encapsulated Data (ED)
Entity Name (EN) Instance Identifier (II)
Integer Number (INT) Monetary Amount (MO)
Physical Quantity (PQ) Point In Time (TS)
Postal Address (AD) Ratio (RTO)
Real Number (REAL) Telecommunication Address (TEL)
• Generic CollectionsBag (BAG) Interval (IVL)
Set (SET) Sequence (LIST)
• Generic Type ExtensionsHistory Item (HXIT)
History (HIST)
Uncertain Value - Narrative (UVN)
Uncertain Value - Probabilistic (UVP)
Non-Parametric Probability Distribution (NPPD)
Parametric Probability Distribution (PPD)
• Timing SpecificationsPeriodic Interval of Time (PIVL)
Event-Related Periodic Interval of Time (EIVL)
General Timing Specification (GTS)
GTS
SET HIST
BL ST ED
September 2008 HL7 RIM-Based Database Design 24 of 115
Basic Datatype DescriptionsName 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".
September 2008 HL7 RIM-Based Database Design 25 of 115
Basic Datatype DescriptionsName 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.
September 2008 HL7 RIM-Based Database Design 26 of 115
Basic Datatype DescriptionsName 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."
September 2008 HL7 RIM-Based Database Design 27 of 115
HL7 Data Type Packages
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
September 2008 HL7 RIM-Based Database Design 28 of 115
Demographic Datatypes
PostalAndResidentialAddress : AD
use : SET<CS>
AddressPart : ADXP
type : CS
PersonNameType : PN
EntityNamePart : ENXP
type : CSqualifier : SET<CS>use_cd : CS
OrganizationName : ON
CharacterString : ST
List_ADXP : LIST<ADXP>
<<extends>>
List_ENXP : LIST<ENXP>
<<extends>>
EntityName : EN
use_cd : CSvalid_time : IVL<TS>
TrivialName : TN
<<extends>>
<<restricts>>
<<restricts>>
<<restricts>>
<<extends>>
September 2008 HL7 RIM-Based Database Design 29 of 115
Entity Name Data Types
PersonNameType : PN
OrganizationName : ON
TrivialName : TN
DataValue : ANY
+ dataType : CodedSimpleValue+ nullFlavor : CodedSimpleValue
(from AnyDataType)
CodedSimpleValue : CS
+ code : CharacterString+ displayName : CharacterString
(from ConceptDescriptorDataTypes)
EntityNamePart : ENXP
+ type : CodedSimpleValue+ qualifier : Set<CodedSimpleValue>+ useCode : CodedSimpleValue
0..nqualifier 0..n
Set
EntityName : EN
+ useCode : CodedSimpleValue+ validTime : Interval<PointInTime>+ value : List<EntityNamePart> 1..n
value
1..n
List
Data Type Features:
• Inheritance Structure
• Structural Properties
• Relational Properties
• Operational Properties
• Constraint Properties
September 2008 HL7 RIM-Based Database Design 30 of 115
Thing Datatypes
ISO_object_identifier : OIDInstanceIdentifier : II
root : OIDextension : STassigningAuthorityName : STvalidTime : IVL<TS>
TelecommunicationAddress : TEL
use : SET<CS>validTime : GTS
CodedValue : CV
code : STcodeSystem : OIDcodeSystemName : STcodeSystemVersion : STdisplayName : SToriginalText : ST
ConceptDescriptor : CD
code : STcodeSystem : OIDcodeSystemName : STcodeSystemVersion : STdisplayName : SToriginalText : EDtranslation : SET<CD>modifier : LIST<CR>
UniversalResourceLocator : URL
scheme : CSaddress : ST
ConceptRole : CR
name : CVvalue : CDinverted : BL
CodedSimpleValue : CS
code : STdisplayName : ST
CodedWithEquivalents : CE
code : STcodeSystem : OIDcodeSystemName : STcodeSystemVersion : STdisplayName : SToriginalText : EDtranslation : SET<CV>
<<extends>>
DataValue : ANY
<<restricts>>
<<restricts>>
<<extends>> <<extends>>
<<extends>>
<<extends>>
<<extends>>
<<restricts>>
CodeRoleForControlledCategory : CCR
name : CSvalue : CS
<<Data_type>>
CodeWithCategory : CC
code : STcodeSystem : OIDmodifier : SET<CCR>codeSystemName : STcodeSystemVersion : SToriginalTest : EDtranslation : SET<CV>displayName : ST
<<Data_type>><<restricts>>
<<restricts>>
September 2008 HL7 RIM-Based Database Design 31 of 115
Concept Descriptor Data Types
CodedSimpleValue : CS
+ code : CharacterString+ displayName : CharacterString
DataValue : ANY
+ dataType : CodedSimpleValue+ nullFlavor : CodedSimpleValue
(from AnyDataType)
ConceptRole : CR
+ name : CodedSimpleValue+ value : ConceptDescriptor+ inverted : Boolean
ConceptDescriptor : CD
+ modifier : List<ConceptRole>1..n
modifier
1..n
List
CodedValue : CV
+ codeSystem : ISOObjectIdentifier+ codeSystemName : CharacterString+ codeSystemVersion : CharacterString+ originalText : CharacterString
CodedWithEquivalents : CE
+ translation : Set<CodedValue>
1..n
translation
1..n
Set
Data Type Category:
• Abstract
• Primitive
• Complex
• Computational
• Parameterized
September 2008 HL7 RIM-Based Database Design 32 of 115
Reductionist View of Concept Descriptor
ConceptDescriptor : CD
- dataType: CodedSimpleValue- nullFlavor: CodedSimpleValue- code: CharacterString- displayName: CharacterString- codeSystem: ISOObjectIdentifier- codeSystemName: CharacterString- codeSystemVersion: CharacterString- originalText: CharacterString-/ translation: CodedValue [0..*] (SET)-/ modifier: ConceptRole [0..*] (LIST)
CodedValue : CV
- dataType: CodedSimpleValue- nullFlavor: CodedSimpleValue- code: CharacterString- displayName: CharacterString- codeSystem: ISOObjectIdentifier- codeSystemName: CharacterString- codeSystemVersion: CharacterString- originalText: CharacterString
ConceptRole : CR
- dataType: CodedSimpleValue- nullFlavor: CodedSimpleValue- name: CodedSimpleValue- value: ConceptDescriptor- inverted: Boolean
+translation
0..*«SET»
+modifier 0..*
«LIST»
CodedSimpleValue : CS
+ code : CharacterString+ displayName : CharacterString
DataValue : ANY
+ dataType : CodedSimpleValue+ nullFlavor : CodedSimpleValue
(from AnyDataType)
ConceptRole : CR
+ name : CodedSimpleValue+ value : ConceptDescriptor+ inverted : Boolean
ConceptDescriptor : CD
+ modifier : List<ConceptRole>1..n
modifier
1..n
List
CodedValue : CV
+ codeSystem : ISOObjectIdentifier+ codeSystemName : CharacterString+ codeSystemVersion : CharacterString+ originalText : CharacterString
CodedWithEquivalents : CE
+ translation : Set<CodedValue>
1..n
translation
1..n
Set
September 2008 HL7 RIM-Based Database Design 33 of 115
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.
September 2008 HL7 RIM-Based Database Design 34 of 115
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.
• A context expression provides a means of designating which value sets within 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.
September 2008 HL7 RIM-Based Database Design 35 of 115
HL7 V3 Vocabulary Specification Schematic
ParentConcept
VocabularyDomain
name : Stringdescription : String
CodedConcept
conceptCode : StringconceptDesignation : String
0..*0..*
0..*0..*
ValueSet
name : Stringdescription : StringdefiningExpression : String
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
September 2008 HL7 RIM-Based Database Design 36 of 115
Vocabulary Metamodel Description
• A vocabulary domain has a unique name and a description and is associated with zero, one, or more value sets.
• If a vocabulary domain is associated with more than one value set, a value set context is used to specify the context under which each value set is relevant.
• A value set is associated with zero, one, or more vocabulary domain. It has a name and description. A value set is a collection of coded concepts from one or more code systems.
• The coded concepts included in a value set are drawn from a single coding system according to a defining expression. A value set’s defining expression defines what subset, projection, or partition of the code system concepts are within the scope of the value set.
• The context expression describes the constraints, if any, governing the use of the value sets. Constraints include restrictions on jurisdictions, medical specialties, time periods, and other factors that together describe the context for which the value set is relevant.
• Coded concepts have a concept code as assigned by the coding system and a concept designation. The coded concept designation is the name of the coded concept.
• HL7 allows multiple designations for a coded concept, primarily to accommodate multiple languages.
• A coded concept may be the parent concept of a collection of additional coded concepts. The parent concept is a generalization of the child concepts it collects. The parent concepts and its child concepts are part of the same value set.
September 2008 HL7 RIM-Based Database Design 37 of 115
HL7 Vocabulary TableLvl Type, Domain name and/ or Mnemonic code Concept ID Mnemonic Print Name
1 S: ActClassRoot (ACT) 13856 ACT act
2 S: ActClassContract (CNTRCT) 14002 CNTRCT contract
3 S: ActClassFinancialContract (FCNTRCT) 14003 FCNTRCT financial contract
4 L: (COV) 14004 COV coverage
2 S: ActClassControlAct (CACT) 11534 CACT control act
3 L: (ACTN) 18952 ACTN action
3 L: (INFO) 18953 INFO information
3 L: (STC) 18954 STC state transition control
2 S: ActClassObservation (OBS) 11529 OBS observation
3 S: ActClassObservationSeries (OBSSER) 18875 OBSSER observation series
4 L: (OBSCOR) 18876 OBSCOR correlated observation sequences
3 S: ActClassPublicHealthCase (CASE) 11530 CASE public health case
4 L: (OUTB) 11531 OUTB outbreak
3 A: ActClassROI 17893
4 L: (ROIBND) 17895 ROIBND bounded ROI
4 L: (ROIOVL) 16392 ROIOVL overlay ROI
3 L: (ALRT) 16123 ALRT alert
3 L: (CLNTRL) 18972 CLNTRL clinical trial
3 L: (CNOD) 18863 CNOD condition node
3 L: (COND) 18862 COND condition
3 L: (DGIMG) 13921 DGIMG diagnostic image
3 L: (MPROT) 16230 MPROT monitoring program
3 L: (SPCOBS) 13949 SPCOBS specimen observation
2 S: ActClassSupply (SPLY) 11535 SPLY supply
3 L: (DIET) 16109 DIET diet
September 2008 HL7 RIM-Based Database Design 38 of 115
HL7 Reference to External Code Systems
Domain name for External ReferenceConcept
IDSource
TerminologyDefining expression
CountryCode 10873 ISO 3166-1 ALLCountryCodeAlpha2 10874 ISO 3166-1 WHERE part = Part1, alpha-2CountryCodeAlpha3 10875 ISO 3166-1 WHERE part = Part1, alpha-3CountryCodeNumeric3 10876 ISO 3166-1 WHERE part = Part1, numeric-3DiagnosisICD9CM 15931 I9C AllDocumentSectionType 10871 LN WHERE class = doc.sectionDocumentType 10870 LN WHERE class = doc.typeECGAnnotationTypeMDC 19335 MDC MDC, restricted to ECG category namesECGBeatTypeMDC 19337 MDC MDC, restricted to ECG Beat TypesECGContourObservationTypeMDC 19341 MDC MDC, restricted to ECG Observation TypesECGControlVariableMDC 19336 MDC MDC, restricted to ECG Control VariablesECGLeadTypeMDC 19334 MDC MDC restricted to ECG Lead TypesECGNoiseTypeMDC 19340 MDC MDC, restricted to ECG Noise TypesECGRhythmTypeMDC 19339 MDC MDC, restricted to ECG Rhythm TypesECGWaveComponentTypeMDC 19338 MDC MDC, restricted to ECG Waveform Component TypesEmploymentStatusUB92 15930 NUBC-UB92 Form Locator 64: Employment Status Code of the InsuredEncounterDischargeDisposition 15928 NUBC-UB92 Form Locator 22:Patient StatusHumanLanguage 11526 IETF RFC 1766 Entire domainIndustryClassificationSystem 16039 NAICS Entire domainLogicalObservationIdentifierNamesAndCodes 16492 LOINC Entire domainMaritalStatusUB92 15929 NUBC-UB92 Form Locator 16:Patient Marital Status
September 2008 HL7 RIM-Based Database Design 39 of 115
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
September 2008 HL7 RIM-Based Database Design 40 of 115
Normative RIM Structural Vocabulary
• ActClass
• ActStatus
• ParticipationType
• ActMood
• ContextControl
• RelationshipConjunction
• ActRelationshipCheckpoint
• EntityClass
• RoleClass
• ActRelationshipJoin
• EntityDeterminer
• RoleLinkType
• ActRelationshipSplit
• EntityStatus RoleStatus
• ActRelationshipType
• ManagedParticipationStatus
September 2008 HL7 RIM-Based Database Design 41 of 115
Entity.classCode
Lvl Type, Domain name and/ or Mnemonic code Concept I D Mnemonic Print Name
1 S: EntityClassRoot (ENT) 13922 ENT entity
2 A: EntityClassDocumentReceiving 16754
3 A: EntityClassPersonOrOrgReceiving 16756
4 S: EntityClassOrganization (ORG) 10889 ORG organization
5 L: (PUB) 10891 PUB public institution
5 L: (STATE) 10890 STATE state
4 L: (PSN) 10887 PSN person
3 L: (HCE) 16755 HCE health chart entity
2 S: EntityClassLivingSubject (LIV) 10884 LIV living subject
3 S: EntityClassNonPersonLivingSubject (NLIV) 11621 NLIV non-person living subject
4 L: (ANM) 10885 ANM animal
4 L: (MIC) 14028 MIC microorganism
4 L: (PLNT) 10886 PLNT plant
3 L: (PSN) 10887 PSN person
2 S: EntityClassMaterial (MAT) 10883 MAT material
3 S: EntityClassManufacturedMaterial (MMAT) 13934 MMAT manufactured material
4 S: EntityClassContainer (CONT) 11622 CONT container
5 L: (HOLD) 14029 HOLD holder
4 S: EntityClassDevice (DEV) 11623 DEV device
5 L: (CER) 16098 CER certificate representation
5 L: (MODDV) 13939 MODDV imaging modality
3 L: (CHEM) 10888 CHEM chemical substance
3 L: (FOOD) 14027 FOOD food
EntityClass Classifies the Entity class and all of its subclasses. The terminology is hierarchical. At the top is this HL7-defined domain of high-level categories (such as represented by the Entity subclasses). Each of these terms must be harmonized and is specializable. The value sets beneath are drawn from multiple, frequently external, domains that reflect much more fine-grained typing.This table controls values for structural elements of the HL7 Reference Information Model. Therefore, it is part of the Normative Ballot for the RIM.
September 2008 HL7 RIM-Based Database Design 42 of 115
Database Design Modeling Steps
• Select a Subset of RIM Model Elements
• Resolve Inheritance Anomalies
• Specialize Attribute Datatypes
• Resolve Collection Datatypes
• Resolve Complex Datatypes
• Transform Classes into Tables
• Define Data Integrity Rules
• Assign Primary, Foreign, and Alternate Keys
• Optimize the Database Design Model
• Generate Database Definition Language
• Document Departures from the RIM
September 2008 HL7 RIM-Based Database Design 43 of 115
Select a Subset of RIM Model Elements
• Inputs:
Project Scope
Information Needs
HL7 v3 RIM
• Outputs:
RIM Subset Model
• Process:
Select in-scope classes
Select in-scope attributes
Select in-scope relationships
• This activity involves reviewing the project scope and information needs to identify the RIM model elements of interest.
• Select the relevant classes, attributes, and relationships for the project.
• This subset becomes the starting point for the design.
• The subset definition rationale should also be documented.
September 2008 HL7 RIM-Based Database Design 44 of 115
Example Project
• Project Scope
Construct a RIM-based relational database structure to persist the data content of immunization related messages used in the California Statewide Immunization Information System (SIIS) System Integration Project (SIP)
• Information Needs
The information needs of the SIIS SIP immunization database are documented in the SIIS SIP Message Profile and SIIS SIP Logical Data Model
September 2008 HL7 RIM-Based Database Design 45 of 115
SIIS SIP Logical Data Modelclass 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(providerOrganizationIdNumber)
«PK»+ PK_Facility(idNumber)
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(facilityIdNumber)
«PK»+ PK_Patient(idNumber)
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(personIdNumber)
«PK»+ PK_PersonPostalAddress(idNumber)
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(personIdNumber)
Person
*PK idNumber: int surname: char(50) givenName: char(30) middleName: char(30) nameSuffix: char(20)
«PK»+ PK_Person(idNumber)
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(organizationIdNumber)+ FK_PersonIdentifier_Person(personIdNumber)
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(personIdNumber)
PatientRelationship
*PK idNumber: int*FK patientIdNumber: int* typeCode: char(20)*FK patientIdNumber: int*FK personIdNumber: int* effectiveDate: datetime
«FK»+ FK_PatientRelationship_Patient(patientIdNumber)+ FK_PatientRelationship_Person(patientIdNumber)
«PK»+ PK_PatientRelationship(idNumber)
Organization
*PK idNumber: int idCode: char(20)* assigningAuthorityIdCode: char(20)* name: char(50)
«PK»+ PK_ProvderOrganization(idNumber)
FacilityAlternateIdentifier
*PK facilityAlternateId: char(20)*pfK FacilityIdNumber: int FK identifierAssigningAuthority: int identifierTypeCode: bigint
«FK»+ FK_FacilityAlternateIdentifier_Facility(FacilityIdNumber)+ FK_FacilityAlternateIdentifier_Organization(identifierAssigningAuthority)
«PK»+ PK_FacilityAlternateIdentifier(facilityAlternateId, FacilityIdNumber)
TreatmentRefusal
*PK reasonIdCode: char(20)*pfK vaccineAdministrationIdNumber: int
«FK»+ FK_TreatmentRefusal_VaccineAdministration(vaccineAdministrationIdNumber)
«PK»+ PK_TreatmentRefusal(reasonIdCode, vaccineAdministrationIdNumber)
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(FacilityIdNumber)+ FK_VaccineAdministration_Patient(patientIdNumber)+ FK_VaccineAdministration_Person(administeringProvideridNumber)
«PK»+ PK_VaccineAdministration(idNumber)
0..*
(FacilityIdNumber = idNumber)
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
September 2008 HL7 RIM-Based Database Design 46 of 115
SIIS SIP Logical Data Model Classes
• Facility
• Facility Alternate Identifier
• Organization
• Patient
• Patient Relationship
• Person
• PersonAlternateName
• PersonIdentifier
• PersonPostalAddress
• PersonTelecommunicationAddress
• Treatment Refusal
• Vaccine Administration
September 2008 HL7 RIM-Based Database Design 47 of 115
SIIS SIP Information Needs RMIM
PersonclassCode *: <= "PSN"determinerCode *: <= INSTANCEid: SET<II> [0..1]name: BAG<PN> [0..*]telecom: BAG<TEL> [0..*]addr: BAG<AD> [0..*]
0..1 patientPerson
Patient
0..* asPatientclassCode *: <= "PAT"PatientPerson
classCode*: <= "PSN"determinerCode *: <= INSTANCEid: SET<II> [0..*]name: BAG<EN> [0..*]telecom: BAG<TEL> [0..*]administrativ eGenderCode: CE CWE [0..1] <= AdministrativeGenderbirthTime: TS [0..1]deceasedInd: BL [0..1]multipleBirthInd: BL [0..1]addr: BAG<AD> [0..*]raceCode: CE CWE [0..1] <= RaceethnicGroupCode: CE CWE [0..1] <= Ethnicity
0..1 relationshipHolder
0..1 personalRelationshipWith
PersonalRelationship
0..* personalRelationship
0..* asPersonalRelationship
classCode *: <= "PRS"code: CE CWE [0..1] <= RoleCodeef f ectiv eTime: TS [0..1]
0..1 careGiv erPerson
0..1 careGiv erScoper
CareGiver
0..* careGiv er
0..* asCareGiv er
classCode *: <= "CAREGIVER"id: SET<II> [0..*]code: CE CWE [0..1] <= RoleCodeef f ectiv eTime: TS [0..1]
FacilityclassCode *: <= "PLC"determinerCode *: <= INSTANCEid: SET<II> [0..*]addr: AD [0..1]
0..1 location
0..1 serv iceProv iderPatientPerson
ServiceDeliveryLocation0..* serv iceDeliv ery Location
0..* asServ iceDeliv ery LocationclassCode *: <= "SDLOC"
ServiceDeliveryOrganizationclassCode *: <= "ORG"determinerCode *: <= INSTANCEid: II [0..1]name: ON [0..1]
0..1 locatedServ iceDeliv ery Organization
0..1 location
LocatedEntity
0..* locatedEntity
0..* asLocatedEntity
classCode *: <= "LOCE"
VaccineAdministrationclassCode *: <= "SBADM"moodCode *: <= EVNid: II [0..1]code: CE CWE [0..1] < ActCodenegationInd: BL [0..1]activ ity Time: IVL<TS> [0..1]av ailability Time: TS [0..1]routeCode: CE CWE [0..1] < RouteOfAdministrationapproachSiteCode: SET<CD> CWE [0..*] < ActSitedoseQuantity : PQ [0..1]
ManufacturedMaterialclassCode *: <= "MMAT"determinerCode *: <= INSTANCEcode: CD CWE [0..1] <= EntityCodef ormCode: CE CWE [0..1] <= MaterialFormlotNumberText: ST [0..1]
0..1 manuf acturedMaterial
0..1 manuf acturerProductManuf acturer
ManufacturedProduct
0..* manuf acturedProduct
0..* asManuf acturedProduct
classCode *: <= "MANU"
ProductManufacturerclassCode *: <= "ORG"determinerCode *: <= INSTANCEid: II [0..1]
0..* v accineAdministration
0..* careGiv er
typeCode *: <= "PRF"
performer / performance
0..* v accineAdministration
0..* patient
typeCode *: <= "SBJ"subject / subjectOf2
0..* v accineAdministration
0..* serv iceDeliv ery Location
typeCode*: <= "LOC"
location / locationOf
0..* v accineAdministration
0..* manuf acturedProduct
typeCode *: <= "CSM"
consumable /consumedInPrimaryLanguage
(LanguageCommunication)languageCode: CE CWE [0..1] <= HumanLanguagepref erenceInd: BL [0..1]
0..*
0..*
targetName
sourceName
TreatmentRefusalclassCode *: <= "CONS"moodCode*: <= EVNcode: CD CWE [0..1] <= ActCodenegationInd: BL [0..1]reasonCode: CE CWE [0..1] <= ActReason
0..* v accineAdministration
0..* treatmentRef usal
typeCode *: <= "PERT"
pertinentInformation /pertainsTo
PatientRegistryObservationclassCode *: <= "OBS"moodCode *: <= EVNcode: CD CWE [0..1] < ActCodev alue: CE CWE [0..1] < ObservationValue
0..* patientRegistry Observ ation
0..* patient
typeCode *: <= "SBJ"
subject /subjectOf1
September 2008 HL7 RIM-Based Database Design 48 of 115
SIIS SIP Project Related RIM Classes
• Entity (Person, Organization, Place, Material)
• Living Subject (Person)
• Person (Patient Person, Associated Person)
• Language Communication (Primary Language)
• Organization (Service Delivery Organization, Manufacturer)
• Place (Facility)
• Material (Manufactured Material)
• Manufactured Material (Vaccine)
• Role (Personal Relationship, CareGiver, Patient, Service Delivery Location, Located Entity, Manufactured Product)
• Participation (Performer, Subject, Location, Consumable)
• Act (Substance Administration, Observation, Consent)
• Act Relationship (Pertains)
• Consent Consent (Treatment Refusal)
• Observation (Patient Registry Observation)
• Substance Administration (Vaccine Administration)
September 2008 HL7 RIM-Based Database Design 49 of 115
SIIS SIP RIM Class Subset Model (Level 0)
class RIM Subset
Entity
# classCode: CS# determinerCode: CS+ id: SET<II>+ code: CE- quantity: SET<PQ>+ name: BAG<EN>- desc: ED- statusCode: SET<CS>- existenceTime: IVL<TS>+ telecom: BAG<TEL>- riskCode: CE- handlingCode: CE
Liv ingSubject
+ administrativeGenderCode: CE+ birthTime: TS+ deceasedInd: BL- deceasedTime: TS+ multipleBirthInd: BL- multipleBirthOrderNumber: INT- organDonorInd: BL
Person
+ addr: BAG<AD>- maritalStatusCode: CE- educationLevelCode: CE+ raceCode: SET<CE>- disabil ityCode: SET<CE>- l ivingArrangementCode: CE- religiousAffi l iationCode: CE+ ethnicGroupCode: SET<CE>
LanguageCommunication
+ languageCode: CE- modeCode: CE- proficiencyLevelCode: CE- preferenceInd: BL
Organization
- addr: BAG<AD>- standardIndustryClassCode: CE
Place
- mobileInd: BL+ addr: AD- directionsText: ED- positionText: ED- gpsText: ST
Material
+ formCode: CE
ManufacturedMaterial
+ lotNumberText: ST- expirationTime: IVL<TS>- stabilityTime: IVL<TS>
Role
# classCode: CS+ id: SET<II>+ code: CE- negationInd: BL- addr: BAG<AD>- telecom: BAG<TEL>- statusCode: SET<CS>+ effectiveTime: IVL<TS>- certificateText: ED- quantity: RTO- positionNumber: LIST<INT>- name: EN
Participation
# typeCode: CS- functionCode: CD- contextControlCode: CS- sequenceNumber: int- negationInd: BL- noteText: ED- time: IVL<TS>- modeCode: CE- awarenessCode: CE- signatureCode: CE- signatureText: ED- performInd: BL- substitutionConditionCode: CE
Act
# classCode: CS# moodCode: CS+ id: SET<II>+ negationInd: BL- derivationExpr: ST- title: ST- text: ED- statusCode: SET<CS>- effectiveTime: GTS+ availabilityTime: TS- priorityCode: SET<CE>- confidentialityCode: SET<CE>- repeatNumber: IVL<INT>- InterruptibleInd: BL- levelCode: CE- independentInd: BL- uncertaintyCode: CE+ reasonCode: SET<CE>- languageCode: CE+ code: CS+ activityTime: GTS
SubstanceAdministration
+ routeCode: CE+ approachSiteCode: SET<CD>+ doseQuantity: IVL<PQ>- rateQuantity: IVL<PQ>- doseCheckQuantity: SET<RTO>- maxDoseQuantity: SET<RTO>
ActRelationship
# typeCode: CS- inversionInd: BL- contextControlCode: CS- contextConductionInd: BL- sequenceNumber: INT- priorityNumber: INT- pauseQuantity: PQ- checkpointCode: CS- splitCode: CS- joinCode: CS- negationInd: BL- conjunctionCode: CS- localVariableName: ST- separatableInd: BL- uncertaintyCode: CE
Observ ation
+ value: ANY- interpretationCode: SET<CE>- methodCode: SET<CE>- targetSiteCode: SET<CD>
+target
1
+inboundRelationship
0..*
+outboundRelationship
0..*
+source
1
1 0..*
0..*
1
+scoper
0..1
+scopedRole
0..*
+player
0..1
+playedRole
0..*10..*
September 2008 HL7 RIM-Based Database Design 50 of 115
SIIS SIP RIM Attribute Subset Model (Level 1)
class RIM Subset
Entity
# classCode: CS# determinerCode: CS+ id: SET<II>+ code: CE+ name: BAG<EN>+ telecom: BAG<TEL>
Liv ingSubject
+ administrativeGenderCode: CE+ birthTime: TS+ deceasedInd: BL+ multipleBirthInd: BL
Person
+ addr: BAG<AD>+ raceCode: SET<CE>+ ethnicGroupCode: SET<CE>
LanguageCommunication
+ languageCode: CE
OrganizationPlace
+ addr: AD
Material
+ formCode: CE
ManufacturedMaterial
+ lotNumberText: ST
Role
# classCode: CS+ id: SET<II>+ code: CE+ effectiveTime: IVL<TS>
Participation
# typeCode: CS
Act
# classCode: CS# moodCode: CS+ id: SET<II>+ negationInd: BL+ availabilityTime: TS+ reasonCode: SET<CE>+ code: CS+ activityTime: GTS
SubstanceAdministration
+ routeCode: CE+ approachSiteCode: SET<CD>+ doseQuantity: IVL<PQ>
ActRelationship
# typeCode: CS
Observ ation
+ value: ANY
+target
1
+inboundRelationship
0..*
+outboundRelationship
0..*
+source
1
1 0..*
0..*
1
+scoper
0..1
+scopedRole
0..*
+player
0..1
+playedRole
0..*10..*
September 2008 HL7 RIM-Based Database Design 51 of 115
Database Design Modeling Steps
Select a Subset of RIM Model Elements
• Resolve Inheritance Anomalies
• Specialize Attribute Datatypes
• Resolve Collection Datatypes
• Resolve Complex Datatypes
• Transform Classes into Tables
• Define Data Integrity Rules
• Assign Primary, Foreign, and Alternate Keys
• Optimize the Database Design Model
• Generate Database Definition Language
• Document Departures from the RIM
September 2008 HL7 RIM-Based Database Design 52 of 115
Resolve Inheritance Anomalies
• Inputs: RIM Subset Model (Level 1)
Information Needs
• Outputs: RIM Subset Model (Level 2)
• Process: Propagate and promote
attributes and associations as needed.
Eliminate unnecessary classes and inherited attributes
Replace generalization relationships with optional one-to-one associations.
• This activity involves streamlining the RIM subset model to eliminated unnecessary inheritance structures.
• Specialization classes inherit attributes and associations from parent generalization classes.
• Three basic approaches are used to eliminate inheritance:
Association Method
Propagation Method
Promotion Method
• Generalization relationships are replaced by optional one-to-one association relationships.
• Consideration must be given to resolving inherited association relationships.
• Not all inherited attributes and associations are relevant for the design project scope and information needs.
September 2008 HL7 RIM-Based Database Design 53 of 115
Generalization Relationships Indicate Inheritance
class Inheritance Resolution
A
- X- Y- Z
B
- Q- R- S
C
- H- I- J
class Inheritance Resolution
A
- X- Y- Z
B
- Q- R- S::A- X- Y- Z
C
- H- I- J::A- X- Y- Z
=
September 2008 HL7 RIM-Based Database Design 54 of 115
Association Method
Replace the generalization relationships with optional one-to-one association relationships
class Inheritance Resolution
A
- X- Y- Z
B
- Q- R- S::A- X- Y- Z
C
- H- I- J::A- X- Y- Z
=
class Inheritance Resolution
A
- X- Y- Z
B
- Q- R- S
C
- H- I- J
0..1
isA
1
0..1
isA
1
September 2008 HL7 RIM-Based Database Design 55 of 115
Propagation Method
Propagate attributes and associations from the parent generalization class into child specialization classes
class Inheritance Resolution
A
- X- Y- Z
B
- Q- R- S::A- X- Y- Z
C
- H- I- J::A- X- Y- Z
=
class Inheritance Resolution
B
- Q- R- S- X- Y- Z
C
- H- I- J- X- Y- Z
September 2008 HL7 RIM-Based Database Design 56 of 115
Promotion Method
Promote attributes and associations from child specialization classes into their parent generalization class
class Inheritance Resolution
A
- X- Y- Z
B
- Q- R- S::A- X- Y- Z
C
- H- I- J::A- X- Y- Z
=
class Inheritance R...
A
- H- I- J- Q- R- S- X- Y- Z
September 2008 HL7 RIM-Based Database Design 57 of 115
RIM Subset Model (Inheritance Exposed)
class RIM Subset
Entity
# classCode: CS# determinerCode: CS+ id: SET<II>+ code: CE+ name: BAG<EN>+ telecom: BAG<TEL>
Liv ingSubject
+ administrativeGenderCode: CE+ birthTime: TS+ deceasedInd: BL+ multipleBirthInd: BL::Entity# classCode: CS# determinerCode: CS+ id: SET<II>+ code: CE+ name: BAG<EN>+ telecom: BAG<TEL>
Person
+ addr: BAG<AD>+ raceCode: SET<CE>+ ethnicGroupCode: SET<CE>::LivingSubject+ administrativeGenderCode: CE+ birthTime: TS+ deceasedInd: BL+ multipleBirthInd: BL::Entity# classCode: CS# determinerCode: CS+ id: SET<II>+ code: CE+ name: BAG<EN>+ telecom: BAG<TEL>
LanguageCommunication
+ languageCode: CE
Organization
::Entity# classCode: CS# determinerCode: CS+ id: SET<II>+ code: CE+ name: BAG<EN>+ telecom: BAG<TEL>
Place
+ addr: AD::Entity# classCode: CS# determinerCode: CS+ id: SET<II>+ code: CE+ name: BAG<EN>+ telecom: BAG<TEL>
Material
+ formCode: CE::Entity# classCode: CS# determinerCode: CS+ id: SET<II>+ code: CE+ name: BAG<EN>+ telecom: BAG<TEL>
ManufacturedMaterial
+ lotNumberText: ST::Material+ formCode: CE::Entity# classCode: CS# determinerCode: CS+ id: SET<II>+ code: CE+ name: BAG<EN>+ telecom: BAG<TEL>
Role
# classCode: CS+ id: SET<II>+ code: CE+ effectiveTime: IVL<TS>
Participation
# typeCode: CS
Act
# classCode: CS# moodCode: CS+ id: SET<II>+ negationInd: BL+ availabilityTime: TS+ reasonCode: SET<CE>+ code: CS+ activityTime: GTS
SubstanceAdministration
+ routeCode: CE+ approachSiteCode: SET<CD>+ doseQuantity: IVL<PQ>::Act# classCode: CS# moodCode: CS+ id: SET<II>+ negationInd: BL+ availabilityTime: TS+ reasonCode: SET<CE>+ code: CS+ activityTime: GTS
ActRelationship
# typeCode: CS
Observ ation
+ value: ANY::Act# classCode: CS# moodCode: CS+ id: SET<II>+ negationInd: BL+ availabilityTime: TS+ reasonCode: SET<CE>+ code: CS+ activityTime: GTS
+target
1
+inboundRelationship
0..*
+outboundRelationship
0..*
+source
1
1 0..*
0..*
1
+scoper
0..1
+scopedRole
0..*
+player
0..1
+playedRole
0..*10..*
September 2008 HL7 RIM-Based Database Design 58 of 115
RIM Subset Model (Inheritance Anomalies)
• Unnecessarily inherited structural attributes with immutable values (classCode, determinerCode, moodCode).
• Place name and telcom attributes are out of scope.
• Person id and code attributes are out of scope
• Material id, name and telcom attributes are out of scope.
• Organization telcom attribute is out of scope.
• Observation negation indicator, availability time, reason code, and activity time are out of scope.
• Substance administration reason code is out of scope.
• The association to language communication class is out of scope for place, manufactured material, and organization.
• Material and living subject classes are superfluous.
September 2008 HL7 RIM-Based Database Design 59 of 115
RIM Subset Model (Inheritance Anomalies Resolved)class RIM Subset
Entity
# classCode: CS# determinerCode: CS+ id: SET<II>+ code: CE
Person
+ addr: BAG<AD>+ administrativeGenderCode: CE+ birthTime: TS+ deceasedInd: BL+ raceCode: SET<CE>+ multipleBirthInd: BL+ name: BAG<EN>+ ethnicGroupCode: SET<CE>+ telecom: BAG<TEL>
LanguageCommunication
+ languageCode: CE
Organization
+ id: SET<II>+ code: CE+ name: BAG<EN>
Place
+ addr: AD+ id: SET<II>+ code: CE
ManufacturedMaterial
+ formCode: CE+ lotNumberText: ST+ code: CE
Role
# classCode: CS+ id: SET<II>+ code: CE+ effectiveTime: IVL<TS>
Participation
# typeCode: CS
Act
# classCode: CS# moodCode: CS+ id: SET<II>+ code: CD
SubstanceAdministration
+ routeCode: CE+ approachSiteCode: SET<CD>+ doseQuantity: IVL<PQ>+ availabilityTime: TS+ activityTime: GTS+ id: SET<II>+ code: CD
ActRelationship
# typeCode: CS
Observation
+ value: ANY+ code: CD
Consent
+ code: CD+ negationInd: BL+ reasonCode: SET<CE>
+target
1
+inboundRelationship
0..*
+outboundRelationship
0..*
+source
1
1 0..*
0..*
1
+scoper
0..1
+scopedRole
0..*
+player
0..1
+playedRole
0..*
0..1
isA
1
0..1
isA
1
0..1
isA
1
0..1
isA
1
1
0..1
1
isA
0..1
0..1 isA
1
0..1
isA 1
September 2008 HL7 RIM-Based Database Design 60 of 115
Database Design Modeling Steps
Select a Subset of RIM Model Elements
Resolve Inheritance Anomalies
• Specialize Attribute Datatypes
• Resolve Collection Datatypes
• Resolve Complex Datatypes
• Transform Classes into Tables
• Define Data Integrity Rules
• Assign Primary, Foreign, and Alternate Keys
• Optimize the Database Design Model
• Generate Database Definition Language
• Document Departures from the RIM
September 2008 HL7 RIM-Based Database Design 61 of 115
Specialize Attribute Datatypes
• Inputs:
RIM Subset Model (Level 2)
Information Needs
• Outputs:
RIM Subset Model (Level 3)
• Process:
Replace collection datatypes with non-collection datatypes.
Replace generic datatypes with dependent child datatypes
Replace all concept descriptor datatypes with the CD datatype
• This activity involves replacing the RIM abstract datatypes with project domain specific datatypes.
• RIM collections datatypes (LIST, SET, and BAG) are used for repeating attributes.
• Eliminate collection datatypes where attribute repetition is inconsistent with information needs.
• RIM generic datatypes (EN, QTY, GTS, and ED) are intentionally abstract.
• Replace generic datatypes with more domain suitable datatypes.
• RIM concept descriptor datatypes (CS, CV, CE, and CE) provide a diverse approach to handling vocabulary needs.
• Replace all concept descriptor datatypes with CD to provide a uniform approach to handling vocabulary needs.
September 2008 HL7 RIM-Based Database Design 62 of 115
RIM Subset Model (Level 2)class RIM Subset
Entity
# classCode: CS# determinerCode: CS+ id: SET<II>+ code: CE
Person
+ addr: BAG<AD>+ administrativeGenderCode: CE+ birthTime: TS+ deceasedInd: BL+ raceCode: SET<CE>+ multipleBirthInd: BL+ name: BAG<EN>+ ethnicGroupCode: SET<CE>+ telecom: BAG<TEL>
LanguageCommunication
+ languageCode: CE
Organization
+ id: SET<II>+ code: CE+ name: BAG<EN>
Place
+ addr: AD+ id: SET<II>+ code: CE
ManufacturedMaterial
+ formCode: CE+ lotNumberText: ST+ code: CE
Role
# classCode: CS+ id: SET<II>+ code: CE+ effectiveTime: IVL<TS>
Participation
# typeCode: CS
Act
# classCode: CS# moodCode: CS+ id: SET<II>+ code: CD
SubstanceAdministration
+ routeCode: CE+ approachSiteCode: SET<CD>+ doseQuantity: IVL<PQ>+ availabilityTime: TS+ activityTime: GTS+ id: SET<II>+ code: CD
ActRelationship
# typeCode: CS
Observation
+ value: ANY+ code: CD
Consent
+ code: CD+ negationInd: BL+ reasonCode: SET<CE>
+target
1
+inboundRelationship
0..*
+outboundRelationship
0..*
+source
1
1 0..*
0..*
1
+scoper
0..1
+scopedRole
0..*
+player
0..1
+playedRole
0..*
0..1
isA
1
0..1
isA
1
0..1
isA
1
0..1
isA
1
1
0..1
1
isA
0..1
0..1 isA
1
0..1
isA 1
September 2008 HL7 RIM-Based Database Design 63 of 115
Attributes with Collection Datatypes
• Entity.id : SET<II>
• Place.id : SET<II>
• Person.addr : BAG<AD>
• Person.raceCode : SET<CE>
• Person.name : BAG<EN>
• Person.ethnicGroupCode : SET<CE>
• Person.telcom : BAG<TEL>
• Organization.id : SET<II>
• Organization.name : BAG<EN>
• Role.id : SET<II>
• Act.id : SET<II>
• SubstanceAdministration.approachSiteCode : SET<CD>
• SubstanceAdminstration.id : SET<II>
• Consent.reasonCode : SET<CE>
September 2008 HL7 RIM-Based Database Design 64 of 115
Assessed Attributes with Collection Datatypes
Entity.id : SET<II>
Place.id : SET<II>
Person.addr : BAG<AD>
Person.raceCode : SET<CE>
Person.name : BAG<EN>
Person.ethnicGroupCode : SET<CE>
Person.telcom : BAG<TEL>
Organization.id : SET<II>
Organization.name : BAG<EN>
Role.id : SET<II>
Act.id : SET<II>
SubstanceAdministration.approachSiteCode : SET<CD>
SubstanceAdminstration.id : SET<II>
Consent.reasonCode : SET<CE>
September 2008 HL7 RIM-Based Database Design 65 of 115
Assessed Attributes with Collection Datatypes
Entity.id : SET<II>
Place.id : SET<II>
Person.addr : BAG<AD>
Person.raceCode : CE
Person.name : BAG<EN>
Person.ethnicGroupCode : CE
Person.telcom : BAG<TEL>
Organization.id : II
Organization.name : EN
Role.id : SET<II>
Act.id : II
SubstanceAdministration.approachSiteCode : CD
SubstanceAdminstration.id : II
Consent.reasonCode : CE
September 2008 HL7 RIM-Based Database Design 66 of 115
RIM Subset Model (Level 2.1)class RIM Subset
Entity
# classCode: CS# determinerCode: CS+ id: SET<II>+ code: CE
Person
+ addr: BAG<AD>+ administrativeGenderCode: CE+ birthTime: TS+ deceasedInd: BL+ raceCode: CE+ multipleBirthInd: BL+ name: BAG<EN>+ ethnicGroupCode: CE+ telecom: BAG<TEL>
LanguageCommunication
+ languageCode: CE
Organization
+ id: II+ code: CE+ name: EN
Place
+ addr: AD+ id: SET<II>+ code: CE
ManufacturedMaterial
+ formCode: CE+ lotNumberText: ST+ code: CE
Role
# classCode: CS+ id: SET<II>+ code: CE+ effectiveTime: IVL<TS>
Participation
# typeCode: CS
Act
# classCode: CS# moodCode: CS+ id: II+ code: CD
SubstanceAdministration
+ routeCode: CE+ approachSiteCode: CD+ doseQuantity: IVL<PQ>+ availabilityTime: TS+ activityTime: GTS+ id: II+ code: CD
ActRelationship
# typeCode: CS
Observation
+ value: ANY+ code: CD
Consent
+ code: CD+ negationInd: BL+ reasonCode: CE
+target
1
+inboundRelationship
0..*
+outboundRelationship
0..*
+source
1
1 0..*
0..*
1
+scoper
0..1
+scopedRole
0..*
+player
0..1
+playedRole
0..*
0..1
isA
1
0..1
isA
1
0..1
isA
1
0..1
isA
1
1
0..1
1
isA
0..1
0..1 isA
1
0..1
isA 1
September 2008 HL7 RIM-Based Database Design 67 of 115
Attributes with Generic Datatypes
• Person.name : BAG<EN> replace with BAG<PN>
• Organization.name : EN replace with ON
• SubtanceAdministration.activityTime : GTS replace with IVL<TS>
September 2008 HL7 RIM-Based Database Design 68 of 115
RIM Subset Model (Level 2.2)class RIM Subset
Entity
# classCode: CS# determinerCode: CS+ id: SET<II>+ code: CE
Person
+ addr: BAG<AD>+ administrativeGenderCode: CE+ birthTime: TS+ deceasedInd: BL+ raceCode: CE+ multipleBirthInd: BL+ name: BAG<PN>+ ethnicGroupCode: CE+ telecom: BAG<TEL>
LanguageCommunication
+ languageCode: CE
Organization
+ id: II+ code: CE+ name: ON
Place
+ addr: AD+ id: SET<II>+ code: CE
ManufacturedMaterial
+ formCode: CE+ lotNumberText: ST+ code: CE
Role
# classCode: CS+ id: SET<II>+ code: CE+ effectiveTime: IVL<TS>
Participation
# typeCode: CS
Act
# classCode: CS# moodCode: CS+ id: II+ code: CD
SubstanceAdministration
+ routeCode: CE+ approachSiteCode: CD+ doseQuantity: IVL<PQ>+ availabilityTime: TS+ activityTime: IVL<TS>+ id: II+ code: CD
ActRelationship
# typeCode: CS
Observation
+ value: ANY+ code: CD
Consent
+ code: CD+ negationInd: BL+ reasonCode: CE
+target
1
+inboundRelationship
0..*
+outboundRelationship
0..*
+source
1
1 0..*
0..*
1
+scoper
0..1
+scopedRole
0..*
+player
0..1
+playedRole
0..*
0..1
isA
1
0..1
isA
1
0..1
isA
1
0..1
isA
1
1
0..1
1
isA
0..1
0..1 isA
1
0..1
isA 1
September 2008 HL7 RIM-Based Database Design 69 of 115
Attributes with Concept Descriptor Datatypes
• Entity.classCode : CS
• Entity.determinerCode : CS
• Entity.code : CE
• Place.code : CE
• Person.administrativeGenderCode : CE
• Person.raceCode : CE
• Person.ethnicGroupCode : CE
• LanguageCommuniction.languageCode : CE
• ManufacturedMaterial.formCode : CE
• ManufacturedMaterial.code : CE
• Role.ClassCode : CS
• Role.code : CE
• Organization.code : CE
• Observation.value : CD
• Observation.code : CD
• SubstanceAdministration.routeCode : CE
• SubstanceAdminstration.approachSiteCode : CD
• SubstanceAdministration.code : CD
• Participation.typeCode : CS
• Act.classCode : CS
• Act.moodCode : CS
• Act.code : CD
• Consent.code :CD
• Consent.reasonCode : CE
• ActRelationship.typeCode : CS
September 2008 HL7 RIM-Based Database Design 70 of 115
RIM Subset Model (Level 3)class RIM Subset
Entity
# classCode: CD# determinerCode: CD+ id: SET<II>+ code: CD
Person
+ addr: BAG<AD>+ administrativeGenderCode: CD+ birthTime: TS+ deceasedInd: BL+ raceCode: CD+ multipleBirthInd: BL+ name: BAG<PN>+ ethnicGroupCode: CD+ telecom: BAG<TEL>
LanguageCommunication
+ languageCode: CD
Organization
+ id: II+ code: CD+ name: ON
Place
+ addr: AD+ id: SET<II>+ code: CD
ManufacturedMaterial
+ formCode: CD+ lotNumberText: ST+ code: CD
Role
# classCode: CD+ id: SET<II>+ code: CD+ effectiveTime: IVL<TS>
Participation
# typeCode: CD
Act
# classCode: CD# moodCode: CD+ id: II+ code: CD
SubstanceAdministration
+ routeCode: CD+ approachSiteCode: CD+ doseQuantity: IVL<PQ>+ availabilityTime: TS+ activityTime: IVL<TS>+ id: II+ code: CD
ActRelationship
# typeCode: CD
Observation
+ value: ANY+ code: CD
Consent
+ code: CD+ negationInd: BL+ reasonCode: CD
+target
1
+inboundRelationship
0..*
+outboundRelationship
0..*
+source
1
0..1
isA 1
1 0..*
0..*
1
+scoper
0..1
+scopedRole
0..*
+player
0..1
+playedRole
0..*
0..1 isA
1
1
isA
0..1
1
0..1
0..1
isA
1
0..1
isA
1
0..1
isA
1
0..1
isA
1
September 2008 HL7 RIM-Based Database Design 71 of 115
Database Design Modeling Steps
Select a Subset of RIM Model Elements
Resolve Inheritance Anomalies
Specialize Attribute Datatypes
• Resolve Collection Datatypes
• Resolve Complex Datatypes
• Transform Classes into Tables
• Define Data Integrity Rules
• Assign Primary, Foreign, and Alternate Keys
• Optimize the Database Design Model
• Generate Database Definition Language
• Document Departures from the RIM
September 2008 HL7 RIM-Based Database Design 72 of 115
Resolve Collection Datatypes
• Inputs: RIM Subset Model (Level 3)
Information Needs
• Outputs: RIM Subset Model (Level 4)
• Process: Promote SET, LIST, and BAG
attributes to dependent classes
Replace IVL attributes with a pair of from/thru attributes where appropriate.
Replace IVL attributes with a single low, center, width, or high value where appropriate.
• This step involves revising the RIM subset model to have only single value attributes.
• The SET, LIST, and BAG datatypes indicate that the attribute may assume multiple values.
SET indicates the attribute values are unique.
LIST indicates the attribute values are ordered.
BAG indicates the attribute values are non-unique and unordered.
• The Interval (IVL) datatype indicates that the attribute is a an interval of values including:
Low value
Center value
Width value
High value
September 2008 HL7 RIM-Based Database Design 73 of 115
RIM Subset Model (Level 3)class RIM Subset
Entity
# classCode: CD# determinerCode: CD+ id: SET<II>+ code: CD
Person
+ addr: BAG<AD>+ administrativeGenderCode: CD+ birthTime: TS+ deceasedInd: BL+ raceCode: CD+ multipleBirthInd: BL+ name: BAG<PN>+ ethnicGroupCode: CD+ telecom: BAG<TEL>
LanguageCommunication
+ languageCode: CD
Organization
+ id: II+ code: CD+ name: ON
Place
+ addr: AD+ id: SET<II>+ code: CD
ManufacturedMaterial
+ formCode: CD+ lotNumberText: ST+ code: CD
Role
# classCode: CD+ id: SET<II>+ code: CD+ effectiveTime: IVL<TS>
Participation
# typeCode: CD
Act
# classCode: CD# moodCode: CD+ id: II+ code: CD
SubstanceAdministration
+ routeCode: CD+ approachSiteCode: CD+ doseQuantity: IVL<PQ>+ availabilityTime: TS+ activityTime: IVL<TS>+ id: II+ code: CD
ActRelationship
# typeCode: CD
Observation
+ value: ANY+ code: CD
Consent
+ code: CD+ negationInd: BL+ reasonCode: CD
+target
1
+inboundRelationship
0..*
+outboundRelationship
0..*
+source
1
0..1
isA 1
1 0..*
0..*
1
+scoper
0..1
+scopedRole
0..*
+player
0..1
+playedRole
0..*
0..1 isA
1
1
isA
0..1
1
0..1
0..1
isA
1
0..1
isA
1
0..1
isA
1
0..1
isA
1
September 2008 HL7 RIM-Based Database Design 74 of 115
Attributes with Collection Datatypes
• Entity.id : SET<II>
• Place.id : SET<II>
• Person.addr : BAG<AD>
• Person.name : BAG<PN>
• Person.telcom : BAG<TEL>
• Role.id : SET<II>
• Role.effectiveTime : IVL<TS>
• SubstanceAdministration.doseQuantity : IVL<PQ>
• SubstanceAdministration.activityTime : IVL<TS>
September 2008 HL7 RIM-Based Database Design 75 of 115
RIM Subset Model (Level 4)
class RIM Subset
Entity
# classCode: CD# determinerCode: CD+ code: CD
Person
+ administrativeGenderCode: CD+ birthTime: TS+ deceasedInd: BL+ raceCode: CD+ multipleBirthInd: BL+ ethnicGroupCode: CD
LanguageCommunication
+ languageCode: CD
Organization
+ id: II+ code: CD+ name: ON
Place
+ addr: AD+ code: CD
ManufacturedMaterial
+ formCode: CD+ lotNumberText: ST+ code: CD
Role
# classCode: CD+ code: CD+ effectiveTime: TS
Participation
# typeCode: CD
Act
# classCode: CD# moodCode: CD+ id: II+ code: CD
SubstanceAdministration
+ routeCode: CD+ approachSiteCode: CD+ doseQuantity: PQ+ availabilityTime: TS+ activityFromTime: TS+ id: II+ code: CD+ activityThruTime: TS
ActRelationship
# typeCode: CD
Observ ation
+ value: ANY+ code: CD
Consent
+ code: CD+ negationInd: BL+ reasonCode: CD
«II»PlaceIdentifier
«II»EntityIdentifier
«II»RoleIdentifier
«AD»PersonPostalAddress
«PN»PersonName
«TEL»PersonTelcomAddress
1 0..*
0..1
isA
1
0..1
isA
1
0..1
isA
1
10..1
1
isA
0..1 0..1
isA
1
+player
0..1
+playedRole
0..*
0..1
isA
1
0..*
1
0..*
«BAG» 0..1
isA
1
0..*
«SET»
+outboundRelationship
0..*
+source 1
+target
1
+inboundRelationship 0..*
0..*
«SET»
0..*
«SET»
0..*
«BAG»
0..*
«BAG»
+scoper
0..1
+scopedRole
0..*
September 2008 HL7 RIM-Based Database Design 76 of 115
Database Design Modeling Steps
Select a Subset of RIM Model Elements
Resolve Inheritance Anomalies
Specialize Attribute Datatypes
Resolve Collection Datatypes
• Resolve Complex Datatypes
• Transform Classes into Tables
• Define Data Integrity Rules
• Assign Primary, Foreign, and Alternate Keys
• Optimize the Database Design Model
• Generate Database Definition Language
• Document Departures from the RIM
September 2008 HL7 RIM-Based Database Design 77 of 115
Resolve Complex Datatypes
• Inputs:
RIM Subset Model (Level 4)
Information Needs
• Outputs:
RIM Subset Model (Level 5)
• Process:
Replace attributes with complex datatypes with attributes representing the structural features of their underlying datatypes.
Prepare a structure for common handling of attributes with concept descriptor datatypes.
Prepare a structure for handling attributes with the ANY datatype.
• This step involves revising the RIM subset model to have only primitive attributes.
• Prepare a data model of the complex datatypes used within the RIM subset model.
• Remove optional datatype features where possible.
• Simplify the datatype model structure by consolidating classes where possible
• Use the datatype data model to guide replacement of complex attributes in the RIM subset model.
• Prepare a structure to manage coded concepts.
• Prepare a data structure with the flexibility to handle the ANY datatype.
September 2008 HL7 RIM-Based Database Design 78 of 115
RIM Subset Model (Level 4)
class RIM Subset
Entity
# classCode: CD# determinerCode: CD+ code: CD
Person
+ administrativeGenderCode: CD+ birthTime: TS+ deceasedInd: BL+ raceCode: CD+ multipleBirthInd: BL+ ethnicGroupCode: CD
LanguageCommunication
+ languageCode: CD
Organization
+ id: II+ code: CD+ name: ON
Place
+ addr: AD+ code: CD
ManufacturedMaterial
+ formCode: CD+ lotNumberText: ST+ code: CD
Role
# classCode: CD+ code: CD+ effectiveTime: TS
Participation
# typeCode: CD
Act
# classCode: CD# moodCode: CD+ id: II+ code: CD
SubstanceAdministration
+ routeCode: CD+ approachSiteCode: CD+ doseQuantity: PQ+ availabilityTime: TS+ activityFromTime: TS+ id: II+ code: CD+ activityThruTime: TS
ActRelationship
# typeCode: CD
Observ ation
+ value: ANY+ code: CD
Consent
+ code: CD+ negationInd: BL+ reasonCode: CD
«II»PlaceIdentifier
«II»EntityIdentifier
«II»RoleIdentifier
«AD»PersonPostalAddress
«PN»PersonName
«TEL»PersonTelcomAddress
1 0..*
0..1
isA
1
0..1
isA
1
0..1
isA
1
10..1
1
isA
0..1 0..1
isA
1
+player
0..1
+playedRole
0..*
0..1
isA
1
0..*
1
0..*
«BAG» 0..1
isA
1
0..*
«SET»
+outboundRelationship
0..*
+source 1
+target
1
+inboundRelationship 0..*
0..*
«SET»
0..*
«SET»
0..*
«BAG»
0..*
«BAG»
+scoper
0..1
+scopedRole
0..*
September 2008 HL7 RIM-Based Database Design 79 of 115
Complex Datatypes Use in the RIM Subset Model
• II : Instance Identifier
• AD : Postal Address
• PN : Person Name
• ON : Organization Name
• TEL : Telecommunication Address
• PQ : Physical Quantity
• CD : Concept Descriptor
• ANY : Data Value
September 2008 HL7 RIM-Based Database Design 80 of 115
II: Instance IdentifierName 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.)
September 2008 HL7 RIM-Based Database Design 81 of 115
Instance Identifier
class II Datatype
InstanceIdentifier
- identifierNameSpace: ST- identifierValue: ST
September 2008 HL7 RIM-Based Database Design 82 of 115
AD: Postal AddressName Type Status Definition
LIST<ADXP> mandatory The address data
use SET<CS> optionalA 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
September 2008 HL7 RIM-Based Database Design 83 of 115
Postal Address
class PostalAddress
PostalAddress
- usageTypeCode: CD- effectiveFromTime: TS- effectiveThruTime: TS
PostalAddressPart
- addressPartSequence: INT- addressPartTypeCode: CD- addressPartValue: ST
1..*
«LIST»
September 2008 HL7 RIM-Based Database Design 84 of 115
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
September 2008 HL7 RIM-Based Database Design 85 of 115
Entity Name
class EntityName
EntityName
- usageTypeCode: CD- effectiveFromTime: TS- effectiveThruTime: TS
EntityNamePart
- namePartSequence: INT- namePartTypeCode: CD- namePartValue: ST
1..*
«LIST»
September 2008 HL7 RIM-Based Database Design 86 of 115
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.
September 2008 HL7 RIM-Based Database Design 87 of 115
Telecommunication Address
class TelcomAddress
TelcomAddress
- addressTypeCode: CD- usageTypeCode: CD- effectiveFromTime: TS- effectiveThruTime: TS- addressValue: ST
September 2008 HL7 RIM-Based Database Design 88 of 115
PQ: Physical QuantityName 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.
September 2008 HL7 RIM-Based Database Design 89 of 115
Physical Quantity
class PhysicalQuantity
PhysicalQuantity
- quantityValue: REAL- quantityUnitCode: CD
September 2008 HL7 RIM-Based Database Design 90 of 115
CD: Concept DescriptorName 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
September 2008 HL7 RIM-Based Database Design 91 of 115
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
September 2008 HL7 RIM-Based Database Design 92 of 115
Property Summary of Concept Descriptor
class CodedValueDatatype
ConceptDescriptor
- codeValue: ST- displayName: ST- codeSystemIdentifier: ST- codeSystemVersion: ST
September 2008 HL7 RIM-Based Database Design 93 of 115
Data Value
class DataValue
DataValue
- dataTypeCode: CD- booleanValue: BL- codedValue: CD
September 2008 HL7 RIM-Based Database Design 94 of 115
Complex Datatypes
class DataTypes
DataValue
- dataTypeCode: CD- booleanValue: BL- codedValue: CD
EntityName
- usageTypeCode: CD- effectiveFromTime: TS- effectiveThruTime: TS
EntityNamePart
- namePartSequence: INT- namePartTypeCode: CD- namePartValue: ST
InstanceIdentifier
- identifierNameSpace: ST- identifierValue: ST
PhysicalQuantity
- quantityValue: REAL- quantityUnitCode: CD
PostalAddress
- usageTypeCode: CD- effectiveFromTime: TS- effectiveThruTime: TS
PostalAddressPart
- addressPartSequence: INT- addressPartTypeCode: CD- addressPartValue: ST
TelcomAddress
- addressTypeCode: CD- usageTypeCode: CD- effectiveFromTime: TS- effectiveThruTime: TS- addressValue: ST
CodedValueDatatype::ConceptDescriptor
- codeValue: ST- displayName: ST- codeSystemIdentifier: ST- codeSystemVersion: ST
1..*«LIST»
1..*«LIST»
September 2008 HL7 RIM-Based Database Design 95 of 115
RIM Subset Model (Level 5)
class RIM Subset
Entity
# classCode: ST# determinerCode: ST+ code: ST
Person
+ administrativeGenderCode: ST+ birthTime: TS+ deceasedInd: BL+ raceCode: ST+ multipleBirthInd: BL+ ethnicGroupCode: ST
LanguageCommunication
+ languageCode: ST
Organization
+ code: ST
Place
+ code: ST
ManufacturedMaterial
+ formCode: ST+ lotNumberText: ST+ code: ST
Role
# classCode: ST+ code: ST+ effectiveTime: TS
Participation
# typeCode: ST
Act
# classCode: ST# moodCode: ST+ code: ST
SubstanceAdministration
+ routeCode: ST+ approachSiteCode: ST+ availabilityTime: TS+ activityFromTime: TS+ code: ST+ activityThruTime: TS
ActRelationship
# typeCode: CD
Observation
+ code: ST
Consent
+ code: ST+ negationInd: BL+ reasonCode: ST
PlaceIdentifier
+ identifierNameSpace: ST+ identifierValue: ST
EntityIdentifier
+ identifierNameSpace: ST+ identifierValue: ST
RoleIdentifier
+ identifierNameSpace: ST+ identifierValue: ST
PersonPostalAddress
+ usageTypeCode: ST+ effectiveFromTime: TS+ effectiveThruTime: TS
PersonName
+ usageTypeCode: ST+ effectiveFromTime: TS+ effectiveThruTime: TS
PersonTelcomAddress
+ addressTypeCode: ST+ usageTypeCode: ST+ effectiveFromTime: TS+ effectiveThruTime: TS+ addressValue: ST
PlacePostalAddress
+ usageTypeCode: ST+ effectiveFromTime: TS+ effectiveThruTime: TS
PlacePostalAddressPart
+ addressPartSequence: INT+ addressPartTypeCode: ST+ addressPartValue: ST
PersonPostalAddressPart
+ addressPartSequence: INT+ addressPartTypeCode: ST+ addressPartValue: ST
PersonNamePart
+ namePartSequence: INT+ namePartTypeCode: ST+ namePartValue: ST
OrganizationIdentifier
+ identifierNameSpace: ST+ identifierValue: ST
OrganizationName
+ usageTypeCode: ST+ effectiveFromTime: TS+ effectiveThruTime: TS
OrganizationNamePart
+ namePartSequence: INT+ namePartTypeCode: ST+ namePartValue: ST
ActIdentifier
+ identifierNameSpace: ST+ identifierValue: ST
SubstanceAdministrationIdentifier
+ identifierNameSpace: ST+ identifierValue: ST
SubstanceAdministrationDose
+ quantityValue: REAL+ quantityUnitCode: ST
ObservationValue
+ datatypeCode: ST+ booleanValue: BL+ codedValue: ST
CodedValue
+ codeValue: ST+ displayName: ST
CodeSystemValueSet
+ codeSystemIdentifier: ST+ codeSystemVersion: ST
CodedAttribute
+ tableName: ST+ columnName: ST
0..1
isA
1
0..1
isA
1
0..1
isA
1
0..1
isA
1
10..1
1
isA
0..10..1
isA
1
+player
0..1
+playedRole
0..*
+scoper
0..1
+scopedRole
0..*
0..1
isA
1 1 0..*0..1
0..*
«SET»
+outboundRelationship 0..*
+source 1 +target 1
+inboundRelationship 0..*
0..*
«SET»
0..*
«SET»
0..*
«BAG»
0..*
«BAG»
0..*
«BAG»
0..* 1
1..*
«LIST»
1..* «LIST»
1..* «LIST»
0..1
0..1
1..*
«LIST»
0..1
0..1 0..1 0..1
0..*«SET»
0..1
0..*
September 2008 HL7 RIM-Based Database Design 96 of 115
Database Design Modeling Steps
Select a Subset of RIM Model Elements
Resolve Inheritance Anomalies
Specialize Attribute Datatypes
Resolve Collection Datatypes
Resolve Complex Datatypes
• Transform Classes into Tables
• Define Data Integrity Rules
• Assign Primary, Foreign, and Alternate Keys
• Optimize the Database Design Model
• Generate Database Definition Language
• Document Departures from the RIM
September 2008 HL7 RIM-Based Database Design 97 of 115
Transform Classes into Tables
• Inputs: RIM Subset Model (Level 5)
Information Needs
• Outputs: Logical Data Model (Level 1)
• Process: Select a database management
system.
Add a table to the Logical Data Model for each class in the RIM Subset Model (Level 5).
Add a column to each Logical Data Model table for each attribute in the RIM Subset Model (Level 5).
• This step involves creation of a level one Logical Data Model.
• Select a database management system for the LDM.
• Add tables to the LDM. Adopt a naming convention that obeys table naming constraints of the DBMS.
• Add columns to the LDM. Adopt a naming convention that obeys column naming constraints of the DBMS.
• Assign datatypes to columns in the LDM. Adopt a pattern for assigning datatypes in the LDM based upon datatypes and other factors in the RIM Subset Model.
• Add relationships between tables. Use navigation to depict foreign key reference direction.
September 2008 HL7 RIM-Based Database Design 98 of 115
Develop Modeling Conventions for the LDM
• Keep table and column names to less than 30 characters.
• Use a consistent set of abbreviations in table and column names.
• Prefix table names with E, R, P, or A to correspond to classes based upon Entity, Role, Participation, and Act.
• Establish additional table name prefixes conventions for classes not based upon Entity, Role, Participation, and Act.
• Assign column datatypes based upon a consistent mapping of V3 primitive datatypes to DBMS datatypes.
• Use a consistent length for columns based upon the attribute type in the RIM subset model.
September 2008 HL7 RIM-Based Database Design 99 of 115
RIM Logical Data Model (Level 1)
class RIM Subset LDM
E_PlacePostalAddrPart
addrPartSeq: int addrPartTypeCD: varchar(10) addrPartVal: varchar(50)
E_PlacePostalAddr
usageTypeCD: varchar(10) effectiveFromDT: datetime effectiveThurDT: datetime
E_Place
typeCD: varchar(10)
E_PlaceID
identifierNameSpaceID: varchar(50) identifierVal: varchar(50)
E_Entity
classCD: varchar(10) determinerCD: varchar(10) typeCD: varchar(10)
E_EntityID
identifierNameSpaceID: varchar(50) identifierVal: varchar(50)
R_Role
classCD: varchar(10) typeCD: varchar(10) effectiveDT: datetime
R_RoleID
identifierNameSpaceID: varchar(50) identifierVAL: varchar(50)
P_Participation
typeCD: varchar(10)
E_Person
administrativeGenderCD: varchar(10) birthDT: datetime deceasedInd: bit raceCD: varchar(10) multiBirthInd: bit ethnicGroupCD: varchar(10)
E_PersonPostalAddr
usageTypeCD: varchar(10) effectiveFromDT: datetime effectiveThruDT: datetime
E_PersonPostalAddrPart
addrPartSeq: int addrPartTypeCD: varchar(10) addrPartVal: varchar(50)
E_PersonName
usageTypeCD: varchar(10) effectiveFromDT: datetime effectiveThruDT: datetime
E_PersonNamePart
namePartSeq: int namePartTypeCD: varchar(10) namePartVal: varchar(50)
E_PersonTelcomAddr
addrTypeCD: varchar(10) usagetypeCD: varchar(10) effectiveFromDT: datetime effectiveThruDT: datetime addressVal: varchar(50)
E_LangCom
langCD: varchar(10)
A_ACT
classCD: varchar(10) moodCD: varchar(10) typeCD: varchar(10)
A_ActRelationship
typeCD: varchar(10)
A_SubstanceAdmin
routeCD: varchar(10) approachSiteCD: varchar(10) availabilityDT: datetime actFromDT: datetime actThruDT: datetime typeCD: varchar(10)
A_SubstanceAdminID
identifierNameSpaceID: varchar(50) identifierVal: varchar(50)
A_SubstanceAdminDose
doseQty: real doseQtyUnitCD: varchar(10)
A_Consent
typeCD: varchar(10) negInd: bit reasonCD: varchar(10)
A_ActID
identifierNameSpaceID: varchar(50) identifierVal: varchar(50)
+player
+scoper
+source +target
September 2008 HL7 RIM-Based Database Design 100 of 115
Database Design Modeling Steps
Select a Subset of RIM Model Elements
Resolve Inheritance Anomalies
Specialize Attribute Datatypes
Resolve Collection Datatypes
Resolve Complex Datatypes
Transform Classes into Tables
• Define Data Integrity Rules
• Assign Primary, Foreign, and Alternate Keys
• Optimize the Database Design Model
• Generate Database Definition Language
• Document Departures from the RIM
September 2008 HL7 RIM-Based Database Design 101 of 115
Define Data Integrity Rules
• Inputs:
Logical Data Model (Level 1)
Information Needs
• Outputs:
Data Integrity Rules
Logical Data Model (Level 2)
• Process:
Define column integrity rules
Define referential integrity rules
Update the LDM
Document data integrity rules
• This step involves specification of data integrity rules and the creation of a level two Logical Data Model.
• Define column integrity rules which specify:
Optionality
Uniqueness
Update
Derivation
Value constraint
• Define table relationship rule which specify:
Insert / Update rules
Delete rules
Cardinality rules
• Update the LDM and document the data integrity rules.
September 2008 HL7 RIM-Based Database Design 102 of 115
Column Integrity Rules
• All columns should have integrity rules specified.
• Three important integrity rules to include are optionality, uniqueness, and update.
Optionality indicates if the column is required (must always have value), optional (may be unvalued), conditional (must be valued under certain conditions)
Uniqueness specifies whether multiple instances of the table are allowed to have the same value for this column. The uniqueness specification may reference other columns in the same table that in combination with this column must be unique. Specify as unique, not-unique, or unique in combination
Update specifies if the value of the column is allowed to be modified once the instance of the table has been created.
• Integrity rules should be used to specify derivation algorithms for derived columns. A derived column is an column whose value can be determined algorithmically from other columns also in the model.
• Any constraints on the allowable values of an column that is conditioned by the value of other columns should be documented as an integrity rule.
September 2008 HL7 RIM-Based Database Design 103 of 115
Determine Table Relationship Rules
• Table relationship rules are data integrity rules specified on relationships. The table relationship rules govern the effects of insert, delete, and update operations on relationships.
• Table relationship rules are sometimes referred to as “referential integrity rules” because they govern the integrity of the references from one table to another (i.e., primary and foreign keys).
• Insert and Update rules apply to child tables (tables on the “many” side of a one-to-many relationship). They specify what restrictions associated parent tables (tables on the “one” side of the one-to-many relationship) impose upon the insert of a row in child table or the update of foreign key columns.
• Possible insert/update rules are: Dependent, Automatic, Nullify, Default, Customize, and None.
• Delete rules apply to the parent table. They specify what restrictions the associated child tables impose upon the deletion of a row in the parent table or an update to its primary key.
• Possible delete rules are: Restrict, Cascade, Nullify, Default, Customize, and None.
September 2008 HL7 RIM-Based Database Design 104 of 115
Referential Integrity Rules
Insert/Update Rules
• Dependent: Permit insertion of child table instance only when matching parent table instance already exist.
• Automatic: Always permit insertion of child table instance. If matching parent table instance does not already exist, create it.
• Nullify: Always permit insertion of child table instance. If matching parent table instances does not already exist, set foreign key in child to null.
• Default: Always permit insertion of child table instance. If matching parent table instance does not exist, set foreign key in child to a previously defined default value.
• Customize: Permit insertion of child table instance only if certain customize validity constraints are met.
• None: Always permit insertion of child table instance. No matching parent table instance need exist, and thus no validity checking need be done.
Delete Rules
• Restrict: Permit deletion of parent table instance only when there are no matching child table instances.
• Cascade: Always permit deletion of parent table instance and cascade the deletion to any matching child table instances.
• Nullify: Always permit deletion of parent table instance. If any matching child table instances exist, set their foreign keys to null.
• Default: Always permit deletion of parent table instance. If any matching child table instances exist, set their foreign keys to a previously defined default.
• Customized: Permit deletion of parent table instance only if certain customized validity constraints are met.
• None: Always permit deletion of parent table instance. Matching child table instances may or may not exist, and thus no validity checking need be done.
September 2008 HL7 RIM-Based Database Design 105 of 115
Sample referential integrity rules• Each E_Entity sometimes is a E_Place; on delete restrict.
• Each E_Place always is a E_Entity; insert/update dependent.
• Each E_Place sometime has one E_PlacePostalAddr; on delete cascade.
• Each E_PlacePostalAddr always pertains to one E_Place; insert/update dependent.
• Each E_PlacePostalAddr always has one or more E_PlacePostalAddrPart; on delete cascade.
• Each E_PlacePostalAddrPart always pertains to one E_PlacePostalAddr; insert/update dependent.
• Each E_Entity sometimes is a E_Person; on delete restrict.
• Each E_Person always is a E_Entity; insert/update dependent.
• Each E_Person sometime has one or more E_PersonPostalAddr; on delete cascade.
• Each E_PersonPostalAddr always pertains to one E_Person; insert/update dependent.
• Each E_PersonPostalAddr always has one or more E_PersonPostalAddrPart; on delete cascade.
• Each E_PersonPostalAddrPart always pertains to one E_PersonPostalAddr; insert/update dependent.
class RIM Subset LDM
E_PlacePostalAddrPart
addrPartSeq: int addrPartTypeCD: varchar(10) addrPartVal: varchar(50)
E_PlacePostalAddr
usageTypeCD: varchar(10) effectiveFromDT: datetime effectiveThurDT: datetime
E_Place
typeCD: varchar(10)
E_PlaceID
identifierNameSpaceID: varchar(50) identifierVal: varchar(50)
E_Entity
classCD: varchar(10) determinerCD: varchar(10) typeCD: varchar(10)
E_EntityID
identifierNameSpaceID: varchar(50) identifierVal: varchar(50)
R_Role
classCD: varchar(10) typeCD: varchar(10) effectiveDT: datetime
R_RoleID
identifierNameSpaceID: varchar(50) identifierVAL: varchar(50)
P_Participation
typeCD: varchar(10)
E_Person
administrativeGenderCD: varchar(10) birthDT: datetime deceasedInd: bit raceCD: varchar(10) multiBirthInd: bit ethnicGroupCD: varchar(10)
E_PersonPostalAddr
usageTypeCD: varchar(10) effectiveFromDT: datetime effectiveThruDT: datetime
E_PersonPostalAddrPart
addrPartSeq: int addrPartTypeCD: varchar(10) addrPartVal: varchar(50)
E_PersonName
usageTypeCD: varchar(10) effectiveFromDT: datetime effectiveThruDT: datetime
E_PersonNamePart
namePartSeq: int namePartTypeCD: varchar(10) namePartVal: varchar(50)
E_PersonTelcomAddr
addrTypeCD: varchar(10) usagetypeCD: varchar(10) effectiveFromDT: datetime effectiveThruDT: datetime addressVal: varchar(50)
E_LangCom
langCD: varchar(10)
A_ACT
classCD: varchar(10) moodCD: varchar(10) typeCD: varchar(10)
A_ActRelationship
typeCD: varchar(10)
A_SubstanceAdmin
routeCD: varchar(10) approachSiteCD: varchar(10) availabilityDT: datetime actFromDT: datetime actThruDT: datetime typeCD: varchar(10)
A_SubstanceAdminID
identifierNameSpaceID: varchar(50) identifierVal: varchar(50)
A_SubstanceAdminDose
doseQty: real doseQtyUnitCD: varchar(10)
A_Consent
typeCD: varchar(10) negInd: bit reasonCD: varchar(10)
A_ActID
identifierNameSpaceID: varchar(50) identifierVal: varchar(50)
+player
+scoper
+source +target
September 2008 HL7 RIM-Based Database Design 106 of 115
Sample column integrity rules• E_Entity.classCD
Required, Not Unique, Immutable
Must have matching CodedValue.codeValue
• E_Entity.typeCD
Conditional, Not Unique, Updateable
Must have matching CodedValue.codeValue
Required if classCD is PLC, ORG, or MAT
• E_Person.administrativeGenderCD
Optional, Not Unique, Updateable
Must have matching CodedValue.codeValue
• E_Person.birthDT
Optional, Not Unique, Updateable
Must be less than or equal to current date
• E_Person.deceasedInd
Optional, Not Unique, Updateable
• E_PersonTelcomAddr.addrTypeCD Required, Not Unique, Updateable
Must have matching CodedValue.codeValue
• E_PersonTelcomAddr.effectiveFromDT Optional, Not Unique, Updateable
Must be less than or equal to effectiveThruDT
class RIM Subset LDM
E_PlacePostalAddrPart
addrPartSeq: int addrPartTypeCD: varchar(10) addrPartVal: varchar(50)
E_PlacePostalAddr
usageTypeCD: varchar(10) effectiveFromDT: datetime effectiveThurDT: datetime
E_Place
typeCD: varchar(10)
E_PlaceID
identifierNameSpaceID: varchar(50) identifierVal: varchar(50)
E_Entity
classCD: varchar(10) determinerCD: varchar(10) typeCD: varchar(10)
E_EntityID
identifierNameSpaceID: varchar(50) identifierVal: varchar(50)
R_Role
classCD: varchar(10) typeCD: varchar(10) effectiveDT: datetime
R_RoleID
identifierNameSpaceID: varchar(50) identifierVAL: varchar(50)
P_Participation
typeCD: varchar(10)
E_Person
administrativeGenderCD: varchar(10) birthDT: datetime deceasedInd: bit raceCD: varchar(10) multiBirthInd: bit ethnicGroupCD: varchar(10)
E_PersonPostalAddr
usageTypeCD: varchar(10) effectiveFromDT: datetime effectiveThruDT: datetime
E_PersonPostalAddrPart
addrPartSeq: int addrPartTypeCD: varchar(10) addrPartVal: varchar(50)
E_PersonName
usageTypeCD: varchar(10) effectiveFromDT: datetime effectiveThruDT: datetime
E_PersonNamePart
namePartSeq: int namePartTypeCD: varchar(10) namePartVal: varchar(50)
E_PersonTelcomAddr
addrTypeCD: varchar(10) usagetypeCD: varchar(10) effectiveFromDT: datetime effectiveThruDT: datetime addressVal: varchar(50)
E_LangCom
langCD: varchar(10)
A_ACT
classCD: varchar(10) moodCD: varchar(10) typeCD: varchar(10)
A_ActRelationship
typeCD: varchar(10)
A_SubstanceAdmin
routeCD: varchar(10) approachSiteCD: varchar(10) availabilityDT: datetime actFromDT: datetime actThruDT: datetime typeCD: varchar(10)
A_SubstanceAdminID
identifierNameSpaceID: varchar(50) identifierVal: varchar(50)
A_SubstanceAdminDose
doseQty: real doseQtyUnitCD: varchar(10)
A_Consent
typeCD: varchar(10) negInd: bit reasonCD: varchar(10)
A_ActID
identifierNameSpaceID: varchar(50) identifierVal: varchar(50)
+player
+scoper
+source +target
September 2008 HL7 RIM-Based Database Design 107 of 115
RIM Logical Data Model (Level 2)
class RIM Subset LDM
E_PlacePostalAddrPart
* addrPartSeq: int* addrPartTypeCD: varchar(10)* addrPartVal: varchar(50)
E_PlacePostalAddr
usageTypeCD: varchar(10) effectiveFromDT: datetime effectiveThurDT: datetime
E_Place
* typeCD: varchar(10)
E_PlaceID
* identifierNameSpaceID: varchar(50)* identifierVal: varchar(50)
E_Entity
* classCD: varchar(10)* determinerCD: varchar(10) typeCD: varchar(10)
E_EntityID
* identifierNameSpaceID: varchar(50)* identifierVal: varchar(50)
R_Role
* classCD: varchar(10) typeCD: varchar(10) effectiveDT: datetime
R_RoleID
* identifierNameSpaceID: varchar(50)* identifierVAL: varchar(50)
P_Participation
* typeCD: varchar(10)
E_Person
administrativeGenderCD: varchar(10) birthDT: datetime deceasedInd: bit raceCD: varchar(10) multiBirthInd: bit ethnicGroupCD: varchar(10)
E_PersonPostalAddr
usageTypeCD: varchar(10) effectiveFromDT: datetime effectiveThruDT: datetime
E_PersonPostalAddrPart
* addrPartSeq: int* addrPartTypeCD: varchar(10)* addrPartVal: varchar(50)
E_PersonName
usageTypeCD: varchar(10) effectiveFromDT: datetime effectiveThruDT: datetime
E_PersonNamePart
* namePartSeq: int* namePartTypeCD: varchar(10)* namePartVal: varchar(50)
E_PersonTelcomAddr
* addrTypeCD: varchar(10) usagetypeCD: varchar(10) effectiveFromDT: datetime effectiveThruDT: datetime* addressVal: varchar(50)
E_LangCom
* langCD: varchar(10)
A_ACT
* classCD: varchar(10)* moodCD: varchar(10) typeCD: varchar(10)
A_ActRelationship
* typeCD: varchar(10)
A_SubstanceAdmin
routeCD: varchar(10) approachSiteCD: varchar(10) availabilityDT: datetime* actFromDT: datetime actThruDT: datetime* typeCD: varchar(10)
A_SubstanceAdminID
* identifierNameSpaceID: varchar(50)* identifierVal: varchar(50)
A_SubstanceAdminDose
* doseQty: real* doseQtyUnitCD: varchar(10)
A_Consent
* typeCD: varchar(10)* negInd: bit* reasonCD: varchar(10)
A_ActID
* identifierNameSpaceID: varchar(50)* identifierVal: varchar(50)
1..*
1
0..* 1
0..*
1
0..1 1
0..*
1
0..*
+player
1
0..*
+scoper
1
0..*
1
0..*
1
0..1
1
0..* 11..* 1
0..*
1
1..*
1
0..*
1
0..1
1
0..* 1
0..*
+source 1
0..*
+target 1
0..1
1
1
1
0..1
1
0..1
1
0..*1
September 2008 HL7 RIM-Based Database Design 108 of 115
Database Design Modeling Steps
Select a Subset of RIM Model Elements
Resolve Inheritance Anomalies
Specialize Attribute Datatypes
Resolve Collection Datatypes
Resolve Complex Datatypes
Transform Classes into Tables
Define Data Integrity Rules
• Assign Primary, Foreign, and Alternate Keys
• Optimize the Database Design Model
• Generate Database Definition Language
• Document Departures from the RIM
September 2008 HL7 RIM-Based Database Design 109 of 115
Assign Primary, Foreign, and Alternate Keys
• Inputs:
Logical Data Model (Level 2)
Data Integrity Rules
• Outputs:
Logical Data Model (Level 3)
• Process:
Identify candidate keys
Assign primary keys
Propagate foreign keys
• This step involves creation of a level two Logical Data Model.
• Assess the data integrity rules for table columns to determine a list of candidate keys.
• Choose a primary key from among the list of candidates or assign a surrogate key.
• Propagate primary keys to dependent tables as foreign keys.
September 2008 HL7 RIM-Based Database Design 110 of 115
Specify Table Keys
• A key is an attribute or minimal set of attributes that uniquely identifies a specific occurrence of a table.
• Many different types of keys may be specified for a table.
Candidate Keys
Primary Keys
Alternate Keys
Foreign Keys
Composite Keys
Surrogate Keys
• All tables must have a primary key specified.
• In addition to keys, some tables may have an inversion entry specified.
September 2008 HL7 RIM-Based Database Design 111 of 115
Types of Keys
• Candidate Key: an attribute or group of attributes that might be chosen as a primary key
• Primary Key: an attribute or group of attributes that have been chosen as the unique identifier of a table
• Alternate Key: a candidate key that has not been chosen as the primary key
• Foreign Key: an attribute or group of attributes in a table that is the primary key of a parent table
• Composite Key: a primary key that contains two or more attributes, possibly foreign keys
• Surrogate Key: a single meaningless attribute assigned as the primary key of a table
• Inversion Entry: an attribute of group of attributes that will frequently be used to access a table but may not result in finding exactly one instance.
September 2008 HL7 RIM-Based Database Design 112 of 115
Assigning Keys
• Start with the tables that are only on the “one” side of one-to-many relationships (root tables).
• Make a list of candidate keys
Review the integrity rules for each attribute in the table
List those attributes that are required and are unique either by themselves or in combination
• Select a primary key
Eliminate from the list of candidate keys those attributes that are updateable, derived, or have their allowable values constrained by other attributes.
If no candidate keys remain, assign a surrogate key.
If multiple candidate keys remain, choose one with the least number of attributes
Mark the unselected candidate keys as alternate keys
• Propagate the primary keys as foreign keys to the child tables on the “many” side of the one-to-many relationships.
• Repeat the process of identifying candidate keys and selecting primary keys.
• Continue on to the next set of child tables until all tables have been assigned a primary key.
• Review key assignments and adjust for abnormalities
September 2008 HL7 RIM-Based Database Design 113 of 115
RIM Logical Data Model (Level 3)class RIM Subset LDM
E_PlacePostalAddrPart
*pfK addrID: bigint*PK addrPartSeq: int* addrPartTypeCD: varchar(10)* addrPartVal: varchar(50)
«FK»+ FK_E_PlacePostalAddrPart_E_PlacePostalAddr(addrID)
«PK»+ PK_E_PlacePostalAddrPart(addrID, addrPartSeq)
E_PlacePostalAddr
*PK addrID: bigint*FK entityID: bigint usageTypeCD: varchar(10) effectiveFromDT: datetime effectiveThurDT: datetime
«FK»+ FK_E_PlacePostalAddr_E_Place(entityID)
«PK»+ PK_E_PlacePostalAddr(addrID)
E_Place
*pfK entityID: bigint* typeCD: varchar(10)
«FK»+ FK_E_Place_E_Entity(entityID)
«PK»+ PK_E_Place(entityID)
E_PlaceID
*pfK entityID: bigint*PK identifierNameSpaceID: varchar(50)*PK identifierVal: varchar(50)
«FK»+ FK_E_PlaceID_E_Place(entityID)
«PK»+ PK_E_PlaceID(entityID, identifierNameSpaceID, identifierVal)
E_Entity
*PK entityID: bigint* classCD: varchar(10)* determinerCD: varchar(10) typeCD: varchar(10)
«PK»+ PK_E_Entity(entityID)
E_EntityID
*pfK entityID: bigint*PK identifierNameSpaceID: varchar(50)*PK identifierVal: varchar(50)
«FK»+ FK_E_EntityID_E_Entity(entityID)
«PK»+ PK_E_EntityID(entityID, identifierNameSpaceID, identifierVal)
R_Role
*PK roleID: bigint*FK playerEntityID: bigint*FK scoperEntityID: bigint* classCD: varchar(10) typeCD: varchar(10) effectiveDT: datetime
«FK»+ FK_R_Role_ScoperE_Entity(scoperEntityID)+ FK_R_Role_PlayerE_Entity(playerEntityID)
«PK»+ PK_R_Role(roleID)
R_RoleID
*pfK roleID: bigint*PK identifierNameSpaceID: varchar(50)*PK identifierVAL: varchar(50)
«FK»+ FK_R_RoleID_R_Role(roleID)
«PK»+ PK_R_RoleID(roleID, identifierNameSpaceID, identifierVAL)
E_Person
*pfK entityID: bigint administrativeGenderCD: varchar(10) birthDT: datetime deceasedInd: bit raceCD: varchar(10) multiBirthInd: bit ethnicGroupCD: varchar(10)
«FK»+ FK_E_Person_E_Entity(entityID)
«PK»+ PK_E_Person(entityID)
E_PersonPostalAddr
*PK addrID: bigint*FK entityID: bigint usageTypeCD: varchar(10) effectiveFromDT: datetime effectiveThruDT: datetime
«FK»+ FK_E_PersonPostalAddr_E_Person(entityID)
«PK»+ PK_E_PersonPostalAddr(addrID)
E_PersonPostalAddrPart
*pfK addrID: bigint*PK addrPartSeq: int* addrPartTypeCD: varchar(10)* addrPartVal: varchar(50)
«FK»+ FK_E_PersonPostalAddrPart_E_PersonPostalAddr(addrID)
«PK»+ PK_E_PersonPostalAddrPart(addrID, addrPartSeq)
E_PersonName
*PK nameID: bigint*FK entityID: bigint usageTypeCD: varchar(10) effectiveFromDT: datetime effectiveThruDT: datetime
«FK»+ FK_E_PersonName_E_Person(entityID)
«PK»+ PK_E_PersonName(nameID)
E_PersonNamePart
*pfK nameID: bigint*PK namePartSeq: int* namePartTypeCD: varchar(10)* namePartVal: varchar(50)
«FK»+ FK_E_PersonNamePart_E_PersonName(nameID)
«PK»+ PK_E_PersonNamePart(nameID, namePartSeq)
E_PersonTelcomAddr
*PK addrID: bigint*FK entityID: bigint* addrTypeCD: varchar(10) usagetypeCD: varchar(10) effectiveFromDT: datetime effectiveThruDT: datetime* addressVal: varchar(50)
«FK»+ FK_E_PersonTelcomAddr_E_Person(entityID)
«PK»+ PK_E_PersonTelcomAddr(addrID)
E_LangCom
*pfK entityID: bigint* langCD: varchar(10)
«FK»+ FK_E_LangCom_E_Person(entityID)
«PK»+ PK_E_LangCom(entityID)
0..*(addrID = addrID)
1
0..1
(entityID = entityID)
1
0..*
(entityID = entityID)
1
0..1
(entityID = entityID)
1
0..*
(entityID = entityID)
1
0..*
(roleID = roleID)
1
0..1
(entityID = entityID)
1
0..*
(entityID = entityID)
10..*
(addrID = addrID)
1
0..*
(entityID = entityID)
1
0..*
(nameID = nameID)
1
0..*
(entityID = entityID)
1
0..1
(entityID = entityID)
1
0..*
(playerEntityID = entityID)
1
0..*
(scoperEntityID = entityID)
1
September 2008 HL7 RIM-Based Database Design 114 of 115
Database Design Modeling Steps
Select a Subset of RIM Model Elements
Resolve Inheritance Anomalies
Specialize Attribute Datatypes
Resolve Collection Datatypes
Resolve Complex Datatypes
Transform Classes into Tables
Define Data Integrity Rules
Assign Primary, Foreign, and Alternate Keys
• Optimize the Database Design Model
• Generate Database Definition Language
• Document Departures from the RIM
September 2008 HL7 RIM-Based Database Design 115 of 115
Optimize the Database Design Model
• Inputs:
Logical Data Model (Level 3)
Data Integrity Rules
Information Needs
• Outputs:
Physical Data Model (Level 1)
• Process:
Rename tables and columns to use problem domain specific nomenclature
Use specialization tables to simplify enforcement of referential integrity rules
Selectively promote attributes from dependent tables into their respective parent classes.
• This step involves creation of a physical data model.
• A goal of optimization is to create a model that is easier for SMEs to validate and for developers to understand.
• Optimization includes reducing redundancy, ambiguity, optionality, and abstraction.
• Access path analysis and performance hotspots should be carefully considered.
• A balance should be struck between optimal performance and future-proofing
September 2008 HL7 RIM-Based Database Design 116 of 115
Eliminate Redundancy
class EntityIdentifier
E_Entity
*PK entityID: bigint* classCD: varchar(10)* determinerCD: varchar(10) typeCD: varchar(10)
«PK»+ PK_E_Entity(bigint)
E_Place
*pfK entityID: bigint* typeCD: varchar(10)
«FK»+ FK_E_Place_E_Entity(bigint)
«PK»+ PK_E_Place(bigint)
E_PlaceID
*pfK entityID: bigint*PK identifierNameSpaceID: varchar(50)*PK identifierVal: varchar(50)
«FK»+ FK_E_PlaceID_E_Place(bigint)
«PK»+ PK_E_PlaceID(bigint, varchar, varchar)
E_EntityID
*pfK entityID: bigint*PK identifierNameSpaceID: varchar(50)*PK identifierVal: varchar(50)
«FK»+ FK_E_EntityID_E_Entity(bigint)
«PK»+ PK_E_EntityID(bigint, varchar, varchar)
0..1
(entityID = entityID)
1
0..*
(entityID = entityID)
1
0..*
(entityID = entityID)
1
September 2008 HL7 RIM-Based Database Design 117 of 115
Reduce ambiguity and abstraction
class PlaceAddress
E_Place
*pfK entityID: bigint* typeCD: varchar(10)
«FK»+ FK_E_Place_E_Entity(bigint)
«PK»+ PK_E_Place(bigint)
E_PlacePostalAddr
*PK addrID: bigint*FK entityID: bigint usageTypeCD: varchar(10) effectiveFromDT: datetime effectiveThurDT: datetime
«FK»+ FK_E_PlacePostalAddr_E_Place(bigint)
«PK»+ PK_E_PlacePostalAddr(bigint)
E_PlacePostalAddrPart
*pfK addrID: bigint*PK addrPartSeq: int* addrPartTypeCD: varchar(10)* addrPartVal: varchar(50)
«FK»+ FK_E_PlacePostalAddrPart_E_PlacePostalAddr(bigint)
«PK»+ PK_E_PlacePostalAddrPart(bigint, int)
0..1
(entityID = entityID)
1
0..*
(addrID = addrID)
1
class FacilityAddress
E_Facility
*pfK entityID: bigint* typeCD: varchar(10) addrLine1text: varchar(50) addrLine2Text: varchar(50) addrCityName: varchar(50) addrStateCD: varchar(10) addrPostalCode: varchar(50) addrCountyCD: varchar(10)
«FK»+ FK_E_Place_E_Entity(bigint)
«PK»+ PK_E_Place(bigint)
E_PlacePostalAddr
*PK addrID: bigint*FK entityID: bigint usageTypeCD: varchar(10) effectiveFromDT: datetime effectiveThurDT: datetime
«FK»+ FK_E_PlacePostalAddr_E_Place(bigint)
«PK»+ PK_E_PlacePostalAddr(bigint)
E_PlacePostalAddrPart
*pfK addrID: bigint*PK addrPartSeq: int* addrPartTypeCD: varchar(10)* addrPartVal: varchar(50)
«FK»+ FK_E_PlacePostalAddrPart_E_PlacePostalAddr(bigint)
«PK»+ PK_E_PlacePostalAddrPart(bigint, int)
0..1
(entityID = entityID)
1
0..*
(addrID = addrID)
1
September 2008 HL7 RIM-Based Database Design 118 of 115
Optimal Performance and Future Proofing
class E_PatientName
E_Person
*pfK entityID: bigint administrativeGenderCD: varchar(10) birthDT: datetime deceasedInd: bit raceCD: varchar(10) multiBirthInd: bit ethnicGroupCD: varchar(10)
«FK»+ FK_E_Person_E_Entity(bigint)
«PK»+ PK_E_Person(bigint)
E_PersonName
*PK nameID: bigint*FK entityID: bigint usageTypeCD: varchar(10) effectiveFromDT: datetime effectiveThruDT: datetime
«FK»+ FK_E_PersonName_E_Person(bigint)
«PK»+ PK_E_PersonName(bigint)
E_PersonNamePart
*pfK nameID: bigint*PK namePartSeq: int* namePartTypeCD: varchar(10)* namePartVal: varchar(50)
«FK»+ FK_E_PersonNamePart_E_PersonName(bigint)
«PK»+ PK_E_PersonNamePart(bigint, int)
0..*
(entityID =entityID)
1
0..*
(nameID =nameID)
1
class E_PatientName
E_Person
*pfK entityID: bigint administrativeGenderCD: varchar(10) birthDT: datetime deceasedInd: bit raceCD: varchar(10) multiBirthInd: bit ethnicGroupCD: varchar(10) primaryLanguageCD: varchar(10) primarySurname: varchar(50) primaryGivenName: varchar(50) primaryMiddleName: varchar(50) primaryNameSuffix: varchar(50)
«FK»+ FK_E_Person_E_Entity(bigint)
«PK»+ PK_E_Person(bigint)
E_PersonName
*PK nameID: bigint*FK entityID: bigint usageTypeCD: varchar(10) effectiveFromDT: datetime effectiveThruDT: datetime surname: varchar(50) givenName: varchar(50) middleName: varchar(50) nameSuffix: varchar(50)
«FK»+ FK_E_PersonName_E_Person(bigint)
«PK»+ PK_E_PersonName(bigint)
E_PersonNamePart
*pfK nameID: bigint*PK namePartSeq: int* namePartTypeCD: varchar(10)* namePartVal: varchar(50)
«FK»+ FK_E_PersonNamePart_E_PersonName(bigint)
«PK»+ PK_E_PersonNamePart(bigint, int)
0..*
(entityID =entityID)
1
0..*
(nameID =nameID)
1
September 2008 HL7 RIM-Based Database Design 119 of 115
Structural Simplification
class E_Language
E_Person
*pfK entityID: bigint administrativeGenderCD: varchar(10) birthDT: datetime deceasedInd: bit raceCD: varchar(10) multiBirthInd: bit ethnicGroupCD: varchar(10)
«FK»+ FK_E_Person_E_Entity(bigint)
«PK»+ PK_E_Person(bigint)
E_LangCom
*pfK entityID: bigint* langCD: varchar(10)
«FK»+ FK_E_LangCom_E_Person(bigint)
«PK»+ PK_E_LangCom(bigint)
0..1
(entityID =entityID)
1
class Language
E_Person
*pfK entityID: bigint administrativeGenderCD: varchar(10) birthDT: datetime deceasedInd: bit raceCD: varchar(10) multiBirthInd: bit ethnicGroupCD: varchar(10) primaryLanguageCD: varchar(10) primarySurname: varchar(50) primaryGivenName: varchar(50) primaryMiddleName: varchar(50) primaryNameSuffix: varchar(50)
«FK»+ FK_E_Person_E_Entity(bigint)
«PK»+ PK_E_Person(bigint)
E_LangCom
*pfK entityID: bigint* langCD: varchar(10)
«FK»+ FK_E_LangCom_E_Person(bigint)
«PK»+ PK_E_LangCom(bigint)
0..1
(entityID =entityID)
1
September 2008 HL7 RIM-Based Database Design 120 of 115
Simplify RI Enforcement
class R_Patient
E_Entity
*PK entityID: bigint* classCD: varchar(10)* determinerCD: varchar(10) typeCD: varchar(10)
«PK»+ PK_E_Entity(bigint)
E_Person
*pfK entityID: bigint administrativeGenderCD: varchar(10) birthDT: datetime deceasedInd: bit raceCD: varchar(10) multiBirthInd: bit ethnicGroupCD: varchar(10)
«FK»+ FK_E_Person_E_Entity(bigint)
«PK»+ PK_E_Person(bigint)
R_Role
*PK roleID: bigint*FK playerEntityID: bigint*FK scoperEntityID: bigint* classCD: varchar(10) typeCD: varchar(10) effectiveDT: datetime
«FK»+ FK_R_Role_ScoperE_Entity(bigint)+ FK_R_Role_PlayerE_Entity(bigint)
«PK»+ PK_R_Role(bigint)
0..1
(entityID =entityID)
1
0..*
(scoperEntityID =entityID)
0..1
0..*
(playerEntityID =entityID)
1
class R_Patient
E_Entity
*PK entityID: bigint* classCD: varchar(10)* determinerCD: varchar(10) typeCD: varchar(10)
«PK»+ PK_E_Entity(bigint)
R_Role
*PK roleID: bigint*FK playerEntityID: bigint*FK scoperEntityID: bigint* classCD: varchar(10) typeCD: varchar(10) effectiveDT: datetime
«FK»+ FK_R_Role_ScoperE_Entity(bigint)+ FK_R_Role_PlayerE_Entity(bigint)
«PK»+ PK_R_Role(bigint)
R_Patient
*pfK roleID: bigint*FK playerEntityID: bigint
«FK»+ FK_R_Patient_E_Person(bigint)+ FK_R_Patient_R_Role(bigint)
«PK»+ PK_R_Patient(bigint)
«unique»+ UQ_R_Patient_playerEntityID(bigint)
E_Person
*pfK entityID: bigint administrativeGenderCD: varchar(10) birthDT: datetime deceasedInd: bit raceCD: varchar(10) multiBirthInd: bit ethnicGroupCD: varchar(10) primaryLanguageCD: varchar(10) primarySurname: varchar(50) primaryGivenName: varchar(50) primaryMiddleName: varchar(50) primaryNameSuffix: varchar(50)
«FK»+ FK_E_Person_E_Entity(bigint)
«PK»+ PK_E_Person(bigint)
0..*
(scoperEntityID =entityID)
0..1
0..*
(playerEntityID =entityID)
1
0..*
(roleID = roleID)
1
0..*
(playerEntityID =entityID)
1
0..1
(entityID =entityID)
1
September 2008 HL7 RIM-Based Database Design 121 of 115
Physical Data Model (Level 1)E_PlacePostalAddrPart
*pfK addrID: bigint*PK addrPartSeq: int* addrPartTypeCD: varchar(10)* addrPartVal: varchar(50)
«FK»+ FK_E_PlacePostalAddrPart_E_PlacePostalAddr(addrID)
«PK»+ PK_E_PlacePostalAddrPart(addrID, addrPartSeq)
E_PlacePostalAddr
*PK addrID: bigint*FK entityID: bigint usageTypeCD: varchar(10) effectiveFromDT: datetime effectiveThurDT: datetime
«FK»+ FK_E_PlacePostalAddr_E_Place(entityID)
«PK»+ PK_E_PlacePostalAddr(addrID)
E_Facility
*pfK entityID: bigint* typeCD: varchar(10) addrLine1text: varchar(50) addrLine2Text: varchar(50) addrCityName: varchar(50) addrStateCD: varchar(10) addrPostalCode: varchar(50) addrCountyCD: varchar(10)
«FK»+ FK_E_Place_E_Entity(entityID)
«PK»+ PK_E_Place(entityID)
E_Entity
*PK entityID: bigint* classCD: varchar(10)* determinerCD: varchar(10) typeCD: varchar(10)
«PK»+ PK_E_Entity(entityID)
E_EntityID
*pfK entityID: bigint*PK identifierNameSpaceID: varchar(50)*PK identifierVal: varchar(50)
«FK»+ FK_E_EntityID_E_Entity(entityID)
«PK»+ PK_E_EntityID(entityID, identifierNameSpaceID, identifierVal)
R_Role
*PK roleID: bigint*FK playerEntityID: bigint*FK scoperEntityID: bigint* classCD: varchar(10) typeCD: varchar(10) effectiveDT: datetime
«FK»+ FK_R_Role_ScoperE_Entity(scoperEntityID)+ FK_R_Role_PlayerE_Entity(playerEntityID)
«PK»+ PK_R_Role(roleID)
R_RoleID
*pfK roleID: bigint*PK identifierNameSpaceID: varchar(50)*PK identifierVAL: varchar(50)
«FK»+ FK_R_RoleID_R_Role(roleID)
«PK»+ PK_R_RoleID(roleID, identifierNameSpaceID, identifierVAL)
E_Person
*pfK entityID: bigint administrativeGenderCD: varchar(10) birthDT: datetime deceasedInd: bit raceCD: varchar(10) multiBirthInd: bit ethnicGroupCD: varchar(10) primaryLanguageCD: varchar(10) primarySurname: varchar(50) primaryGivenName: varchar(50) primaryMiddleName: varchar(50) primaryNameSuffix: varchar(50)
«FK»+ FK_E_Person_E_Entity(entityID)
«PK»+ PK_E_Person(entityID)
E_PersonPostalAddr
*PK addrID: bigint*FK entityID: bigint usageTypeCD: varchar(10) effectiveFromDT: datetime effectiveThruDT: datetime addrLine1Text: bigint addrLine2Text: varchar(50) addrCityName: varchar(50) addrStateCD: varchar(10) addrPostalCode: varchar(50) addrCountryCD: varchar(10)
«FK»+ FK_E_PersonPostalAddr_E_Person(entityID)
«PK»+ PK_E_PersonPostalAddr(addrID)
E_PersonPostalAddrPart
*pfK addrID: bigint*PK addrPartSeq: int* addrPartTypeCD: varchar(10)* addrPartVal: varchar(50)
«FK»+ FK_E_PersonPostalAddrPart_E_PersonPostalAddr(addrID)
«PK»+ PK_E_PersonPostalAddrPart(addrID, addrPartSeq)
E_PersonName
*PK nameID: bigint*FK entityID: bigint usageTypeCD: varchar(10) effectiveFromDT: datetime effectiveThruDT: datetime surname: varchar(50) givenName: varchar(50) middleName: varchar(50) nameSuffix: varchar(50)
«FK»+ FK_E_PersonName_E_Person(entityID)
«PK»+ PK_E_PersonName(nameID)
E_PersonNamePart
*pfK nameID: bigint*PK namePartSeq: int* namePartTypeCD: varchar(10)* namePartVal: varchar(50)
«FK»+ FK_E_PersonNamePart_E_PersonName(nameID)
«PK»+ PK_E_PersonNamePart(nameID, namePartSeq)
E_PersonTelcomAddr
*PK addrID: bigint*FK entityID: bigint* addrTypeCD: varchar(10) usagetypeCD: varchar(10) effectiveFromDT: datetime effectiveThruDT: datetime* addressVal: varchar(50)
«FK»+ FK_E_PersonTelcomAddr_E_Person(entityID)
«PK»+ PK_E_PersonTelcomAddr(addrID)
E_LangCom
*pfK entityID: bigint* langCD: varchar(10)
«FK»+ FK_E_LangCom_E_Person(entityID)
«PK»+ PK_E_LangCom(entityID)
E_PlaceID
*pfK entityID: bigint*PK identifierNameSpaceID: varchar(50)*PK identifierVal: varchar(50)
«FK»+ FK_E_PlaceID_E_Place(entityID)
«PK»+ PK_E_PlaceID(entityID, identifierNameSpaceID, identifierVal)
R_Patient
*pfK roleID: bigint*FK playerEntityID: bigint
«FK»+ FK_R_Patient_E_Person(playerEntityID)+ FK_R_Patient_R_Role(roleID)
«PK»+ PK_R_Patient(roleID)
«unique»+ UQ_R_Patient_playerEntityID(playerEntityID)
0..*
(addrID = addrID)
1
0..1
(entityID = entityID)
10..1
(entityID = entityID)
1
0..*
(entityID = entityID)
1
0..*
(roleID = roleID)
1
0..1
(entityID = entityID)
1
0..*
(entityID = entityID)
10..*
(addrID = addrID)
1
0..*
(entityID = entityID)
1
0..*
(nameID = nameID)
1
0..*
(entityID = entityID)
1
0..1
(entityID = entityID)
1
0..*
(playerEntityID = entityID)
1
0..*
(scoperEntityID = entityID)
0..1
0..*
(entityID = entityID)
1
0..*
(roleID = roleID)
1
0..*
(playerEntityID = entityID)
1
September 2008 HL7 RIM-Based Database Design 122 of 115
Database Design Modeling Steps
Select a Subset of RIM Model Elements
Resolve Inheritance Anomalies
Specialize Attribute Datatypes
Resolve Collection Datatypes
Resolve Complex Datatypes
Transform Classes into Tables
Define Data Integrity Rules
Assign Primary, Foreign, and Alternate Keys
Optimize the Database Design Model
• Generate Database Definition Language
• Document Departures from the RIM
September 2008 HL7 RIM-Based Database Design 123 of 115
Generated DDL (PDM Level 2)• CREATE TABLE E_Person (
• entityID bigint NOT NULL,
• administrativeGenderCD varchar(10),
• birthDT datetime,
• deceasedInd bit,
• raceCD varchar(10),
• multiBirthInd bit,
• ethnicGroupCD varchar(10),
• primaryLanguageCD varchar(10),
• primarySurname varchar(50),
• primaryGivenName varchar(50),
• primaryMiddleName varchar(50),
• primaryNameSuffix varchar(50)
• )
• ;
• ALTER TABLE E_Person ADD CONSTRAINT PK_E_Person
• PRIMARY KEY CLUSTERED (entityID)
• ;
• ALTER TABLE E_Person ADD CONSTRAINT FK_E_Person_E_Entity
• FOREIGN KEY (entityID) REFERENCES E_Entity (entityID)
• ;
September 2008 HL7 RIM-Based Database Design 124 of 115
Database Design Modeling Steps
Select a Subset of RIM Model Elements
Resolve Inheritance Anomalies
Specialize Attribute Datatypes
Resolve Collection Datatypes
Resolve Complex Datatypes
Transform Classes into Tables
Define Data Integrity Rules
Assign Primary, Foreign, and Alternate Keys
Optimize the Database Design Model
Generate Database Definition Language
• Document Departures from the RIM
September 2008 HL7 RIM-Based Database Design 125 of 115
Departures from the RIM
• Limited Place to a single address
• Renamed Place to Facility
• Limited Language Communication to Person only
• Limited Person to a single Language Communication
• Limited Observation Value to datatypes of BL and CD only.
• Renamed Substance Administration to Vaccine Administration
September 2008 HL7 RIM-Based Database Design 126 of 115
Database Design Modeling Steps
Select a Subset of RIM Model Elements
Resolve Inheritance Anomalies
Specialize Attribute Datatypes
Resolve Collection Datatypes
Resolve Complex Datatypes
Transform Classes into Tables
Define Data Integrity Rules
Assign Primary, Foreign, and Alternate Keys
Optimize the Database Design Model
Generate Database Definition Language
Document Departures from the RIM
September 2008 HL7 RIM-Based Database Design 127 of 115
Questions / Discussion / Feedback
September 2008 HL7 RIM-Based Database Design 128 of 115
Closing Thought
September 2008 HL7 RIM-Based Database Design 129 of 115
Characteristics of a Useful Model Salient: Since no model can represent everything, it must selectively represent those things most relevant to the task at hand.
Accurate: The model should precisely encode the actual state of affairs and not an erroneous or biased view.
Complete yet Parsimonious: The model should be as simple as possible, but no simpler. It should concisely capture all the relevant dimensions of the problem without squeezing out the opportunity for serendipitous or creative insight.
Perceptible: Models should be appropriately displayed in high fidelity as they won't be much use if we can't clearly see, hear, or feel them.
Understandable: Once we perceive the model we must be able to make sense of it; it mustn't be too complicated or unfamiliar for us to understand.
Descriptive: The model should clearly and objective describe the true situation.
Emotive: In addition, the model should convey a subjective feel for the emotional and value-laden connotations of the situation being modeled.
Inspiring: Because people are drawn to and inspired by thoughtful design, models should be elegant, i.e. they should synergistically combine style and substance.
Memorable: Models are not of much use if they pass quickly from the mind, or if they cannot be used as a mnemonic device. Models should be easily accessible for future reference and to refresh our understanding.
Flexible: As all models are, to some degree, inaccurate, irrelevant, mistaken, time-sensitive etc., they should be open to recursive revision to reflect new data, our growing understanding, or our evolving needs.
Coherent: Models do not exist in isolation but in interlocking systems, thus any particular model should be coherent with other related models.
Productive: Ultimately, the model has a purpose: the production of effective action. A good model should help define our goals and then specify the actions necessary to reach them.
Useful: Usefulness is the sum of the above properties and the degree to which they combine to promote understanding and effective action. It is important to note that the most accurate, or the most complete, or the most elegant model is not necessarily the most useful. All models are incomplete. All models a compromise. The model maker's art lies in making those shrewd trade-offs that will render the model most useful to the problem at hand.
September 2008 HL7 RIM-Based Database Design 130 of 115
Thank You
Abdul-Malik ShakirPrincipal Consultant
Shakir Consulting1407 Foothill Blvd., Suite 145
La Verne, CA 91750
Office: (909) 596-6790 Mobile: (626) 644-4491Email: [email protected]