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

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
key
BloodPressure
items
SystolicBloodPressureMeas
key
SystolicBloodPressure
data
120 mmHg
DiastolicBloodPressureMeas
key
DiastolicBloodPressure
data
80 mmHg

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

15. The use of Qualifiers SystolicBloodPressureMeas key
data
120 mmHg

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

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

18. Modeling Issues

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

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

21. More than just groups of codes
Let’s see, I want to analyze numbness symptoms in neurological patients . . .
Fortunately, we store SNOMED CT codes. I see this patient had:
Numbness ( )
Right ( )
Arm ( )
Left ( )
Leg ( )
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 kg AND Weight type = “dry”)
THEN . . .

25. Different ways to model
If Dry Weight > 70 kg, then . . . IF
(Dry Weight > 70 kg OR
(Weight > 70 kg AND Weight 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 kg AND Weight 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:
Body Location = “right arm”
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?