# 1 Practical modeling issues: Representing coded and structured patient data in EHR systems SHARP August 23, 2010 Stanley M Huff, MD Chief Medical Informatics Officer

# 2 Acknowledgements Tom Oniki Joey Coyle Yan Heras Cessily Johnson Julie Glasgow Roberto Rocha Lee Min Lau Craig Parker Many, many, others…

# 3 Why do we need detailed clinical models?

# 4 A diagram of a simplified clinical model

# 5 Need for a standard model A stack of coded items is ambiguous (SNOMED CT) –Numbness of right arm and left leg Numbness ( ) Right ( ) Arm ( ) Left ( ) Leg ( ) –Numbness of left arm and right leg Numbness ( ) Left ( ) Arm ( ) Right ( ) Leg ( )

# 6 70 What if there is no model? Dry Weight: Site #1 kg Weight: Site #2 Dry kg Wet Ideal

# 7 Too many ways to say the same thing A single name/code and value –Dry Weight is 70 kg Combination of two names/codes and values –Weight is 70 kg Weight type is dry

# 8 Model fragment in XML Pre-coordinated representation Dry weight (LOINC ) 70 kg Post-coordinated (compositional) representation Weight (LOINC ) Weight type (LOINC ) Dry (SNOMED CT ) 70 kg

# 9 Relational database implications How would you calculate the desired weight loss during the hospital stay? Patient Identifier Date and TimeObservation TypeObservation Value Units /4/2005Dry Weight70kg /19/2005Current Weight73kg Patient Identifier Date and TimeObservation Type Weight typeObservation Value Units /4/2005WeightDry70kg /19/2005WeightCurrent73kg

# 10 Another example If you use LOINC, and SNOMED –You still have many ways to express the same information A single name/code and value –Left patellar deep tendon reflex intensity is 2+ Combination of two names/codes and values –Patellar deep tendon reflex intensity is 2+ Laterality is left Combination of three names/codes and values –Deep tendon reflex intensity is 2+ Body location is patella –Laterality is left

# 11 More complicated items: Signs, symptoms Diagnoses Problem list Family History Use of negation – “No Family Hx of Cancer” Description of a heart murmur Description of breath sounds –“Rales in right and left upper lobes” –“Rales, rhonchi, and egophony in right lower lobe”

# 12 What do we model? All data in the patient’s EMR, including: –Allergies –Problem lists –Laboratory results –Medication and diagnostic orders –Medication administration –Physical exam and clinical measurements –Signs, symptoms, diagnoses –Clinical documents –Procedures –Family history, medical history and review of symptoms

# 13 How are the models used? Source of normalization specifications for data aggregation Payload in an NHIN Connect service exchange Target for the structured and encoded output from NLP Data entry screens, flow sheets, reports, ad hoc queries –Basis for application access to clinical data Computer-to-Computer Interfaces –Creation of maps from departmental/foreign system models to the standard database model Core data storage services –Validation of data as it is stored in the database Decision logic –Data references in phenotype definitions –Basis for referencing data in decision support logic Does NOT dictate physical storage strategy

# 14 Clinical modeling activities Netherlands – William Goossen, ISO, DCMs UK – NHS, Logical Record Architecture Australia - openEHR HL7 –Version 3 RIM, message templates –TermInfo –CDA plus Templates –Detailed Clinical Models VA Tolven NIH/NCI – Common Data Elements, CaBIG

# 15 Progress on a strategy for open sharing

# 16 Open Sharing of Models and Terms GE owns and holds the copyright for the models and terminology Intermountain has a perpetual license to distribute and sublicense the models and terminology for free GE and Intermountain are sharing the models in perpetuity without cost Models will be posted to a website for free download (terminology to follow) No cost license to protect Intermountain and GE use Anyone is allowed to make and own derivative works

# 17 Access to the models Send me an and I will send you a zip file Web browser – –Works best with Mozilla Firefox browser

# 18 Model Classes Created Patient, Employee, Provider, Organization, ContactParty, PatientContact (visit), ServiceDeliveryLocation, AdmitDiagnosis HealthIssue (Problem), Allergy, Intolerance, Document Order –OrderLab, OrderLabMicro, OrderBloodProduct –OrderMedAmb, OrderMedCont, OrderMedInt, OrderMedPCA, OrderMedReg –OrderNutrition, OrderRadiology, OrderNursing, OrderRepiratory, OrderTherapies LabObs, MicroLabObs, Assert, Eval, Meas, Proc Qualifiers, Modifiers (Subject), Attributions, Panels

# 19 Model Subtypes Created Number of models created –Laboratory models – 2933 –Evaluations – 210 –Measurements – 353 –Assertions – 143 –Procedures – 87 –Qualifiers, Modifiers, and Components Statuses – 26 Date/times – 27 Others – 400+ –Panels – 79

# 20 We assume that the model is used in association with a terminology server.

Model and Terminology MedicationOrder { drug PenVK, dose 250, route Oral, frequency Q6H, startTime 09/01/95 10:01, endTime 09/11/95 23:59, orderedBy Don Jones, M.D., orderNumber A } Instance data MedicationOrder ::= SET { drug Drug, dose Decimal, route DrugRoute, frequency DrugFrequency, startTime DateTime, endTime DateTime, orderedBy Clinician, orderNumber OrderNumber} Model If the medicationOrder.drug is_a “antibiotic” then notify the infection control officer.

# 22 Concept Semantic Network Drugs Antibiotics Analgesics Cardiovascular Penicillins Aminoglycosides CephalosporinsPen VK Amoxicillin Nafcillin

# 23 Denormalized Semantic Network Drugshas-childAntibiotics Drugshas-childAnalgesics Drugshas-childCardiovascular Antibioticshas-childPenicillins Antibioticshas-childCephalosporins Antibioticshas-childAminoglycosides Penicillinshas-childPen VK Penicillinshas-childAmoxicillin Penicillinshas-childNafcillin Drugshas-memberAntibiotics Drugshas-memberPenicillins Drugshas-memberPen VK Drugshas-memberAmoxicillin Drugshas-memberNafcillin

# 24 Model Centered Data Representation Models Models and Concepts SNOMED ICD-10 RxNorm FDB LOINC CPT SNOMED ICD-10 RxNorm FDB LOINC CPT LexGrid Terminology Server Context Specific Mapping Tables ECIS Thesaurus Mayo Thesaurus Internal Terminology (ECIDS) IH Thesaurus

# 25 The Clinical Element Model

# 26 The Logical Structure is Preeminent A formalism is needed to be able to discuss the modeling issues. However, the particulars of a particular formalism is not the issue. The logical structure of the data and relationships and associations between data elements is the most important thing. What are the issues of “style” that we can agree on?

# 27 Basic elements of the core model Type - The name of a particular model Key - Links the model to a concept in an external coded terminology. Value Choice - Possible ways to convey the model’s value.

# 28 Value Choice Data - Value conveyed as an HL7 version 3 data type Items - Value conveyed by multiple Clinical Elements collectively

# 29 A Simple Laboratory Observation SerumSodiumMeas

# 30 Simplified Representation

# 31 A Panel containing 2 Observations

# 32 Mods and Quals of the Value Choice Mods - Component CE’s which change the meaning of the Value Choice. Quals - Component CE’s which give more information about the Value Choice.

# 33 The use of Qualifiers

# 34 The use of Qualifiers

# 35 The use of Modifiers

# 36 The use of Modifiers

# 37 Clinical Element Modeling Language (CEML)

# 38 Model Source Expression (CEML)

# 39 Type “name” and “key code” … The name of this model Binding to a single “observable” concept

# 40 Binding to a “domain” (value set) Path to the coded element The name of the terminology “domain” that the element is “bound” to

# 41 Domain (value set) definition A domain (value set) is defined by –A head node (concept) –The name of a relationship (is_a, part_of, component_of, has_ingredient, etc.) –All of the concepts that have the named relationship to the head node Domains are maintained in the terminology server

CDL – Constraint Definition Language Intermountain and GE will be moving to CDL “soon” CDL has CEML capabilities and more CDL is easier to parse than CEML CDL is NOT an XML language CDL is a context free language # 42

# 43 “Isosemantic” Models

# 44 Pre and Post Coordination data 138 mmHg SystolicBPRightArmSitting SystolicBPRightArmSittingObs data 138 mmHg quals SystolicBP SystolicBPObs data Right Arm BodyLocation data Sitting PatientPosition Precoordinated Model (User Interface Model) Post coordinated Model (Storage Model)

# 45 Most Pre – Coordinated Model data 138 mmHg PatientSystolicBPRightArmSittingAdultCuff PatientSystolicBPRightArmSittingAdultCuffObs quals AbnormalFlag abnormalFlag DeltaFlag deltaFlag ReferenceRangeNar referenceRangeNar RelativeTemporalContext relativeTemporalContext Observed observed ReportedReceived reportedReceived Verified verified “Standard Qualifiers” In Subsequent Models

# 46 Post Coordinated “Subject” data 138 mmHg SystolicBPRightArmSittingAdultCuff SystolicBPRightArmSittingAdultCuffObs mods Subject subject plus “Standard Qualifiers”

# 47 Post Coordinated “Subject” and “BodyLocation” data 138 mmHg SystolicBPSittingAdultCuff SystolicBPSittingAdultCuffObs mods Subject subject BodyLocationPrecoord bodyLocationPrecoord plus “Standard Qualifiers” quals

# 48 Expanded BodyLocation data 138 mmHg SystolicBPSittingAdultCuffSystolicBPSittingAdultCuffObs mods Subject subject BodyLocation bodyLocation plus “Standard Qualifiers” quals BodySide bodySide BodyLateralitybodyLaterality data {Body Location} BodyLocationQualifierbodyLocationQualifier quals

# 49 Post Coordinated subject, loc, device data 138 mmHg SystolicBPSitting SystolicBPSittingObs mods Subject subject BodyLocationPrecoord bodyLocationPrecoord plus “Standard Qualifiers” MethodDevice methodDevice quals

# 50 Post Coordinated subject, loc, device, position data 138 mmHg SystolicBP SystolicBPObs mods Subject subject BodyLocationPrecoord bodyLocationPrecoord plus “Standard Qualifiers” MethodDevice methodDevice BodyPosition bodyPosition quals

# 51 Fully Atomic SysBP Model data 138 mmHg SystolicBPSystolicBPObs Subject subject BodyLocation bodyLocation plus “Standard Qualifiers” BodySide bodySide BodyLateralitybodyLaterality data {Body Location} BodyLocationQualifierbodyLocationQualifier MethodDevice methodDevice BodyPosition bodyPosition

# 52 Isosemantic models User interface models –Convenient for data entry –Typically pre-coordinated –Many variations Storage models –Only one model is designated as the storage model –Comprehensive set of qualifiers and modifiers –The storage model is referenced in reports, rules, protocols, data analysis Composition – Decomposition mappings

# 53 Decomposition Mapping data 138 mmHg SystolicBPRightArmSitting SystolicBPRightArmSittingObs data 138 mmHg quals SystolicBP SystolicBPObs data Right Arm BodyLocation data Sitting PatientPosition Precoordinated Model (User Interface Model) Post coordinated Model (Storage Model)

# 54 Information Model Ideas HL7 Translator HTML UML openEHR Archetype V2 “|” CEMs DCMs CDA Templates LRA Models HL7 Shared Format HL7 Shared Format HL7 Shared Format HL7 Shared Format HL7 Shared Format openEHR Archetypes CEN Archetypes CEMs DCMs CDA Templates openEHR Archetypes CEN Archetypes CMETs, HMDs RMIMs LRA Models CMETs, HMDs RMIMs Standard Terminologies V2 XML V3 XML V3 Next CEN Archetype CDA SOA Payload CEM LRA OWL

Discussion Questions How do you want to use models? –UML, XML, Java What instance representations should we support? –XML, Java, CDA, HL7 V2, HL7 V3 (classic), HL7 V3 abbreviated ITS, others Search tools and browsers Requesting a new model or a change to an existing model Moving developed models to the public website # 55

# 56 Questions?