SHARPn Face to Face Meeting

1
Clinical Data Normalization / Practical Modeling
Issues Representing Coded Structured Patient
Data

• SHARPn Face to Face Meeting
• June 11, 2012
• Stanley M Huff, MD
• Chief Medical Informatics Officer

2
Acknowledgements

• Tom Oniki
• Joey Coyle
• Craig Parker
• Yan Heras
• Cessily Johnson
• Roberto Rocha
• Lee Min Lau
• Alan James
• Harold Solbrig
• Many, many, others

3
Why do we need detailed clinical models?
4
A diagram of a simplified clinical model
5
What if there is no model?
Site 1
70
70
kg
Dry Weight
Site 2
70
kg
70
Weight
6
Relational database implications
How would you calculate the desired weight loss
during the hospital stay?
7
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

8
What do we model?

• 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

9
How are the models used in an EMR?

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

10
How Would the Models Be Used Globally?

• They are the pattern for clinical data in many
  different contexts
• Messages for electronic data exchange (HL7,
  Script, DICOM)
• Models for EMR data
• Reference for data used in clinical decision
  support
• Payload in standard services (patient data
  access)
• Target for structured output of NLP
• Normalization target for secondary data use
• Others

11
Clinical modeling activities

• Netherlands/ISO Standard
• CEN 13606
• United Kingdom NHS
• Singapore
• Sweden
• Australia - openEHR
• Canada
• US Veterans Administration
• US Department of Defense
• Intermountain Healthcare
• Mayo Clinic

• HL7
• Version 3 RIM, message templates
• TermInfo
• CDA plus Templates
• Detailed Clinical Models
• greenCDA
• Tolven
• NIH/NCI Common Data Elements, CaBIG
• CDISC SHARE

12
Clinical Information Modeling Initiative

• Mission
• Improve the interoperability of healthcare
  information systems through shared implementable
  clinical information models.

13
Clinical Information Modeling Initiative

• Goals
• Shared repository of detailed clinical
  information models
• Using a single formalism
• Based on a common set of base data types
• With formal bindings of the models to standard
  coded terminologies
• Repository is open and models are free for use at
  no cost

14
Progress on a strategy for open sharing
15
Access to the models

• Browser and download site
• http//intermountainhealthcare.org/CEM/Pages/Licen
  seAgreement.aspx

16
Model Subtypes Created

• Number of models created - 4384
• Laboratory models 2933
• Evaluations 210
• Measurements 353
• Assertions 143
• Procedures 87
• Qualifiers, Modifiers, and Components
• Statuses 26
• Date/times 27
• Others 400
• Panels 79

17
Tools - Browser

• Browsers/Editors
• Daedalus authoring, real time links to
  terminology (not finished)
• Compiler
• Syntax check
• Verification of terminology links (value sets)
• Outputs
• Compiled representation for run time use
• Multiple outputs (future)

18
The Clinical Element Model
19
The Logical Structure is Preeminent

• A formalism is needed to enable discussion of
  modeling issues. However, the specifics of a
  given formalism is not the key issue. The
  logical structure of the data, relationships and
  associations between data elements, and binding
  to standard terminologies are the most important
  things. What are the issues of style that we
  can agree on?

20
Mods and Quals of the Value Choice
21
Simplifying the Graphical Representation
22
A Panel containing 2 Observations
23
The Use of Qualifiers
SystolicBPObs
SystolicBP
138 mmHg
data
24
The Use of Modifiers (subject)
Blood Type
BloodTypeObs
O negative
data
25
The Constraint Definition Language (CDL)

• CDL is GE and Intermountains context-free
  grammar for specifying instances of the Abstract
  Constraint model.
• CDL is not a schema for dictating the physical
  structure of data instances.

26
The Core Model (reminder)
27
Clinical Element Abstract Constraint Model
Constrains the Abstract Instance Model to
represent the semantics of a particular type of
data
Constraint Model
e.g., for Heart Rate Constrain type Heart
Rate Model Constrain key Heart
Rate Constrain data type Phys.
Quantity Constrain set of valid quals body
location Constrain set of valid mods subject
CDL and CEML are two implementations of
the Abstract Constraint Model. Theyre just
grammars for saying this
28
The Heart Rate Measurement Constraint Model in CDL
model HeartRateMeas key code(HeartRate_KEY_EC
ID) data PQ qualifier BodyLocation
bodyLocation card(0..1) modifier Subject
subject card(0..1) constraint
bodyLocation.CD.code.domain (HeartRateBodyLocation
_VALUESET_ECID)
29
The Heart Rate Measurement Constraint Model in CDL
model HeartRateMeas constrains type to be
Heart Rate Measurement Model key
code(HeartRate_KEY_ECID) data PQ
qualifier BodyLocation bodyLocation card(0..1)
modifier Subject subject card(0..1)
constraint bodyLocation.CD.code.domain
(HeartRateBodyLocation_VALUESET_ECID)
30
The Heart Rate Measurement Constraint Model in CDL
model HeartRateMeas constrains type to be
Heart Rate Measurement Model key
code(HeartRate_KEY_ECID) constrains key to be
Heart Rate Measurement data PQ qualifier
BodyLocation bodyLocation card(0..1) modifier
Subject subject card(0..1) constraint
bodyLocation.CD.code.domain (HeartRateBodyLocation
_VALUESET_ECID)
31
The Heart Rate Measurement Constraint Model in CDL
model HeartRateMeas constrains type to be
Heart Rate Measurement Model key
code(HeartRate_KEY_ECID) constrains key to be
Heart Rate Measurement data PQ constrains
data to be of type PQ qualifier BodyLocation
bodyLocation card(0..1) modifier Subject
subject card(0..1) constraint
bodyLocation.CD.code.domain (HeartRateBodyLocation
_VALUESET_ECID)
32
The Heart Rate Measurement Constraint Model in CDL
model HeartRateMeas constrains type to be
Heart Rate Measurement Model key
code(HeartRate_KEY_ECID) constrains key to be
Heart Rate Measurement data PQ constrains
data to be of type PQ qualifier BodyLocation
bodyLocation card(0..1) constrains valid quals
to be body location, constrains cardinality to
be 0-1 modifier Subject subject card(0..1)
constraint bodyLocation.CD.code.domain
(HeartRateBodyLocation_VALUESET_ECID)
33
The Body Location Constraint Model in CDL
model BodyLocation is component key
code(BodyLocation_KEY_ECID) data CD
code.card(0..1) code.domain(BodyLocation_VALUESET_
ECID) qualifier BodyLaterality bodyLaterality
card(0..1) qualifier BodySide bodySide
card(0..1)
34
The Heart Rate Measurement Constraint Model in CDL
model HeartRateMeas constrains type to be
Heart Rate Measurement Model key
code(HeartRate_KEY_ECID) constrains key to be
Heart Rate Measurement data PQ constrains
data to be of type PQ qualifier BodyLocation
bodyLocation card(0..1) constrains valid quals
to be body location, constrains cardinality to
be 0-1 modifier Subject subject
card(0..1) constrains valid mods to be
subject, constrains cardinality to be 0-1
constraint bodyLocation.CD.code.domain
(HeartRateBodyLocation_VALUESET_ECID)
35
The Heart Rate Measurement Constraint Model in CDL
model HeartRateMeas constrains type to be
Heart Rate Measurement Model key
code(HeartRate_KEY_ECID) constrains key to be
Heart Rate Measurement data PQ constrains
data to be of type PQ qualifier BodyLocation
bodyLocation card(0..1) constrains valid quals
to be body location, constrains cardinality to
be 0-1 modifier Subject subject
card(0..1) constrains valid mods to be
subject, constrains cardinality to be 0-1
constraint bodyLocation.CD.code.domain
(HeartRateBodyLocation_VALUESET_ECID) constrains
valid values of a heart rate body location
36
The Heart Rate Measurement Constraint Model in CDL
model HeartRateMeas constrains type to be
Heart Rate Measurement Model key
code(HeartRate_KEY_ECID) constrains key to be
Heart Rate Measurement data PQ constrains
data to be of type PQ qualifier BodyLocation
bodyLocation card(0..1) constrains valid quals
to be body location, constrains cardinality to
be 0-1 modifier Subject subject
card(0..1) constrains valid mods to be
subject, constrains cardinality to be 0-1
constraint bodyLocation.CD.code.domain
(HeartRateBodyLocation_VALUESET_ECID) constrains
valid values of a heart rate body location
37
The Heart Rate Measurement Constraint Model in CDL
model HeartRateMeas constrains type to be
Heart Rate Measurement Model key
code(HeartRate_KEY_ECID) constrains key to be
Heart Rate Measurement data PQ constrains
data to be of type PQ qualifier BodyLocation
bodyLocation card(0..1) constrains valid quals
to be body location, constrains cardinality to
be 0-1 modifier Subject subject
card(0..1) constrains valid mods to be
subject, constrains cardinality to be 0-1
constraint bodyLocation.CD.code.domain
(HeartRateBodyLocation_VALUESET_ECID) constrains
valid values of a heart rate body location
Controlled Terminology Codes!
38
Specific Cases in Modeling
39
Disclaimer This is our current best thinking.
Some models have not been used in a production
system yet. Some models may change when we have
more production experience.
40
Assertion versus Evaluation Styles
41
Data Entry Styles
Hair Color
Brown
Hair Color

Brown Blonde Red
Evaluation Styles

Brown hair
Finding
Brown hair Blonde hair Red hair
Assertion Style
42
Assertion Vs Evaluation
Evaluation Style
HairColorObs
Hair Color
Brown
Assertion Style
Assertion
HairColorObs
Brown Hair Color
43
Assertion Vs Evaluation

• Both evaluation and assertion styles are accurate
  and unambiguous
• Evaluation style is more common as a data entry
  mode
• Assertion style allows each assertion to become a
  present/absent column for statistical analysis
• Evaluation style is our preferred storage form
  when the value represents an attribute of the
  patient
• Storage of assertion style instances is best for
  reasons, complications, final diagnoses, etc.
• Conclusion You need to support both styles and
  be able to convert between them

44
Deprecated representation

• Only the code (HL7) or key (CEM) has a value
• It is implied that this means that the patient
  has brown hair color
• Implying meaning is usually a bad idea

45
Subject
46
Subject Evaluation Style
Fetal Blood Type
FetalBloodTypeObs
data
O negative
Blood Type
BloodTypeObs
O negative
data
mods
Subject
Subject
Fetus
data
47
Subject Assertion Style 1
Assertion
FetalBloodTypeObs
data
Fetal Blood Type O negative
Assertion
BloodTypeObs
Blood Type O negative
data
mods
Subject
Subject
Fetus
data
48
Subject Assertion Style 2
Assertion
BreastCancerInMotherObs
Breast Cancer in Mother
data
Assertion
BreastCancerObs
Breast Cancer
data
mods
Subject
Subject
Mother
data
49
Subject as a Compound Statement
Subject
Subject
Relationship
Relationship
Maternal Aunt
PersonIdentity
Person Identity
PersonName
PersonName
Clara Barton
50
Representation of Family History
Assertion
BreastCancerObs
Breast Cancer
Subject
Subject
Relationship
Relationship
Family (ancestor)
51
Pre Vs Post Coordinated Subject

• Pre coordinated
• Easier for data entry
• Can lead to combinatorial explosion
• Post coordinated
• Easier to coordinate findings between patient and
  related party
• Easier to extend model with additional qualifiers
• Consistent with family history
• Allows detail on the identity of the subject
• Easier to misuse data (mistake cancer in mother
  for cancer in patient)
• Conclusion Support both pre and post coordinated
  subject styles , but use post coordinated model
  for storage

52
Negation and Uncertainty
53
Data Entry Styles
Medical History
(handles pertinent negatives)
No
Unk
Yes
Diabetes

Hx Finding
(repeating field)
Diabetes Renal Disease Cancer
54
Negation
Diabetes
DiabetesObs
Yes
data
(Implicit that this means diabetes is present.)
Assertion
FindingObs
Diabetes
data
mods
Negation
NegationIndicator
Present
data
55
Pre Coordinated Negation
Assertion
FindingObs
No Diabetes
data
(Leads to combinatorial explosion)
56
Negation and Uncertainty
Assertion
FindingObs
data
Diabetes
mods
Negation
NegationIndicator
data
Present
Uncertainty
Uncertainty
Probable
data
Use of Negation and Certainty are mutually
exclusive sets. Negation is only present/absent.
All other degrees of probability are represented
as values of Certainty.
57
Combined Negation and Uncertainty
Assertion
FindingObs
Diabetes
data
mods
Negation
CombinedUncertainty
Probably Not
data
Possible values for CombinedUncertainty Not
present, present, maybe, maybe not, probably,
probably not, might, might not, likely, unlikely,
very unlikely, very likely.
58
Conclusions on Negation

• Picklist style selection of findings does not
  allow for the representation of pertinent
  negative findings
• Pre coordinating negation with findings leads to
  combinatorial explosion in many situations
• It is difficult to avoid using pre-coordination
  for some common phrases, No Salmonella,
  Shigella, or Campylobacter identified.
• You can separate pure negation from uncertainty,
  or combine them into one field.
• Combining negation and uncertainty into one field
  will probably prevent entry of some nonsensical
  expressions.

59
Done and Not Done
Appendectomy
AppendectomyProc
Done
data
(Implicitly this means appendectomy was done.)
Procedure
Procedure
Appendectomy
data
mods
DoneNotDone
DoneNotDoneIndicator
Done
data
60
Done and Not Done

• Recording of whether actions or events occurred
  or not has a similar structure to negation, but
  the values are Done and Not Done.
• Theoretically, it is possible to use both
  Negation, and Done/Not Done in a single
  statement. For example The patient had
  abdominal surgery but it was NOT an appendectomy.

61
History Of
62
History Of issues

• A clinician can observe a sign or perform a
  procedure and record the event in the EHR.
• The patient or family can report a symptom or
  procedure occurred.
• It is essential to distinguish these two cases.
• When you query for existence of a given disease
  you want consistency of representation between
  direct observations and historical observations.

63
Consistency of Representation
Assertion
FindingObs
Vomiting
data
(Observed by a clinician)
Assertion
FindingObs
data
History of Vomiting
(Reported by the patients mother)
As data ages, the observed information becomes
the same as reported information. If you ask the
database Did the patient have vomiting?, you
want True to be returned in either case.
64
Attribution

• Recording the source of information
• Who, when, where
• Database add/modify/delete timestamps are handled
  separately from clinical processes
• Attributions pertain to actions or events
• Attributions are represented as a special class
  of qualifiers

65
General model for act attribution

• State the act (action or event)
• Observed, reported, ordered, counter signed,
  transcribed
• State the attribution information
• Who
• Participation (observer, reporter, receiver)
• Role (mother, physician, nurse, student)
• When (exact or fuzzy time)
• Where
• Geograpical place
• Network place
• Could be different for patient than for clinician
• Reason for the action
• Reason for order, reason for cancel, reason for
  hold

66
Differences for Observed and Reported

• Observed
• Action (Observed)
• Observer
• Timestamp
• Reported
• Action (Reported)
• Reporter
• Receiver
• Timestamp
• Observer, reporter, and receiver could be
  programs or electronic data stores

67
Attribution - Observed
Action
Observed
Observed
data
quals
Participant
Participant
Observer
data
quals
Role
Role
Physician
data
68
Attribution - Reported
Action
Reported
Reported
data
quals
ReportTime
ReportTimeObs
data
11/09/2007
Reporter
Participant
items
Role
Role
data
Mother
Receiver
Participant
items
Role
Role
Clnician
data
69
Assertion with Attributions
Assertion
VomitingObs
data
Vomiting
mods
Subject
Subject
data
Patient
quals
Observed
(As previously defined)
Reported
70
Attributions

• Attribution information unifies the historical
  and observational data.
• Attribution allows status change information to
  be carried in the instance of data.
• Specific models for particular kinds of
  attributions allows participants, roles,
  locations, and reasons to be specified.

71
Pain and Pain Severity
72
Pain Assertion and Qualifiers
Assertion
PainObs
Pain
data
quals
Body Location
BodyLocation
Abdomen
data
Pain Quality
PainQuality
Dull
data
Pain Severity
PainSeverity
Moderate
data
73
Pain Scale
PainScale
PainScaleObs
Mild, 3
data
74
Pain Modeling Issues

• Pain severity is not usually measured unless
  there is pain.
• A pain severity of (None, 0) is the same as no
  pain.
• In common practice Pain Severity Scales are
  thought of as independent observations, not
  qualifiers of pain.
• Conclusion We allow the pain severity scales as
  independent observations. However, the pain
  assertion model is more expressive.

75
Semantic links
76
How much data in a single record?

• Chest pain made worse by exercise
• Two events, but very close association
• Normally would go into a single finding
• Ate a meal at a restaurant and 30 minutes later
  he felt nauseated, and then an hour later he
  began vomiting blood.
• Discrete events with known time and potential
  causal relationships
• May need to be represented by multiple associated
  findings
• Semantic links are used to represent
  relationships between distinct event instances

77
Semantic Links (from Roberto Rocha)
78
Representation of Semantic Links

• InstanceId 1 Relationship InstanceId 2
• (123) Nausea followed-by (987) Vomiting

• Semantic links can also have certainty and
  attribution
• Certainty (certain, possible, probable, not
  likely)
• Attribution (who or what asserted the
  relationship, when, and why?)

79
Questions?
80
Information Model Ideas
V2
CEM
Standard Terminologies
LRA
V2 XML
HTML
CEMs
V3 XML
V3 Next
DCMs
Repository of Shared Models in a Single Formalism
Realm Specific Specializations
UML
Realm Specific Specializations
CDA Templates
Realm Specific Specializations
Realm Specific Specializations
openEHR Archetype
Realm Specific Specializations
openEHR Archetypes
CDA
OWL
CEN Archetypes
SOA Payload
LRA Models
CDISC SHARE
CMETs, HMDs RMIMs
CEN Archetype
Initial Loading of Repository
81
Other issues

• Levels of models boundary between what is in
  file and what we represent in tables or some
  other kind of knowledge representation. Models
  in files to the level of different attributes and
  then further constraints in tables?
• Could these models be represented in OWL, DL and
  other semantic web tools?
• Examples using coded ordinal data type
• Yes/no questions are really a different user
  entry style for assertion models
• More examples with Family History
• Better slides for semantic links
• Specific examples of Hx of
• Discussion of other modifiers planned
  procedures, goals, etc.
• Examples of Relative Temporal Context
• Implementation choices in object oriented
  languages

82
Other issues

• Show how the hierarchy of CEMs could produce the
  Act hierarchy in the HL7 RIM
• Inheritance of qualifiers and attributions
  between panels and statements
• Common qualifiers across models and within the
  same family of models
• Status, body location, changes (in vision,
  appetite, etc.)
• Dont want hard hierarchies, but want common
  query and behaviors across different models
• Co-occurrence constraints
• CHOICE in Qualifiers
• Items that could be numeric or conceptual
  (frequency of after meals XOR every 4 hours
• Use of aggregate data

83
Other issues

• Storage of data that does not conform to the
  model
• Alternative data (data type does not match)
• Unrecognized qualifier
• Too many qualifiers - cardinality of qualifier is
  not allowed
• Support for calculated values
• Relative temporal context
• Practical compromises
• Allowing value sets with low, med, high, not
  assessed

84
Other Issues

• Types of collections
• Statements
• Complex statements orders
• Panels
• Apgar scores, Treadmill test
• Folders, sections, and other arbitrary
  collections (from CEN 13606)