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 Healthcares 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 patients 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
ltcetype name"SystolicBloodPressureMeas"gt ltkey
code"SystolicBloodPressureMeas_KEY_ECID"/gt ltqua
l name"bodyPosition" card"0-1"/gt ltconstraint
path"qual.bodyPosition.data.cwe.domain"
value"BloodPressureBodyPosition_DOMAIN_ECID"
/gt ltconstraint path"data.pq.unit.domain"
value"PressureUnitOfMeasure_DOMAIN_ECID"/gt
ltconstraint path"data.pq.unit.preferred"
value"mmHg_ECID"/gt lt/cetypegt
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
  models 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 CEMs 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
Lets see, I want to analyze numbness symptoms in
neurological patients . . .
More than just groups of codes
20
Lets 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
Lets 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 gt 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 gt 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 gt 70 kg, then . . .

• IF
• (Dry Weight gt 70 kg
• OR
• (Weight gt 70 kg AND Weight type dry)
• THEN . . .

25
Different ways to model
If Dry Weight gt 70 kg, then . . .

• IF
• (Dry Weight gt 70 kg
• OR
• (Weight gt 70 kg AND Weight type dry)
• OR . . .
• are there any other ways??)
• THEN . . .

26
Different ways to model
If Dry Weight gt 70 kg, then . . .

• IF
• (Dry Weight gt 70 kg
• OR
• (Weight gt 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
• 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 arent 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 dont 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

• Were 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?