CIMI Practitioners' Guide

Introduction

Scope

CIMI considers its work in the "Universal Realm”; where, current work might be considered "US Realm".

1. CIMI uses International Standards, when available.
2. CIMI is using a SNOMED extension including LOINC and RxNorm (SOLOR).
   1. SNOMED and LOINC are used beyond the US, such as Canada and UK.
   2. RxNorm is the most international medication terminology available
   3. RxNorm includes chemical ingredients, which are international; where, US pharmaceutical units, packaging and manufacturers can be replaced by foreign equivalents
3. Technically, CIMI's SOLOR semantic-bindings are completely defined; where,
   1. SOLOR follows the SNOMED observation model with explicit context expressions (e.g., body site)
   2. 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.

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

Introduction

Core Modeling Principles

The following principles guide CIMI’s modeling approach:

1. CIMI favors a design by specialization over a design by constraint approach. This approach is summarized as follows:
   1. if a class has a number of specializations, each requiring a different set of attributes, common attributes are represented in the parent class while child attributes are added to the appropriate specializations. An alternative approach may be to include the union of all attributes in a single class and constrain attributes out at the archetype level.
      1. The former approach is preferred over the latter except in certain cases.
      2. For instance, if a specialization differs from its parent by a single attribute, the inclusion of the attribute in the parent class may be preferred over the creation of a new class.
2. CIMI generally favors the definition of explicit attributes in the reference model over the slicing of lists in archetype definitions. The attribute subset pattern is achieved by defining a multi-cardinality attribute in the reference model and specifying subsets of the list elements in archetypes.
   1. For instance, one may specify that the LOCATABLE class, the supertype of all CIMI classes, has an attribute called participation of type PARTICIPATION and whose cardinality is 0..*.
   2. In an archetype, one may then constrain the participation attribute in the following manner.
      1. The first element of the list represents the author.
      2. The second element represents the data enterer.
      3. The third element represents the location where the authoring activity took place.
      4. The fourth element of the list represents the system where the information was recorded.
      5. While such subsets are allowed in both UML and ADL, CIMI generally avoids their use and favors the explicit representations of such subsets as full-fledged attributes in the model. For instance, CIMI explicitly adds an attribute for the
         1. agent of an activity,
         2. the location of an activity,
         3. the entity involved in the performance of the activity, and so on.
   3. The motivation for this approach stems from the fact that CIMI is a logical model rather than a physical model and favors greater reference model expressivity over physical patterns that enable better economies of structure.
3. CIMI may offer a number of variants for a given attribute.
   1. For instance, CIMI defines bodyLocation: AnatomicalLocation and bodyLocationPrecoord:
      1. CODED_TEXT to support both a coded and a post-coordinated anatomical location.
   2. Similarly, Assertion.dueToCode:CODED_TEXT and Assertion.dueTo:
      1. ClinicalStatement allow users to link an assertion to another clinical statement or simply define its type to be CODED_TEXT.
   3. Archetypes will need to specify a single property in such cases in order to avoid semantic collision.

CIMI Model’s Alignment to Terminology

Information models are often developed independently of clinical ontologies. As a result, many information models align poorly with the terminologies or ontologies upon which they ultimately depend for their formal semantics. Moreover, by not explicitly specifying the model’s semantics, the meaning of the model is left open for interpretation during implementation further hindering interoperability. In an effort to better align models of use with models of meaning, the Clinical Information Model is designed to align closely with the SNOMED CT Concept Model wherever such an overlap exists. In CIMI, the model’s formal semantics are specified through terminology bindings defined at the archetype level. These terminology bindings occur at three levels:

1. To define the relationship between the attribute and its class. CIMI model attributes are aligned with their corresponding SNOMED CT concept model attributes when such a correspondence exists.
   1. An example in the CIMI Finding Assertion Model, the body site data element aligns with the SNOMED CT concept 363698007|Finding site (attribute)|from the SNOMED CT Clinical finding concept model.
2. To define the semantics that the attribute can contain. CIMI model attribute ranges are aligned with the ranges specified for their corresponding SNOMED CT concept model attribute when such a correspondence exists. Using the example above, the range for the Body Site is the range defined in the SNOMED CT technical guide for Finding Site Anatomical or acquired body structure | 442083009 (<<)
3. To define the post-coordinated representation of some of the semantics of the archetype using the SNOMED CT concept model. CIMI preferred models favor post-coordination in the model rather than in the terminology.
   1. In some cases, CIMI archetypes may be associated with SNOMED CT expressions, provided that the expression conforms to the constraints specified for the flattened archetype.
   2. For instance, a CIMI Clinical Statement may be associated with a SNOMED CT Situation with Explicit Context expression or a pre-coordinated code.
   3. We are currently investigating the use of SNOMED CT Templates for such bindings

CIMI Architectural Framework

The CIMI 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.

1. 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.
2. 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.
3. 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...
   1. 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.
   2. 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).
4. 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.
5. 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).

The CIMI Reference Model Hierarchy

The CIMI Reference Model is done in UML and contains three Basic Meta-Model (BMM) hierarchical layers of Pattern structures aka Clinical Pattern structures:

1. Each Pattern contains a single class or group of related classes that can be constrained by ADM or AML archetypes in order to define a family of related and consistent Detailed Clinical Models (DCMs), such as types of
   1. Lab Orders,
   2. Procedures,
   3. Skin Wounds, etc.
2. The three layer CIMI Reference Model contains modular sets of (Clinical) Patterns, which can be used to create leaf-level DCMs:
   1. Core BMM Reference Model Level-1 defines core types and two root classes:
      1. Data Types
      2. Data Value Types
      3. LOCATABLE class, from which the majority of CIMI domain classes derive and
      4. ASSOCIATION_CLASS from which we derive
   2. Foundational BMM Reference Model Level-2 defines the foundational underpinnings of the CIMI model.
      1. This structure aligns with the ISO 13606 EHR and the OpenEHR Reference Models.
      2. The Foundation Reference Model defines the top-level hierarchies to derive lower-level classes and clinical patterns:
      3. CLUSTER,
      4. COMPOSITION,
      5. CONTENT,
      6. PARTY,
      7. ACTOR,
      8. ROLE,
      9. PARTICIPATION, and
      10. PARTY_RELATIONSHIP.
   3. Clinical BMM Reference Model Level-3 builds upon the Level-1 Core and Level-2 Foundation to specify the Level-4 CIMI Preferred Archetypes aka Semantic Anchors for DCMs.
3. The CIMI Core and Foundational reference modules provide the core semantics, structure, and granularity of the CIMI model.
4. the CIMI Clinical Reference Model module provides an intuitive domain semantic-anchor view for DCMs.
5. This modular approach allows for
   1. additional, domain-specific Level-3 Reference Archetypes and Level-4 Patterns
   2. alternate iso-semantic patterns to be introduced at the appropriate level in the model.
   3. Over time, it can be expected that the layers will hierarchically become more stable
      1. Level-1 Core BMM purposely being most stable.
      2. Level-2 Foundation BMM might change, such as when new underlying taxonomy-structures are added.
      3. Level-3 Clinical BMM might change, such as when new clinical disciplines and data-structures are added.
      4. Level-4 Reference Archetypes changing, such as when new domains are added.
      5. Level-5 DCMs under a constant-state of flux, such as when new information-exchange requirements are added.
   4. If change occurs, it should be backward-compatible with-respect-to lower layers and legacy-DCMs.

The CIMI Archetype Hierarchies

The CIMI archetype hierarchies form the second part of the CIMI model. These hierarchies serve two primary purposes:

1. They enable the progressive application of constraints on reference clinical patterns including the specification of terminology constraints that assign formal meanings to both model attributes and their range.
2. They allow for the definition of sets of models whose members vary solely based on the constraints they apply to a common underlying reference model pattern. Archetypes can specialize more general archetypes in ADL. They do so by progressively constraining the underlying reference model pattern in a manner that is consistent with and not contradictory to the constraints specified in archetypes higher up in the hierarchy. Examples of constraint refinements are listed below:
   1. A top-level archetype restricts the range of Ingredient.substanceCode to the set of all concepts subsumed by the SNOMED CT concept ‘Pharmaceutical/biologic product’. A downstream specialization of this archetype restricts the Ingredient.substanceCode to ‘Metoprolol’.
   2. A top-level archetype assigns the SNOMED CT concept ‘Procedure site (attribute)’ as the semantic binding of the attribute Procedure.site. A downstream specialization of this Detailed Clinical Models (DCMs), highly specific models that enable the interoperable exchange of clinical information, typically reside at the leaf-level of CIMI archetype hierarchies. The cumulative constraints applied on a DCM are intended to be precise enough to allow for the unambiguous exchange of interoperable clinical information and thus constitute highly specific constraints on the underlying reference model pattern.

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.

CIMI_Core_BMM_Mind_Map.jpg

=Primitive Types

CIMI_Primative_Types_BMM_Mind_Map.jpg

=Data Value Types

CIMI_Primative_Types_BMM_Mind_Map.jpg

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.

CIMI_Core_Foundation_BMM_Mind_Map

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

CIMI_Foundational_Architype_Patterns_Mind_Map.jpg

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

Skin-Wound DCM

• 2917-02-09-1000 ET Patient Care Workgroup Telecom
• Attendees: Jay, Susan, Richard, Claude, Steve

1. Skin Wound content & scope
   1. Braden
   2. Skin Assessment
   3. Wound Assessment, with Pressure Ulcer specialization
   4. No Skin Risk Assessment (out of scope)
2. Schedule
   1. Feb 13: Requirements UML and Terminology spreadsheet finished
   2. Feb 13 to Mar 3 - VA verification and validation of spreadsheet
      1. Diagram
      2. Data-Element and Value-Set Spreadsheet
   3. Mar 8: Presented at LOINC conference by Susan

UML

Mind Maps

References

1. Jan 2017 CIMI Architecture, Methodology and Style Guide from Ballot
2. CIMI Tools
3. CIMI References