Clinical Element Models

1. Clinical Element Models W3C Semantic Web Healthcare and Life Sciences Interest Group November 8, 2007 Tom Oniki, PhD Sr. Medical Informaticist Intermountain Healthcare Salt Lake City, UT

2. Acknowledgements • Stan Huff, Joey Coyle, Craig Parker, Yan Heras, and many others

3. Intermountain Healthcare • Health Delivery Network, not-for-profit • Serving Utah and Southern Idaho • 21 Hospitals/ 2105 beds/150 Clinics • Medical Group of 550 employed physicians • Insurance plan of 500,000 covered lives • $85M/year charitable care exclusive of bad debt • 27,000 employees • Partner in the Utah Health Information Network

4. The essentials of the proposition • The need for the clinical models is dictated by what we want to accomplish as providers of health care • The best clinical care requires the use of computerized clinical decision support and automated data analysis • Clinical decision support and automated data analysis can only function against standard structured coded data • Detailed clinical models provide the standard structure and terminology needed for clinical decision support and automated data analysis • One important clinical decision support and automated data analysis use case is clinical trials recruitment

5. The Clinical Element Model • Intermountain Healthcare’s design for 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.

6. What do we model using Clinical Element Models (CEMs)? • 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

7. How will Clinical Element models be used? • Interfaces • Core services • Decision logic • Data entry screens, flow sheets, reports, ad hoc queries • Does NOT dictate physical storage strategy

8. The Systolic Blood Pressure Example in CEML <cetype name="SystolicBloodPressureMeas"> <key code="SystolicBloodPressureMeas_KEY_ECID"/> <qual name="bodyPosition" card="0-1"/> <constraint path="qual.bodyPosition.data.cwe.domain" value="BloodPressureBodyPosition_DOMAIN_ECID"/> <constraint path="data.pq.unit.domain" value="PressureUnitOfMeasure_DOMAIN_ECID"/> <constraint path="data.pq.unit.preferred" value="mmHg_ECID"/> </cetype>

9. The Clinical Element Model • 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.

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

11. A Simple Observation Clinical Element SystolicBloodPressureMeas (concept that represents “our model for capturing systolic blood pressure measurements”) type SystolicBloodPressure (“real world” concept; may be mapped to SNOMED code) key data 120 mm Hg

12. A Simple Observation (shorthand) SystolicBloodPressureMeas SystolicBloodPressure (“real world” concept; may be mapped to SNOMED code) key data 120 mm Hg

13. A panel containing two observations BloodPressurePanel BloodPressure key items SystolicBloodPressureMeas SystolicBloodPressure key 120 mmHg data DiastolicBloodPressureMeas DiastolicBloodPressure key 80 mmHg data

14. Qualifiers of the Value Choice • Qualifiers – CEM’s which give more information about the Value Choice.

15. The use of Qualifiers SystolicBloodPressureMeas key SystolicBloodPressure data 120 mmHg

16. The use of Qualifiers SystolicBloodPressureMeas key SystolicBloodPressure data 120 mmHg quals BodyPosition key BodyPosition data Sitting

17. The use of Qualifiers SystolicBloodPressureMeas key SystolicBloodPressure data 120 mmHg quals BodyPosition key BodyPosition data Sitting Controlled Terminology Codes!

18. Modeling Issues

19. Let’s see, I want to analyze numbness symptoms in neurological patients . . . More than just groups of codes

20. Let’s see, I want to analyze numbness symptoms in neurological patients . . . More than just groups of codes • Fortunately, we store SNOMED CT codes. I see this patient had: • Numbness (44077006) • Right (24028007) • Arm (40983000) • Left (7771000) • Leg (30021000)

21. Let’s see, I want to analyze numbness symptoms in neurological patients . . . More than just groups of codes • Fortunately, we store SNOMED CT codes. I see this patient had: • Numbness (44077006) • Right (24028007) • Arm (40983000) • Left (7771000) • Leg (30021000) • But does this mean: • Numbness of right arm and left leg? • Numbness of left arm and right leg? • Numbness of both arms and legs?

22. Different ways to model If Dry Weight> 70 kg, then . . . • What if Dry Weight is stored/accessed as: • A single name/code and value • Dry Weight = 70 kg

23. Different ways to model If Dry Weight> 70 kg, then . . . • What if Dry Weight is stored/accessed as: • A single name/code and value • Dry Weight = 70 kg • The combination of two names/codes and values • Weight = 70 kg • Weight type = “dry”

24. Different ways to model If Dry Weight> 70 kg, then . . . • IF • (Dry Weight > 70 kg • OR • (Weight > 70 kgANDWeight type = “dry”) • THEN . . .

25. Different ways to model If Dry Weight> 70 kg, then . . . • IF • (Dry Weight > 70 kg • OR • (Weight > 70 kgANDWeight type = “dry”) • OR . . . • are there any other ways??) • THEN . . .

26. Different ways to model If Dry Weight> 70 kg, then . . . • IF • (Dry Weight > 70 kg • OR • (Weight > 70 kgANDWeight type = “dry”) • OR . . . • are there any other ways??) • THEN . . . We want to store only one way!

27. Different ways to model Another example: “Systolic Blood Pressure Taken from the Right Arm with a Cuff” • Stored/accessed as: • A single name/code and value • Right Arm Cuff Systolic Blood Pressure = 120 mm Hg • The combination of multiple names/codes and values • Systolic Blood Pressure = 120 mm Hg • Body Location = “arm” • Body Location Laterality = “right” • Device = “cuff”

28. Different ways to model Another example: “Systolic Blood Pressure Taken from the Right Arm with a Cuff” • Even if we store it this way: • Systolic Blood Pressure = 120 mm Hg • Body Location = “arm” • Body Location Laterality = “right” • Device = “cuff” • A UI will want to present it this way: • Systolic Blood Pressure = 120 mm Hg • Body Location = “right arm” • Device = “cuff” • We need a conversion mechanism – just like we need for converting to Clinical Trials models!

29. Different ways to model SystolicBloodPressureMeas key SystolicBloodPressure data 120 mm Hg SystolicBloodPressureAssert key Assertion data “SystolicBloodPressure = 120 mm Hg”

30. Different ways to model SystolicBloodPressureMeas key SystolicBloodPressure data 120 mm Hg SystolicBloodPressureAssert key Assertion data “SystolicBloodPressure = 120 mm Hg”

31. Different ways to model AsthmaAssert key Assertion data Asthma

32. Different ways to model HairColorMeas key HairColor data Blonde HairColorAssert key Assertion data Blonde Hair Color

33. Common Processing • Heart Rates and Blood Pressures both have body locations. • They aren’t the same body locations, but an application may want to process them similarly, e.g., display them in the same column • Do we create a parent “things with body locations”? • Vision changes and Weight changes don’t have much in common. • But an application may want to display/capture “things that have changed” since the last visit. • Do we create a parent “things that can change”?

34. Things we seek: • Explicit models for data elements – including standardized coded terminology • A single way (or at least a very few well-defined ways) to store/access a data element • A standard or “interlingua” for models that make them shareable between institutions • Extensibility • Applications that address data generically

35. Status • We’re in the process of creating models as part of our partnership with GE • We have very few of the items on the functional requirements xls • We do not have any data stored against our models yet • We can discuss creating the needed models

36. Questions?