Clinical Information Modeling Initiative
Complements of the CIMI team and task forces
Especially
Stanley M. Huff, MD
Chief Medical Informatics Officer
Intermountain Health (Utah)
Infoway SCSC
Presented by Dennis Giokas, Chief Technology Officer
June 27, 2012
Agenda
• Mission and Goals
• Scope
• Why a new paradigm?
• Roadmap
• Logical Models
• Isosemantic Models
• Terminology
• Decisions to Date
• Next Steps
2
Clinical Information Modeling Initiative
Mission
Improve the interoperability of healthcare systems
through shared implementable clinical information
models.
3
Clinical Information Modeling Initiative
Goals
Meet the needs of the clinical modeling community –
everyone contributing, benefiting, and actively
involved
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
—
4
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
5
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
6
What Do We Want To Model
All data in the patient’s clinical record, 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
Intermountain’s Modeling Initiative
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+
8
Value Proposition of CIMI
Sharing of:
Data
— Information
— Application
— Decision logic
— Reports
— Knowledge
—
9
Modeling Contexts
• Messages
• Services, e.g. service calls
• 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
• Order entry
• Natural Language Processing
10
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
—
11
Model & terminology must be done together
• Terminology models and information models
Models made by data modelers (message standards)
— Models made by terminology groups (maintenance of
terms)
—
• “Impedance mismatch” arises when one group is
making terms and another group is making the
model
• Post coordination in a single field in the model is
just a way of hiding part of the model
12
Some Principles
• CIMI is 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” Reference Model and Data
Types
— Get practical use ASAP
— Change Reference Model and Data Types based on
use
—
13
Standard
Terminologies
CEM
CDA
Templates
openEHR
Archetypes
V2 XML
HTML
CEMs
DCMs
V2 “|”
LRA
V3 XML
Repository
of Shared
Models in
a Single
Formalism
V3 Next
Realm
Realm
Specific
Realm
Specific
Specializati
Realm
Specific
Realm
Specializati
ons
Specific
Specific
Specializati
ons
Specializati
Specializations
ons
ons
Translators
Translators
Translators
UML
ADL
CDA
OWL
CEN
SOA
LRA
CMETs, HMDs CDISC
Archetypes Models
Payload
SHARE CEN
RMIMs
Archetype
Initial Loading of Repository
14
Roadmap
• 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
15
Roadmap
(cont)
• 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
—
16
Roadmap
(cont)
• Create a process (e.g. editorial board) for curating 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, FHIR, SMART RDF, etc.
17
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
18
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
19
Isosemantic Models - Definition
A model that, while different in structure, represents
the same semantic content as a second model
20
Isosemantic Models
• User interface models
Convenient for data entry
— Typically pre-coordinated
— Many variations
—
• Storage models
Only one model is designated as the storage model
— Comprehensive set of qualifiers and modifiers
— The storage model is referenced in reports, rules,
protocols, data analysis
—
• Composition – Decomposition mappings
21
Fully Atomic SysBP Model
SystolicBPObs
data
SystolicBP
138 mmHg
subject
Subject
bodyLocation
BodyLocation
bodySite
BodySite
bodyLaterality
BodyLaterality
methodDevice
MethodDevice
bodyPosition
BodyPosition
plus “Standard Qualifiers”
22
Post Coordinated subject, loc, device, position
SystolicBP
SystolicBPObs
data
138 mmHg
mods
subject
Subject
quals
bodyLocationPrecoord
BodyLocationPrecoord
methodDevice
MethodDevice
bodyPosition
BodyPosition
plus “Standard Qualifiers”
23
Most Pre-Coordinated Model
PatientSystolicBPRightArmSittingAdultCuffObs
data
PatientSystolicBPRightArmSittingAdultCuff
138 mmHg
quals
abnormalFlag
AbnormalFlag
deltaFlag
DeltaFlag
referenceRangeNar
ReferenceRangeNar
relativeTemporalContext
RelativeTemporalContext
observed
Observed
reportedReceived
ReportedReceived
verified
Verified
“Standard Qualifiers”
In Subsequent
Models
24
Isosemantic Models – Example of Problem
e.g. “Suspected Lung Cancer”
Complements of Singapore MOHH
25
Isosemantic Models – Example Instances
e.g. “Suspected Lung Cancer”
26
IsoSemantic Models – Compositional Grammar
(162573006
27
Isosemantic Models
• CIMI is committed to isosemantic clinical models in
terms of both:
The ability to transform CIMI models into isosemantic representations in other
languages/standards (e.g. OWL, UML, HL7);
— The ability to transform CIMI models between isosemantic representations that use a different split
between terminology pre-coordination versus
structure.
—
28
Isosemantic Models
• 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
29
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 extensions to the reference
terminologies when needed concepts do not exist
—
CIMI will maintain the extensions until they are
accepted by the RT organization
30
Terminology
• 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
31
Three Task Forces
• Glossary
• Reference Model
• Clinical Models
See Appendices for the first two items
32
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
33
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.
34
Key Decisions from the Pleasanton & Vancouver Meeting in May
CIMI held its 6th group meeting from May 10 – 12, 2012 in Pleasanton
California and via video conference in Vancouver. Over 40 people attended in
person at the two locations with additional participants attending via WebEx.
At this meeting, the group:
• Reviewed, revised, and approved a reference model developed by the
Reference Model Task Force
• Agreed to undertake work to map existing clinical models to the reference
model
• Agreed to establish a new Modeling Task Force to oversee the clinical model
mapping
• Establish participation guidelines for members of CIMI task forces
• Reviewed the work of the Glossary Task Force
• Agreed that CIMI should not become a separate organization and that an RFI
should be issued to identify a parent organization and determine the
contributions of collaborating organizations
• Reviewed the draft RFP to be presented to OMG
• Began plans for next face-to-face meeting in September/October 2012
35
Next Steps - RFI
• The CIMI IEC is nearing completion of the Request for Information to solicit
proposals for the following:
• Organizational infrastructure: CIMI’s primary focus is on the development of
specifications and models. Since CIMI strongly prefers to not create a new
organizational structure we are requesting information about how an
organization might support CIMI with administrative support, overall
governance, and collaboration with other SDOs and major stakeholders. We
are interested in an assessment of the resources, facilities, people or skills
that collaborating members would be willing to provide
• Intellectual property (including models and tooling): The development of CIMI
models will require the integration of intellectual property (IP) from a number
of organizations. The RFI lays out a series of intellectual property issues and
asks for suggestions on how these might be addressed.
36
Next Steps – Reference Model Validation
Several clinical models will be used for mapping to the CIMI Reference Model.
Various examples of these models will be contributed by CIMI members and will
be uploaded to the CIMI wiki. The models are:
•
•
•
•
•
•
•
•
•
Heart rate (observation entry/measurement) Apgar Score (Entry)
BMI (grouping for calculation)
Apgar Score (Entry)
Glucose tolerance (Entry)
Adverse reaction report (composition)
Medication order (composition)
Problem list (Composition)
Care giver reported Nausea (observation entry/assertion)
Wound culture (Reflex test results, e.g., automatically triggered orders based
on a result)
The reference and clinical model TFs will be combined and work together
37
Next Steps – Organizational Structure
• By consensus the meeting participants agreed that
CIMI should not become an organization, but should
look to affiliate with another organization. The IEC
will continue to work on the development of and
circulation of an RFI to lay the groundwork for such
an affiliation
38
More information and WIKI
http://informatics.mayo.edu/CIMI/index.php/Main_Page
39
Thank you
APPENDICES
41
Glossary - Charter
• To define terms and abbreviations that are used in
communication relating to CIMI and which may not
be commonly understood, or those required for
logically grouping these terms, and to document
these definitions in a commonly accessible glossary
• Criterion for what “may not be commonly
understood”: whether there has been debate, or
such debate might reasonably be predicted
42
Glossary – SKMT Glossary Tool
• Joint Initiative Council of Health Informatics
Standards Development Organisations
• www.skmtglossary.org
• Best practices documented in ISO TC 215/SC
Development of terms and definitions for the Health
Informatics Glossary
• Allows batch upload of terms
• Includes harmonisation process
43
Reference Model - Mission
• To define a candidate CIMI reference model
• Define a set of requirements for the CIMI reference
model
• Define or choose a candidate CIMI reference model
• Work with the Clinical Modeling taskforce to test the
candidate reference model in the development of a
set of initial clinical information models
• Compare the candidate CIMI reference model with
the requirements to identify gaps
• Present the results at the face-to-face meeting in
May
44
Reference Model - Definition
• The CIMI Reference Model is the underlying
Reference Model on which CIMI’s clinical models will
be defined.
• This reference model defines a rigorous and stable
set of modelling patterns, including a set of
structural patterns, complex data types and
demographic classes.
• All CIMI clinical models (i.e. archetypes) will be
defined by constraining the CIMI reference model.
• Each example instance of a CIMI Clinical Model will
be an instance of the CIMI reference model, which
conforms to the constraints defined by the
associated clinical model.
45
Reference Model Team
Members
• Linda Bird (Chair) – Ministry of Health Holdings, Singapore
• Michael van der Zel – Results4Care & LifeLines
• Gerard Freriks, EN13606 Association
• Josh Mandel, SMART
• Thomas Beale – Ocean Informatics
• Dave Carlson
• Stephen Chu – NeHTA
• Michael Lincoln
• Rahil Qamar Siddiqui
• Mark Shafarman
• GE/Intermountain - TBD
46
Reference Model - Requirements
• General Technical
Support for architectural framework
— Multiple purpose & outputs
— Realm-specific specialisations & extensions (*)
— Move clinically-relevant attributes to clinical patterns
— Model mapping & query support (*)
— Versioning & Approval status (*)
— Stability
—
• General governance
Governance, cost and licensing
— Clinician verification (*)
— Inter-organisation semantic interoperability
—
47
Reference Model - Requirements
• Structural
Data elements
— Relationships / Links
— Data groups
— Tree structure
— Entry / Clinical statement
— Composition
— Data absent
—
• Information Pattern
Concept model
— Participation
— Parties and roles
—
48
Reference Model - Requirements
• Terminology Binding
Semantic / Value / Name binding (*)
— Relationship semantics (*)
— Concept model terminology definition (*)
— Translations
—
• Datatype
Common datatypes
— Datatype constraints & mappings
— Inheritance from single type
— Primitive & string-based datatypes
— Complex datatypes
— Attachment, Ordinal, Codeable concept, Coding,
Identifier, Interval, Quantity, Ratio
—
49
Reference Model - Resolution
By formal vote of the CIMI membership present the
following resolution was passed unanimously:
Resolution: The reference model presented by the
Reference Model Task Force is endorsed as a starting
point and establishes the direction that CIMI wishes
to take. We expect that this model will be tested and
modified as modeling work continues.
50
Reference Model Selection – Starting Point
• openEHR reference model selected as starting point by 6 of 9 members
Reasons
• The range of existing archetypes, tooling, infrastructure, methodology and
documentation;
• Established reference model tested by multiple authoring participants;
• Can benefit from lessons learned by many implementations;
• Able to start designing clinical models straight away;
• Demonstrable use within a two-level modelling architecture;
• Specification is freely available on the web to read and redistribute without cost;
• Willingness of the organisation to work with CIMI and make changes as needed to
meet CIMI’s needs
Concerns
• Complexity of current model - a simplified model is preferred;
• Need to bridge the gap between the model and the requirements;
• Requires us to work together to simplify and improve
• It is not a standard, and there are IP concerns relating to the specifications
• Requires work to develop a UML-based profile and editing environment
51