A Brief Review of CIMI
Plans and Goals
London CIMIStandards
Meetings
Kaiser Permanente
Summit
November 29,
September
7-8 2011
, 2011
Stanley M. Huff, MD
Stanley M Huff, MD
Chief Medical Informatics Officer
Huff # 1
The Ultimate Value Proposition of CIMI
• Sharing of:
– Data
– Information
– Applications
– Decision logic
– Reports
– Knowledge
Huff # 2
Patient
Clinical System Approach
Intermountain can only provide
the highest quality, lowest cost
health care with the use of
advanced clinical decision
support systems integrated into
frontline workflow
James # 5
Newborns w/ hyperbilirubinemia
50
50
Bilirubin > 19.9 mg/dL
Bilirubin > 25 mg/dL
40
37
34
34
34
32
30
32
31
30
28
26
30
28
27
26
26
24
27
27
25
24
22
20
21
20
19
17
16
20
16
14
14
15
15
13
13
12
2
1
1
1
2
0
1
2
0
10
3
1
0
0
0
1
0
1
1
0
0
0
0
0
M
ar
M
ay
1
10
N
Ja ov
n
20
04
2
Se
p
2
Ju
l
0
1
M
ar
M
ay
2
N
Ja ov
n
20
03
0
3
Se
p
2
Ju
l
0
2
M
ar
M
ay
3
N
Ja ov
n
20
02
0
3
Se
p
3
2
Ju
l
0
1
16
15
10
M
ay
0
16
15
13
10
M
ar
20
01
Number of patients
40
James # 6
Decision Support Modules
•
•
•
•
Antibiotic Assistant
Ventilator weaning
ARDS protocols
Nosocomial infection
monitoring
• MRSA monitoring and
control
• Prevention of Deep
Venous Thrombosis
• Infectious disease
reporting to public health
•
•
•
•
•
•
•
•
•
•
Diabetic care
Pre-op antibiotics
ICU glucose protocols
Ventilator disconnect
Infusion pump errors
Lab alerts
Blood ordering
Order sets
Patient worksheets
Post MI discharge meds
Strategic Goals
• Minimum goal: Be able to share
applications, reports, alerts, protocols,
and decision support with ALL GE
customers
• Maximum goal: Be able to share
applications, reports, alerts, protocols,
and decision support with anyone in the
WORLD
Order Entry API (adapted from Harold Solbrig)
Application
Interface
Service
Data
VA Order
Entry
Update Medication Order
COS
VA
Order
Services
Update PharmacyOrder
WHERE orderNumber = “4674” …
MUMPS
Database
Order Entry API – Different Client,
Same Service (adapted from Harold Solbrig)
Application
Interface
Service
Data
Dept
of
Defense
Update Medication Order
COS
VA
Order
Services
Update PharmacyOrder
WHERE orderNumber = “4674” …
MUMPS
Database
Order Entry API – Different Server,
Same Client (adapted from Harold Solbrig)
Application
Interface
Dept
of
Defense
Update Medication Order
COS
GE
Services
Update PharmacyOrder
WHERE orderNumber = “4674” …
Service
Data
GE
Repository
Oracle
Tables
Order Entry API (adapted from Harold Solbrig)
...
Application
Interface
Service
Data
COS
From Ben Adida and Josh Mandel
What Is Needed to Create a New Paradigm?
• 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
• Sharing of decision logic and applications
Clinical modeling activities
•
•
•
•
•
•
•
•
•
•
•
•
Netherlands/ISO Standard
CEN 13606
United Kingdom – NHS
Singapore
Sweden
Australia
openEHR Foundation
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
• Korea
# 15
Clinical Information Modeling Initiative
Goal
Meet the needs of the clinical
modeling community –
everyone contributing,
benefiting, and actively
involved
Huff # 16
Clinical Information Modeling Initiative
Mission
Improve the interoperability of
healthcare systems through shared
implementable clinical
information models.
Huff # 17
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
Huff # 18
Goal: Models that support multiple contexts
•
•
•
•
•
•
•
•
Messages
Services
Decision logic (queries of EHR data)
EHR data storage
Clinical trials data (clinical research)
Normalization of data for secondary use
Creation of data entry screens
Natural Language Processing
Information Model Ideas
CEMs
DCMs
CDA
Templates
Repository
of Shared
Models in
a Single
Formalism
V2 “|”
CEM
Standard
LRA
Terminologies
V2 XML
HTML
V3 XML
V3 Next
Realm
Realm
Specific
UML
Realm
Translators
Specific
Specializations
Realm
Specific
Specializations
Realm
Specific
Specializations
Specific
Specializations
Specializations
openEHR
Archetypes
CEN
Archetypes
LRA
Models
CMETs, HMDs
RMIMs
Initial Loading of Repository
Translators
Translators
ADL
CDA
OWL
SOA
CDISC
SHARE CEN Payload
Archetype
# 20
Roadmap (some parallel activities)
• Choose a single formalism
• Choose the initial set of agreed data
types
• Define strategy for the core reference
model and our modeling style and
approach
– Development of “style” will continue as we
begin creating content
Roadmap (continued)
• Create an open shared repository of models
– Requirements
– Find a place to host the repository
– Select or develop the model repository software
• Create model content in the repository
– Start with existing content that participants can
contribute
– Must engage clinical experts for validation of the
models
Roadmap (continued)
• Create a process (editorial board?) for curation and
management of model content
• Resolve and specify IP policies for open sharing of models
• Find a way of funding and supporting the repository and
modeling activities
• Create tools/compilers/transformers to other formalisms
– Must support at least ADL, UML/OCL, Semantic Web, HL7
• Create tools/compilers/transformers to create what
software developers need
– Examples: XML schema, Java classes, CDA templates,
greenCDA, RFH, SMART RDF, etc.
Selected Decisions
Decisions (London, Dec 1, 2011)
• We agree to create and use a single logical
representation (the CIMI core reference model)
comprising one or more models as the basis for
interoperability across formalisms.
• We approve ADL 1.5 as the initial formalism in the
repository using OpenEHR Constraint Model noting
that modifications are required.
• The corresponding Archetype Object Model will be
included and adapted as the CIMI UML profile
• The CIMI UML profile will be developed
concurrently as a set of UML stereotypes, XMI
specification and transformations
Decisions (London, Dec 1, 2011)
• We will create a workplan to say how we review
and update the Constraint Model, reference models
and languages including HL7 Clinical Statement
Pattern and Entry model of 13606 / OpenEHR. The
workplan to be approved in January.
• The CIMI information model as described in the
UML profile must be consistent with the evolving
AOM. We will ensure this consistency by creating a
single technical working group.
Definition of “Logical Model”
• Models show the structural relationship of the
model elements (containment)
• Coded elements have explicit binding to
allowed coded values
• Models are independent of a specific
programming language or type of database
• Support explicit, unambiguous query
statements against data instances
Definition of “Logical Model” (cont)
• Models shall specify a single unit of measure
(unit normalization)
• Models can support inclusion of processing
knowledge
– Models can support recommend defaults
– Models can specify assumed values of attributes
(meaning of absence of the item)
• Examples can be created for the model
Isosemantic Models
Precoordinated Model (CIMI deprecated Model)
HematocritManual (LOINC 4545-0)
HematocritManualModel
data
37 %
Post coordinated Model (CIMI preferred Model)
Hematocrit (LOINC 20570-8)
HematocritModel
data
37 %
quals
HematocritMethodModel
data
Hematocrit Method
Manual
# 29
Isosemantic Models
• CIMI is committed to isosemantic clinical
models in terms of both:
– The ability to transform CIMI models into
iso-semantic representations in other
languages/standards (e.g. OWL, UML,
HL7);
– The ability to transform CIMI models
between iso-semantic representations that
use a different split between terminology
pre-coordination versus structure.
Isosemantic Models (cont)
• Only include isosemantic models in the
repository when they are useful
– Re-use of transforms by other enterprises
– Re-use of transforms by other processes
• Lab data transforms
• Data normalization for clinical trials or secondary use
• Repository requirement
– Know which models are part of the same isosemantic
family
• Transform rules may be reused based on “type
of model”
– Only difference may be terminology mapping
Terminology
• SNOMED CT will be the primary reference
terminology
• LOINC was also approved as a reference
terminology
– In the event of overlap, SNOMED CT will be the
preferred source
• CIMI will propose extension to the reference
terminologies when needed concepts do not exist
– CIMI will maintain the extensions until they are accepted
by the RT organization
Terminology (cont)
• The primary version of models will
only contain references (pointers) to
value sets
• We will create tools that read the
terminology tables and create
versions of the models that contain
enumerated value sets
Three Task Forces
• Glossary
• Reference Model
• Clinical Models
Some Principles
• CIMI DOES care about implementation. There
must be at least one way to implement the models in
a popular technology stack that is in use today. The
models should be as easy to implement as possible.
• Only use will determine if we are producing
anything of value
– Approve “Good Enough” RM and DTs
– Get practical use ASAP
– Change RM and DTs based on use