Presentation is loading. Please wait.

Presentation is loading. Please wait.

CIMI Modelling Taskforce Report Dr Linda Bird 14 th May 2012.

Similar presentations


Presentation on theme: "CIMI Modelling Taskforce Report Dr Linda Bird 14 th May 2012."— Presentation transcript:

1 CIMI Modelling Taskforce Report Dr Linda Bird 14 th May 2012

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

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

4 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

5 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

6 D1 CIMI Reference ModelOne or more computable representations (UML & BMM) D2 CIMI RM DocumentationOne or more artefacts documenting the CIMI RM (Word) D3 CIMI Modelling PatternsA set of modelling patterns (UML & ADL) D4 CIMI Clinical ModelsBased 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 D5 CIMI Modelling MethodologyModelling Style Guide / Best Practices Guidelines Document –Iterative approach to methodology development D6 CIMI TerminologyCIMI value sets, semantic concepts, and CIMI SNOMED CT extension –Documentation of approach to terminology binding D7 Updates to AOMComputable representation of AOM to meet CIMI requirements D8 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 MinutesA summary of taskforce meetings Planned Deliverables

7 D1 CIMI Reference ModelOne or more computable representations (UML & BMM) D2 CIMI RM DocumentationOne or more artefacts documenting the CIMI RM (Word) D3 CIMI Modelling PatternsA set of modelling patterns (UML & ADL) D4 CIMI Clinical ModelsBased 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 D5 CIMI Modelling MethodologyModelling Style Guide / Best Practices Guidelines Document –Iterative approach to methodology development D6 CIMI TerminologyCIMI value sets, semantic concepts, and CIMI SNOMED CT extension –Documentation of approach to terminology binding D7 Updates to AOMComputable representation of AOM to meet CIMI requirements D8 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 MinutesA summary of taskforce meetings Planned Deliverables

8 Overview of Work

9 July 5Mission, TOR, Deliverables, Call for Models, Secretary July 12Tasks & Activities Planning, Secretary July 19Model Submissions, Storage/Github, Modelling Process July 26 Modelling Patterns: openEHR, NHS LRA August 2Modelling Patterns: ADL workbench, SNOMED August 9Modelling Patterns: VA, MOHH, R4C, EN13606 Assoc Heart Rate model submissions: comparative analysis August 16HL7 v3, Modelling Pattern Review, CIMI Entry patterns August 23CIMI Entry patterns, Heart Rate Model & Style Guide August 30Terminology: NHS, Extensions to AOM, Binding Syntax September 6Model granularity, Time Series, Heart Rate Terminology Planning for Rockville Meeting Summary

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

11 Issue tracking (github) –https://github.com/clinicalmodels/cimi/https://github.com/clinicalmodels/cimi/ Google doc repository –Documents, clinical models, reference model, modelling patterns, model submissions –http://content.clinicalmodels.orghttp://content.clinicalmodels.org Google groups email list –cimi-modelling-taskforce –http://groups.google.com/group/cimi-modelling- taskforce?hl=en-GBhttp://groups.google.com/group/cimi-modelling- taskforce?hl=en-GB CIMI website –CIMI models tab, Quick links, Links to the Doc repository Infrastructure

12 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

13 Call For Models

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

15 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

16 Modelling Approach

17 CIMI Architectural Overview

18 CIMI Modelling Layers Reference Model Modelling Patterns Schedule, Address, Material Observation, Action Clinical List Event Summary, Assessment Clinical Models Medication Item Blood PressureMedication List Discharge Summary Add Specialty Context Paediatric Medication Item Neonatal Blood Pressure Nephrologist Medication List Cardiology Discharge Summary CLUSTER ENTRYSECTION 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

19 IsoSemantic Models – Example of Problem e.g. “Suspected Lung Cancer”

20 IsoSemantic Models – Example Instances e.g. “Suspected Lung Cancer”

21 IsoSemantic Models – Graph-based Model

22 IsoSemantic Models – Compositional Grammar Problem Diagnosis = $ProblemDiagnosisName: 246090004 |associated finding| = (404684003|Clinical Finding|: 363698007 | finding site | = ($BodySite: 272741003|laterality| = $Laterality), 246112005 | severity| = $Severity), 408729009 | finding context | = $FindingContext GP Problem Diagnosis = 86049000|Cancer| : 246090004 |associated finding| = (404684003|Clinical Finding| : 363698007 | finding site | = 39607008|Lung|), 408729009 | finding context | = 415684004|Suspected| Polyclinic Problem Diagnosis = 162572001 |Suspected cancer|: 246090004 |associated finding| = (404684003|Clinical Finding|: 363698007 | finding site | = 39607008|Lung|) RH Problem Diagnosis = 86049000|Suspected lung cancer|

23 Foundations 1.CIMI Reference Model 2.Archetype Object Model 3.CIMI Modelling Patterns 4.CIMI Style Guide Modelling Approach 1.Analyse clinical models submitted (with value sets) 2.Identify maximal set of data elements 3.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 Instances 8.Technical Validation o ADL, UML 9.Clinical Validation / Review 10.Confirm mappings from submitted models Overview

24 F1. Define CIMI Reference Model

25

26 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

27 Extend to support relationship meaning Terminology binding syntax Review to identify other gaps Test through use F2. Archetype Object Model

28 Relationship_id[0..1]:String

29 F2. Archetype Object Model

30 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 : [:version] ? = [& = extensionvalue]* query_type: concept, conceptlist, refset / refsetlist, escg, ocl E.g. terminology:2.16.840.1.113883.6.96:20110123?refset=284296007 &scope=CIMI F2. Archetype Object Model

31 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

32 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

33 Clinical Investigator Record (CIR) Ontology

34 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)

35 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.Patient System 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)

36 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)

37 F3. CIMI Modelling Patterns (Clinical Entry) Who Where When What/How/Why

38 F3. CIMI Modelling Patterns (Observation) Who Where When What/Why/How What

39 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

40 (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)

41 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

42 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.

43 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.

44 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)

45 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.

46 Foundations 1.CIMI Reference Model 2.Archetype Object Model 3.CIMI Modelling Patterns 4.CIMI Style Guide Modelling Approach 1.Analyse clinical models submitted (with value sets) 2.Identify maximal set of data elements 3.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 Meaning (nodes, node relationships) o Value sets (maximal set from submitted models) 7.Add Example Model Data Instances 8.Technical Validation o ADL, UML 9.Clinical Validation / Review 10.Confirm mappings from submitted models Overview

47 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 M1. Analyse clinical models submitted (with value sets)

48 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

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

50

51

52 M1. Analyse clinical models submitted (Heart Rate - MOHH) LIDNameCardinalityDefinition E12 OBSERVATION-An individual observation that was performed. E12.17 Observing Clinician0..1The Healthcare Professional who performed the observation. E12.18 Other Participation0..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.1Observation Name1The name of the observation. E12.19.2Observation Timing Description0..1 A descriptor used in combination with the Observation Name to fully define the description of the observation. E12.19.3Context Group0..1Qualifying attributes that define the context of the observation. E12.19.4Associated Finding0..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.5Episodicity0..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.6Clinical Course0..1This attribute is used to represent both the course and onset of a disease. E12.19.7Site Laterality0..ManyAttributes used to describe the finding site. Site0..1The site of the observation measurement Laterality0..1The laterality of the observation measurement E12.19.8Severity0..1The seriousness of the impact of the adverese reaction on the person. E12.19.9Care Setting0..1The care setting where the observation took place. E12.19.10Category0..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.11Type0..1The type of the observation. E12.19.12Subtype0..1The subtype of the observation, if required. E12.19.13Clinical Notes0..1The remarks associated with the observation result. E12.20 Observation Status Details0..1Information related to the status of the observation. E12.20.1Observation Status0..1The status of the observation measurement, in terms of its clinical workflow. E12.21 Observation Dates0..1Dates associated with the observation. E12.21.1Observation DateTime0..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 Result0..1Information related to the result of the observation. E12.22.1Observation Result Value0..1The result value of the observation. E12.22.2Observation Result Value Type0..1The data type used to record the observation result value. E12.22.3Interpretation0..1An indicator as to whether or not the clinical results are normal or abnormal. E12.22.4Reference Range0..1The reference range of the observation.

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

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

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

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

57 M2. Identify maximal set of data elements Heart Rate - Data Elements CIMIopenEHR/NEHTAMOHHIMHResults4CareEN13606 AssociationTOLVEN Data RequirementData 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)ParticipationSubject (II) Subject (Coded) Subject Patient Information Provider (II)ParticipationInformation Provider (II) ObserverParticipation Observing Clinician (II) Performer Participant included in reference model Participant (II) Participant (Cluster) (ParticipationType (Coded) Role (Coded) IndividualPerson.PersonIdent ifier (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 DateTimeDateTime Start Date/Time (DateTime) Observation DateTime (IVL ) Point in Time time of observation Observation DateTime Range Interval ObservedStartTime (DateTime)/ ObservedEndTme (DateTime) Range in Time Relative TimeDurationEvent time (DateTime) Relative Time Observation DurationDurationDuration (DateTime) Observation Offset / Observation Offset Origin DateTime Events (Event) Time of Day (Codeabe)CodedText Time of Day (Codeable) RelativeTemporalContext (Coded) Observation StatusCodedText Observation Status (Coded) statusCode Where Location of SubjectParticipation Observed.PatientLocation (String) Location/Addre ss Location of ObserverParticipation Observed.ProviderLocation (String) What (measurement) / How / Why Observation NameCodedText Observation Name (Coded) key (String) Physiology+Org an System title Observation ReasonCodedText Observed.Reason (Coded) Body PositionCodedTextPosition (Coded) BodyPosition (Coded) Confounding FactorsCodeableText Confounding Factors (Codeable) PatientPrecondition (Coded) ExcertionSlotExcertion (Slot) Excertion (Coded) Care SettingCodeableText Care Setting (Codeable) Body Location (Cluster): Site/Laterality Group:Body Location (Cluster): Body SiteCodeableText Body Site (Codeable)Body Location.data (Coded)Location (Coded) Anatomical Location site Aggregate Body Site Aggregate (Coded) Body LateralityCodedText BodyLaterality (Coded) BodySideCodedText Laterality (Codeable)BodySide (Coded) laterality Body Location QualifierCodedText BodyLocationQualifier (Coded) Observation MethodCodeableTextMethod (Codeable) Observed.ActionMethod (Coded) Method (coded)Protocol DeviceSlotDevice (Slot) MethodDevice (Coded) Device Aggregate Function (Codeable) Aggregate Function (Coded) PointInTime (Coded) What (Observation) Heart RateQuantityHeart Rate (Quantity) Result Value (Quantity) data (PQ) Frequency (Quantity[unit=/min]) Result (Quantity) observation Heart Rate Present?BooleanHeart Beat Present? (Bl) Regularity Out of scope- >Specialisation? 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 NotesString Clinical Notes (String)Comment (String) comment InterpretationCodedText Interpretation (Coded) AbnormalInterpretation (Coded) DeltaFlagCodedText DeltaFlag (Coded) Reference RangeSlot Reference Range Set (Cluster) ReferenceRangeNar (String)

58 M2. Identify maximal set of data elements Data RequirementData Type Who Subject (II)Participation Information Provider (II)Participation ObserverParticipation Participant ReportedReceived Verified Updated When Link from (instruction) Workflow Id Observation DateTimeDateTime Observation DateTime Range Interval Relative TimeDuration Observation DurationDuration Observation Offset / Observation Offset Origin DateTime Time of Day (Codeabe)CodedText Observation StatusCodedText Where Location of SubjectParticipation Location of ObserverParticipation What (measurement) / How / Why Observation NameCodedText Observation ReasonCodedText Body PositionCodedText Confounding FactorsCodeableText ExcertionSlot Care SettingCodeableText Body Location (Cluster): Body SiteCodeableText Aggregate Body SiteCodedText Body LateralityCodedText BodySideCodedText Body Location QualifierCodedText Observation MethodCodeableText DeviceSlot Aggregate Function (Codeable) What (Observation) Heart RateQuantity Heart Rate Present?Boolean Regularity Rhythm Strength FrequencyQualification Volume Clinical NotesString InterpretationCodedText DeltaFlagCodedText Reference RangeSlot

59 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.

60 M3. Remove ‘out of scope’ data elements (Style Guide) Data RequirementData TypeReason for Exclusion Who Subject (II)Participationin Clinical Entry Pattern Information Provider (II)Participationin Clinical Entry Pattern ObserverParticipationin Observation Pattern Participant in reference model ReportedReceived record-keeping use-case Verified record-keeping use-case Updated record-keeping use-case When Link from (instruction) in reference model Workflow Id implementation specific? Observation DateTimeDateTimein Observation Pattern Observation DateTime RangeInterval in Observation Pattern Relative TimeDurationin Observation Pattern Observation DurationDurationin Observation Pattern Observation Offset / Observation Offset Origin DateTime in Observation Pattern Time of Day (Codeabe)CodedText Observation StatusCodedTextin Observation Pattern Where Location of SubjectParticipationin Observation Pattern Location of ObserverParticipationin Observation Pattern

61 M3. Remove ‘out of scope’ data elements (Style Guide) What (measurement) / How / Why Observation NameCodedTextin Observation Pattern Observation ReasonCodedText Body PositionCodedText Confounding FactorsCodeableText ExcertionSlot Care SettingCodeableText Body Location (Cluster): Body SiteCodeableText Aggregate Body SiteCodedText Body LateralityCodedText BodySideCodedText Body Location QualifierCodedText Observation MethodCodeableText DeviceSlot Aggregate Function (Codeable) What (Observation) Heart RateQuantity 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 NotesString InterpretationCodedTextin Observation Pattern DeltaFlagCodedText Reference RangeSlot

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

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

64 M6. Add Terminology bindings openEHR/NEHTA CIMI nodeSource nodeSCT term bindingCIMI data typeSCT value set binding heart rate valueat0004Observable entity364075005|Heart rate|QUANTITY- body positionat00013Observable entity422431001|Body position for procedure|CODED_TEXTClinical finding methodat1019Procedure386053000|Evaluation procedure| Results4Care CIMI nodeSource nodeSCT term bindingCIMI data typeSCT value set binding rootat0000Observable entity364075005|Heart rate|-- heart rate valueat0001Observable entity364075005|Heart rate|QUANTITY- body locationat0016Attribute 363704007|Procedure site|[2] CODED_TEXTBody structure body positionat0045Clinical finding9851009|Body position finding|CODED_TEXTClinical finding methodat0054Qualifier value84203001|Has method|CODED_TEXTProcedure Proposed Bindings AttributeSCT constraint observable364075005|Heart rate (Observable entity)| name=<364075005|Heart rate (Observable entity)| reason404684003|Clinical finding| body position9851009|Body position finding| confounding factors404684003|Clinical finding| time of day272106006|Temporal periods of day|

65 M6. Add Terminology bindings

66 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?

67 M6. Add Terminology bindings

68 Important for both technical and clinical validation. Format for instance data will be discussed tomorrow. M7. Add Example Instance Data

69 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

70 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

71 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

72 Foundations 1.CIMI Reference Model 2.Archetype Object Model 3.CIMI Modelling Patterns 4.CIMI Style Guide Modelling Approach 1.Analyse clinical models submitted (with value sets) 2.Identify maximal set of data elements 3.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 Instances 8.Technical Validation o ADL, UML 9.Clinical Validation / Review 10.Confirm mappings from submitted models Overview

73


Download ppt "CIMI Modelling Taskforce Report Dr Linda Bird 14 th May 2012."

Similar presentations


Ads by Google