CIMI Modelling Taskforce Report Dr Linda Bird 14

CIMI Modelling Taskforce Report Dr Linda Bird 14 th May 2012

Agenda • • • Members Mission & TOR Overview of work Call For Models Modelling Approach o Background o Foundations o Summary of Approach

Taskforce Members 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 Technical Resources: • Peter Hendler • Galen Mulrooney • Grahame Grieve • Dipak Kalra • Daniel Karlsson • Cecil Lynch • David Moner Clinical Modelling Resource: • William Goossen • Jay Lyle • Ian Mc. Nicoll • Anneke Goossen • Heather Leslie • Marcelo Rodrigues dos Santos • Sarah Ryan • Hendry Wijaya

Mission To develop a CIMI modelling methodology, style guide and a set of models, which together demonstrate and test the approach to CIMI clinical modelling.

Terms of Reference 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.

Planned Deliverables D 1 CIMI Reference Model D 2 CIMI RM Documentation D 3 CIMI Modelling Patterns D 4 CIMI Clinical Models One or more computable representations (UML & BMM) One or more artefacts documenting the CIMI RM (Word) A set of modelling patterns (UML & ADL) 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 data D 5 CIMI Modelling Methodology. Modelling Style Guide / Best Practices Guidelines Document – Iterative approach to methodology development D 6 CIMI Terminology CIMI value sets, semantic concepts, and CIMI SNOMED CT extension – Documentation of approach to terminology binding D 7 Updates to AOM Computable representation of AOM to meet CIMI requirements D 8 CIMI Taskforce Report A 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 D 9 Meeting Minutes A summary of taskforce meetings

Overview of Work

Meeting Summary 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: open. EHR, NHS LRA August 2 Modelling Patterns: ADL workbench, SNOMED August 9 Modelling Patterns: VA, MOHH, R 4 C, EN 13606 Assoc Heart Rate model submissions: comparative analysis August 16 HL 7 v 3, 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 Terminology Planning for Rockville

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

Infrastructure • 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-modellingtaskforce? hl=en-GB • CIMI website – CIMI models tab, Quick links, Links to the Doc repository

CIMI Modelling • 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

Call For Models

Call For Models • Modelling Patterns plus: • Heart Rate • Body Mass Index • Apgar Score • Glucose Tolerance Test Result • Adverse Reaction • Medication order • Problem list • Nausea • Wound Culture Result

Model Submissions • CIHI/Infoway – Allergy/Intolerance, Medication Order • EN 13606 Association – Blood Pressure, Investigation, Observation, Description of others • Intermountain Healthcare – All requested models • Kaiser Permanente – Health. Concern • MOHHoldings – All models (some generalisations) • NEHTA – Adverse Reaction, Problem/Diagnosis, Med Order • NHS – Allergies/Adverse Reaction, Problem&Issue, Diagnosis, Medication Activity • open. EHR – All models • Results 4 Care – Heart rate, BMI, Apgar Score • Tolven – All models (except Apgar score & wound culture) • VA – Problem List

Modelling Approach

CIMI Architectural Overview

CIMI Modelling Layers CLUSTER ENTRY SECTION COMPOSITION Add Implementation Purpose Context Dispensed Medications GUI Neonatal Blood Pressure in EHR Current Medication List in EHR Discharge Summary Doc or Message Add Care Setting Context G. P. Dispensed Medication Item Home Blood Pressure Outpatient Clinic Current Medication List Inpatient Discharge Summary Add Specialty Context Paediatric Medication Item Neonatal Blood Pressure Nephrologist Medication List Cardiology Discharge Summary Add Use Case Context Dispensed Medication Item Standing Blood Pressure Current Medication List Medication Reconciliation Report Clinical Models Medication Item Blood Pressure Medication List Discharge Summary Modelling Patterns Schedule, Address, Material Observation, Action Clinical List Event Summary, Assessment Reference Model

Iso. Semantic Models – Example of Problem e. g. “Suspected Lung Cancer”

Iso. Semantic Models – Example Instances e. g. “Suspected Lung Cancer”

Iso. Semantic Models – Graph-based Model

Overview • Foundations 1. 2. 3. 4. CIMI Reference Model Archetype Object Model CIMI Modelling Patterns CIMI Style Guide • Modelling Approach 1. 2. 3. 4. 5. 6. 7. 8. Analyse clinical models submitted (with value sets) Identify maximal set of data elements Remove ‘out of scope’ data elements (Style Guide) Select appropriate CIMI Modelling Patterns(Style Guide) Define CIMI model (Mindmap, ADL, UML) Add Terminology bindings o o Meaning (nodes, node relationships) Value sets (maximal set from submitted models) Add Example Model Data Instances Technical Validation o ADL, UML 9. Clinical Validation / Review 10. Confirm mappings from submitted models

F 1. Define CIMI Reference Model

F 1. Define CIMI Reference Model • • Updated documentation Discussion on Git. Hub regarding issues raised in reviews Create BMM file to load CIMI Reference Model in ADL Workbench Automated EA UML to BMM file generation

F 2. Archetype Object Model • • Extend to support relationship meaning Terminology binding syntax Review to identify other gaps Test through use

F 2. Archetype Object Model Relationship_id[0. . 1]: String

F 2. Archetype Object Model

F 2. Archetype Object Model Terminology Binding Syntax • Semantics/meaning (node and relationships) • Value sets • Options – CTS 2 – 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

F 3. CIMI Modelling Patterns Reviewed: • open. EHR • NHS LRA • SNOMED CT • results 4 Care DCMs • IMH CEMs • MOHH LIM • VA’s Discernables • EN 13606 Association • HL 7 v 3 RIM • Tolven

F 3. 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: ISO 13606, 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

Clinical Statement Types (Observation) • open. EHR – Observation, Evaluation, Instruction, Admin Entry • MOHH – Observation, Finding, Activity (Medication, Laboratory), Administration • NHS LRA – ELEMENTs: Property Observation, Finding Observation, Activity (Investigation, Material, General), Material Entity – ENTRYs: Generic. Finding, Generic. Procedure, Generic. Problem. And. Issue, . . • Intermountain/GE – Observed, Standard. Lab. Obs, Procedure, Order, Intolerance, Allergy, Adverse Reaction Summary, Admit/Admin. Diagnosis, . . . • SNOMED CT – Observable Entity, Clinical Finding, Procedure, . . . • EN 13606 Association – Observation, Evaluation, Instruction, Action • HL 7 v 3 – Act (Observation, Procedure, Exposure, Patient Encounter, Financial Contract, Financial Transaction, Account, Invoice Element, Context Structure, Device, Task, Supply)

Observation (Existing Definitions) • open. EHR – 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 • EN 13606 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. • HL 7 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 (Suggested CIMI Definition) 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 questionanswer pattern • Supports isosemantic representation of Observation Names that may include method, patient_state, device, body location and other related information in pre or postcoordinated form.

F 3. CIMI Modelling Patterns (Clinical Entry) Who When Where What/How/Why

F 3. CIMI Modelling Patterns (Observation) When Who What/Why/How Where What

F 4. CIMI Style Guide 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

F 4. 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)

F 4. 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 precoordination 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

F 4. 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.

F 4. 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.

F 4. 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, open. EHR, ISO 13606, 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)

F 4. 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.

Overview • Foundations 1. 2. 3. 4. CIMI Reference Model Archetype Object Model CIMI Modelling Patterns CIMI Style Guide • Modelling Approach 1. 2. 3. 4. 5. 6. 7. 8. Analyse clinical models submitted (with value sets) Identify maximal set of data elements Remove ‘out of scope’ data elements (Style Guide) Select appropriate CIMI Modelling Patterns(Style Guide) Define CIMI model structure (Mindmap, ADL, UML) Add Terminology bindings o o Meaning (nodes, node relationships) Value sets (maximal set from submitted models) Add Example Model Data Instances Technical Validation o ADL, UML 9. Clinical Validation / Review 10. Confirm mappings from submitted models

M 1. Analyse clinical models submitted (with value sets) • Heart Rate o Linda and Marcello • Body Mass Index o Gerard and Rahil • Apgar Score o William and Michael • Problem list o Mike and Galen • Adverse Reaction • • o Stan and Stephen Glucose Tolerance Test Result Medication order Care Giver Reported Nausea Wound Culture Result

M 1. Analyse clinical models submitted (Heart Rate) • open. EHR – open. EHR-EHR. OBSERVATION. heart_rate. v 1 – Rev 5 • MOHHoldings – Observation • IMH – Heart. Rate. Meas • Results 4 Care – Heart. Rate • EN 13606 Association – Heart Rate ACTION – Heart Rate OBSERVATION • NEHTA – open. EHR. OBSERVATION. heart_rate. v 1 – Rev 5 • TOLVEN – Pulse Rate

M 1. Analyse clinical models submitted (Heart Rate – open. EHR/NEHTA)

LID E 12 M 1. Analyse clinical models submitted (Heart Rate - MOHH) E 12. 17 Name OBSERVATION Observing Clinician E 12. 18 E 12. 19. 1 E 12. 19. 2 E 12. 19. 3 Cardinality Definition An individual observation that was performed. 0. . 1 The Healthcare Professional who performed the observation. Other participants involved in the patient's healthcare, who are relevant to this Other Participation 0. . Many entry. Observation Item The name and/or description of the observation that is associated with this 1 (Design Pattern) Observation ENTRY. Observation Name 1 The name of the observation. A descriptor used in combination with the Observation Name to fully define the Observation Timing Description 0. . 1 description of the observation. Context Group 0. . 1 Qualifying attributes that define the context of the observation. E 12. 19. 4 Associated Finding 0. . 1 E 12. 19. 5 Episodicity 0. . 1 E 12. 19. 6 E 12. 19. 7 Clinical Course Site Laterality Site 0. . 1 0. . Many 0. . 1 This attribute is used to represent both the course and onset of a disease. Attributes used to describe the finding site. The site of the observation measurement Laterality 0. . 1 The laterality of the observation measurement E 12. 19. 8 Severity 0. . 1 The seriousness of the impact of the adverese reaction on the person. E 12. 19. 9 Care Setting 0. . 1 The care setting where the observation took place. E 12. 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). E 12. 20 E 12. 21 E 12. 19. 12 E 12. 19. 13 E 12. 20. 1 Type Subtype Clinical Notes Observation Status Details Observation Status Observation Dates 0. . 1 E 12. 21. 1 Observation Date. Time 0. . 1 E 12. 22. 1 E 12. 22. 3 E 12. 22. 4 Observation Result Value Type Interpretation Reference Range 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. 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. The type of the observation. The subtype of the observation, if required. The remarks associated with the observation result. Information related to the status of the observation. The status of the observation measurement, in terms of its clinical workflow. Dates associated with the observation. The point of time, or time interval at/during which the observation took place, such as an average observation over a time interval. Information related to the result of the observation. The result value of the observation. The data type used to record the observation result value. An indicator as to whether or not the clinical results are normal or abnormal. The reference range of the observation.

M 1. Analyse clinical models submitted (Heart Rate - IMH)

M 1. Analyse clinical models submitted (Heart Rate – Results 4 Care)

M 1. Analyse clinical models submitted (Heart Rate – en 13606 Assoc)

M 1. Analyse clinical models submitted (Heart Rate - Tolven)

M 2. Identify maximal set of data elements Heart Rate - Data Elements CIMI Data Requirement Data Type Who Subject (II) Participation Information Provider (II) Participation Observer Participation Participant Reported. Received Verified Updated When Link from (instruction) Workflow Id Observation Date. Time Range Relative Time Observation Duration Observation Offset / Observation Offset Origin Date. Time Reason for Exclusion included in reference model open. EHR/NEHTA (open. EHREHR. OBSERVATION. heart_rate. v 1 - Rev. 5) Subject (II) MOHH IMH Results 4 Care (Observation) (Heart. Rate. Meas) (Heart. Rate) Subject (Coded) Subject Patient Participant (Cluster) (Participation. Type (Coded) Role (Coded) Individual. Person. Ident ifier (II) Individual. Person. Nam e (Name Cluster) Performer data. Entered Author Subject (II) Information Provider (II) Observing Clinician (II) Participant (II) record-keeping Reported. Received (Cluster) use-case record-keeping Verified (Attribution) use-case record-keeping Updated (Attribution) use-case included in reference model implementation Workflow Identifier (id) specific? Start Date/Time Observation Date. Time (Date. Time) (IVL<Date. Time>) Observed. Start. Time Interval<Date. Ti (Date. Time)/ me> Observed. End. Tme (Date. Time) Duration Event time (Date. Time) Duration (Date. Time) Events (Event) Time of Day (Codeabe) Coded. Text Time of Day (Codeable) Participation Relative. Temporal. Context (Coded) Observation Status (Coded) Observed. Patient. Location (String) Observed. Provider. Location (String) Observation Status Where Coded. Text Location of Subject Location of Observer EN 13606 Association (Heart Rate ACTION) OBSERVATION) Reason (Link to INSTRUCTION) ACTION) TOLVEN (Pulse Rate) encounter transition Point in Time time of observation Range in Time Relative Time Location/Addre ss status. Code

M 2. Identify maximal set of data elements Data Requirement Who Subject (II) Information Provider (II) Observer Participant Reported. Received Verified Updated When Link from (instruction) Workflow Id Observation Date. Time Data Type Participation Date. Time Interval<Date. Tim Observation Date. Time Range e> Relative Time Duration Observation Offset / Observation Offset Origin Date. Time of Day (Codeabe) Coded. Text Observation Status Coded. Text Where Location of Subject Participation Location of Observer Participation What (measurement) / How / Why Observation Name Observation Reason Body Position Confounding Factors Excertion Care Setting Body Location (Cluster): Body Site Aggregate Body Site Body Laterality Body. Side Body Location Qualifier Observation Method Device Aggregate Function (Codeable) What (Observation) Heart Rate Present? Regularity Rhythm Strength Frequency. Qualification Volume Clinical Notes Interpretation Delta. Flag Reference Range Coded. Text Codeable. Text Slot Codeable. Text Coded. Text Codeable. Text Slot Quantity Boolean String Coded. Text Slot

M 3. 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.

M 3. Remove ‘out of scope’ data elements (Style Guide) Data Requirement Data Type Who Subject (II) Participation Information Provider (II) Participation Observer Participation Participant Reported. Received Verified Updated When Link from (instruction) Workflow Id Observation Date. Time Range Interval<Date. Time> Relative Time Duration Observation Offset / Observation Offset Origin Date. Time of Day (Codeabe) Coded. Text Observation Status Coded. Text Where Location of Subject Participation Location of Observer Participation Reason for Exclusion in Clinical Entry Pattern in Observation Pattern in reference model record-keeping use-case in reference model implementation specific? in Observation Pattern in Observation Pattern

M 3. Remove ‘out of scope’ data elements (Style Guide) What (measurement) / How / Why Observation Name Observation Reason Body Position Confounding Factors Excertion Care Setting Body Location (Cluster): Body Site Aggregate Body Site Body Laterality Body. Side Body Location Qualifier Observation Method Device Aggregate Function (Codeable) What (Observation) Heart Rate Present? Regularity Coded. Text Codeable. Text Slot Codeable. Text Coded. Text Codeable. Text Slot Quantity Boolean in Observation Pattern Out of scope->Specialisation? Rhythm Out of scope->Specialisation? Strength Out of scope->Specialisation? Frequency. Qualification Out of scope->Specialisation? Volume Clinical Notes Interpretation Delta. Flag Reference Range String Coded. Text Slot Out of scope->Specialisation? in Observation Pattern

M 4. Select appropriate CIMI Modelling Pattern (Style Guide) When Who What/Why/How Where What

M 5. Define CIMI model (Mindmap, ADL, UML) When Who What/Why/How Where What

M 6. Add Terminology bindings

M 6. Add Terminology bindings 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?

M 6. Add Terminology bindings

M 7. Add Example Instance Data • Important for both technical and clinical validation. • Format for instance data will be discussed tomorrow.

M 8. Technical validation • 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

M 9. Clinical Validation / Review • 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)

M 10. Confirm transformations back to submitted models • open. EHR – open. EHR-EHR. OBSERVATION. heart_rate. v 1 – Rev 5 • MOHH – Observation • IMH – Heart. Rate. Meas • Results 4 Care – Heart. Rate • EN 13606 Association – Heart Rate ACTION – Heart Rate OBSERVATION • NEHTA – open. EHR. OBSERVATION. heart_rate. v 1 – Rev 5 • TOLVEN – Pulse Rate

Overview • Foundations 1. 2. 3. 4. CIMI Reference Model Archetype Object Model CIMI Modelling Patterns CIMI Style Guide • Modelling Approach 1. 2. 3. 4. 5. 6. 7. 8. Analyse clinical models submitted (with value sets) Identify maximal set of data elements Remove ‘out of scope’ data elements (Style Guide) Select appropriate CIMI Modelling Patterns(Style Guide) Define CIMI model (Mindmap, ADL, UML) Add Terminology bindings o o Meaning (nodes, node relationships) Value sets (maximal set from submitted models) Add Example Model Data Instances Technical Validation o ADL, UML 9. Clinical Validation / Review 10. Confirm mappings from submitted models