1. CIMI Modelling Taskforce Report Dr Linda Bird 26 th June 2013

2. Agenda Background CIMI Modelling Approach CIMI Modelling Foundations CIMI Modelling Methodology Future Work Tomorrow: Terminology Binding

3. BACKGROUND

4. Core Members: Linda Bird (co-chair) Harold Solbrig (co-chair) Tom Beale Dave Carlson Stephen Chu Stan Huff Mike Lincoln Rahil Qamar Siddiqui Gerard Freriks Josh Mandel Mark Shafarman Michael van der Zel Secretary: Eithne Keelaghan Taskforce Members Technical Resources: Peter Hendler Galen Mulrooney Daniel Karlsson Cecil Lynch Joey Coyle Grahame Grieve Dipak Kalra David Moner Clinical Modelling Resource: William Goossen Jay Lyle Ian McNicoll Anneke Goossen Heather Leslie Sarah Ryan Marcelo Rodrigues dos Santos

5. This taskforce has been established to: Develop CIMI's modelling methodology; Create an initial set of CIMI clinical models; Further test and develop CIMI technical models, including: –CIMI reference model –Archetype Object Model 1.5, and –CIMI terminology. Terms of Reference

6. 2012 May 10 th -12 th Pleasanton meeting: Modelling Taskforce established May to SepTaskforce infrastructure and planning Modelling methodology Observation modelling pattern Heart rate model Sept 14 th -16 th Rockville meeting Oct to DecLaboratory Results models and patterns Terminology binding methodology & reference sets Dec 2 nd -4 th Groningen: Taskforce meeting 2013 Jan 18 th -20 th Scottsdale meeting Feb – MarTerminology and Modelling Tooling CIMI Modelling Style Guides (TOC) Comparative Analysis Spreadsheet template Laboratory Results Models Example Terminology bindings Lab Specialisation Models – CBC; Gas & CM Panels Demographics models CIMI Reference Model Review Modelling Taskforce History

7. 2013 Apr 4-6Leeds meetings Apr to JuneTechnical/Implementation CIMI Reference Model DSTU (link associations, instance ids) Implementation artefacts: EA, BMM, XMI, XML Schema, XML, RDF opencimi Github repository CIMI URIs Semver.org versioning rules Archetype identification rules (openEHR) CIMI-Mindmap to ADL conversion Archetype Definition Language (ADL) 1.5 Archetype Modelling Language (AML) Modelling Unit of Measure: modelling style and approach CIMI Model Example Instance Formats Modelling Taskforce: Post-Leeds

8. Major version – incremented for a breaking change Minor version – incremented for non-breaking change Patch version – incremented for change to the informal parts Version modifier – e.g. “-rc” (release candidate), “-dstu” (draft standard for trial use), “+u” Commit number – incremented every time artefact is committed First version rule = 0.0.1 E.g. 1.0.0-dstu Semver.org Versioning Rules

9. Knowledge Artefact Identification (openEHR Foundation) rm_publisher = “CIMI” rm_closure in {“CORE”, “PARTY”, “DATA_VALUE”} rm_class_name: name of reference model class e.g. ENTRY concept_id: human-readable id of concept e.g. heart_rate version: as per semver.org rules Examples: E.g. CIMI-CORE-ENTRY.observation.v.0.0.4 E.g. CIMI-CORE-CLUSTER.reference_range.v.0.0.1 E.g. CIMI-PARTY-ACTOR.person.v.0.0.2 Archetype Identification Rules

10. Where global standard exists (e.g. Systolic BP in “mmHg”) –CIMI Models will define specific Unit of Measure Where no global standard exists (e.g. Body temperature) –CIMI General Model will restrict the property (e.g. mass concentration, time, volume, pressure) of each quantity units by binding to a reference set of valid alternative units for that property –Jurisdictional specialisations can specialise the CIMI general models to define the specific unit of measure used locally –CIMI ‘Canonical/Preferred Model’ will be defined, which specialises the CIMI General Model to the specific unit of measure to be used when interoperability between jurisdictions is required CIMI Models will use SNOMED CT to define Units Jurisdictional implementations can choose to adopt other code sets (e.g. UCUM), and map to SNOMED CT for cross- jurisdictional interoperability Unit of Measure: Modelling Style

11. CIMI MODELLING APPROACH

12. Modular for reusability Composable to meet use-cases Pattern-based for consistency Constraint-based to allow specialisation Logical for implementation in multiple formats Maximal for completeness Extensible for local requirements Bound to terminology for isosemanticity & interoperability CIMI’s Modeling Approach

13. CIMI Terminology Server CIMI Architectural Overview CIMI Repository International Clinical Model (AOM/AML) CIMI Reference Model Constrains Specialise & Extend International Reference Terminology National Reference Terminology MeaningValueValue setMeaning Map Conforms to Existing Clinical Models Transform Clinical Model Editor (AOM/AML) Generate M0M0 M2M2 Terminology Workbench Implementation- Specific Terminology Map Value set Realm-Specific Clinical Model (AOM / AML) Require ments Clinical Visualisation Clinical Verification Generate Value set CIMI Model Examples Implementation Models Generate Instance of DCM CEM CDA openEHR ISO / CEN LRA CMET RMIM HL7 v2 HL7 v3 HL7 CDA HL7 FHIR SOA OWL openEHR ISO/CEN XML Schema

14. Foundations 1.CIMI Reference Model 2.Archetype Object Model / Archetype Modelling Language 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 (relationship, object, modifier) o Value sets (maximal set from submitted models) 7.Add Example Model Data Instances 8.Technical Validation o ADL, AML 9.Clinical Validation / Review 10.Confirm mappings from submitted models Modelling Methodology

15. FOUNDATION 1: CIMI REFERENCE MODEL

16. CIMI Reference Model - Core

17. CIMI Reference Model – Data Values

18. CIMI Reference Model – Party Model

19. FOUNDATION 2: ARCHETYPE OBJECT MODEL / ARCHETYPE MODELLING LANGUAGE

20. Archetype Object Model (AOM) 1.5

21. AOM 1.5 Archetype

22. AOM 1.5 Constraint Model

23. AOM 1.5 Primitive

24. AOM 1.5 Assertion

25. AOM 1.5 Ontology

26. archetype (adl_version=1.5)CIMI-RM-CLUSTER.anatomical_location.v1 concept[at0000]-- Anatomical location languageoriginal_language = description original_author = < ["name"] = ["date"] = > details = purpose = use = misuse = copyright = >> lifecycle_state = other_contributors = <> other_details = <> definition CLUSTER[at0000] matches {-- Anatomical location items matches { ELEMENT[at0001] occurrences matches {0..1} matches {-- Body site name value matches { TEXT matches {*}}} ELEMENT[at0002] occurrences matches {0..1} matches {-- Body site description value matches { TEXT matches {*} }} ELEMENT[at0003] occurrences matches {0..1} matches {-- Body side value matches { TEXT matches {*}}}}}} ontology term_definitions = <["en"] = < items = description = > ["at0001"] = description = > ["at0002"] = description = > ["at0003"] = description = >>>> Archetype Definition Language 1.5

27. FOUNDATION 3: CIMI MODELLING PATTERNS

28. CIMI Modelling Layers Reference Model Patterns Observable, Finding, Action, Material Entity Observation, Clinical Activity Request Clinical List Clinical Report Clinical Models Laboratory Test Result Item, Refernce Range Laboratory Test Observation Medication List Laboratory Results Report Specialty Context Biochemistry Test Result Item Microbiology Test Observation Cardiology Medication List Biochemistry Laboratory Results Report CLUSTER ENTRYSECTION COMPOSITION Care Setting Context Inpatient Laboratory Test Result Item Outpatient Laboratory Test Observation Outpatient Clinic Current Medication List Inpatient Laboratory Results Report Implementation Purpose Context Laboratory Test Result Item API Laboratory Test Observation GUI Current Medication List in EHR Laboratory Report Message Use Case Context Full Blood Count Test Result Item Gas and Carbon Monoxide Panel Observation Current Medication List Full Blood Count Results Report

29. ENTRY modelling patterns Clinical Report Header Clinical Entry Observation Request Request Clinical ActivityObservation ENTRY constrains

30. CIMI-ENTRY.clinical_entry constrains

31. CIMI-ENTRY.observation Clinical Entry ENTRY constrains

32. CLUSTER modelling patterns Finding ObservableMaterial Entity Action CLUSTER constrains Finding GroupFinding Item constrains Request Action

33. FOUNDATION 4: STYLE GUIDES

34. CIMI Modelling Guides User Guide –Modelling Framework –Modellng Methodology –Modelling Examples and Use Cases Editorial Guide –Modelling Principles –Modelling Patterns Terminology Binding Guide –Types of Terminology Bindings –Terminology Binding Rules –Terminology Binding Patterns –Terminology Binding Examples and Use Cases Technical Guide –CIMI Reference Model –Archetype Object Model –Archetype Definition Language –Archetype Modelling Language –Model Instance Representation –Model Transformation and Implementation

35. MODELLING METHODOLOGY

36. Foundations 1.CIMI Reference Model 2.Archetype Object Model / Archetype Modelling Language 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, AML) 6.Add Terminology bindings o Meaning (relationship, object, modifier) o Value sets (maximal set from submitted models) 7.Add Example Model Data Instances 8.Technical Validation o ADL, AML 9.Clinical Validation / Review 10.Confirm mappings from submitted models Modelling Methodology

37. Comparative Analysis Template Purpose: To compare a set of existing clinical models, and identify the maximal set of data items to be included in the international CIMI models. In so doing, it also documents the high-level mapping from the CIMI data items to the source data models.

38. Comparative Analysis Template

39. Foundations 1.CIMI Reference Model 2.Archetype Object Model / Archetype Modelling Language 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, AML) 6.Add Terminology bindings o Meaning (relationship, object, modifier) o Value sets (maximal set from submitted models) 7.Add Example Model Data Instances 8.Technical Validation o ADL, AML 9.Clinical Validation / Review 10.Confirm mappings from submitted models Modelling Methodology

40. Foundations 1.CIMI Reference Model 2.Archetype Object Model / Archetype Modelling Language 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, AML) 6.Add Terminology bindings o Meaning (relationship, object, modifier) o Value sets (maximal set from submitted models) 7.Add Example Model Data Instances 8.Technical Validation o ADL, AML 9.Clinical Validation / Review 10.Confirm mappings from submitted models Modelling Methodology

41. Archetype Map for Laboratory Results Report Composition: Entry: Cluster: Laboratory Report Header Patient Encounter Summary Laboratory Test Request Summary Laboratory Test Observation Action Laboratory Test Request Laboratory Test Observable Laboratory Test Result Group Laboratory Test Observable Action Reference Range Specimen Action

42. Entry Laboratory Test Observation Observation ENTRY constrains Clinical Entry constrains

43. CIMI-ENTRY.laboratory_test_observation Observation ENTRY constrains Clinical Entry constrains

44. Complete Blood Count Laboratory Test Observation Observation ENTRY constrains Clinical Entry constrains

45. Foundations 1.CIMI Reference Model 2.Archetype Object Model / Archetype Modelling Language 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, AML) 6.Add Terminology bindings o Meaning (relationship, object, modifier) o Value sets (maximal set from submitted models) 7.Add Example Model Data Instances 8.Technical Validation o ADL, AML 9.Clinical Validation / Review 10.Confirm mappings from submitted models Modelling Methodology

46. Foundations 1.CIMI Reference Model 2.Archetype Object Model / Archetype Modelling Language 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, AML) 6.Add Terminology bindings o Meaning (relationship, object, modifier) o Value sets (maximal set from submitted models) 7.Add Example Model Data Instances 8.Technical Validation o ADL, AML 9.Clinical Validation / Review 10.Confirm mappings from submitted models Modelling Methodology

47. Types of Example Instances Different example representation formats, e.g.: –Clinical user interface form –Mindmap example instance –XML instance Reference Model vs Model Specific Instances Full vs Lite/Green Instances Goal: Automated bi-directional transforms XML Instance  Mindmap instance  Clinical form Reference Model Instance  Model-Specific Instance Full instance  Green instance + Archetype

48. Mindmap Example Instance 1

49. Mindmap Example Instance 2

50. Mindmap Example Instance 3

51. Reference Model Instance Clinical Entry ENTRY constrains Blood Pressure Observation

52. CIMI-ENTRY

53. Reference-Model Instance (XML) <Entry xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance xmlns=http://opencimi.orghttp://www.w3.org/2001/XMLSchema-instancehttp://opencimi.org archetype_node_id = “at0000.1.1” name = “Blood_pressure_observation” uid = “123456”>...

54. Model Specific Instance Clinical Entry ENTRY constrains Blood Pressure Observation

55. Full Model Specific Instance...........http://www.w3.org/2001/XMLSchema-instancehttp://opencimi.org

56. Green Model Specific Instance 456789 Full instance  Green instance + Archetype

57. Foundations 1.CIMI Reference Model 2.Archetype Object Model / Archetype Modelling Language 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 (relationship, object, modifier) o Value sets (maximal set from submitted models) 7.Add Example Model Data Instances 8.Technical Validation o ADL, AML 9.Clinical Validation / Review 10.Confirm mappings from submitted models Modelling Methodology

58. FUTURE WORK

59. Future Work Foundations –Reference model: Documentation and testing –Archetype object model: Finalise support for terminology binding Archetype modelling language: Finalise UML profile –Modelling patterns: Documentation, Terminology bindings and Review –Style guides: Complete content Modelling –Laboratory Results models: Example instances, specialisations, terminology bindings –Immunization models: Gather requirements, and define models –Temperature and other priorities: As above Implementation –Complete Mindmap-to-ADL generation for modelling patterns –CIMI Model Validators (Mindmaps, ADL, AML) –AML editor –ADL-to-instance generation –Model repository and visualisations –Model instance visualisations –Transformations to implementation formats Governance –Establish modelling development, review and publication processes and procedures

60. Taskforce Minutes –http://informatics.mayo.edu/CIMI/index.php/Main_Pagehttp://informatics.mayo.edu/CIMI/index.php/Main_Page openCIMI Github repository –https://github.com/opencimihttps://github.com/opencimi 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 Online References

61. QUESTIONS

62. TERMINOLOGY BINDING

63. Foundations 1.CIMI Reference Model 2.Archetype Object Model / Archetype Modelling Language 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 (relationship, object, modifier) 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 Modelling Methodology

64. Use Cases for Terminology in Models 1.Management and quality control of model libraries a)Searching model libraries b)Identifying semantic overlap between models c)Inconsistency of model interdependencies 2.Transforming between isosemantic representations of the model: both a)Different levels of precoordination b)Different model formalisms 3.Querying data instances of models (including clinical decision support) which use different representations – for example: a)Different level of precoordiation versus structure b)Different modeling design choices c)Subsumption testing of values 4.Supporting data validation and semantic interoperability

65. 1.Standard (reproducible) way of doing terminology bindings 2.The ability to represent the valid set of values for a given coded element. 3.The ability to state the association between the intended interpretation of nodes in the model and concepts in the terminology 4.Terminology bindings that are agnostic as to whether nodes are connected using a hierarchy or using links. 5.Terminology bindings that allow the values to be represented in a way that is agnostic to the degree of precoordination versus structure. 6.Terminology bindings that enable the transformation between isosemantic representations of the same model 7.Terminology bindings that allow consistency to be checked within models, and between models related by specialisation or used to fill slots (using an underlying ontology). Requirements for using Terminology in Models

66. The meaning of each node has 3 parts: Relationship: The relationship from the parent node to this node Object: The ‘class’ of things defined by this node’s values Modifier: The context of the node’s meaning – including subject-relationship context, temporal context, procedure/finding context, negation, state, certainty Terminology Binding Approach

67. Meaning Value Set Relationship ObjectModifier (Linkage concept) Pharm/biol product (Context values) - (Linkage concept) Pharm/biol product (Context values) Medication Ref_Set Has ingredient Substance (Context values) Substance Ref_Set Has basis of strength substance Substance (Context values) Substance Ref_Set Has strength Measur e m ent Finding (Context values) - Has dose form Drug dose form (Context values) Dose_Form Ref_Set CIMI Terminology Binding Approach Cluster: Element: Medication Ingredient Element: Dose form Strength STRUCTURE TERMINOLOGYBINDING Medication Name Element: Basis of Strength

68. Meaning Value Set Relationship ObjectModifier (Linkage concept) Oral dosage form product (Context values) - (Linkage concept) Oral dosage form product (Context values) Oral Medict Ref_Set Has ingredient Substance (Context values) Substance Ref_Set Has basis of strength substance Substance (Context values) Substance Ref_Set Has strength Measur e m ent Finding (Context values) - Has dose form Oral dosage form (Context values) Oral Dose_Form Ref_Set Specialising Object Meaning Cluster: Element: Oral Medication Ingredient Element: Dose form Strength STRUCTURE TERMINOLOGYBINDING Medication Name Element: Basis of Strength

69. Meaning Value Set Relationship ObjectModifier (Linkage concept) Pharm/biol product (Context values) - (Linkage concept) Pharm/biol product (Context values) Medication Ref_Set Has active ingredient Substance (Context values) Active Substance Ref_Set Has basis of strength substance Substance (Context values) Substance Ref_Set Has strength Measur e m ent Finding (Context values) - Has dose form Drug dose form (Context values) Dose_Form Ref_Set Specialising Relationship Meaning Cluster: Element: Medication with Active Ingredients Active ingredient Element: Dose form Strength STRUCTURE TERMINOLOGYBINDING Medication Name Element: Basis of Strength

70. Meaning Value Set Relationship ObjectModifier (Linkage concept) Pharm/biol product Current- (Linkage concept) Pharm/biol product (Context values) Medication Ref_Set Has ingredient Substance (Context values) Substance Ref_Set Has basis of strength substance Substance (Context values) Substance Ref_Set Has strength Measuremen t Finding (Context values) - Has dose form Drug dose form (Context values) Dose_Form Ref_Set Specialising Modifier Meaning Cluster: Element: Current Medication Ingredient Element: Dose form Strength STRUCTURE TERMINOLOGYBINDING Medication Name Element: Basis of Strength

71. Meaning Value Set Relationship ObjectModifier Has diagnosis Clinical Finding (Context values) - Meaning Value Set Relationship ObjectModifier Has primary diagnosis Clinical Finding (Context values) - Filling Archetype Slots Cluster: Element: Diagnosis Onset datetime Element: Clinical status Diagnosis datetime STRUCTURE TERMINOLOGY BINDING Diagnosis name Element: Comments Element: Composition Cluster: Discharge Summary Primary diagnosis Medical record number Element:

72. Meaning Value Set Relationship ObjectModifier Has diagnosis Clinical finding (Context values) - Meaning Value Set Relationship ObjectModifier Has diagnosis Clinical finding Family member - Filling Archetype Slots Entry: Element: Diagnosis Onset datetime Element: Clinical status Diagnosis datetime STRUCTURE TERMINOLOGY BINDING Diagnosis name Element: Comments Element: Composition Entry: Discharge Summary Family history Medical record number Element:

73. Clinical Entry

74. Clinical Entry & Clinical Activity constrains

75. Clinical Activity & Request constrains

76. Request & Observation Request constrains

77. Observation Request & Laboratory Test Request Summary constrains

78. Proposed Observation Bindings