Detailed Clinical Models WC3, March 29, 2007

1. Detailed Clinical ModelsWC3, March 29, 2007

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

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

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

5. A Detailed Clinical Model

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

7. 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 Real time, patient specific, decision support

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

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

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

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

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

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

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

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

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

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

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

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

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

21. 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 • Numbness (44077006) • Left (7771000) • Arm (40983000) • Right (24028007) • Leg (30021000) • Observation#3: You need to specify the order and roles of the codes

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

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

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

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

26. 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”

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

28. 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” Pre and post coordinated models, families of “iso-semantic” models

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

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

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

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

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

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

35. EIM Subject Areas

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

38. “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.

39. “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

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

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

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

43. A Simple Laboratory Observation

44. A Panel containing 2 Observations

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

46. The use of Qualifiers

47. The use of Qualifiers

48. The use of Modifiers

49. The use of Modifiers

50. Modeling with CEML