Detailed Clinical Models WC3, March 29, 2007

Acknowledgements Joseph (Joey) Coyle Thomas (Tom) Oniki Craig Parker Yan Heras Roberto Rocha Harold Solbrig and many others …

Agenda What are the capabilities we want in the new system? Why are detailed clinical models essential? What are the implications for software development if we do detailed clinical models? The clinical element model in a nutshell Relationship of CE’s to other models Detailed clinical models and the PRD process

The essentials of the proposition The motivation for creating detailed clinical models is to support the capabilities we want the system to have Longitudinal conception to grave EHR Real-time patient specific decision support Sharing of data within and outside of the enterprise Clinical and administrative research and analysis Sharing of decision support logic and protocols Standard, open, modular, application development environment The only feasible way to meet these goals is to support detailed clinical models for clinical data that reference standard coded terminology

A Detailed Clinical Model

Longitudinal conception to grave EHR Comprehensive of all categories of clinical data History, physical, pharmacy, laboratory, … All types of data Text, numeric, coded, images, sounds, … Retained for 100+ years The legal record for all or part of the patient’s data The data will outlive any particular application, service, programming language, database, or message format

Real time, patient specific, decision support Alerts Potassium and digoxin Coagulation clinic Reminders Mammography Immunizations Protocols Ventilator weaning ARDS protocol Prophylactic use of antibiotics in surgery Advising Antibiotic assistant Critiquing Blood ordering Interpretation Blood gas interpretation Management – purpose specific aggregation and presentation of data DVT management Diabetic report

Sharing of data Sharing within the enterprise Between ADT/Registration, LIS, RIS, Labor and Delivery Sharing outside the enterprise Adverse event reporting (drugs and devices) Morbidity and mortality reporting Patient safety reporting Quality of care reports - HEDIS measures Regional Health Information Networks Bio-surveillance, infectious disease reports Cancer registries and disease specific repositories

Clinical and administrative research and analysis Clinical research at Intermountain Effects of inducing labor prior to 39 weeks Length of stay with TURPs Whole blood use Human genomic/proteonomic correlations Health population statistics Clinical trials Post-marketing information on drugs and devices Enrollment

National and international sharing of decision support modules There are more rules and knowledge to represent than a single entity can create Initiatives to allow sharing Arden syntax HL7 Decision Support Technical Committee SAGE – Shared Active Guideline Environment $18 million dollar NIST contract to IDX

Creating a new kind of Healthcare IT market place Separate application development (front end) from data persistence (back end) Common detailed models and terminology are shared public infrastructure, not market advantage or product discriminator Competition is based on making the best application and/or providing the best back end

Order Entry API (adapted from Harold Solbrig) IHC Order Entry Application Update Medication Order VA Order Services COS Interface Service Update PharmacyOrder WHERE orderNumber = “4674” … Data MUMPS Database

Update Medication Order Order Entry API – Different Client, Same Service (adapted from Harold Solbrig) Dept of Defense Application Update Medication Order VA Order Services COS Interface Service Update PharmacyOrder WHERE orderNumber = “4674” … MUMPS Database Data

Order Entry API (adapted from Harold Solbrig) . . . Application COS Interface Service Data

What things need to be in place to create a new market place? Standard set of detailed clinical data models coupled with… Standard coded terminology Standard API’s (Application Programmer Interfaces) for healthcare related services Open sharing of models, coded terms, and API’s

DCM – Detailed Clinical Models Create a national and international collaboration Independent Not-For-Profit organization, or as part of IHE or HL7 Create an open shared library of clinical models Associated vocabulary content linked to the models Providers as the primary participants/drivers

Agenda What are the capabilities we want in the new system? Why are detailed clinical models essential? What are the implications for software development if we do detailed clinical models? The clinical element model in a nutshell Relationship of CE’s to other models Detailed clinical models and the PRD process

Arden Syntax, “the curly braces problem” data: /* total calcium in mg/dL */ calcium := read last {'06210519','06210669','CALCIUM'} Etc. evoke storage_of_calcium; logic: /* if creatinine is present and greater than 6, then stop now */ IF creatinine is present THEN IF creatinine is greater than 6.0 THEN conclude false ENDIF ENDIF

The goal Have a shared logical model for detailed clinical data that is the basis for data referenced in shared guidelines The model should link information models and standardized coding schemes/reference terminologies There should be a standard logical model and syntax for these models There should be a repository where these models can be accessed

Need for coded data Tom East’s experience with “Oral meds” Oral, ORAL, Oral, ORALLY, Orally, ORALY, OR, or, PO, P.O., P.O, PO., po, per os, by mouth, … (26 variants) Observation #1: You can not anticipate all of the ways that information can be recorded in free text. Observation #2: You can not reliably execute real time decision logic against free text data Conclusion #1: You need coded data

Need for a standard model A stack of coded items is ambiguous (SNOMED CT) Numbness of right arm and left leg Numbness (44077006) Right (24028007) Arm (40983000) Left (7771000) Leg (30021000) Numbness of left arm and right leg Observation#3: You need to specify the order and roles of the codes

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

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

Model fragment in XML Pre-coordinated representation <observation> <cd>Dry weight (LOINC 8340-2) </cd> <value>70 kg</value> </observation> Post-coordinated (compositional) representation <cd>Weight (LOINC 3141-9) </cd> <qualifier> <cd> Weight type (LOINC 8337-8) </cd> <value> Dry (SNOMED CT 13880007) </value>

Relational database implications Patient Identifier Date and Time Observation Type Observation Value Units 123456789 7/4/2005 Dry Weight 70 kg 7/19/2005 Current Weight 73 Patient Identifier Date and Time Observation Type Weight type Observation Value Units 123456789 7/4/2005 Weight Dry 70 kg 7/19/2005 Current 73 How would you calculate the desired weight loss during the hospital stay?

I have presented the most simple examples. 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”

Some Observations Note that what we’ve talked about are differences at the “detail” level. The high level “model” of an Observation or a Med Administration wasn’t the question. It was the codes, the value constraints, the qualifiers, etc. that caused problems. We need consistent coded terminology and explicit, consistent models. Even a single enterprise needs multiple models for a single kind of data to support different user interfaces and different levels of pre-coordination

Pre and post coordinated models, families of “iso-semantic” models Model A (pre coordinated) Key: “Systolic BP Right Arm Sitting” Data: 120 mm/Hg Model B (post coordinated) Key: “Systolic BP” Data: 120 mm/Hg Location: “Right Arm” Position: “Sitting”

Agenda What are the capabilities we want in the new system? Why are detailed clinical models essential? What are the implications for software development if we do detailed clinical models? The clinical element model in a nutshell Relationship of CE’s to other models Detailed clinical models and the PRD process

What do we model using CE’s? 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

How are Clinical Element models used? Computer-to-Computer Interfaces Creation of maps from departmental/foreign system models to the standard storage model Core services Validation of data as it is stored in the database Decision logic Basis for referencing data in decision support logic Data entry screens, flow sheets, reports, ad hoc queries Basis for application access to clinical data Models do NOT dictate physical storage strategy

Validation in data storage service (DSS) Incoming Message CE models DSS Validate Codes and Terms DB Tables

Implications Data must be modeled before it is stored in the database Adequate resources must be allocated to support the modeling Modeling must be an essential part of the development process Tools need to be created to integrate use of the models with development processes

Agenda What are the capabilities we want in the new system? Why are detailed clinical models essential? What are the implications for software development if we do detailed clinical models? The clinical element model in a nutshell Relationship of CE’s to other models Detailed clinical models and the PRD process

EIM Subject Areas

Which “level” of model to implement as an object class? Implement only the core model as a Java class Other levels of models represented as constraints (interpreted metadata) on the core model Every model is a Java class ~10,000+ classes Something in the middle? Classes for patient, encounter, order, result, allergy

“The” Clinical Element Model Intermountain’s overall effort in the design of detailed clinical models Evolution and refinement of The Clinical Event Model which Intermountain has been using for the past 12 years. ~200 million instances of clinical data stored in our repository.

“A” Clinical Element Model A conceptual model for representing a piece of clinical data. Examples Systolic Blood Pressure model Heart Rate model Lab Panel model Order Model

A Clinical Element Model describes the constraints for a piece of Clinical Information

Models describe the constraints for… Type - The name of a particular model Key - Real world concept. Links model to an external coded terminology. Value Choice - Possible ways to convey the model’s value. Do not want to store LOINC, SNOMED code directly by design. We link to external coded terminology. 1. Impossible to correct errors made in standard terminology, I.e. SNOMED, unless change database. If use mapping, then can just change the mapping to correct the error. 2. Standard terminology makes mistakes.

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

A Simple Laboratory Observation

A Panel containing 2 Observations

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.

The use of Qualifiers

The use of Qualifiers

The use of Modifiers

The use of Modifiers

Modeling with CEML

Naming the new type <cetype name=“LabObservationQn”>

Constraining the Key for a Specializable Clinical Element <cetype name=“LabObservationQn”> <key domain=“LabObservationQn_DOMAIN_ECID”/> </cetype>

Constraining the Key for a Specializable Clinical Element <cetype name=“LabObservationQn”> <key domain=“LabObservationQn_DOMAIN_ECID”/> </cetype> Or in Longhand… <constraint path=“key.domain” value=“LabObservationQn_DOMAIN_ECID”/>

Constraining the HL7 datatype <cetype name=“LabObservationQn”> <key domain=“LabObservationQn_DOMAIN_ECID”/> <data type=“pq”/> </cetype>

Constraining the units of PQ <cetype name=“LabObservationQn”> <key domain=“LabObservationQn_DOMAIN_ECID”/> <data type=“pq”/> <constraint path=“data.pq.units.domain” value=“UnitsQn_DOMAIN_ECID”/> </cetype> Or… <data type=“pq”> <constraint path=“pq.units.domain” value=“UnitsQn_DOMAIN_ECID”/> </data>

Adding a qualifier <cetype name=“LabObservationQn”> <key domain=“LabObservationQn_DOMAIN_ECID”/> <data type=“pq”/> <qual name=“specimen” type=“Specimen” card=“0-1”/> <constraint path=“data.pq.units.domain” value=“UnitsQn_DOMAIN_ECID”/> </cetype>

Modeling a Specific Clinical Element <cetype name=“HematocritQn” base=“LabObservationQn”> <key code=“Hematocrit_ECID”/> <data type=“pq”/> <qual name=“specimen” type=“Specimen” card=“0-1”/> <constraint path=“data.pq.value” value=“0-100” type=“range” /> <constraint path=“data.pq.units.code” value=“PercentageUnit_ECID”/> </cetype>

Hard issues What level of model becomes a Java class? How do you make models easy to use in Java? Opposition to this level of detailed models Modeling of concepts and quantitative values in a single language/paradigm Huge diversity of modeling styles: how to be consistent? Defining computable connections between model and externally defined terminology Large number of models needed

Questions?