cimi reference model taskforce report dr linda bird 10 th may 2012
TRANSCRIPT
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 Intersections
Guests
• 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.
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
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]+ integrity_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
DURATIONTEMPORAL
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
+mappings
0..*
+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;
Recommendations (5-6 of 11)
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;
Recommendations (7-11 of 11)
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 guide
5: 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 – Hierarchy
ELEMENTName: Problem Diagnosis Name
Meaning: 404684003|Clinical finding|Parent-child-link: 246090004|Associated finding|
Value: ϵ ProbDiag_RefSet
CLUSTERName: Location Details
Meaning: 123037004|Body structure|Parent-child-link: 363698007|Finding site|
ELEMENTName: Body Site
Meaning: 123037004|Body structure|Parent-child-link: 363698007|Finding 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
Meaning: 404684003|Clinical finding|Parent-child-link: 246090004|Associated finding|
IsoSemantic Models – Graph-based Model
246090004 |associated finding|
<<Cluster>>Problem Diagnosis
meaning: 243796009|Situation with explicit context|
<<Element>>Problem Diagnosis Name
meaning: 404684003|Clinical Finding| value: ϵ ProbDiag_RefSet
363698007 |finding site|
<<Cluster>>Location Details
meaning: 123037004|Body structure|
<<Element>>Body Site
meaning: 123037004|Body structure| value: ϵ BodyStructure_RefSet
363698007 |finding site|
<<Element>>Laterality
meaning: 182353008|Side| value: ϵ Side_RefSet
272741003|laterality|
<<Element>>Severity
meaning: 272141005|Severities| value: ϵ Severity_RefSet
246112005 |severity|
<<Element>>Finding Context
meaning: 410514004|Finding context value| value: ϵ FindingContext_RefSet
408729009 |finding context|
<<Navigational Cluster>>Associated Problem Diagnosis
meaning: 404684003|Clinical Finding|
246090004 |associated finding|
IsoSemantic Models – Compositional Grammar
Problem Diagnosis = 243796009 |situation with explicit context| :
246090004 |associated finding| =( $ProblemDiagnosisName : 363698007 | finding site | = ($BodySite:
272741003|laterality| = $Laterality), 246112005 | severity| = $Severity),
408729009 | finding context | = $FindingContext
GP Problem Diagnosis = 243796009 |situation with explicit context| :
246090004 |associated finding| =(86049000|Cancer| : 363698007 | finding site | = 39607008|Lung |),
408729009 | finding context | = 415684004|Suspected|Polyclinic Problem Diagnosis = 243796009 |situation with explicit context| :
246090004 |associated finding| =(162572001 |Suspected cancer|:
363698007 | finding site | = 39607008|Lung|)RH Problem Diagnosis = 243796009 |situation with explicit context| :
246090004 |associated finding| = (86049000|Suspected lung cancer|)
Clinical Modelling Layers - Ideas
Reference Model
Clinical Patterns
e.g. Schedulee.g.
Observatione.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
e.g. Dispensed Medication
GUI
e.g. Neonatal Blood
Pressure GUI
e.g. Current Medication List in EHR
e.g. Inpatient Discharge Summary
Message/Doc
CLUSTER ENTRY SECTION COMPOSITN
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 – Hierarchy
ELEMENTName: Problem Diagnosis Name
Meaning: 404684003|Clinical finding|Parent-child-link: 246090004|Associated finding|
Value: ϵ ProbDiag_RefSet
CLUSTERName: Location Details
Meaning: 123037004|Body structure|Parent-child-link: 363698007|Finding site|
ELEMENTName: Body Site
Meaning: 123037004|Body structure|Parent-child-link: 363698007|Finding 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
Meaning: 404684003|Clinical finding|Parent-child-link: 246090004|Associated finding|
IsoSemantic Models – Graph-based Model
246090004 |associated finding|
<<Cluster>>Problem Diagnosis
meaning: 243796009|Situation with explicit context|
<<Element>>Problem Diagnosis Name
meaning: 404684003|Clinical Finding| value: ϵ ProbDiag_RefSet
363698007 |finding site|
<<Cluster>>Location Details
meaning: 123037004|Body structure|
<<Element>>Body Site
meaning: 123037004|Body structure| value: ϵ BodyStructure_RefSet
363698007 |finding site|
<<Element>>Laterality
meaning: 182353008|Side| value: ϵ Side_RefSet
272741003|laterality|
<<Element>>Severity
meaning: 272141005|Severities| value: ϵ Severity_RefSet
246112005 |severity|
<<Element>>Finding Context
meaning: 410514004|Finding context value| value: ϵ FindingContext_RefSet
408729009 |finding context|
<<Navigational Cluster>>Associated Problem Diagnosis
meaning: 404684003|Clinical Finding|
246090004 |associated finding|
IsoSemantic Models – Compositional Grammar
Problem Diagnosis = 243796009 |situation with explicit context| :
246090004 |associated finding| =( $ProblemDiagnosisName : 363698007 | finding site | = ($BodySite:
272741003|laterality| = $Laterality), 246112005 | severity| = $Severity),
408729009 | finding context | = $FindingContext
GP Problem Diagnosis = 243796009 |situation with explicit context| :
246090004 |associated finding| =(86049000|Cancer| : 363698007 | finding site | = 39607008|Lung |),
408729009 | finding context | = 415684004|Suspected|Polyclinic Problem Diagnosis = 243796009 |situation with explicit context| :
246090004 |associated finding| =(162572001 |Suspected cancer|:
363698007 | finding site | = 39607008|Lung|)RH Problem Diagnosis = 243796009 |situation with explicit context| :
246090004 |associated finding| = (86049000|Suspected lung cancer|)
• 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. Schedulee.g.
Observatione.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
e.g. Dispensed Medication
GUI
e.g. Neonatal Blood
Pressure GUI
e.g. Current Medication List in EHR
e.g. Inpatient Discharge Summary
Message/Doc
CLUSTER ENTRY SECTION COMPOSITN