Rim Based Relational Database Design Tutorial September 2008

130
Reference Information Reference Information Model-Based Relational Model-Based Relational Database Design Database Design Abdul-Malik Shakir Principal Consultant, Shakir Consulting HL7 Working Group Meeting, Vancouver, BC September 2008

description

 

Transcript of Rim Based Relational Database Design Tutorial September 2008

Page 1: 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

Page 2: Rim Based Relational Database Design Tutorial 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

Page 3: Rim Based Relational Database Design Tutorial September 2008

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

Page 4: Rim Based Relational Database Design Tutorial September 2008

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.

Page 5: Rim Based Relational Database Design Tutorial September 2008

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.

Page 6: Rim Based Relational Database Design Tutorial September 2008

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

Page 7: Rim Based Relational Database Design Tutorial September 2008

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

Page 8: Rim Based Relational Database Design Tutorial September 2008

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.

Page 9: Rim Based Relational Database Design Tutorial September 2008

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.

Page 10: Rim Based Relational Database Design Tutorial September 2008

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

Page 11: Rim Based Relational Database Design Tutorial September 2008

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

Page 12: Rim Based Relational Database Design Tutorial September 2008

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

Page 13: Rim Based Relational Database Design Tutorial September 2008

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

Page 14: Rim Based Relational Database Design Tutorial September 2008

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

Page 15: Rim Based Relational Database Design Tutorial September 2008

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

Page 16: Rim Based Relational Database Design Tutorial September 2008

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

Page 17: Rim Based Relational Database Design Tutorial September 2008

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.

Page 18: Rim Based Relational Database Design Tutorial September 2008

September 2008 HL7 RIM-Based Database Design 18 of 115

HL7 RIM Normative Specification

Page 19: Rim Based Relational Database Design Tutorial September 2008

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.

Page 20: Rim Based Relational Database Design Tutorial September 2008

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.

Page 21: Rim Based Relational Database Design Tutorial September 2008

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

Page 22: Rim Based Relational Database Design Tutorial September 2008

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

Page 23: Rim Based Relational Database Design Tutorial September 2008

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

Page 24: Rim Based Relational Database Design Tutorial September 2008

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

Page 25: Rim Based Relational Database Design Tutorial September 2008

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.

Page 26: Rim Based Relational Database Design Tutorial September 2008

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

Page 27: Rim Based Relational Database Design Tutorial September 2008

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

Page 28: Rim Based Relational Database Design Tutorial September 2008

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

Page 29: Rim Based Relational Database Design Tutorial September 2008

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

Page 30: Rim Based Relational Database Design Tutorial September 2008

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

Page 31: Rim Based Relational Database Design Tutorial September 2008

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

Page 32: Rim Based Relational Database Design Tutorial September 2008

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

Page 33: Rim Based Relational Database Design Tutorial September 2008

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.

Page 34: Rim Based Relational Database Design Tutorial September 2008

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.

Page 35: Rim Based Relational Database Design Tutorial September 2008

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

Page 36: Rim Based Relational Database Design Tutorial September 2008

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.

Page 37: Rim Based Relational Database Design Tutorial September 2008

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

Page 38: Rim Based Relational Database Design Tutorial September 2008

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

Page 39: Rim Based Relational Database Design Tutorial September 2008

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

Page 40: Rim Based Relational Database Design Tutorial September 2008

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

Page 41: Rim Based Relational Database Design Tutorial September 2008

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.

Page 42: Rim Based Relational Database Design Tutorial September 2008

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

Page 43: Rim Based Relational Database Design Tutorial September 2008

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.

Page 44: Rim Based Relational Database Design Tutorial September 2008

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

Page 45: Rim Based Relational Database Design Tutorial September 2008

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

Page 46: Rim Based Relational Database Design Tutorial September 2008

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

Page 47: Rim Based Relational Database Design Tutorial September 2008

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

Page 48: Rim Based Relational Database Design Tutorial September 2008

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)

Page 49: Rim Based Relational Database Design Tutorial September 2008

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

Page 50: Rim Based Relational Database Design Tutorial September 2008

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

Page 51: Rim Based Relational Database Design Tutorial September 2008

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

Page 52: Rim Based Relational Database Design Tutorial September 2008

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.

Page 53: Rim Based Relational Database Design Tutorial September 2008

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

=

Page 54: Rim Based Relational Database Design Tutorial September 2008

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

Page 55: Rim Based Relational Database Design Tutorial September 2008

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

Page 56: Rim Based Relational Database Design Tutorial September 2008

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

Page 57: Rim Based Relational Database Design Tutorial September 2008

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

Page 58: Rim Based Relational Database Design Tutorial September 2008

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.

Page 59: Rim Based Relational Database Design Tutorial September 2008

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

Page 60: Rim Based Relational Database Design Tutorial September 2008

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

Page 61: Rim Based Relational Database Design Tutorial September 2008

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.

Page 62: Rim Based Relational Database Design Tutorial September 2008

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

Page 63: Rim Based Relational Database Design Tutorial September 2008

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>

Page 64: Rim Based Relational Database Design Tutorial September 2008

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>

Page 65: Rim Based Relational Database Design Tutorial September 2008

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

Page 66: Rim Based Relational Database Design Tutorial September 2008

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

Page 67: Rim Based Relational Database Design Tutorial September 2008

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>

Page 68: Rim Based Relational Database Design Tutorial September 2008

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

Page 69: Rim Based Relational Database Design Tutorial September 2008

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

Page 70: Rim Based Relational Database Design Tutorial September 2008

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

Page 71: Rim Based Relational Database Design Tutorial September 2008

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

Page 72: Rim Based Relational Database Design Tutorial September 2008

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

Page 73: Rim Based Relational Database Design Tutorial September 2008

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

Page 74: Rim Based Relational Database Design Tutorial September 2008

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>

Page 75: Rim Based Relational Database Design Tutorial September 2008

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

Page 76: Rim Based Relational Database Design Tutorial September 2008

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

Page 77: Rim Based Relational Database Design Tutorial September 2008

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.

Page 78: Rim Based Relational Database Design Tutorial September 2008

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

Page 79: Rim Based Relational Database Design Tutorial September 2008

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

Page 80: Rim Based Relational Database Design Tutorial September 2008

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

Page 81: Rim Based Relational Database Design Tutorial September 2008

September 2008 HL7 RIM-Based Database Design 81 of 115

Instance Identifier

class II Datatype

InstanceIdentifier

- identifierNameSpace: ST- identifierValue: ST

Page 82: Rim Based Relational Database Design Tutorial September 2008

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

Page 83: Rim Based Relational Database Design Tutorial September 2008

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»

Page 84: Rim Based Relational Database Design Tutorial September 2008

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

Page 85: Rim Based Relational Database Design Tutorial September 2008

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»

Page 86: Rim Based Relational Database Design Tutorial September 2008

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.

Page 87: Rim Based Relational Database Design Tutorial September 2008

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

Page 88: Rim Based Relational Database Design Tutorial September 2008

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.

Page 89: Rim Based Relational Database Design Tutorial September 2008

September 2008 HL7 RIM-Based Database Design 89 of 115

Physical Quantity

class PhysicalQuantity

PhysicalQuantity

- quantityValue: REAL- quantityUnitCode: CD

Page 90: Rim Based Relational Database Design Tutorial September 2008

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

Page 91: Rim Based Relational Database Design Tutorial September 2008

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

Page 92: Rim Based Relational Database Design Tutorial September 2008

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

Page 93: Rim Based Relational Database Design Tutorial September 2008

September 2008 HL7 RIM-Based Database Design 93 of 115

Data Value

class DataValue

DataValue

- dataTypeCode: CD- booleanValue: BL- codedValue: CD

Page 94: Rim Based Relational Database Design Tutorial September 2008

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»

Page 95: Rim Based Relational Database Design Tutorial September 2008

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

Page 96: Rim Based Relational Database Design Tutorial September 2008

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

Page 97: Rim Based Relational Database Design Tutorial September 2008

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.

Page 98: Rim Based Relational Database Design Tutorial September 2008

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.

Page 99: Rim Based Relational Database Design Tutorial September 2008

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

Page 100: Rim Based Relational Database Design Tutorial September 2008

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

Page 101: Rim Based Relational Database Design Tutorial September 2008

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.

Page 102: Rim Based Relational Database Design Tutorial September 2008

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.

Page 103: Rim Based Relational Database Design Tutorial September 2008

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.

Page 104: Rim Based Relational Database Design Tutorial September 2008

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.

Page 105: Rim Based Relational Database Design Tutorial September 2008

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

Page 106: Rim Based Relational Database Design Tutorial September 2008

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

Page 107: Rim Based Relational Database Design Tutorial September 2008

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

Page 108: Rim Based Relational Database Design Tutorial September 2008

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

Page 109: Rim Based Relational Database Design Tutorial September 2008

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.

Page 110: Rim Based Relational Database Design Tutorial September 2008

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.

Page 111: Rim Based Relational Database Design Tutorial September 2008

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.

Page 112: Rim Based Relational Database Design Tutorial September 2008

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

Page 113: Rim Based Relational Database Design Tutorial September 2008

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

Page 114: Rim Based Relational Database Design Tutorial September 2008

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

Page 115: Rim Based Relational Database Design Tutorial September 2008

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

Page 116: Rim Based Relational Database Design Tutorial September 2008

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

Page 117: Rim Based Relational Database Design Tutorial September 2008

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

Page 118: Rim Based Relational Database Design Tutorial September 2008

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

Page 119: Rim Based Relational Database Design Tutorial September 2008

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

Page 120: Rim Based Relational Database Design Tutorial September 2008

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

Page 121: Rim Based Relational Database Design Tutorial September 2008

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

Page 122: Rim Based Relational Database Design Tutorial September 2008

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

Page 123: Rim Based Relational Database Design Tutorial September 2008

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)

• ;

Page 124: Rim Based Relational Database Design Tutorial September 2008

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

Page 125: Rim Based Relational Database Design Tutorial September 2008

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

Page 126: Rim Based Relational Database Design Tutorial September 2008

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

Page 127: Rim Based Relational Database Design Tutorial September 2008

September 2008 HL7 RIM-Based Database Design 127 of 115

Questions / Discussion / Feedback

Page 128: Rim Based Relational Database Design Tutorial September 2008

September 2008 HL7 RIM-Based Database Design 128 of 115

Closing Thought

Page 129: Rim Based Relational Database Design Tutorial September 2008

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.

Page 130: Rim Based Relational Database Design Tutorial September 2008

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]