cimi modelling taskforce report

CIMI Modelling Taskforce Report

Dr Linda Bird14th May 2012

Agenda

• Members• Mission & TOR• Overview of work• Call For Models• Modelling Approach

o Backgroundo Foundationso Summary of Approach

Core Members:• Linda Bird• Tom Beale• Dave Carlson• Stephen Chu• Stan Huff• Mike Lincoln• Rahil Qamar Siddiqui• Gerard Freriks• Josh Mandel• Mark Shafarman• Michael van der Zel

Taskforce MembersTechnical Resources:• Peter Hendler• Galen Mulrooney• Grahame Grieve• Dipak Kalra• Daniel Karlsson• Cecil Lynch• David MonerClinical Modelling Resource:• William Goossen• Jay Lyle• Ian McNicoll• Anneke Goossen• Heather Leslie• Marcelo Rodrigues dos Santos• Sarah Ryan• Hendry Wijaya• Harold Solbrig

To develop a CIMI modelling methodology, style guide and a set of models, which

together demonstrate and test the approach to CIMI clinical modelling.

Mission

This taskforce has been established to:• Further develop and document CIMI's modelling

methodology, including modelling patterns and modelling style guides;

• Create an initial set of CIMI clinical models to demonstrate the approach and test the technical artefacts;

• Further test and develop CIMI technical models and documentation, including the CIMI reference model, the Archetype Object Model 1.5, and CIMI terminology.

Terms of Reference

D1 CIMI Reference Model One or more computable representations (UML & BMM)D2 CIMI RM Documentation One or more artefacts documenting the CIMI RM (Word)D3 CIMI Modelling Patterns A set of modelling patterns (UML & ADL)D4 CIMI Clinical Models Based on call for models (UML & ADL)

– Heart rate, BMI, Apgar score, Glucose tolerance, Adverse Reaction, Medication Order, Problem List, Nausea, Wound Culture

– Example instance dataD5 CIMI Modelling Methodology Modelling Style Guide / Best Practices Guidelines Document

– Iterative approach to methodology developmentD6 CIMI Terminology CIMI value sets, semantic concepts, and CIMI SNOMED CT extension

– Documentation of approach to terminology bindingD7 Updates to AOM Computable representation of AOM to meet CIMI requirementsD8 CIMI Taskforce ReportA report describing the activities of the modelling taskforce, including:

– Mission, Terms of Reference, Planned Deliverables– Outcomes of work item and summary of results– Gap analysis and evaluation between UML & AOM approaches– Methodology for transforming CIMI models into other artefacts, and the

degree of semantic interoperability that is supported by these transformations– A methodology for subsumption testing of models– A methodology for providing multiple visualisations of clinical models for

different audiences (both clinical and technical)– Recommendations

D9 Meeting Minutes A summary of taskforce meetings

Planned Deliverables

Overview of Work

July 5 Mission, TOR, Deliverables, Call for Models, Secretary

July 12 Tasks & Activities Planning, Secretary

July 19 Model Submissions, Storage/Github, Modelling Process

July 26 Modelling Patterns: openEHR, NHS LRA

August 2 Modelling Patterns: ADL workbench, SNOMED

August 9 Modelling Patterns: VA, MOHH, R4C, EN13606 AssocHeart Rate model submissions: comparative

analysis

August 16 HL7 v3, Modelling Pattern Review, CIMI Entry patterns

August 23 CIMI Entry patterns, Heart Rate Model & Style Guide

August 30 Terminology: NHS, Extensions to AOM, Binding Syntax

September 6 Model granularity, Time Series, Heart Rate TerminologyPlanning for Rockville

Meeting Summary

• Infrastructure• Call For Models• Model Submissions - Review• CIMI Modelling Patterns• CIMI Style Guide• CIMI Models

Overview of Work

• Issue tracking (github)– https://github.com/clinicalmodels/cimi/

• Google doc repository– Documents, clinical models, reference model, modelling

patterns, model submissions– http://content.clinicalmodels.org

• Google groups email list – cimi-modelling-taskforce– http://groups.google.com/group/cimi-modelling-taskforce

?hl=en-GB• CIMI website

– CIMI models tab, Quick links, Links to the Doc repository

Infrastructure

https://github.com/clinicalmodels/cimi/issues?page=1&state=open

http://content.clinicalmodels.org/

http://groups.google.com/group/cimi-modelling-taskforce?hl=en-GB

http://groups.google.com/group/cimi-modelling-taskforce?hl=en-GB

• CIMI Reference Model– Published draft– Outstanding issues discussed on github

• CIMI Style Guide & Patterns– Early draft includes draft quality criteria and modelling principles

• CIMI Modelling Patterns– ENTRY types (e.g. Observation)– Isosemantic patterns– Time series

• CIMI Models– First draft of CIMI Heart Rate model, based on:

• Comparative analysis of CIMI model submissions• Proposed OBSERVATION design pattern

CIMI Modelling

Call For Models

• Modelling Patternsplus:

• Heart Rate• Body Mass Index• Apgar Score• Glucose Tolerance Test Result• Adverse Reaction • Medication order• Problem list• Nausea • Wound Culture Result

Call For Models

• CIHI/Infoway – Allergy/Intolerance, Medication Order• EN13606 Association – Blood Pressure, Investigation,

Observation, Description of others• Intermountain Healthcare – All requested models• Kaiser Permanente – HealthConcern• MOHHoldings – All models (some generalisations)• NEHTA – Adverse Reaction, Problem/Diagnosis, Med Order• NHS – Allergies/Adverse Reaction, Problem&Issue, Diagnosis,

Medication Activity• openEHR – All models• Results4Care – Heart rate, BMI, Apgar Score• Tolven – All models (except Apgar score & wound culture)• VA – Problem List

Model Submissions

Modelling Approach

CIMI Architectural Overview

CIMI Modelling Layers

Reference Model

Modelling Patterns

Schedule,Address,Material

Observation,Action Clinical List Event Summary,

Assessment

Clinical Models Medication Item Blood Pressure Medication List Discharge Summary

Add Specialty Context

Paediatric Medication Item

Neonatal Blood Pressure

Nephrologist Medication List

Cardiology Discharge Summary

CLUSTER ENTRY SECTION COMPOSITION

Add Care Setting Context

G.P. Dispensed Medication Item

Home Blood Pressure

Outpatient Clinic Current

Medication List

Inpatient Discharge Summary

Add Implementation

Purpose Context

Dispensed Medications GUI

Neonatal Blood Pressure in EHR

Current Medication List in

EHR

Discharge Summary Doc or

Message

Add Use Case Context

Dispensed Medication Item

Standing Blood Pressure

Current Medication List

Medication Reconciliation

Report

IsoSemantic Models – Example of Problem

e.g. “Suspected Lung Cancer”

IsoSemantic Models – Example Instances

e.g. “Suspected Lung Cancer”

IsoSemantic Models – Graph-based Model

• Foundations1. CIMI Reference Model2. Archetype Object Model3. CIMI Modelling Patterns4. CIMI Style Guide

• Modelling Approach1. Analyse clinical models submitted (with value sets)2. Identify maximal set of data elements3. Remove ‘out of scope’ data elements (Style Guide)4. Select appropriate CIMI Modelling Patterns(Style Guide)5. Define CIMI model (Mindmap, ADL, UML)6. Add Terminology bindings

o Meaning (nodes, node relationships)o Value sets (maximal set from submitted models)

7. Add Example Model Data Instances8. Technical Validation

o ADL, UML

9. Clinical Validation / Review10. Confirm mappings from submitted models

Overview

F1. Define CIMI Reference Model class CIMI Core Reference Model

COMPOSITION

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

CONTENT_ITEM

ENTRY

+ language :CODED_TEXT

SECTION

ARCHETYPED

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

LOCATABLE

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

LINK

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

ITEM

ELEMENT

+ null_flavor :CODED_TEXT [0..1]

CLUSTER

+ structure_type :CODED_TEXT [0..1]

DATA_VALUE

PARTICIPATION

+ function :CODEABLE_TEXT+ time :INTERVAL<DATE_TIME> [0..1]+ mode :CODED_TEXT

PARTY_PROXY

+participation

0..*

+value 0..1

1

+items0..*

+data1..*

+content 0..*

+links

0..*

+items1..*

+party

1..1

+archetype_details

0..1

F1. Define CIMI Reference Model class CIMI Data Value Types

YESNO

+ value :Boolean

DATA_VALUE

IDENTIFIER

+ id :String+ type :CODED_TEXT+ issuer :String

ENCAPSULATED

MULTIMEDIA

+ alternate_text :String [0..1]+ media_type :CODED_TEXT+ uri :URI [0..1]

«is_im_runtime»+ data :Byte [0..*] (Array)+ integrity_check :Byte [0..*] (Array)

PARSABLE

+ formalism :CODED_TEXT+ value :String

COUNT

+ magnitude :Integer

QUANTITY

+ magnitude :Double+ units :CODED_TEXT+ precision :Integer [0..1]

PROPORTION

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

ORDINAL

+ symbol :CODED_TEXT+ value :Integer

ORDERED

QUANTIFIED

+ magnitude_status :String [0..1]

AMOUNT

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

ABSOLUTE_QUANTITY

DATE

+ value :String+ magnitude :Integer [0..1]

TIME

+ value :String+ magnitude :Double [0..1]

DATE_TIME


DURATION


TEMPORAL

TEXT

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

CODEABLE_TEXT

URI

+ value :String

CODED_TEXT

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

EHR_URI

T : ORDERED

INTERVAL

+ upper_unbounded :Boolean+ lower_unbounded :Boolean+ upper_included :Boolean+ lower_included :Boolean

TERM_MAPPING

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

PLAIN_TEXT

+upper0..1

+mappings0..*

+lower

0..1

+target 1..1

• Updated documentation• Discussion on GitHub regarding issues raised in reviews• Create BMM file to load CIMI Reference Model in ADL Workbench• Automated EA UML to BMM file generation

F1. Define CIMI Reference Model

• Extend to support relationship meaning• Terminology binding syntax• Review to identify other gaps• Test through use

F2. Archetype Object Model


Relationship_id[0..1]:String

Terminology Binding Syntax• Semantics/meaning (node and relationships)• Value sets• Options

– CTS2– FHIR– IHTSDO: URI Specification (Draft)

• E.g. http://snomed.info/sct/{sctid}/version/{timestamp}– MOHH: URI Specification (Generic binding)

• terminology : <code system id>[:version] ? <query type> = <query expression> [& <extension key> = extensionvalue]*

• query_type: concept, conceptlist, refset / refsetlist, escg, ocl• E.g. terminology:2.16.840.1.113883.6.96:20110123?refset=284296007

&scope=CIMI


F3. CIMI Modelling Patterns

Modelling Patterns Reviewed:• openEHR• NHS LRA• SNOMED CT• results4Care DCMs• IMH CEMs• MOHH LIM• VA’s Discernables • EN13606 Association• HL7 v3 RIM• Tolven

F3. CIMI Modelling Patterns

• Modelling Patterns Considered– Clinical Statement/Entry Types

• Observation, Evaluation/Finding, Instruction, Action– Isosemantic Patterns

• Name (focal concept), Details– Event History/ Time Series

• E.g. Heart rate time series, Apgar score (1, 2, 5, 8, 10 mins)– Clinical process links

• E.g. interprets, caused by, evidence for, derived from• Review: ISO13606, LRA, SNOMED CT

– Other Patterns & Reusable Model Components• E.g. Event summary, Reference Range, Schedule, Material,

Score/Assessment Scale– State machine / Careflow

• E.g. Medication activity state transitions, Contsys

Clinical Investigator Record (CIR) Ontology

• openEHR– Observation, Evaluation, Instruction, Action, Admin Entry

• MOHH– Observation, Finding, Activity (Medication, Laboratory), Administration

• NHS LRA– ELEMENTs: Property Observation, Finding Observation, Activity (Investigation,

Material, General), Material Entity– ENTRYs: GenericFinding, GenericProcedure, GenericProblemAndIssue, ....

• Intermountain/GE– Observed, StandardLabObs, Procedure, Order, Intolerance, Allergy, Adverse

Reaction Summary, Admit/AdminDiagnosis, ...

• SNOMED CT– Observable Entity, Clinical Finding, Procedure, ...

• EN13606 Association– Observation, Evaluation, Instruction, Action

• HL7 v3– Act (Observation, Procedure, Exposure, Patient Encounter, Financial Contract,

Financial Transaction, Account, Invoice Element, Context Structure, Device, Task, Supply)

Clinical Statement Types(Observation)

• openEHR– Observation: the observation of any phenomenon or state of interest to do with the

patient.• NHS LRA

– Property Observation: Used to represent the results of investigations undertaken to find out more information about a patient's state of health or wellbeing and device or procedure related parameter settings. (Meaning-value pairs)

• SNOMED CT– Observable Entity: represents a question or procedure which can produce an

answer or a result. Used to code elements on a checklist or any element where a value

• EN13606 Association– Observation/Inspection: Used to define all that can be documented about a specific

state of a process in the Patient System at a point in time using the faculties of seeing, hearing, tasting, touching, smelling, or directly via a medical device or service.

• HL7 RIM– Observation: An Act of recognizing and noting information about the subject, and

whose immediate and primary outcome (post-condition) is new data about a subject. Observations often involve measurement or other elaborate methods of investigation, but may also be simply assertive statements.

Observation (Existing Definitions)

http://www.en13606.org/wiki/index.php?title=Patient_System

Used to represent the results of investigations undertaken to find out more information about a patient’s state of health or wellbeing, and related settings.

Comments:• E.g. Heart rate, Blood glucose• Represented using the common name-value or question-

answer pattern• Supports isosemantic representation of Observation

Names that may include method, patient_state, device, body location and other related information in pre or post-coordinated form.

Observation(Suggested CIMI Definition)

F3. CIMI Modelling Patterns(Clinical Entry)

Who

Where

When

What/How/Why

F3. CIMI Modelling Patterns(Observation)

Who

Where

When

What/Why/How

What

To describe and demonstrate the approach to CIMI clinical modelling

Goal: Consistency and reproducibility of CIMI models

Table of Contents:– Background & Architectural Framework– Reference Model– Modelling Layers– Modelling Patterns– Modelling Principles

• Quality Criteria• Scope of Clinical Models• Granularity of Clinical Models• Consistency and Reuse• Isosemantic Models• Terminology Binding• Additional Principles

– Modelling Methodology– Appendix: Example models and instance data

F4. CIMI Style Guide

F4. CIMI Style Guide(Quality Criteria – 6.1)

CIMI models will be:• Able to satisfy the URU principles – that is they will be

– Understandable (cohesive and coherently expressed)– Reliable and reusable (consistency)– Useful (fit for purpose)– Uptodate (currency)

• Clinically accurate• Clinically valid• Evidence based• Adequate to express required clinical statements• Able to maintain contextual integrity (when transformed into isosemantic

models)• Able to maintain semantic fidelity (when transformed into isosemantic

models)• Clear and precise, minimizing the potential for:

– Misinterpretation and– Misuse or inconsistency in use

• With low complexity (suitable for easy implementation and avoid cognitive overload of users)

F4. CIMI Style Guide(Scope – 6.2)

The following information will be included in CIMI clinical models:

• Information that is considered to be directly relevant to the clinical concept being modelled.

• Information that describes the who, what, when, where, how and why of the clinical concept being modelled.

• Information that may either be represented using pre-coordination or post-coordinated in the structure – for example, the body location of a diagnosis.

• Information that is not described in the exclusion list.• To be decided: Information that provides a classification

for other items in the model

F4. CIMI Style Guide(Scope – 6.2)

The following information will be excluded from CIMI clinical models:• Information that is specific to an implementation use-case - for example,

recordkeeping metadata (unless the model is specifically designed for this purpose).

• Information that is specific to a care-setting - for example, hospital ward details (unless the model is specifically designed for this purpose).

• Information that is specific to a clinical specialty – for example, neonatal care information (unless the model is specifically designed for this purpose).

• Information that is used for administrative purposes only – e.g. financial details (unless the model is specifically designed to include this)

• Information that is specific to a local environment (e.g. to satisfy local legislation requirements).

• Information that is included in the pattern on which the model is based• Information that is considered not to be directly related to the clinical

concept being modelled.

F4. CIMI Style Guide(Granularity of Models – 6.3)

More than one piece of atomic data can be included in the same clinical model when the following conditions hold:

• The atomic pieces of data are all directly related to the concept being modelled

• It is considered to be good clinical practice for instances of these data items to be observed, evaluated or performed together, using the same who, what, when, where and how information.

For example:• Systolic and diastolic blood pressures will be included together within

a single ‘Blood Pressure’ observation model.

F4. CIMI Style Guide(Isosemantic Models – 6.5)

CIMI clinical models will support isosemantic models in terms are both:• The ability to transform CIMI models to/from isosemantic representations in other

languages/ standards (e.g. CDA, openEHR, ISO13606, DCM, CEM), and• The ability to transform CIMI models between isosemantic representations that use a

different split between terminology pre-coordination and structure.The first category of isosemantic models (alternative language representations) will be

supported by defining mappings to other languages. It is not anticipated that CIMI will provide these mappings, although some exemplars may be provided to demonstrate the capability.

The second category of isosemantic models (terminology pre-coordination versus structure) will be supported by:

• Identifying where in the model intensional description logic applies• Including the structural representation, for any information which may be represented

using a separate attribute in some clinical contexts;• Defining the semantics of each of these structural attributes using terminology bindings;• Defining the semantics of the relationships between these structural attributes using

terminology bindings;• Identifying the focus attribute of the isosemantic pattern (i.e. the attribute which may be

represented using a precoordination of the other attributes)• Providing an expression formalism to show the relationship between different isosemantic

forms (e.g. compositional grammar)

F4. CIMI Style Guide(Terminology Binding)

All finalised CIMI Clinical Models will:• Include a terminology semantic binding from each node in the

model to a terminology concept (or expression), which represents the meaning of the node.

• Include a terminology semantic binding from each node relationship in all isosemantic patterns to a terminology concept that represents the meaning of the relationship.

All finalised CIMI Clinical Models may (where appropriate):• Include a terminology semantic binding from other node

relationships to a terminology concept that represents the meaning of the relationship.

• Include a terminology value binding from a node of type Codeable Text to a terminology reference set, containing concepts which represent the set of valid values for the node.


• Modelling Approach1. Analyse clinical models submitted (with value sets)2. Identify maximal set of data elements3. Remove ‘out of scope’ data elements (Style Guide)4. Select appropriate CIMI Modelling Patterns(Style Guide)5. Define CIMI model structure (Mindmap, ADL, UML)6. Add Terminology bindings



o ADL, UML


Overview

• Heart Rateo Linda and Marcello

• Body Mass Indexo Gerard and Rahil

• Apgar Scoreo William and Michael

• Problem list o Mike and Galen

• Adverse Reactiono Stan and Stephen

• Glucose Tolerance Test Result• Medication order• Care Giver Reported Nausea• Wound Culture Result

M1. Analyse clinical models submitted (with value sets)

M1. Analyse clinical models submitted (Heart Rate)

• openEHR– openEHR-EHR.OBSERVATION.heart_rate.v1 – Rev 5

• MOHHoldings– Observation

• IMH– HeartRateMeas

• Results4Care– HeartRate

• EN13606 Association– Heart Rate ACTION– Heart Rate OBSERVATION

• NEHTA– openEHR.EHR.OBSERVATION.heart_rate.v1 – Rev 5

• TOLVEN– Pulse Rate

M1. Analyse clinical models submitted (Heart Rate – openEHR/NEHTA)

M1. Analyse clinical models submitted (Heart Rate - MOHH)

LID Name Cardinality DefinitionE12 OBSERVATION - An individual observation that was performed. E12.17 Observing Clinician 0..1 The Healthcare Professional who performed the observation. E12.18 Other Participation 0..Many Other participants involved in the patient's healthcare, who are relevant to this

entry. E12.19 Observation Item

(Design Pattern) 1 The name and/or description of the observation that is associated with this Observation ENTRY.

E12.19.1 Observation Name 1 The name of the observation.

E12.19.2 Observation Timing Description 0..1 A descriptor used in combination with the Observation Name to fully define the description of the observation.

E12.19.3 Context Group 0..1 Qualifying attributes that define the context of the observation. E12.19.4 Associated Finding 0..1 This attribute links concepts in the Situation with explicit context hierarchy to their related

Clinical finding. It specifies the Clinical finding concept whose context is being modified. E12.19.5 Episodicity 0..1 EPISODICITY is used to represent episodes of care provided by a physician or other care

provider, typically a general practitioner, not episodes of disease experienced by the patient. E12.19.6 Clinical Course 0..1 This attribute is used to represent both the course and onset of a disease. E12.19.7 Site Laterality 0..Many Attributes used to describe the finding site. Site 0..1 The site of the observation measurement Laterality 0..1 The laterality of the observation measurement E12.19.8 Severity 0..1 The seriousness of the impact of the adverese reaction on the person. E12.19.9 Care Setting 0..1 The care setting where the observation took place.

E12.19.10 Category 0..1 The category of the observation - in particular, whether the observation is a based on a finding (ie. a descriptive term or code) or a property (ie. with an attribute- value pair).

E12.19.11 Type 0..1 The type of the observation. E12.19.12 Subtype 0..1 The subtype of the observation, if required. E12.19.13 Clinical Notes 0..1 The remarks associated with the observation result. E12.20 Observation Status Details 0..1 Information related to the status of the observation. E12.20.1 Observation Status 0..1 The status of the observation measurement, in terms of its clinical workflow. E12.21 Observation Dates 0..1 Dates associated with the observation. E12.21.1 Observation DateTime 0..1 The point of time, or time interval at/during which the observation took place, such

as an average observation over a time interval. E12.22 Observation Result 0..1 Information related to the result of the observation. E12.22.1 Observation Result Value 0..1 The result value of the observation. E12.22.2 Observation Result Value Type 0..1 The data type used to record the observation result value. E12.22.3 Interpretation 0..1 An indicator as to whether or not the clinical results are normal or abnormal. E12.22.4 Reference Range 0..1 The reference range of the observation.

M1. Analyse clinical models submitted (Heart Rate - IMH)

M1. Analyse clinical models submitted (Heart Rate – Results4Care)

class Information Model

«rootconcept»HeartRate

«rootconcept»HeartRate

CD

«qualifier,enumeration»Method

«enum»+ Auscultation+ BedsideMonitor+ ECG+ Palpation/ manual+ Ultrasound

CD

«qualifier,enumeration»Method

«enum»+ Auscultation+ BedsideMonitor+ ECG+ Palpation/ manual+ Ultrasound

CD

«state,enumeration»BodyPosition

«enum»+ Lying+ Sitting+ Standing+ Reclining

CD

«state,enumeration»BodyPosition

«enum»+ Lying+ Sitting+ Standing+ Reclining

CD

«state,enumeration»Exertion

«enum»+ In rest+ Post exercise+ During exercise

CD

«state,enumeration»Exertion

«enum»+ In rest+ Post exercise+ During exercise

CD

«data,enumeration»FrequencyQualification

«enum»+ Alternating bradycardia and tachycardia+ Bradycardia+ Normal+ Tachycardia

CD

«data,enumeration»FrequencyQualification

«enum»+ Alternating bradycardia and tachycardia+ Bradycardia+ Normal+ Tachycardia

CD

«data,enumeration»Rhythm

«enum»+ Bigeminal pulse+ Bisferiens+ Extra-systole+ Irregulair+ Palpitation+ Pulsus alternans+ Pulsus irregularis perpetuus+ Regular+ Trigeminal pulse

CD

«data,enumeration»Rhythm

«enum»+ Bigeminal pulse+ Bisferiens+ Extra-systole+ Irregulair+ Palpitation+ Pulsus alternans+ Pulsus irregularis perpetuus+ Regular+ Trigeminal pulse

CD

«data,enumeration»Volume

«enum»+ Large+ Normal+ Weak

CD

«data,enumeration»Volume

«enum»+ Large+ Normal+ Weak

Name: Information ModelAuthor: Ybranda Koster, Michael van der ZelVersion: 0.71Created: 5/11/2009 3:40:04 PMUpdated: 20/07/2012 12:05:07 AM

CD

«data,enumeration»Regularity

«enum»+ Irregular+ Regular

CD

«data,enumeration»Regularity

«enum»+ Irregular+ Regular

CD

«qualifier,enumeration»Location

«enum»+ Arteria brachialis+ Arteria carotis+ Arteria carotis externa+ Arteria dorsalis pedis+ Arteria femoralis+ Arteria poplitea+ Arteria radialis+ Arteria subclavia+ Arteria temporalis+ Arteria tibialis+ Arteria tibialis posterior+ Fontanel (baby)

CD

«qualifier,enumeration»Location

«enum»+ Arteria brachialis+ Arteria carotis+ Arteria carotis externa+ Arteria dorsalis pedis+ Arteria femoralis+ Arteria poplitea+ Arteria radialis+ Arteria subclavia+ Arteria temporalis+ Arteria tibialis+ Arteria tibialis posterior+ Fontanel (baby)

PQ

«data»Frequency

unit = /min

constraints{Between 0 and 1000}

PQ

«data»Frequency

unit = /min

constraints{Between 0 and 1000}

CD

«data,enumeration»Strength

«enum»+ Normal+ Strong+ Weak

CD

«data,enumeration»Strength

«enum»+ Normal+ Strong+ Weak

CD

«qualifier,enumeratio...PointInTime

«enum»+ 1H min+ 1H max+ 1H mean

CD

«qualifier,enumeratio...PointInTime

«enum»+ 1H min+ 1H max+ 1H mean

?

rootconcept

data

qualifier

state

Legend

0..1

M1. Analyse clinical models submitted (Heart Rate – en13606 Assoc)

M1. Analyse clinical models submitted (Heart Rate - Tolven)

M2. Identify maximal set of data elementsHeart Rate - Data Elements

CIMI openEHR/NEHTA MOHH IMH Results4Care EN13606 Association TOLVEN

Data Requirement Data Type Reason for Exclusion

(openEHR-EHR.OBSERVATION.

heart_rate.v1 - Rev. 5)(Observation) (HeartRateMeas) (HeartRate) (Heart Rate

ACTION)(Heart Rate

OBSERVATION) (Pulse Rate)

Who Subject (II) Participation Subject (II) Subject (II) Subject (Coded) Subject Patient

Information Provider (II) Participation Information Provider (II) Information Provider (II)

Observer Participation Observing Clinician (II) Performer

Participant included in reference model Participant (II) Participant (II)

Participant (Cluster)(ParticipationType (Coded)

Role (Coded)IndividualPerson.PersonIden

tifier (II)IndividualPerson.PersonNam

e (Name Cluster)

dataEntered

ReportedReceived record-keeping use-case ReportedReceived (Cluster) Author

Verified record-keeping use-case Verified (Attribution)

Updated record-keeping use-case Updated (Attribution)

When Link from (instruction) included in

reference model Reason (Link to INSTRUCTION)

Reason (Link to ACTION) encounter

Workflow Id implementation specific? Workflow Identifier (id) transition

Observation DateTime DateTime Start Date/Time (DateTime)

Observation DateTime (IVL<DateTime>) Point in Time time of

observationObservation DateTime

RangeInterval<DateTi

me> ObservedStartTime

(DateTime)/ ObservedEndTme (DateTime)

Range in Time

Relative Time Duration Event time (DateTime) Relative Time Observation Duration Duration Duration (DateTime) Observation Offset /

Observation Offset Origin DateTime

Events (Event)

Time of Day (Codeabe) CodedText Time of Day (Codeable)

RelativeTemporalContext (Coded)

Observation Status CodedText Observation Status (Coded) statusCodeWhere

Location of Subject Participation Observed.PatientLocation (String) Location/

Address

Location of Observer Participation Observed.ProviderLocation (String)

What (measurement) / How / Why

Observation Name CodedText Observation Name (Coded) key (String) Physiology+Org

an System titleObservation Reason CodedText Observed.Reason (Coded)

Body Position CodedText Position (Coded) BodyPosition (Coded) BodyPosition (Coded) Confounding Factors CodeableText Confounding Factors

(Codeable) PatientPrecondition (Coded) Excertion Slot Excertion (Slot) Excertion (Coded)

Care Setting CodeableText Care Setting (Codeable)

Body Location (Cluster): Site/Laterality Group: Body Location (Cluster): Body Site CodeableText Body Site (Codeable) Body Location.data (Coded) Location (Coded) Anatomical

Location siteAggregate Body Site Aggregate (Coded)

Body Laterality CodedText BodyLaterality (Coded) BodySide CodedText Laterality (Codeable) BodySide (Coded) laterality

Body Location Qualifier CodedText BodyLocationQualifier (Coded)

Observation Method CodeableText Method (Codeable) Observed.ActionMethod (Coded) Method (coded) Protocol

Device Slot Device (Slot) MethodDevice (Coded) Device Aggregate Function

(Codeable) Aggregate Function (Coded) PointInTime (Coded)

What (Observation) Heart Rate Quantity Heart Rate (Quantity) Result Value

(Quantity) data (PQ) Frequency (Quantity[unit=/min]) Result

(Quantity) observationHeart Rate Present? Boolean Heart Beat Present? (Bl)

Regularity Out of scope->Specialisation? Regularity (Coded) Regularity (Coded)

Rhythm Out of scope->Specialisation? Rhythm (Coded) rhythm

Strength Out of scope->Specialisation? Strength (Coded)

FrequencyQualification Out of scope->Specialisation? FrequencyQualification

(Coded)

Volume Out of scope->Specialisation? Volume (Coded)

Clinical Notes String Clinical Notes (String) Comment (String) commentInterpretation CodedText Interpretation (Coded) AbnormalInterpretation

(Coded) DeltaFlag CodedText DeltaFlag (Coded)

Reference Range Slot Reference Range Set (Cluster) ReferenceRangeNar (String)

M2. Identify maximal set of data elements

Data Requirement Data TypeWho

Subject (II) ParticipationInformation Provider (II) Participation

Observer ParticipationParticipant

ReportedReceived Verified Updated When

Link from (instruction) Workflow Id

Observation DateTime DateTime

Observation DateTime Range Interval<DateTime>

Relative Time DurationObservation Duration DurationObservation Offset /

Observation Offset Origin DateTime

Time of Day (Codeabe) CodedTextObservation Status CodedText

Where Location of Subject Participation

Location of Observer Participation

What (measurement) / How / Why Observation Name CodedText

Observation Reason CodedTextBody Position CodedText

Confounding Factors CodeableTextExcertion Slot

Care Setting CodeableTextBody Location (Cluster):

Body Site CodeableTextAggregate Body Site CodedText

Body Laterality CodedTextBodySide CodedText

Body Location Qualifier CodedTextObservation Method CodeableText

Device SlotAggregate Function (Codeable)

What (Observation) Heart Rate Quantity

Heart Rate Present? BooleanRegularity

Rhythm Strength

FrequencyQualification Volume

Clinical Notes StringInterpretation CodedText

DeltaFlag CodedTextReference Range Slot

M3. Remove ‘out of scope’ data elements (Style Guide – 6.2)

The following information will be excluded from CIMI clinical models:• Information that is specific to an implementation use-case - for example,

recordkeeping metadata (unless the model is specifically designed for this purpose).

• Information that is specific to a care-setting - for example, hospital ward details (unless the model is specifically designed for this purpose).

• Information that is specific to a clinical specialty – for example, neonatal care information (unless the model is specifically designed for this purpose).

• Information that is used for administrative purposes only – e.g. financial details (unless the model is specifically designed to include this)

• Information that is specific to a local environment (e.g. to satisfy local legislation requirements).

• Information that is included in the pattern on which the model is based• Information that is considered not to be directly related to the clinical

concept being modelled.

M3. Remove ‘out of scope’ data elements (Style Guide)

Data Requirement Data Type Reason for ExclusionWho

Subject (II) Participation in Clinical Entry PatternInformation Provider (II) Participation in Clinical Entry Pattern

Observer Participation in Observation PatternParticipant in reference model

ReportedReceived record-keeping use-caseVerified record-keeping use-caseUpdated record-keeping use-caseWhen

Link from (instruction) in reference modelWorkflow Id implementation specific?

Observation DateTime DateTime in Observation PatternObservation DateTime Range Interval<DateTime> in Observation Pattern

Relative Time Duration in Observation PatternObservation Duration Duration in Observation Pattern

Observation Offset / Observation Offset Origin DateTime in Observation Pattern

Time of Day (Codeabe) CodedText Observation Status CodedText in Observation Pattern

Where Location of Subject Participation in Observation Pattern

Location of Observer Participation in Observation Pattern

M3. Remove ‘out of scope’ data elements (Style Guide)

What (measurement) / How / Why Observation Name CodedText in Observation Pattern

Observation Reason CodedText Body Position CodedText

Confounding Factors CodeableText Excertion Slot

Care Setting CodeableText Body Location (Cluster):

Body Site CodeableText Aggregate Body Site CodedText

Body Laterality CodedText BodySide CodedText

Body Location Qualifier CodedText Observation Method CodeableText

Device Slot Aggregate Function (Codeable)

What (Observation) Heart Rate Quantity

Heart Rate Present? Boolean Regularity Out of scope->Specialisation?

Rhythm Out of scope->Specialisation?

Strength Out of scope->Specialisation?

FrequencyQualification Out of scope->Specialisation?

Volume Out of scope->Specialisation?Clinical Notes String Interpretation CodedText in Observation Pattern

DeltaFlag CodedText Reference Range Slot

M4. Select appropriate CIMI Modelling Pattern (Style Guide)

Who

Where

When

What/Why/How

What

M5. Define CIMI model (Mindmap, ADL, UML)

Who

Where

When

What/Why/How

What


High Level Classes for Observation Model Bindings• Record artifact• Observable entity (or LOINC code)• Clinical findings• Situation with explicit context

Outstanding Questions• Which parts of the model should include semantic node bindings?• Which parts of the model should include semantic relationship

bindings?• Is it appropriate to extend the SNOMED CT concept model to support

isosemantic requirements?• Can terminology binding rules, patterns or principles be identified?• What value set should we use for links between model components?• How should we clearly identify the intensional/DL parts of the model?

• Important for both technical and clinical validation.

• Format for instance data will be discussed tomorrow.

M7. Add Example Instance Data

• Technical validation of:– Reference Model (e.g. BMM file in ADL workbench)– Clinical Modelling Patterns (e.g. ADL, UML tools)– Clinical Models (e.g. ADL, UML tools)

• Requires tooling support – e.g.– ADL Workbench– AML (UML Profile) Tooling– Others

M8. Technical validation

• Clinical validation using different representations, such as:– Mindmaps– Hierarchy– UML– Data entry forms– Etc

TO DO• A methodology for providing multiple visualisations of clinical models

for different audiences (both clinical and technical)

M9. Clinical Validation / Review

M10. Confirm transformations back to submitted models

• openEHR– openEHR-EHR.OBSERVATION.heart_rate.v1 – Rev 5

• MOHH– Observation

• IMH– HeartRateMeas

• Results4Care– HeartRate

• EN13606 Association– Heart Rate ACTION– Heart Rate OBSERVATION

• NEHTA– openEHR.EHR.OBSERVATION.heart_rate.v1 – Rev 5

• TOLVEN– Pulse Rate


• Modelling Approach1. Analyse clinical models submitted (with value sets)2. Identify maximal set of data elements3. Remove ‘out of scope’ data elements (Style Guide)4. Select appropriate CIMI Modelling Patterns(Style Guide)5. Define CIMI model (Mindmap, ADL, UML)6. Add Terminology bindings



o ADL, UML


Overview

cimi modelling taskforce report

Documents

cimi models

cimi clinical modelling

cimi technical models

modelling style guidescreate

set of models

models uml adlheart

transformationsa methodology

uml aom approachesmethodology