Difference between revisions of "CIMI Practitioners' Guide"
Line 60: | Line 60: | ||
=Principles= | =Principles= | ||
+ | |||
+ | |||
+ | =Legend= | ||
+ | |||
+ | Many figures were done in the FreeMind open-source Mind Maps; where, the legend, download information and basic structure are given in this figure. | ||
+ | |||
+ | |||
+ | [[file: CIMI_Legend_Mind_Map.jpg|none|900px|CIMI_Legend_Mind_Map.jpg]] | ||
=Architectural Framework= | =Architectural Framework= |
Revision as of 12:41, 12 February 2017
Contents
Introduction
Scope
CIMI considers its work in the "Universal Realm”; where, current work might be considered "US Realm".
- CIMI uses International Standards, when available.
- CIMI is using a SNOMED extension including LOINC and RxNorm (SOLOR).
- SNOMED and LOINC are used beyond the US, such as Canada and UK.
- RxNorm is the most international medication terminology available
- RxNorm includes chemical ingredients, which are international; where, US pharmaceutical units, packaging and manufacturers can be replaced by foreign equivalents
- Technically, CIMI's SOLOR semantic-bindings are completely defined; where,
- SOLOR follows the SNOMED observation model with explicit context expressions (e.g., body site)
- CIMI's SOLOR terminology bindings are exemplars; where, incomplete exemplars lead to inconsistent implementation artefacts, such as FHIR or CDA profiles and extensions.
Plans
January 2017 Comments-Only Ballot
The CIMI Team focused primarily on the following areas:
- The expansion and modularization of the CIMI Reference Model based on a set of core modeling principles;
- The definition of top-level archetypes based on the CIMI Reference Model
- The development of core modeling patterns including:
- The compositional Clinical Statement Pattern
- The Statement Topic/Context Patterns
- The Attribution/Provenance Pattern
- The Party/Participation Pattern
- The Assertion and EvaluationResult Patterns
- The Procedure Pattern
- The alignment of the CIMI Logical Model with the SNOMED CT Concept Model;
- The modeling of a number of the Skin/Wound Assessment archetypes to illustrate the use of the above patterns.
- Example value set bindings (see attached example-spreadsheet) was done; where, terminology alignment and terminology bindings, apart from those specifying the alignment of model attributes to SNOMED CT Concept Model attributes, are provided as examples.
- In the future, CIMI intends to work with the community to define and use VSAC value sets.
May 2017 Informative Ballot/Standard
Post January, the CIMI working group intends to
- address community comments and refactor the model accordingly.
- complete the CIMI Reference Model,
- complete CIMI top-level archetypes including archetypes that capture US Core and QI Core requirements.
Sep 2017 SRU Ballot/Standard
By the September 2017 HL7 Working Group Meeting, we plan to:
- Complete the terminology bindings for all proposed archetypes,
- Implement detailed clinical models for selected use cases, and
- Specify formal declarative mappings from CIMI to FHIR using the FHIR Mapping Language.
- The model will then be balloted as a Standard for Trial Use.
Principles
Legend
Many figures were done in the FreeMind open-source Mind Maps; where, the legend, download information and basic structure are given in this figure.
Architectural Framework
- Reference: Jan 2017 CIMI Architecture, Methodology and Style Guide from Ballot
- The CIMI technical architecture consists of the three Basic Meta Model (BMM) reference model layers and two archetype layers shown here.
The CIMI Reference Model is expressed using the OpenEHR Basic Metamodel (BMM) Language. The archetype layers are expressed using the OpenEHR Archetype Definition Language (ADL). While reference model modules define classes, attributes, and class hierarchies, the archetype layers only specify progressive constraints on the reference model but do not introduce new classes, attributes, and class-class relationships.
- The CIMI Core BMM Reference Model provides the core granularity of the CIMI model and introduces its top-level classes such as the DATA_VALUE class and the LOCATABLE class. This reference layer module defines the CIMI primitive types and core data types.
- The CIMI Foundational BMM Reference Model is closely aligned to ISO13606 and the OpenEHR Core Reference Model. It defines foundational CIMI clinical documents and clinical record patterns. It also introduces the PARTY, ROLE, and PARTY_RELATIONSHIP patterns and defines the top-level CLUSTER class for complex CIMI type hierarchies. CQI Knowledge Artifacts may also leverage this layer.
- The CIMI Clinical BMM Reference Model consists of the classes derived from existing CIMI archetypes, the FHIM, QUICK, vMR, and QDM. This layer defines the set of 'schematic anchors' (to borrow Richard Esmond's term) or core reference model patterns from which all CIMI archetype hierarchies and ultimately Detailed Clinical Models (DCMs) derive. Requirements for this layer come from FHIM, vMR, QDM, QUICK, FHIR US Core, SDC, etc...
- The 'goal' is to define the reference models with low FHIR transformation costs where feasible noting that we will inherently have some divergence due to the different requirements underlying both models.
- Galen points out that, FHIM’s expressivity will not carry over to CIMI DCMs given the models' different requirements (e.g., FHIM includes finance and accounting).
- The CIMI Foundational Archetype Patterns define the top-level constraints on the CIMI Reference Model. These typically consist of attribute formal documentation and high level attribute semantic and value set bindings. Archetypes at this layer will provide the foundational requirements for future US Core and QI Core profiles. Future pilots will explore the generation of US Core and QI Core archetypes from these CIMI archetypes.
- The CIMI Detailed Clinical Model Layer represents the set of leaf-level constraining profiles on the foundational archetypes to create families of archetypes that only vary in their finest terminology bindings and cardinality constraints. This layer is intended to support clinical interoperability through an unambiguous specification of model constraints for information exchange, information retrieval, and data processing.
From layers 1-5, we define the set of transformations (e.g., SIGG (MDHT, MDMI)) to generate the corresponding FHIR profiles including the US Core and QI Core profile sets. Note that FHIR profiles can be generated from the various levels of the archetype hierarchy depending on requirements. The lower down in the hierarchy, the more prescriptive the profile is in terms of constraints. Much like ADL Archetypes, FHIR profiles can be layered.
It is important to note that some FHIR profiles may be derived from the Foundational Archetype Layer (e.g., US Core, some QI Core profiles, some CQIF profiles on PlanDefinition, Questionnaire and ActivityDefinition, etc...) and others from the DCM Layer (e.g., bilirubin, HgA1c, etc...). In other words, the arrow for FHIR Profiles stems out of the outer box rather than the last of the inner boxes (the DCM box).
Core BMM
The CIMI Core BMM Reference Model provides the core granularity of the CIMI model and introduces its top-level classes such as the DATA_VALUE class and the LOCATABLE class. This reference layer module defines the CIMI primitive types and core data types.
Primitive Types
Data Value Types
Foundation BMM
The CIMI Foundational BMM Reference Model is closely aligned to ISO13606 and the OpenEHR Core Reference Model. It defines foundational CIMI clinical documents and clinical record patterns. It also introduces the PARTY, ROLE, and PARTY_RELATIONSHIP patterns and defines the top-level CLUSTER class for complex CIMI type hierarchies. CQI Knowledge Artifacts may also leverage this layer.
Clinical BMM
- The CIMI Clinical BMM Reference Model consists of the classes derived from existing CIMI archetypes, the FHIM, QUICK, vMR, and QDM. This layer defines the set of 'schematic anchors' (to borrow Richard Esmond's term) or core reference model patterns from which all CIMI archetype hierarchies and ultimately Detailed Clinical Models (DCMs) derive. Requirements for this layer come from FHIM, vMR, QDM, QUICK, FHIR US Core, SDC, etc...
- The 'goal' is to define the reference models with low FHIR transformation costs where feasible noting that we will inherently have some divergence due to the different requirements underlying both models.
- Galen points out that, FHIM’s expressivity will not carry over to CIMI DCMs given the models' different requirements (e.g., FHIM includes finance and accounting).
Clinical BMM Context
Clinical Statement
Clinical Statement Topic
Clinical Statement Association
Clinical Statement Context
Clinical Statement Data Structures
Foundational Archetype Patterns
- The CIMI Foundational Archetypes Patterns define the top-level constraints on the CIMI Reference Model. These typically consist of attribute formal documentation and high level attribute semantic and value set bindings. Archetypes at this layer will provide the foundational requirements for future US Core and QI Core profiles. Future pilots will explore the generation of US Core and QI Core archetypes from these CIMI archetypes.
Detailed Clinical Models (DCMs)
- The CIMI Detailed Clinical Model Layer represents the set of leaf-level constraining profiles on the foundational archetypes to create families of archetypes that only vary in their finest terminology bindings and cardinality constraints. This layer is intended to support clinical interoperability through an unambiguous specification of model constraints for information exchange, information retrieval, and data processing.
PC Requirements for Skin-Wound DCM
- 2917-02-09-1000 ET Patient Care Workgroup Telecom
- Attendees: Jay, Susan, Richard, Claude, Steve
- Skin Wound content & scope
- Braden
- Skin Assessment
- Wound Assessment, with Pressure Ulcer specialization
- No Skin Risk Assessment (out of scope)
- Schedule
- Feb 13: Requirements UML and Terminology spreadsheet finished
- Feb 13 to Mar 3 - VA verification and validation of spreadsheet
- Diagram
- Data-Element and Value-Set Spreadsheet
- Mar 8: Presented at LOINC conference by Susan
UML
Mind Maps