cimi reference model taskforce report

CIMI Reference Model Taskforce Report

Dr Linda Bird10th May 2012

Agenda

• Mission & Charter• Members & Guests• Definition• Architectural Framework• May Deliverables• Requirements• Starting Point• Change List & Exclusions• Proposed CIMI Reference Model• Gap Analysis• Recommendations• Isosemantic Models• Clinical Modelling Layers

Mission & Charter

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

Members & Guests

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• Stan Huff, Intermountain Healthcare• Richard Kavanagh – NHS Connecting for Health• Galen Mulrooney, ONC, U.S.A.• Grahame Grieve – Health IntersectionsGuests• Cecil Lynch• Ian Townend• Dipak Kalra

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.

Architectural Framework

May Deliverables

• A set of requirements for the CIMI reference model;• One or more UML class diagrams, which together represent the

candidate CIMI reference model (and supporting material);• An implementation of the candidate CIMI reference model that

enables a set of initial Clinical Models to be created based on this reference model1 (preferably using ADL);

• A report identifying the gaps between the proposed CIMI reference model and the requirements; and

• A summary of the results and recommendations for the CIMI Reference Model pending CIMI approval.

1: Please note that this implementation may either be as simple as an appropriately formatted spreadsheet, or may involve a tool that is specifically designed for authoring clinical models against a given reference model – depending on the time and resources available.

11 meetings from 23rd February – 3rd May 2012

CIMI RM taskforce website

Requirements - Overview

• General (Technical / Governance)• Structural• Information Pattern• Terminology Binding• Data Type

Requirements – General

• 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

Requirements – Structural & Information Patterns

• Structural‒ Data elements‒ Relationships / Links‒ Data groups‒ Tree structure‒ Entry / Clinical statement‒ Composition‒ Data absent

• Information Pattern‒ Concept model‒ Participation‒ Parties and roles

Requirements – Terminology Binding & Datatype

• 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

Starting Point - Options

Options• A profile, simplification or improvement of ISO13606-1• openEHR reference model• openEHR / ISO13606-1 model• DCM reference model (ISO13972-based)• EN13606 Association proposal

Other models, whose features were considered• Parts of Intermountain Healthcare’s Clinical Element Model• Federal Healthcare Information Model (US Gov FHIM• Logical Record Architecture (NHS LRA)

• Ability to meet requirements– including capturing required information patterns, and semantics

• Demonstrable computability, implementability and transformability (e.g. to ISO13606, openEHR, DCM, HL7 v2, v3, CDA)

• Existing tooling & infrastructure• Existing library of clinical models• Existing community (implementation and clinical)• IP considerations• Simplicity• Can support all use cases

Starting Point - Considerations

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

Starting Point - Selection

Change List - openEHR RM v1.0.2

• Core CIMI reference model‒ Simpify item structure‒ Move ELEMENT.value and null_flavour to ITEM‒ Remove specialisations of ENTRY from model‒ Remove ENTRY.encoding and workflow_id‒ Remove EVENT_CONTEXT

• Datatypes‒ Remove “DV_” prefix from all datatypes‒ Make CODE_PHRASE concrete‒ Add CODE_PHRASE.terminology_version, term, term_id‒ Change datatype of QUANTITY.units to CODE_PHRASE‒ Remove MULTIMEDIA.compression_algorithm and

integrity_check_algorithm‒ Remove ENCAPSULATED.charset and language

• Demographics – no changes

Exclusions - openEHR RM v1.0.2 (1 of 2)

• Assumed types‒ Any, Hash, INTERVAL

• Common‒ FEEDER_AUDIT, FEEDER_AUDIT_DETAILS, CONTRIBUTION,

IMPORTED_VERSION, T, VERSION, VERSIONED_OBJECT, FOLDER, VERSIONED_FOLDER, ATTESTION, AUDIT_DETAILS, REVISION_HISTORY, REVISION_HISTORY_ITEM, AUTHORED_RESOURCE, RESOURCE_DESCRIPTION, RESOURCE_DESCRIPTION_ITEM, TRANSLATION_DETAILS

• Composition‒ EVENT_CONTEXT, ACTION, ACTIVITY, ADMIN_ENTRY, CARE_ENTRY,

EVALUATION, INSTRUCTION, INSTRUCTION_DETAILS, ISM_TRANSITION, OBSERVATION

• Data structures‒ EVENT, HISTORY, INTERVAL_EVENT and POINT_EVENT

Exclusions - openEHR RM v1.0.2 (2 of 2)

• Datatypes‒ DV_STATE, PROPORTION_KIND, REFERENCE_RANGE,

DV_PARAGRAPH, DV_GENERAL_TIME_SPECIFICATION, DV_PERIODIC_TIME_SPECIFICATION, DV_TIME_SPECIFICATION

• Demographics‒ VERSIONED_PARTY

• Ehr‒ EHR, EHR_ACCESS, EHR_STATUS, VERSIONED_COMPOSITION,

VERSIONED_EHR_ACCESS, VERSIONED_EHR_STATUS• Ehr_Extract

‒ EHR, EHR_ACCESS, EHR_STATUS, VERSIONED_COMPOSITION, VERSIONED_EHR_ACCESS, VERSIONED_EHR_STATUS

Proposed CIMI Reference Model - Core

• COMPOSITION (category, language, territory, composer, content)• CONTENT_ITEM

‒ SECTION (items)‒ ENTRY (subject, provider, other_participation, language, data)

• ITEM (null_flavour, value)‒ CLUSTER (structure_type, items)‒ ELEMENT

• DATA_VALUE

• PARTICIPATION (function, mode, time, performer)• LOCATABLE (name, uid, archetype_node_id, archetype_details, links)• LINK (meaning, target, type)• ARCHETYPED (archetype_id, template_id, rm_version

class CIMI Core Reference Model

COMPOSITION

+ category :CODED_TEXT+ language :CODE_PHRASE+ territory :CODE_PHRASE

CONTENT_ITEM

ENTRY

+ language :CODE_PHRASE

SECTION

ARCHETYPED

+ archetype_id :ARCHETYPE_ID+ template_id :TEMPLATE_ID [0..1]+ rm_version :String

LOCATABLE

+ name :TEXT+ uid :UID_BASED_ID [0..1]+ archetype_node_id :String

LINK

+ meaning :TEXT+ target :EHR_URI+ type :TEXT

ITEM

+ null_flavor :CODED_TEXT [0..1]

ELEMENTCLUSTER

+ structure_type :CODE_PHRASE [0..1]

DATA_VALUE

PARTICIPATION

+ function :TEXT+ mode :CODED_TEXT+ time :DATE_TIME [0..1]

PARTY_PROXY PARTY_SELF

PATHABLE

+items1..*

+participations *

+provider

0..1 +subject 1..1

+items

*..*+content

*..*

+data 1..*

1

+other_participation

0..*

+value

0..1

+performer

1..1

+archetype_details

0..1

+links

*..*

+composer

1..1

Proposed CIMI Reference Model - Core

Proposed CIMI Reference Model - Datatypes

• BOOLEAN• IDENTIFIER• URI• CODE_PHRASE• TEXT

‒ CODED_TEXT• ENCAPSULATED

‒ MULTIMEDIA, PARSABLE• INTERVAL• ORDINAL• AMOUNT

‒ COUNT, DURATION, PROPORTION, QUANTITY• TEMPORAL

‒ TIME, DATE, DATE_TIME

Proposed CIMI Reference Model - Datatypes class CIMI Datatypes

BOOLEAN

+ value :Boolean

DATA_VALUE

IDENTIFIER

+ id :String+ type :String+ assigner :String+ issuer :String

ENCAPSULATED

MULTIMEDIA

+ alternate_text :String [0..1]+ data :Byte [0..1]+ integri ty_check :Byte [0..1]+ media_type :CODE_PHRASE+ uri :URI [0..1]

PARSABLE

+ formalism :String+ value :String

COUNT

+ magnitude :Integer

QUANTITY

+ magnitude :Real+ units :CODE_PHRASE+ precision :Integer [0..1]

PROPORTION

+ numerator :Real+ denominator :Real+ precision :Integer [0..1]+ type :CODE_PHRASE

ORDINAL

+ symbol :CODED_TEXT+ value :Integer

ORDERED

+ normal_status :CODE_PHRASE [0..1]

QUANTIFIED

+ magnitude :DATA_VALUE+ magnitude_status :String [0..1]

AMOUNT

+ accuracy :Real [0..1]+ accuracy_is_percent :Boolean [0..1]

ABSOLUTE_QUANTITY

+ accuracy :AMOUNT [0..1]

DATE

+ value :String

TIME

+ value :String

DATE_TIME

+ value :String

DURATION TEMPORAL

TEXT

+ language :CODE_PHRASE [0..1]+ value :String

CODED_TEXT

URI

+ value :String

CODE_PHRASE

+ code_string :String+ terminology_id :TERMINOLOGY_ID+ terminology_version :String [0..1]+ term :String [0..1]+ term_id :String [0..1]

EHR_URI

ORDERED : Class

INTERVAL

TERM_MAPPING

+ match :Char+ purpose :CODED_TEXT [0..1]

+upper

0..1

#normal_range

0..1

+lower

0..1

+mappings0..*

+defining_code1..1

+target

1..1

+thumbnail 0..1

Proposed CIMI Reference Model – Supporting Class

• OBJECT_ID‒ TEMINOLOGY_ID‒ TEMPLATE_ID‒ ARCHETYPE_ID‒ UID_BASED_ID

o HIER_OBJECT_ID• LOCATABLE_REF• PART_REF

• PARTY_PROXY‒ PARTY_IDENTIFIED

o PARTY_RELATED‒ PARTY_SELF

Proposed CIMI Reference Model – Supporting Class

class CIMI Supporting Classes

OBJECT_ID

+ value :String

OBJECT_REF

+ id_namespace :String+ type :String

UID_BASED_ID

ARCHETYPE_IDTEMPLATE_ID

PARTY_REFLOCATABLE_REF

+ path :String [0..1]HIER_OBJECT_ID

TERMINOLOGY_ID

PARTY_PROXY

PARTY_SELF

PARTY_IDENTIFIED

+ identifiers :IDENTIFIER [0..1]+ name :String [0..1]

PARTY_RELATED

+ relationship :CODED_TEXT

+external_ref 0..1

+id

1..1

+id

1..1

Proposed CIMI Reference Model - Assumed

• Integer• Real• String• Boolean• Byte• Char

• UID‒ UUID‒ ISO_OID‒ INTERNET_ID

Proposed CIMI Reference Model - Assumed

class CIMI Assumed Types

UID

+ value :String

UUID ISO_OID INTERNET_ID

«dataType»String

«dataType»Boolean

«dataType»Integer

«dataType»Real

«dataType»Byte

«dataType»

Char

Gap Analyss

• Fully supports‒ Most requirements

• Requires further investigation‒ Realm-specific specialisations and extensions‒ Governance, cost and licensing‒ Inter-organisation Semantic Interoperability‒ Terminology Concept model‒ Relationship semantics‒ Data type mappings‒ Primitive data types (base64Binary)‒ String-based data types (code)

• Partially supports‒ No clinically-significant attributes or specialisations

Recommendations (1-4 of 11)

Recommendation 1: The proposed reference model is thoroughly tested using a representative set of clinical models that together demonstrate all aspects of the reference model;

Recommendation 2: A set of stable clinical patterns (e.g. OBSERVATION, EVALUATION, INSTRUCTION, ACTION, TIME_SERIES, SCHEDULE) are defined as archetypes, upon which more specific clinical models are based, within an agreed framework of ‘clinical model specialisation layers’.

Recommendation 3: The CIMI reference model is fully documented in a format that promotes effective understanding by both clinical modellers and implementers. This documentation should include both example models and example instance data;

Recommendation 4: A coherent modelling methodology is documented to ensure consistent models, including modelling style guides and best practice guidelines;


Recommendation 5: The Archetype Object Model (and associated serialisations) is reviewed against requirements, and extended to fully express the semantic meaning of archetypes, (including the meaning of the relationship between nodes);

Recommendation 6: Further investigation is planned to consider issues, such as the following:

• The syntax and use of terminology bindings for both the meaning and valid values of nodes in the clinical models;

• The semantic meaning between all structural nodes;• The use of CLUSTER.value (including defining the meaning)• Whether null_flavour (or similar) should be allowed on ENTRY or

SECTION• Whether further simplifications can be made to the reference model (e.g.

demographics);• Modelling methodology to ensure consistency of models, including the

development of modelling style guides and best practices;


Recommendation 7: The requirements of iso-semantic clinical models are explored further, in terms of both (a) the ability to transform CIMI models to/from iso-semantic representations in other languages/standards (e.g. CDA, openEHR, ISO13606, DCM, CEM), and (b) the ability to transform CIMI models between iso-semantic representations that use a different split between terminology pre-coordination and structure (Please refer to Appendix B).

Recommendation 8: Appropriate tooling is developed and/or adopted, which allows clinical models to be created and is capable of generating ADL 1.5.

Recommendation 9: Any relevant Intellectual Property issues relating to the CIMI reference model are addressed.

Recommendation 10: A UML Profile is developed, in collaboration with the OMG, which allows CIMI models to be created in UML.

Recommendation 11: The taskforces be reorganised to support the above activities

Recommendations (Summary)

1: Test Reference Model (using clinical models)

2: Define clinical patterns and modelling layers

3: Document (including examples)

4: Modelling style guide5: Review and extend AOM (e.g. node relationship meaning)

6: Further investigate outstanding issues (e.g. terminology binding)

7: Iso-semantic clinical models (transformation and terminology equivalence)

8: Tooling

9: Intellectual Property

10: UML Profile

11: Organise taskforces

Isosemantic Models

Linda Bird10th May 2012

IsoSemantic Models – Example of Problem

e.g. “Suspected Lung Cancer”

IsoSemantic Models – Example Instances


Clinical Model Layers

Linda Bird10th May 2012

Clinical Modelling Layers - Ideas

Reference Model

Clinical Patterns e.g. Schedule e.g.

Observation e.g. List e.g. Event Summary

Clinical Models

e.g. Medication

Item

e.g. Blood Pressure

e.g. Medication

List

e.g. Discharge Summary

Context-Specific Clinical Models

e.g. Dispensed Medication

Item

e.g. Neonatal Blood

Pressure

e.g. Ceased Medication

List

e.g. Inpatient Discharge Summary

Use Case-Specific Clinical Models


GUI

e.g. Neonatal Blood

Pressure GUI

e.g. Current Medication List in EHR


Message/Doc

CLUSTER ENTRY SECTION COMPOSITN

ADL Workbench Editor Demonstration

Thomas Beale10th May 2012

Breakout Session 10:30 – 12:00

RM & CMTaskforces11th May 2012

10:30 – 12:00 pm• Core Reference Model• Datatypes Models• Demographics Model• Requirements Gap Analysis• Semantics/Terminology (e.g. Relationships b/w model elements)

1:00 – 3:00 pm• Isosemantic models and transformations to/from other specifications • Clinical Patterns, Modelling Layers and Modelling Style• Select an initial set of Clinical Models to test CIMI reference model• Modelling/Review process

1:00 – 3:00 pm• Continuation of agenda above• Collaboratively model and/or review specific clinical models• Next Steps

Breakout Agenda Summary

• Core Reference Model• Datatypes Models• Demographics Model• Requirements Gap Analysis• Semantics/Terminology

– including agreeing on method for defining semantics of relationships between model elements

Agenda (10:30 – 12:00 pm)

IsoSemantic Models – Example of Problem


IsoSemantic Models – Example Instances


IsoSemantic Models – Hierarchy

ELEMENTName: Problem Diagnosis Name


Value: ϵ ProbDiag_RefSet

CLUSTERName: Location Details


ELEMENTName: Body Site


Value: ϵ BodyStructure_RefSet

ELEMENTName: Laterality

Meaning: 182353008|Side|Parent-child-link: 272741003|Laterality|

Value: ϵ Side_RefSet

ELEMENTName: Severity

Meaning: 272141004|Severities|Parent-child-link: 246112005|Severity|

Value: ϵ Severity_RefSet

ELEMENTName: Finding Context

Meaning: 410514004|Finding context value|Parent-child-link: 408729009|Finding context|

Value: ϵ FindingContext_RefSet

CLUSTERName: Problem Diagnosis

Meaning: 243796009|Situation with explicit context|

CLUSTERName: Associated Problem Diagnosis


Breakout Session 1:00 – 3:00 pm


• Isosemantic models and transformations to/from other specifications

• Clinical Patterns, Modelling Layers and Modelling Style• Select an initial set of Clinical Models to test CIMI

reference model• Modelling/Review process

Agenda (1:00 – 3:00 pm)

Clinical Modelling Layers - Ideas

Reference Model

Clinical Patterns e.g. Schedule e.g.

Observation e.g. List e.g. Event Summary

Clinical Models

e.g. Medication

Item

e.g. Blood Pressure

e.g. Medication

List

e.g. Discharge Summary

Context-Specific Clinical Models


Item

e.g. Neonatal Blood

Pressure

e.g. Ceased Medication

List


Use Case-Specific Clinical Models


GUI

e.g. Neonatal Blood

Pressure GUI

e.g. Current Medication List in EHR


Message/Doc

CLUSTER ENTRY SECTION COMPOSITN

Breakout Session 3:30 – 5:00 pm


• Continuation of agenda above• Collaboratively model and/or review specific clinical

models• Next Steps

Agenda (3:30 – 5:00 pm)

cimi reference model taskforce report

Documents

candidate reference

cimi reference modelone

cimi reference modeldefine

underlying reference

given reference model

cimi clinical models

cimi approval

reference model1