CIMI Reference Model Taskforce Report

1. CIMI Reference Model Taskforce Report Dr Linda Bird 10th May 2012

2. Agenda • Mission & Charter • Members & Guests • Definition • Architectural Framework • May Deliverables • Requirements • Starting Point • Change List & Exclusions • Proposed CIMI Reference Model • Gap Analysis • Recommendations • Isosemantic Models • Clinical Modelling Layers

3. Mission & Charter • To define a candidate CIMI reference model • Define a set of requirements for the CIMI reference model • Define or choose a candidate CIMI reference model • Work with the Clinical Modeling taskforce to test the candidate reference model in the development of a set of initial clinical information models • Compare the candidate CIMI reference model with the requirements to identify gaps • Present the results at the face-to-face meeting in May

4. Members & Guests • Members • Linda Bird (Chair) – Ministry of Health Holdings, Singapore • Michael van der Zel – Results4Care & LifeLines • Gerard Freriks, EN13606 Association • Josh Mandel, SMArt • Thomas Beale – Ocean Informatics • Stan Huff, Intermountain Healthcare • Richard Kavanagh – NHS Connecting for Health • Galen Mulrooney, ONC, U.S.A. • Grahame Grieve – Health Intersections • Guests • Cecil Lynch • Ian Townend • Dipak Kalra

5. Definition • The CIMI Reference Model is the underlying Reference Model on which CIMI’s clinical models will be defined. • This reference model defines a rigorous and stable set of modelling patterns, including a set of structural patterns, complex data types and demographic classes. • All CIMI clinical models (i.e. archetypes) will be defined by constraining the CIMI reference model. • Each example instance of a CIMI Clinical Model will be an instance of the CIMI reference model, which conforms to the constraints defined by the associated clinical model.

6. Architectural Framework

7. May Deliverables 11 meetings from 23rd February – 3rd May 2012 • A set of requirements for the CIMI reference model; • One or more UML class diagrams, which together represent the candidate CIMI reference model (and supporting material); • An implementation of the candidate CIMI reference model that enables a set of initial Clinical Models to be created based on this reference model1 (preferably using ADL); • A report identifying the gaps between the proposed CIMI reference model and the requirements; and • A summary of the results and recommendations for the CIMI Reference Model pending CIMI approval. 1: Please note that this implementation may either be as simple as an appropriately formatted spreadsheet, or may involve a tool that is specifically designed for authoring clinical models against a given reference model – depending on the time and resources available.

8. CIMI RM taskforce website

9. Requirements - Overview • General (Technical / Governance) • Structural • Information Pattern • Terminology Binding • Data Type

10. Requirements – General • General Technical • Support for architectural framework • Multiple purpose & outputs • Realm-specific specialisations & extensions (*) • Move clinically-relevant attributes to clinical patterns • Model mapping & query support (*) • Versioning & Approval status (*) • Stability • General governance • Governance, cost and licensing • Clinician verification (*) • Inter-organisation semantic interoperability

11. Requirements – Structural & Information Patterns • Structural • Data elements • Relationships / Links • Data groups • Tree structure • Entry / Clinical statement • Composition • Data absent • Information Pattern • Concept model • Participation • Parties and roles

12. Requirements – Terminology Binding & Datatype • Terminology Binding • Semantic / Value / Name binding (*) • Relationship semantics (*) • Concept model terminology definition (*) • Translations • Datatype • Common datatypes • Datatype constraints & mappings • Inheritance from single type • Primitive & string-based datatypes • Complex datatypes • Attachment, Ordinal, Codeable concept, Coding, Identifier, Interval, Quantity, Ratio

13. Starting Point - Options • Options • A profile, simplification or improvement of ISO13606-1 • openEHR reference model • openEHR / ISO13606-1 model • DCM reference model (ISO13972-based) • EN13606 Association proposal • Other models, whose features were considered • Parts of Intermountain Healthcare’s Clinical Element Model • Federal Healthcare Information Model (US Gov FHIM • Logical Record Architecture (NHS LRA)

14. Starting Point - Considerations • Ability to meet requirements • including capturing required information patterns, and semantics • Demonstrable computability, implementability and transformability (e.g. to ISO13606, openEHR, DCM, HL7 v2, v3, CDA) • Existing tooling & infrastructure • Existing library of clinical models • Existing community (implementation and clinical) • IP considerations • Simplicity • Can support all use cases

15. Starting Point - Selection openEHR reference model selected as starting point by 6 of 9 members Reasons • The range of existing archetypes, tooling, infrastructure, methodology and documentation; • Established reference model tested by multiple authoring participants; • Can benefit from lessons learned by many implementations; • Able to start designing clinical models straight away; • Demonstrable use within a two-level modelling architecture; • Specification is freely available on the web to read and redistribute without cost; • Willingness of the organisation to work with CIMI and make changes as needed to meet CIMI’s needs Concerns •  Complexity of current model - a simplified model is preferred; • Need to bridge the gap between the model and the requirements; • Requires us to work together to simplify and improve • It is not a standard, and there are IP concerns relating to the specifications • Requires work to develop a UML-based profile and editing environment

16. Change List - openEHR RM v1.0.2 • Core CIMI reference model • Simpify item structure • Move ELEMENT.value and null_flavour to ITEM • Remove specialisations of ENTRY from model • Remove ENTRY.encoding and workflow_id • Remove EVENT_CONTEXT • Datatypes • Remove “DV_” prefix from all datatypes • Make CODE_PHRASE concrete • Add CODE_PHRASE.terminology_version, term, term_id • Change datatype of QUANTITY.units to CODE_PHRASE • Remove MULTIMEDIA.compression_algorithm and integrity_check_algorithm • Remove ENCAPSULATED.charset and language • Demographics – no changes

17. Exclusions - openEHR RM v1.0.2 (1 of 2) • Assumed types • Any, Hash, INTERVAL • Common • FEEDER_AUDIT, FEEDER_AUDIT_DETAILS, CONTRIBUTION, IMPORTED_VERSION, T, VERSION, VERSIONED_OBJECT, FOLDER, VERSIONED_FOLDER, ATTESTION, AUDIT_DETAILS, REVISION_HISTORY, REVISION_HISTORY_ITEM, AUTHORED_RESOURCE, RESOURCE_DESCRIPTION, RESOURCE_DESCRIPTION_ITEM, TRANSLATION_DETAILS • Composition • EVENT_CONTEXT, ACTION, ACTIVITY, ADMIN_ENTRY, CARE_ENTRY, EVALUATION, INSTRUCTION, INSTRUCTION_DETAILS, ISM_TRANSITION, OBSERVATION • Data structures • EVENT, HISTORY, INTERVAL_EVENT and POINT_EVENT

18. Exclusions - openEHR RM v1.0.2 (2 of 2) • Datatypes • DV_STATE, PROPORTION_KIND, REFERENCE_RANGE, DV_PARAGRAPH, DV_GENERAL_TIME_SPECIFICATION, DV_PERIODIC_TIME_SPECIFICATION, DV_TIME_SPECIFICATION • Demographics • VERSIONED_PARTY • Ehr • EHR, EHR_ACCESS, EHR_STATUS, VERSIONED_COMPOSITION, VERSIONED_EHR_ACCESS, VERSIONED_EHR_STATUS • Ehr_Extract • EHR, EHR_ACCESS, EHR_STATUS, VERSIONED_COMPOSITION, VERSIONED_EHR_ACCESS, VERSIONED_EHR_STATUS

19. Proposed CIMI Reference Model - Core • COMPOSITION (category, language, territory, composer, content) • CONTENT_ITEM • SECTION (items) • ENTRY (subject, provider, other_participation, language, data) • ITEM (null_flavour, value) • CLUSTER (structure_type, items) • ELEMENT • DATA_VALUE • PARTICIPATION (function, mode, time, performer) • LOCATABLE (name, uid, archetype_node_id, archetype_details, links) • LINK (meaning, target, type) • ARCHETYPED (archetype_id, template_id, rm_version

20. Proposed CIMI Reference Model - Core

21. Proposed CIMI Reference Model - Datatypes • BOOLEAN • IDENTIFIER • URI • CODE_PHRASE • TEXT • CODED_TEXT • ENCAPSULATED • MULTIMEDIA, PARSABLE • INTERVAL • ORDINAL • AMOUNT • COUNT, DURATION, PROPORTION, QUANTITY • TEMPORAL • TIME, DATE, DATE_TIME

22. Proposed CIMI Reference Model - Datatypes

23. Proposed CIMI Reference Model – Supporting Class • OBJECT_ID • TEMINOLOGY_ID • TEMPLATE_ID • ARCHETYPE_ID • UID_BASED_ID • HIER_OBJECT_ID • LOCATABLE_REF • PART_REF • PARTY_PROXY • PARTY_IDENTIFIED • PARTY_RELATED • PARTY_SELF

24. Proposed CIMI Reference Model – Supporting Class

25. Proposed CIMI Reference Model - Assumed • Integer • Real • String • Boolean • Byte • Char • UID • UUID • ISO_OID • INTERNET_ID

26. Proposed CIMI Reference Model - Assumed

27. Gap Analyss • Fully supports • Most requirements • Requires further investigation • Realm-specific specialisations and extensions • Governance, cost and licensing • Inter-organisation Semantic Interoperability • Terminology Concept model • Relationship semantics • Data type mappings • Primitive data types (base64Binary) • String-based data types (code) • Partially supports • No clinically-significant attributes or specialisations

28. Recommendations (1-4 of 11) • Recommendation 1: The proposed reference model is thoroughly tested using a representative set of clinical models that together demonstrate all aspects of the reference model; • Recommendation 2: A set of stable clinical patterns (e.g. OBSERVATION, EVALUATION, INSTRUCTION, ACTION, TIME_SERIES, SCHEDULE) are defined as archetypes, upon which more specific clinical models are based, within an agreed framework of ‘clinical model specialisation layers’. • Recommendation 3: The CIMI reference model is fully documented in a format that promotes effective understanding by both clinical modellers and implementers. This documentation should include both example models and example instance data; • Recommendation 4:A coherent modelling methodology is documented to ensure consistent models, including modelling style guides and best practice guidelines;

29. Recommendations (5-6 of 11) • Recommendation 5: The Archetype Object Model (and associated serialisations) is reviewed against requirements, and extended to fully express the semantic meaning of archetypes, (including the meaning of the relationship between nodes); • Recommendation 6: Further investigation is planned to consider issues, such as the following: • The syntax and use of terminology bindings for both the meaning and valid values of nodes in the clinical models; • The semantic meaning between all structural nodes; • The use of CLUSTER.value (including defining the meaning) • Whether null_flavour (or similar) should be allowed on ENTRY or SECTION • Whether further simplifications can be made to the reference model (e.g. demographics); • Modelling methodology to ensure consistency of models, including the development of modelling style guides and best practices;

30. Recommendations (7-11 of 11) • Recommendation 7: The requirements of iso-semantic clinical models are explored further, in terms of both (a) the ability to transform CIMI models to/from iso-semantic representations in other languages/standards (e.g. CDA, openEHR, ISO13606, DCM, CEM), and (b) the ability to transform CIMI models between iso-semantic representations that use a different split between terminology pre-coordination and structure (Please refer to Appendix B). • Recommendation 8: Appropriate tooling is developed and/or adopted, which allows clinical models to be created and is capable of generating ADL 1.5. • Recommendation 9: Any relevant Intellectual Property issues relating to the CIMI reference model are addressed. • Recommendation 10: A UML Profile is developed, in collaboration with the OMG, which allows CIMI models to be created in UML. • Recommendation 11: The taskforces be reorganised to support the above activities

31. Recommendations (Summary) • 1: Test Reference Model (using clinical models) • 2: Define clinical patterns and modelling layers • 3: Document (including examples) • 4:Modelling style guide • 5: Review and extend AOM (e.g. node relationship meaning) • 6: Further investigate outstanding issues (e.g. terminology binding) • 7: Iso-semantic clinical models (transformation and terminology equivalence) • 8:Tooling • 9: Intellectual Property • 10: UML Profile • 11: Organise taskforces

32. Isosemantic Models Linda Bird 10th May 2012

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

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

35. IsoSemantic Models – Hierarchy

36. IsoSemantic Models – Graph-based Model

37. IsoSemantic Models – Compositional Grammar Problem Diagnosis = 243796009 |situation with explicit context| : 246090004 |associated finding| =( $ProblemDiagnosisName: 363698007 | finding site | = ($BodySite: 272741003|laterality| = $Laterality), 246112005 | severity| = $Severity), 408729009 | finding context | = $FindingContext • GP Problem Diagnosis= • 243796009 |situation with explicit context| : • 246090004 |associated finding| =(86049000|Cancer|: • 363698007 | finding site | = 39607008|Lung |), • 408729009 | finding context | = 415684004|Suspected| • Polyclinic Problem Diagnosis= • 243796009 |situation with explicit context| : • 246090004 |associated finding| = • (162572001 |Suspected cancer|: • 363698007 | finding site | = 39607008|Lung|) • RH Problem Diagnosis= • 243796009 |situation with explicit context| : • 246090004 |associated finding| = • (86049000|Suspected lung cancer|)

38. Clinical Model Layers Linda Bird 10th May 2012

39. Clinical Modelling Layers - Ideas CLUSTER COMPOSITN ENTRY SECTION e.g. Dispensed Medication GUI e.g. Inpatient Discharge Summary Message/Doc Use Case-Specific Clinical Models e.g. Neonatal Blood Pressure GUI e.g. Current Medication List in EHR e.g. Dispensed Medication Item e.g. Inpatient Discharge Summary Context-Specific Clinical Models e.g. Neonatal Blood Pressure e.g. Ceased Medication List e.g. Medication Item e.g. Discharge Summary Clinical Models e.g. Blood Pressure e.g. Medication List e.g. Schedule e.g. Event Summary Clinical Patterns e.g. Observation e.g. List Reference Model

41. ADL Workbench Editor Demonstration Thomas Beale 10th May 2012

43. Breakout Session 10:30 – 12:00 RM & CMTaskforces 11th May 2012

44. Breakout Agenda Summary 10:30 – 12:00 pm • Core Reference Model • Datatypes Models • Demographics Model • Requirements Gap Analysis • Semantics/Terminology (e.g. Relationships b/w model elements) 1:00 – 3:00 pm • Isosemantic models and transformations to/from other specifications • Clinical Patterns, Modelling Layers and Modelling Style • Select an initial set of Clinical Models to test CIMI reference model • Modelling/Review process 1:00 – 3:00 pm • Continuation of agenda above • Collaboratively model and/or review specific clinical models • Next Steps

45. Agenda (10:30 – 12:00 pm) • Core Reference Model • Datatypes Models • Demographics Model • Requirements Gap Analysis • Semantics/Terminology • including agreeing on method for defining semantics of relationships between model elements

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

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

48. IsoSemantic Models – Hierarchy

49. IsoSemantic Models – Graph-based Model

50. IsoSemantic Models – Compositional Grammar Problem Diagnosis = 243796009 |situation with explicit context| : 246090004 |associated finding| =( $ProblemDiagnosisName: 363698007 | finding site | = ($BodySite: 272741003|laterality| = $Laterality), 246112005 | severity| = $Severity), 408729009 | finding context | = $FindingContext • GP Problem Diagnosis= • 243796009 |situation with explicit context| : • 246090004 |associated finding| =(86049000|Cancer|: • 363698007 | finding site | = 39607008|Lung |), • 408729009 | finding context | = 415684004|Suspected| • Polyclinic Problem Diagnosis= • 243796009 |situation with explicit context| : • 246090004 |associated finding| = • (162572001 |Suspected cancer|: • 363698007 | finding site | = 39607008|Lung|) • RH Problem Diagnosis= • 243796009 |situation with explicit context| : • 246090004 |associated finding| = • (86049000|Suspected lung cancer|)