Rim Based Relational Database Design Tutorial September 2008

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

About Me Abdul-Malik Shakir Principal 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

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

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.

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.

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

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

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.

HL7 v3.0 Reference Models Reference Information Model Datatype Specification Vocabulary 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.

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. Entity class_cd : CS cd: CE determiner_cd : CS status_cd : CS id : II Act class_cd : CS cd: CD mood_cd : CS status_cd : CS effective_time : GTS id : II 0..* 0..*

RIM Core Classes Entity class_cd : CS cd: CE determiner_cd : CS status_cd : CS id : II Role class_cd : CS cd: CE effective_time : IVL<TS> status_cd : CS id : II Act class_cd : CS cd: CD mood_cd : CS status_cd : CS effective_time : GTS id : II 0..* 0..* 1 0..* plays

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). Entity class_cd : CS cd: CE determiner_cd : CS status_cd : CS id : II Role class_cd : CS cd: CE effective_time : IVL<TS> status_cd : CS id : II Act class_cd : CS cd: CD mood_cd : CS status_cd : CS effective_time : GTS id : II 0..* 0..* 0..1 0..* 0..1 0..* plays scopes

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. Entity class_cd : CS cd: CE determiner_cd : CS status_cd : CS id : II Role class_cd : CS cd: CE effective_time : IVL<TS> status_cd : CS id : II Participation type_cd : CS time : IVL<TS> status_cd : CS Act class_cd : CS cd: CD mood_cd : CS status_cd : CS effective_time : GTS id : II 0..1 0..* 0..1 0..* plays scopes 1 0..* 1 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. Entity class_cd : CS cd: CE determiner_cd : CS status_cd : CS id : II Role class_cd : CS cd: CE effective_time : IVL<TS> status_cd : CS id : II Participation type_cd : CS time : IVL<TS> status_cd : CS Act class_cd : CS cd: CD mood_cd : CS status_cd : CS effective_time : GTS id : II 0..1 0..* Act Relationship type_cd : CS 0..1 0..* plays scopes 1 0..* 1 0..* 1 1 0..* 0..*

Role Link – An association between two Roles . It is used to capture relationships that exists between Entities other than the scoping relationships. A RIM Core Classes Entity class_cd : CS cd: CE determiner_cd : CS status_cd : CS id : II Role class_cd : CS cd: CE effective_time : IVL<TS> status_cd : CS id : II Participation type_cd : CS time : IVL<TS> status_cd : CS Act class_cd : CS cd: CD mood_cd : CS status_cd : CS effective_time : GTS id : II 0..1 0..* Role Link type_cd : CS effective_time : IVL<TS> Act Relationship type_cd : CS 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 0..* 1 0..* 1 1 0..* 0..* 1 1 0..* 0..*

Definition of RIM Core Classes Act – a discernible action of interest in the healthcare domain . An instance of Act is a record of that action. Acts definitions (master files), orders, plans, and performance records (events) are all represented by an instance of Act. Act relationship – an association between two Acts . This includes Act to Act associations such as collector/component, predecessor/successor, and cause/outcome. The semantics of the association is captured by the Act Relationship attributes. Entity - a physical thing or an organization/group of physical things capable of participating in Acts . This includes living subjects, organizations, material, and places. Participation – an association between a Role and an Act representing the function assumed by the Role within the context of the Act . A single Role may participate in multiple Acts and a single Act may have multiple participating Roles. A single Participation is always an association between a particular Role and a particular Act. Role – a classification/specialization of an Entity defined by the relationship of the playing Entity to a scoping Entity . An example of Role is “Employee”. An employee is a classification attributed to a person which has an employment relationship with an organization (Employer). Role Link – An association between two Roles . It is used to capture relationships that exists between Entities other than the scoping relationships. A single Role may have a Role Link with multiple other Roles. A single Role Link is always between two distinct instances of Role.

HL7 RIM Normative Specification

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.

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.

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

v3.0 Ballot Datatype Categories Basic Datatypes Boolean (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 Collections Bag (BAG) Interval (IVL) Set (SET) Sequence (LIST) Generic Type Extensions History Item (HXIT) History (HIST) Uncertain Value - Narrative (UVN) Uncertain Value - Probabilistic (UVP) Non-Parametric Probability Distribution (NPPD) Parametric Probability Distribution (PPD) Timing Specifications Periodic Interval of Time (PIVL) Event-Related Periodic Interval of Time (EIVL) General Timing Specification (GTS) GTS SET HIST BL ST ED

Basic Datatype Descriptions 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". CD Concept Descriptor 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. CE Coded With Equivalents Coded data, consists of a code, display name, code system, and original text. Used when a single code value must be sent. CV Coded Value 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. CS Coded Simple Value 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. ST Character String 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. ED Encapsulated Data The Boolean type stands for the values of two-valued logic. A Boolean value can be either true or false. BL Boolean Description Symbol Name

Basic Datatype Descriptions Positive and negative whole numbers typically the results of counting and enumerating. The standard imposes no bounds on the size of integer numbers. INT Integer Number 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. TN Trivial Name 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. ON Organization Name 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. PN Person Name 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. EN Entity Name For example, a mailing address. Typically includes street or post office Box, city, postal code, country, etc. AD Postal Address 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.) TEL Telecommunication Address 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) II Instance Identifier Description Symbol Name

Basic Datatype Descriptions 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." GTS General Timing Specification A time stamp. TS Point in Time 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. RTO Ratio The amount of money in some currency. Consists of a value and a currency denomination (e.g., U.S.$, Pound sterling, Euro, Indian Rupee.) MO Monetary Amount 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.) PQ Physical Quantity 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. REAL Decimal number Description Symbol Name

Entity Name Data Types Data Type Features: Inheritance Structure Structural Properties Relational Properties Operational Properties Constraint Properties

Concept Descriptor Data Types Data Type Category : Abstract Primitive Complex Computational Parameterized

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»

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.

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.

HL7 V3 Vocabulary Specification Schematic ParentConcept VocabularyDomain name : String description : String CodedConcept conceptCode : String conceptDesignation : String 0..* 0..* 0..* 0..* ValueSet name : String description : String definingExpression : String 0..* 0..* 0..* 0..* 0..* 0..* includes CodeSystem identifier : OID name : String description : String 0..* 0..* 0..* 0..1 0..* 0..1 based on ValueSetContext contextExpression : String

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.

HL7 Reference to External Code Systems

Vocabulary Binding Vocabulary Terms Vocabulary Binding Information Model Class Attribute Vocabulary Domain Value Set Coded Concept Code System 1 0..* 0..* 0..1 0..1 0..* 0..* 0..* 0..* 0..* 0..* 1 0..* 0..1

Normative RIM Structural Vocabulary ActClass ActStatus ParticipationType ActMood ContextControl RelationshipConjunction ActRelationshipCheckpoint EntityClass RoleClass ActRelationshipJoin EntityDeterminer RoleLinkType ActRelationshipSplit EntityStatus RoleStatus ActRelationshipType ManagedParticipationStatus (Most vocabulary domains are published as informative references. Those domains that have a more formal ballot status are shown in bold in this table. See the domain for the exact status.) AcknowledgementCondition AcknowledgementDetailCode AcknowledgementDetailType AcknowledgementMessageCode AcknowledgementType AcknowledgmentMessageType ActClass ActCode ActInjuryCode ActInvoiceElementModifier ActMood ActPatientTransportationModeCode ActPaymentReason ActPriority ActProcedureCode ActReason ActRelationshipCheckpoint ActRelationshipJoin ActRelationshipRelatedOrder ActRelationshipSplit ActRelationshipSubset ActRelationshipType ActSite ActStatus ActTherapyDurationWorkingListCode ActUncertainty AddressPartType AdministrativeGender AmericanIndianAlaskaNativeLanguages AttentionKeyword BatchName Calendar CalendarCycle CalendarType CaseDetectionMethod CaseDiseaseImported CaseTransmissionMode Charset CodeSystem CodeSystemType CodingRationale CommunicationFunctionType CompressionAlgorithm ConceptCodeRelationship ConceptGenerality ConceptPropertyId ConceptStatus Confidentiality ContainerCap ContainerSeparator ContextControl Country CoverageEligibilityReason Currency DataType DeviceAlertLevel Diagnosis DocumentCompletion DocumentStorage EditStatus EducationLevel ElementName EmployeeJob EmployeeJobClass EmployeeSalaryType EmploymentStatus EncounterAccident EncounterAcuity EncounterAdmissionSource EncounterDischargeDisposition EncounterReferralSource EncounterReferralSource EncounterSpecialCourtesy EntityClass EntityCode EntityDeterminer EntityHandling EntityNamePartQualifier EntityNamePartType EntityNameUse EntityRisk EntityStatus EquipmentAlertLevel Ethnicity ExposureAgentEntityType GTSAbbreviation GenderStatus HL7CommitteeIDInRIM HL7ConformanceInclusion HL7DefinedRoseProperty HL7ITSVersionCode HL7StandardVersionCode HL7UpdateMode HealthcareProviderTaxonomyHIPAA HtmlLinkType HumanActSite HumanLanguage ImagingSubjectOrientation IndustryClassificationSystem IntegrityCheckAlgorithm InvoiceElementModifier JobTitleName LanguageAbilityMode LanguageAbilityProficiency ListOwnershipLevel LivingArrangement LocalMarkupIgnore LocalRemoteControlState MDFAttributeType MDFSubjectAreaPrefix ManagedParticipationStatus ManufacturerModelName MapRelationship MaritalStatus MaterialForm MaterialType MdfHmdMetSourceType MdfHmdRowType MdfRmimRowType MediaType MessageCondition MessageWaitingPriority ModifyIndicator NullFlavor ObservationInterpretation ObservationMethod ObservationValue OrganizationIndustryClass OrganizationNameType OtherIndicationValue ParameterizedDataType ParticipationFunction ParticipationMode ParticipationSignature ParticipationType PatientImportance PaymentTerms PeriodicIntervalOfTimeAbbreviation PersonDisabilityType PostalAddressUse PrescriptionDispenseFilterCode ProbabilityDistributionType ProcedureMethod ProcessingID ProcessingMode ProviderCodes QueryParameterValue QueryPriority QueryQuantityUnit QueryRequestLimit QueryResponse QueryStatusCode Race Realm RelationalName RelationalOperator RelationshipConjunction ReligiousAffiliation ResponseLevel ResponseModality ResponseMode RoleClass RoleCode RoleLinkType RoleStatus RouteOfAdministration SQLConjunction Sequencing SetOperator SoftwareName SpecialAccommodation StyleType SubstitutionCondition TableCellHorizontalAlign TableCellScope TableCellVerticalAlign TableFrame TableRules TargetAwareness TelecommunicationAddressUse TimingEvent TribalEntityUS URLScheme UnitsOfMeasureCaseInsensitive UnitsOfMeasureCaseSensitive VaccineManufacturer VaccineType ValueSetOperator ValueSetPropertyId ValueSetStatus VerificationMethod VocabularyDomainQualifier (Most vocabulary domains are published as informative references. Those domains that have a more formal ballot status are shown in bold in this table. See the domain for the exact status.) AcknowledgementCondition AcknowledgementDetailCode AcknowledgementDetailType AcknowledgementMessageCode AcknowledgementType AcknowledgmentMessageType ActClass ActCode ActInjuryCode ActInvoiceElementModifier ActMood ActPatientTransportationModeCode ActPaymentReason ActPriority ActProcedureCode ActReason ActRelationshipCheckpoint ActRelationshipJoin ActRelationshipRelatedOrder ActRelationshipSplit ActRelationshipSubset ActRelationshipType ActSite ActStatus ActTherapyDurationWorkingListCode ActUncertainty AddressPartType AdministrativeGender AmericanIndianAlaskaNativeLanguages AttentionKeyword BatchName Calendar CalendarCycle CalendarType CaseDetectionMethod CaseDiseaseImported CaseTransmissionMode Charset CodeSystem CodeSystemType CodingRationale CommunicationFunctionType CompressionAlgorithm ConceptCodeRelationship ConceptGenerality ConceptPropertyId ConceptStatus Confidentiality ContainerCap ContainerSeparator ContextControl Country CoverageEligibilityReason Currency DataType DeviceAlertLevel Diagnosis DocumentCompletion DocumentStorage EditStatus EducationLevel ElementName EmployeeJob EmployeeJobClass EmployeeSalaryType EmploymentStatus EncounterAccident EncounterAcuity EncounterAdmissionSource EncounterDischargeDisposition EncounterReferralSource EncounterReferralSource EncounterSpecialCourtesy EntityClass EntityCode EntityDeterminer EntityHandling EntityNamePartQualifier EntityNamePartType EntityNameUse EntityRisk EntityStatus EquipmentAlertLevel Ethnicity ExposureAgentEntityType GTSAbbreviation GenderStatus HL7CommitteeIDInRIM HL7ConformanceInclusion HL7DefinedRoseProperty HL7ITSVersionCode HL7StandardVersionCode HL7UpdateMode HealthcareProviderTaxonomyHIPAA HtmlLinkType HumanActSite HumanLanguage ImagingSubjectOrientation IndustryClassificationSystem IntegrityCheckAlgorithm InvoiceElementModifier JobTitleName LanguageAbilityMode LanguageAbilityProficiency ListOwnershipLevel LivingArrangement LocalMarkupIgnore LocalRemoteControlState MDFAttributeType MDFSubjectAreaPrefix ManagedParticipationStatus ManufacturerModelName MapRelationship MaritalStatus MaterialForm MaterialType MdfHmdMetSourceType MdfHmdRowType MdfRmimRowType MediaType MessageCondition MessageWaitingPriority ModifyIndicator NullFlavor ObservationInterpretation ObservationMethod ObservationValue OrganizationIndustryClass OrganizationNameType OtherIndicationValue ParameterizedDataType ParticipationFunction ParticipationMode ParticipationSignature ParticipationType PatientImportance PaymentTerms PeriodicIntervalOfTimeAbbreviation PersonDisabilityType PostalAddressUse PrescriptionDispenseFilterCode ProbabilityDistributionType ProcedureMethod ProcessingID ProcessingMode ProviderCodes QueryParameterValue QueryPriority QueryQuantityUnit QueryRequestLimit QueryResponse QueryStatusCode Race Realm RelationalName RelationalOperator RelationshipConjunction ReligiousAffiliation ResponseLevel ResponseModality ResponseMode RoleClass RoleCode RoleLinkType RoleStatus RouteOfAdministration SQLConjunction Sequencing SetOperator SoftwareName SpecialAccommodation StyleType SubstitutionCondition TableCellHorizontalAlign TableCellScope TableCellVerticalAlign TableFrame TableRules TargetAwareness TelecommunicationAddressUse TimingEvent TribalEntityUS URLScheme UnitsOfMeasureCaseInsensitive UnitsOfMeasureCaseSensitive VaccineManufacturer VaccineType ValueSetOperator ValueSetPropertyId ValueSetStatus VerificationMethod VocabularyDomainQualifier

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.

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

SIIS SIP Logical Data Model Classes Facility Facility Alternate Identifier Organization Patient Patient Relationship Person PersonAlternateName PersonIdentifier PersonPostalAddress PersonTelecommunicationAddress Treatment Refusal Vaccine Administration

SIIS SIP Information Needs RMIM

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 (Treatment Refusal) Observation (Patient Registry Observation) Substance Administration (Vaccine Administration)

SIIS SIP RIM Class Subset Model (Level 0)

SIIS SIP RIM Attribute Subset Model (Level 1)

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.

Generalization Relationships Indicate Inheritance =

Association Method Replace the generalization relationships with optional one-to-one association relationships =

Propagation Method Propagate attributes and associations from the parent generalization class into child specialization classes =

Promotion Method Promote attributes and associations from child specialization classes into their parent generalization class =

RIM Subset Model (Inheritance Exposed)

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.

RIM Subset Model (Inheritance Anomalies Resolved)

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.

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>

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>

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

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>

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

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

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

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>

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.

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

II: Instance Identifier 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.) optional IVL<TS> validTime 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. optional ST assigningAuthorityName 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. mandatory OID root The value of the identifier, unique within its assigning authority's namespace. optional ST extension Definition Status Type Name

AD: Postal Address ADXP: Postal Address Part Identifies 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. optional GTS validTime A code advising a system or user which address in a set of like addresses to select for a given purpose optional SET < CS > use The address data mandatory LIST < ADXP > Definition Status Type Name Indicates whether an address part is the street, city, country, postal code, post box, etc. optional CS type The address part data mandatory ST ST Definition Status Type Name

EN: Entity Name ENXP: Entity Name Part Entity Name Specializations: TN: Trivial Name PN: Person Name ON: Organization Name A set of codes each of which specifies a certain subcategory of the name part in addition to the main name part type EntityNameQualifier NULL optional SET < CS > qualifier Indicates whether the name part is a given name, family name, prefix, suffix, etc. EntityNamePartType NULL optional CS type The entity name part data NULL mandatory ST Definition Constraint Default Status Type Name Identifies the interval of time during which the name was used. Typically used to record historical names. NULL optional IVL<TS> validTime A code advising a system or user which name in a set of names to select for a given purpose NamePurpose NULL optional SET < CS > use The name data NULL mandatory LIST < ENXP > Definition Constraint Default Status Type Name

Tel: Telecommunication Address 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. optional GTS validTime A code advising a system or user which telecommunication address in a set of like addresses to select for a given telecommunication need. optional SET < CS > use The essence of a telecommunication address is a Universal Resource Locator. mandatory URL URL Definition Status Type Name

PQ: Physical Quantity The original unit of measure. optional CV original unit The magnitude of the quantity measured in terms of the original unit. optional REAL original value The unit of measure mandatory CS unit The magnitude of the quantity measured in terms of the unit mandatory REAL value Definition Status Type Name

CD: Concept Descriptor 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 translation 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." modifier 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 ..."). originalText A string qualifying the version of the code system (e.g., "Model Year 2001"). codeSystemVersion A string containing a short, human-readable description of the code system (e.g., "Ford Car and Truck Models "). codeSystemName 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). codeSystem A string containing a short, human-readable description of the code. ("Ford F150 Full-size Pickup Truck") displayName A string containing the value of the code (e.g., "F150") code Description Name

Concept Descriptor Datatypes CS: Coded Simple CV: Coded Value CE: Coded With Equivalents optional ST displayName mandatory ST code Status Type Name optional ST originalText optional ST codeSystemVersion optional ST codeSystemName mandatory OID codeSystem optional ST displayName mandatory ST code Status Type Name optional SET < CV > translation optional ST originalText optional ST codeSystemVersion optional ST codeSystemName mandatory OID codeSystem optional ST displayName mandatory ST code Status Type Name

Property Summary of Concept Descriptor

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.

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.

RIM Logical Data Model (Level 1)

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.

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.

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.

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.

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.

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

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.

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.

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.

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

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

Reduce ambiguity and abstraction

Optimal Performance and Future Proofing

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) 1 0..1 (entityID = entityID) 1 0..* (entityID = entityID) 1 0..* (roleID = roleID) 1 0..1 (entityID = entityID) 1 0..* (entityID = entityID) 1 0..* (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

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

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

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 SDM LDM PDM

Questions / Discussion / Feedback

Closing Thought All models are wrong; some are useful. ~ George Box

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.

Thank You Abdul-Malik Shakir Principal Consultant Shakir Consulting 1407 Foothill Blvd., Suite 145 La Verne, CA 91750 Office: (909) 596-6790 Mobile: (626) 644-4491 Email: AbdulMalik@ShakirConsulting.com

Rim Based Relational Database Design Tutorial September 2008

More Related Content

What's hot (20)

Similar to Rim Based Relational Database Design Tutorial September 2008 (20)

More from Abdul-Malik Shakir (11)

Recently uploaded (20)

Rim Based Relational Database Design Tutorial September 2008