Clinical Information Modeling Initiative

Complements of the CIMI team and task forces

EspeciallyStanley M. Huff, MDChief Medical Informatics OfficerIntermountain Health (Utah)

Presented by Dennis Giokas, Chief Technology Officer June 27, 2012Infoway SCSC

2

Agenda

• Mission and Goals• Scope• Why a new paradigm?• Roadmap• Logical Models• Isosemantic Models• Terminology• Decisions to Date• Next Steps

3

Clinical Information Modeling Initiative

MissionImprove the interoperability of healthcare systems through shared implementable clinical information models.

4

Clinical Information Modeling Initiative

GoalsMeet 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

5

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

6

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

7

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

8

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+

9

Value Proposition of CIMI

Sharing of:— Data— Information— Application— Decision logic— Reports— Knowledge

10

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

11

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

12

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

13

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

14

Repository of SharedModels in a Single

Formalism

DCMs

CDA Templates

openEHRArchetypes

CENArchetypes

LRA Models

CMETs, HMDsRMIMs

CEMs

StandardTerminologies

Initial Loading of Repository

Realm Specific

Specializations

Realm Specific

Specializations

Realm Specific

Specializations

Realm Specific

Specializations

Realm Specific

Specializations

V2 “|”

HTML

UML

ADL

V2 XML

V3 XML

V3 Next

CEN Archetype

CDA

SOAPayload

CEMLRA

OWL

CDISC SHARE

TranslatorsTranslatorsTranslators

15

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

16

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

17

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.

18

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

19

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

20

Isosemantic Models - Definition

A model that, while different in structure, represents the same semantic content as a second model

21

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

22

Fully Atomic SysBP Model

data 138 mmHg

SystolicBPSystolicBPObs

Subjectsubject

BodyLocationbodyLocation

plus “Standard Qualifiers”

BodySitebodySite

BodyLateralitybodyLaterality

MethodDevicemethodDevice

BodyPositionbodyPosition

23

Post Coordinated subject, loc, device, position

data 138 mmHg

SystolicBPSystolicBPObs

mods

Subjectsubject

BodyLocationPrecoordbodyLocationPrecoord

plus “Standard Qualifiers”

MethodDevicemethodDevice

BodyPositionbodyPosition

quals

24

Most Pre-Coordinated Model

data 138 mmHg

PatientSystolicBPRightArmSittingAdultCuffPatientSystolicBPRightArmSittingAdultCuffObs

quals

AbnormalFlagabnormalFlag

DeltaFlagdeltaFlag

ReferenceRangeNarreferenceRangeNar

RelativeTemporalContextrelativeTemporalContext

Observedobserved

ReportedReceivedreportedReceived

Verifiedverified

“Standard Qualifiers” In Subsequent Models

25

Isosemantic Models – Example of Problem

e.g. “Suspected Lung Cancer”

Complements of Singapore MOHH

26

Isosemantic Models – Example Instancese.g. “Suspected Lung Cancer”

27

IsoSemantic Models – Compositional Grammar

(162573006

28

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.

29

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

30

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

31

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

32

Three Task Forces

• Glossary• Reference Model• Clinical Models

See Appendices for the first two items

33

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

34

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.

35

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

36

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.

37

Next Steps – Reference Model ValidationSeveral 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

38

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

39

More information and WIKIhttp://informatics.mayo.edu/CIMI/index.php/Main_Page

Thank you

41

APPENDICES

42

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

43

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

44

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

45

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.

46

Reference Model TeamMembers• 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

47

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

48

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

49

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

50

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.

51

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 needsConcerns•  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