(Back to home)



CIMI Logical Models, Release 1 (PI ID: 1253)

January 2018

CIMI Modeling Architecture Guide

Version 1.3

Published Date: 12/17/2017

Sponsored by:
HL7 CIMI Work Group

HL7 Clinical Decision Support Work Group

HL7 Clinical Quality Information Work Group

HL7 Patient Care Work Group

Copyright © 2017-2018 Health Level Seven International ® ALL RIGHTS RESERVED. The reproduction of this material in any form is strictly forbidden without the written permission of the publisher.  HL7 and Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. Pat & TM Off.

Use of this material is governed by HL7's IP Compliance Policy.

1)  Background        4

2)  CIMI and FHIR        4

3)  CIMI and Other HL7 Standards and Initiatives        6

4)  CIMI Model Architecture        7

Introduction        7

5)  Core Modelling Principles        9

6)  The CIMI Model’s Alignment to Terminology        10

7)  A High Level View of the CIMI Logical Model        11

8)  The CIMI Reference Model        12

What is a ‘reference model pattern’ or ‘clinical pattern’        12

9)  A note on Isosemantic Models        12

10)  The CIMI Archetype Hierarchies        13

11)  Reference Model        14

The CIMI Core Reference Model Module        14

CIMI Primitives        15

CIMI Complex Types        16

The LOCATABLES Root Type        18

The CIMI Foundation Reference Model Module        19

Composition Patterns        19

Party Patterns        19

Entity Patterns        20

Common Foundation Types        22

The CIMI Clinical Reference Model Module        22

The CIMI Role Patterns        22

The CIMI Clinical Statement Pattern        23

InformationEntry        23

ClinicalStatement        24

Compositional Approach to Clinical Statement Design        25

StatementTopic and StatementContext        26

CIMI Clinical Statement Pattern vs. V3 Clinical Statement Pattern        32

The CIMI Attribution/Provenance Patterns        33

The CIMI Assertion and EvaluationResult Pattern        34

The CIMI Adverse Event Pattern (Experimental)        37

The CIMI Adverse Reaction Pattern        38

The CIMI AdverseSensitivityToSubstance Pattern        39

The CIMI Procedure Pattern        40

The CIMI Encounter Pattern (Experimental)        43

CIMI Pharmacy Patterns        43

CIMI Patient Education Pattern        44

CIMI Entities        45

Common CIMI Data Structures        48

Association Classes        50

12)  An Introduction to CIMI Archetype Hierarchies        50

Top Level Value Set Constraints        51

Archetypes constraining attribute types        52

Archetypes as templates        53




Amendment History



Linda Bird

First draft for comment



Rahil Qamar Siddiqui

Revised section 6.6 on Terminology Binding  

Added subsections 6.6.1 to 6.6.4 with preliminary details on the main types of terminology bindings within scope for CIMI. More details to be added in due course.



Susan Matney

Draft for ballot comment



Claude Nanjo

Integration of architectural sections



Susan Matney




Jay Lyle




Claude Nanjo

Review of style guide section and edits



Claude Nanjo

Review of comments and final updates to the documentation based on new artifacts.



Claude Nanjo

Incorporating Patrick’s changes



Claude Nanjo

Updates for September ballot.



Joey Coyle

Updates to “An Introduction to CIMI Archetype Hierarchies” matching new reference model and adl.



Lorraine Constable

Updates for September ballot - applying approved changes from May ballot.



Claude Nanjo

Integrated most comments from May Ballot.



Claude Nanjo

Updates for January submission

Table 1: Version History

1)  Background

The Clinical Information Modelling Initiative (CIMI) is a Health Level Seven (HL7) workgroup dedicated to providing a common definition of health information content so semantically interoperable and computable information may be created and shared in health records, messages, and documents.  

In achieving this goal, CIMI has established a CIMI modelling methodology, style guide, and a set of models which together demonstrate and test the approach to CIMI clinical modelling.

CIMI modelling is the overall strategy for specifying, at a granular level and in a computable fashion, the structure and semantics of the common data elements that will be stored in an Electronic Health Record (EHR).  More precisely, the CIMI Model specifies how to create a “model” of a particular type of element (e.g., a heart rate measurement, a laboratory observation, or a procedure performed). The model declares how a valid “instance” of the element should be structured and the semantics of the structure.  By analogy, a blueprint is used for building cars.  All the cars built as a result of the blueprint conform to the specifications of the blueprint.  The cars conforming to the blueprints are analogous to instances of data (e.g., John Smith’s heart rate measurement at 11 am on January 26th, the observation of Mary Black’s blood glucose on March 20th, or the procedure performed on Jeff Brown June 23rd at 10 am) while the blueprints are analogous to the models (e.g., a model for heart rate measurement instances, a model for laboratory observation instances, or a model for procedure performed instances).

The purpose of this document is to give modellers practical information needed to author CIMI models.  This document describes some initial proposals by the CIMI modelling task force to help inform CIMI’s model architecture, modelling methodology, and style guide.

2)  CIMI and FHIR

The CIMI Logical Model and the FHIR Resource Model are complementary standards. Unlike FHIR, CIMI does not provide a specification for the representation of instances of clinical data. CIMI provides source-content for the production of  implementation models such as FHIR. The CIMI Model offers a formal specification architecture for a set of consistent FHIR logical, resource, and extension profiles to enable both the interoperable exchange of clinical information and the queries, analyses, and computations performed upon such information. Services whose APIs make use of these FHIR profiles will be able to leverage the expressivity and computability of the CIMI logical model within health applications.

The CIMI logical model offers a stable, consistent, and computable clinical model for the development of knowledge artefacts and for the design of execution systems making use of these models in clinical logic.  Clinical Decision Support and Clinical Quality Measures are particularly dependant on the computability characteristics targeted by CIMI.

In order to achieve this, the CIMI preferred models must first be transformed into FHIR resource profiles. The CIMI logical model provides the underlying specification for such profiles through the translation of both reference model structures and archetype constraints into their equivalent representations in corresponding FHIR structure definitions. This process is a two-step process: (1) CIMI models are first converted to FHIR logical profiles and (2) FHIR logical profiles are then converted to FHIR resource profiles using the declarative FHIR Mapping Language which is currently under development in the HL7 FHIR Working Group. Once the set of CIMI-FHIR profiles has been generated, FHIR instances, conformant with these CIMI profiles, represent conformant CIMI instances.

Figure 1: FHIR Profile Generation from CIMI Models

Given their differing requirements, CIMI models and FHIR resources may differ in their structure and therefore transformation costs are inevitable. For instance, while CIMI clinical statements are compositional structures to support model reuse and consistency, FHIR resources tend to prioritize ease of implementation and tend to be flatter. In order to minimize these transformation costs, CIMI aims to:

  1. Align the granularity of its models with those specified by FHIR (to the extent consistent with its requirements mandate)
  2. Provide declarative and computable transformations from all of its models to FHIR profiles
  3. Work with the FHIR team to address specific areas of incongruence

At a high level, the transformation of CIMI models into FHIR profiles can be achieved as follows:

  1. CIMI archetypes are aligned with the corresponding FHIR resources
  2. Reference model attributes are mapped to attributes in the mapped FHIR resource(s). Note that this translation may occur (1) directly from a translation of the CIMI reference model into a set of layered FHIR profiles which then serve as base profiles to other FHIR profile that further apply constraints on these element definitions or (2) indirectly through references to reference model attributes from a flattened archetype.
  3. CIMI attributes with no equivalent in FHIR are handled as FHIR extensions
  4. ADL model constraints are translated into their corresponding representations in FHIR structure definitions

Archetypes in CIMI are defined hierarchically with more specific archetypes further tightening the constraints of their ancestors in the hierarchy. In order to retain this structure in FHIR, the translation of CIMI archetype hierarchies into FHIR resource profiles will most likely result in the generation of layered resource profiles in FHIR that mimic the structure found in CIMI.

One important aspect to note is FHIR’s architecture and the semantics of FHIR Profiles are tightly focused on the needs of an information model transport layer.  FHIR’s success depends on the successful implementation of FHIR across a broad and diverse ecosystem of clients and servers.  In the FHIR community, the weighing of tradeoffs between sophistication and simplicity trend heavily towards simplicity.  FHIR depends on the authoring process to deliver consistent and computable clinical information. How this is achieved is out of scope.  In contrast, the goal and scope of CIMI are tightly focused on providing standards, patterns, and tooling to deliver this process.  

CIMI models can also be applied beyond FHIR implementations, but given the immediate relevance of FHIR within the clinical community, the production of FHIR Profiles from CIMI clinical models is being given the highest possible priority.  The CIMI workgroup believes the value of FHIR resources and profiles generated from CIMI clinical models offers the best of both worlds:  the  clarity, consistency, and computability of CIMI and the implementation simplicity of FHIR.

3)  CIMI and Other HL7 Standards and Initiatives

In addition to existing collaborations with the FHIR, CDS, CQI, and Patient Care Working Groups, the CIMI team intends to approach other working groups at HL7 in order to support CIMI harmonization with existing standards and encourage stronger working group coordination.

CIMI and V3 share the goal of creating models that support interoperability.  CIMI has profited from many of the core concepts in the V3 RIM including the V3 data types and foundational classes for entities, acts, and participation.  The V3 process used HL7 developed tools and processes to specialize the RIM classes to DMIMs (Domain Message Information Models) and then further constrain to Refined Message Information Models (RMIMs) that represent serializable models and are used to create implementable message definitions.  CIMI starts with a core reference model that is entirely general and then builds high level patterns for common classes of healthcare data. These patterns are at roughly the same level as FHIR resources. CIMI then uses formal health information modeling languages (Archetype Definition Language and Archetype Modeling Language) to constrains the patterns to definitions of very specific and explicit health care data elements (systolic blood pressure, heart rate, serum sodium level, pain severity, etc.), primarily by specifying standard codes from SNOMED CT, LOINC, and RxNorm.  Thus, though there are many common ideas and themes between CIMI and V3, there is very little similarity in the technology, processes, or final content.

4)  CIMI Model Architecture


CIMI Clinical Models are defined through two closely integrated OpenEHR syntaxes:

  1. Basic Meta-Model (BMM)
  2. Archetype Definition Language (ADL)

BMM is used to define the structural content of components (i.e., the classes and attributes that make up the model) and has sophisticated capabilities to leverage inheritance, composition, and generics; which offer authors the maximum ability for reuse and consistency across definitions.  BMM is used to produce three structural layers of schematic definitions.

The three layers of BMM schema consist of:

  1. The Core Reference Model Module which introduces the CIMI primitives, data types, and core top-level classes such as Locatable
  2. The Foundational Model Module, closely aligned to the ISO 13606 EHR Standard, which introduces the Composition class (used to represent documents and records), the Content class (used to represent document content such as sections and document entries), and the many other classes that inherit from Locatable (used to represent data structures other than documents and the clinical statements that make up their content)
  3. The CIMI Clinical Patterns Module which introduces the clinical patterns from which interoperable detailed clinical models are derived

BMM and its three layers of definitions delivers a rich hierarchy of information metadata to allow developers of clinical authoring tools and run-time execution engines an opportunity to leverage code-generation and dynamic run-time techniques to deliver sophisticated tools that have a high degree of insulation from evolutionary changes in the information schema.  BMM is not a technology typically exposed to a Subject Matter Expert (SME) as they author clinical content.  It is simply a serialization standard used for standardized persistence and exchange of clinical patterns.

Archetype Definition Language (ADL)

CIMI believes a finite and manageable set of reference clinical patterns can support a much larger number of specific clinical situations recorded in the medical record.  It would be daunting to implementers if each bone in the human body had its own information model definition.  Instead, detailed models for broad clinical domains can be derived from a much smaller set of underlying BMM structural pattern definitions through the application of type and terminology constraints. For instance, a very large number of physical evaluation results can be derived from only a few reference clinical patterns. The models used to represent such clinical domain scenarios are referred to as Detailed Clinical Models (DCMs) and are defined using the Archetype Definition Language (ADL).

Figure 2: Creation of Detailed Clinical Models (DCMs) from CIMI Reference Model Patterns

When the logical-models are transformed into a specific implementation, implementers get to choose the level of granularity for their information model layer.  Using the Fracture topic as an example, the implementation team may choose to store all fractures in a single relational table even though there may be hundreds of Archetypes defined for the hundreds of bones within the human body.  The hierarchy of Archetypes would define all the complex variations of recordable qualifiers and modifiers applying to the different bones.  But in this example, each of these variations would be stored in the same schema structure within the information-model.

Archetypes provide the constraints determining what qualifiers and modifiers are valid for very narrow clinical situations.  Pelvic fractures and Spine fractures are recorded using a different collection of qualifying elements - yet each is a fracture.  ADL provides an expressive collection of semantic options to define the specific clinical situations. However, like BMM, ADL is intended to be a serialization format used by the tooling layer to exchange standardized clinical artifact constraints.  It would not typically be exposed to SMEs during the authoring process, only to the engineers involved in developing authoring and run-time tools and engines.

BMM / ADL relationship to previous and existing modeling standards:

The most commonly understood and used general-purpose modeling language today is Universal Modeling Language (UML).  Two other modeling formalisms used similarly within the Healthcare space are ISO 13606 and openEHR.  Several proprietary clinical modeling languages have also been developed internally within individual healthcare systems such as the Clinical Element Modeling language (CEML) from Intermountain.  Each of these has its strengths and limitations and none of them are likely to disappear from the landscape in the near future.  Therefore, a great deal of effort has been invested in ensuring BMM and ADL formats are semantically compatible with these other formats and also in transformation tooling  to support an ecosystem of intercompatibility between syntaxes.

More will be written about this over time but the fundamental goal of CIMI is to deliver interoperability between teams who are deeply invested in UML as well as teams leveraging BMM / ADL directly.

CIMI Detailed Clinical Models (also referred to as archetypes) are defined as a set of constraints on the CIMI reference model structural patterns. This reference model is the ‘common language’ used to describe all clinical models. CIMI Clinical models are defined using a constraint language whose semantics are defined by the Archetype Object Model (v2)[1]. These constraint semantics can be represented using either the Archetype Definition Language (ADL)[2] (a direct serialisation of the AOM) or Archetype Modelling Language[3] (AML) (a profile of the Unified Modelling Language). CIMI Clinical models will usually include both semantic bindings (i.e., bindings to terminology expressions that define the meaning of the relevant parts of the model) and value bindings (i.e., bindings to terminology reference sets that define the valid values that may populate appropriate parts of the model). For this ballot cycle we are interested in semantic bindings to the SNOMED CT Concept model. For the value bindings we welcome but do not solicit comments.

It is anticipated CIMI Clinical models will be both specialised and extended to develop realm-specific clinical models which will then be further transformed into implementation-specific artifacts.

5)  Core Modelling Principles

The following principles guide CIMI’s modelling approach:

  1. CIMI favors a design-by-class-specialization over a design-by-constraint approach. This approach is summarized as follows: 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. The former approach is preferred over the latter except in certain cases. 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. For instance, one may specify that the Locatable class, the supertype of all CIMI classes, has an attribute called participation of type PartyAssociation and whose cardinality is 0..*. In an archetype, one may then constrain the participation attribute in the following manner. The first element of the list represents the author. The second element represents the data enterer. The third element represents the location where the authoring activity took place. The fourth element of the list represents the system where the information was recorded. 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 agent of an activity, the location of an activity, the entity involved in the performance of the activity, and so on. The motivation for this approach stems from the fact CIMI is a logical model rather than a physical model and thus favors greater reference model expressivity over physical patterns that enable better economies of structure.

6)  The 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 opportunities 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. For 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 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 Editorial Guide for Finding Site 

| Anatomical or acquired body structure | 442083009 (<<)

  1. 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. In some cases CIMI archetypes may be associated with a SNOMED CT expression provided the expression conforms to the constraints specified for the flattened archetype. For instance, a CIMI Clinical Statement may be associated with a SNOMED CT Situation with Explicit Context expression or a pre-coordinated code. We are currently investigating the use of SNOMED CT Template semantics for such bindings.  Template semantics allow for the specification of pre-coordinated / post-coordinated relationships between two fields.  An example would be a Findings field related to a Body-Site field where template semantics could be used to specify the Body-Site field must not conflict with any pre-coordinated body-location within the Finding field.

7)  A High Level View of the CIMI Logical Model

The CIMI model consists of structural patterns and the constraints applied on those patterns:

  1. The CIMI Reference Model specifies the classes, attributes, and allowed relationships defining the model’s primitive types, complex types, data structures, and the clinical patterns built upon them.
  2. The CIMI Archetype Library is composed of archetype hierarchies progressively constraining the patterns defined in the reference model and whose leaf-level archetypes ultimately form the Detailed Clinical Model (DCM) layer of the CIMI model. A DCM consists of the structural patterns and corresponding archetype constraints sufficiently defining a shareable and interoperable unit of information.

The CIMI model is persisted in a format conforming to two OpenEHR specifications:

  1. The Basic Meta Modeling (BMM) language is used to define and persist the CIMI Reference Model[4].
  2. The Archetype Definition Language (ADL2) is used to specify persistent and computable constraints on the reference model[5].

The CIMI model follows a strict rule in the usage of the above-mentioned OpenEHR specifications in order to cleanly delineate the boundary between the reference model and the archetype hierarchies. The basic meta-modeling language is used to specify the classes, attributes, and relationships making up the model. The archetype definition language is used to define the constraints on the reference model but shall not be used to define new model classes and attributes. In other words, the CIMI model specifies classes and attributes explicitly in the reference model and does not offer a way to extend the model within archetypes.

This approach represents a departure from the approach taken by OpenEHR which allows the definition of classes and attributes within archetypes using the meta model constructs of ITEM, CLUSTER, and ELEMENT, and by FHIR whose extension mechanism allows for the definition of new attributes and structures within resource profiles. The motivation for this decision is, unlike FHIR and the OpenEHR models (both physical models), CIMI is a logical model and does not rely on extensions to provide for additional expressivity beyond what is provided by the CIMI Reference Model. The CIMI Logical Model favors expressivity over economy of structure and delegates model extensibility to its underlying physical model target. For instance, attributes existing in the CIMI Reference Model but not existing in the FHIR Core Model shall be mapped to the appropriate FHIR extensions.

8)  The CIMI Reference Model

The CIMI Reference Model is a layered model designed to be modular and currently consists of three layers:

  1. The Core CIMI Reference Model defines the model’s primitives, core types, and two root classes: Locatable, from which the majority of CIMI domain classes derive, and DataType, from which CIMI non-primitive data types derive.
  2. The CIMI Foundation Reference Model defines the foundational underpinnings of the CIMI model. This structure aligns with the ISO 13606 EHR and the OpenEHR Reference Models. The Foundation Reference Model also defines a number of top-level hierarchies: Composition, Content, Party, Role, PartyAssociation, and Entity. All downstream CIMI classes and clinical patterns are derived from these hierarchies.
  3. The CIMI Clinical Reference Model builds upon these two lower layers to provide the structural patterns upon which CIMI preferred archetypes are built. While the CIMI Core and Foundation reference modules provide the core semantics, structure, and granularity of the CIMI model, the CIMI Clinical Reference Model module provides an intuitive domain view for clinical modelers.

This modular approach allows for additional more domain-specific layers to be added in the future; or for alternate isosemantic patterns to be introduced at the appropriate level in the model. Over time it can be expected the lower level reference model modules will become more stable while higher-level modules may still undergo additional flux.

What is a ‘reference model pattern’ or ‘clinical pattern’

A reference model pattern is a structural pattern (a single class or group of related classes) that can be constrained by archetypes in order to define a family of related and consistent detailed clinical models. The set of allowable clinical patterns comprise the CIMI Reference Model.

9)  A note on Isosemantic Models

In CIMI, isosemantic models refer to models that may share a different structure but which are semantically equivalent. In order for two models to be isosemantic the models must support bidirectional transformations without any information loss. Isosemantic models allow models whose representations better address clinical requirements while retaining formal and detailed semantics. For instance, while a more post-coordinated information model may facilitate integration with existing systems, an interface model may favor greater terminology pre-coordination and a simpler structure that aligns better with the needs of an input form presented to a clinician. Typically, isosemantic models range between two poles - a highly detailed information model that makes little use of terminology pre-coordination and post-coordinated expressions and a highly simplified information model where most of the model representation resides in a fully post-coordinated terminology expression based on an underlying concept model. Many isosemantic models reside within this continuum.

10)  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 assigning 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 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’ and 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 and a downstream specialization of this archetype further constrains this meaning to ‘Procedure site – Direct (attribute)’, a concept subsumed by the ‘Procedure site (attribute)’
  3. A downstream archetype refines the cardinality of a container attribute from 0..* to 2..5
  4. A downstream archetype constrains out a class attribute by setting its existence to 0..0
  5. A downstream archetype constrains the datatype of an attribute from DATA_VALUE to QUANTITY

Detailed Clinical Models (DCMs), highly specific models enabling 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. This layered approach is illustrated below:

HSPC Vision for CIMI%2FSOLOR%2FFHIR Ecosystem (5).jpg

Figure 3: CIMI Architectural Framework

CIMI also adopts a bottom-up approach during the validation and piloting phase when specific clinical use cases and scenarios are modeled using CIMI detailed clinical models. This top-down and bottom up approach ensure that CIMI supports the required breadth of models that have been identified through other modeling initiatives but is capable of refining them to meet concrete clinical use cases.

11)  Reference Model

The CIMI reference model defines the core structure and data types of all CIMI clinical models. Each reference model module is further described in the sections below.

The CIMI Core Reference Model Module

The CIMI Core Reference model module introduces three core reference model hierarchies:

  1. The Any hierarchy from which all CIMI primitive types are derived
  2. The DataType hierarchy from which all CIMI complex types are derived
  3. The Locatable hierarchy from which all other CIMI classes are derived

CIMI Primitives

The table below aligns the set of CIMI primitive types and their mappings to UML and FHIR. In CIMI all primitive types derive from the Any abstract class:

CIMI Primitives

UML Primitives

XML Primitives

FHIR Primitives





































Any (root type)




Table 1: CIMI Primitives

Note that while the List<T> and Array<T> types do not exist in FHIR, they are OpenEHR constructs to handle container types and multiple cardinality attributes.

Class_Diagram__CIMI_Reference_Model__CIMI_Primitive_Types.jpgFigure 4 - CIMI Primitive Types

CIMI Complex Types

The table below aligns the CIMI ‘complex’ data types and their mappings to FHIR. In CIMI all complex data types derive from the DataType abstract class:

CIMI Data Types

FHIR Primitives

FHIR Complex Types



























Period, Range
















Base64Binary, Markdown




Attachment (partial match)







DataType (root type)



Table 2 - Extended FHIR Primitive Types

CIMI and FHIR differ in the boundary between primitives and complex data types as shown in the table above. Moreover, a number of FHIR types do not have equivalents in CIMI. These include SampledData, though such types can be accommodated within the CIMI Locatable hierarchy.

Figure 5 - CIMI Data Value Types


All classes in CIMI, apart from CIMI primitives and complex types, derive from the Locatable class.

Figure 6 - CIMI Core Model

The following sections introduce some of the reference model patterns found in CIMI that build upon the CIMI Core Reference Model Module.

The CIMI Foundation Reference Model Module

The CIMI Foundational Reference Model introduces a number of classes, hierarchies and patterns that are not unique to the healthcare domain but that nonetheless play an important role in the overall CIMI model.

Composition Patterns

The Composition and Content pattern introduce document-based patterns in CIMI which can be used to represent a patient record, a knowledge artifact such as an order set, or a report such as an adverse event report. This pattern represents a relaxation of the ISO 13606 and the OpenEHR Composition pattern in order  to support a broader set of document types. A composition can be thought of as a document composed of content items such as sections (which can be nested) and entries. It is expected that reference model modules that depend on the CIMI Foundation Reference Module will introduce the required specialization of these classes. At the current time, no specializations of Composition have been introduced in CIMI but such specializations are planned for future iterations of the model. Both Content and Composition inherit from Locatable (not shown in this diagram). The Entry class plays an important role in CIMI as it is the parent class for the CIMI InformationEntry and ClinicalStatement classes.

Figure 7 - CIMI Composition Patterns

Party Patterns

The CIMI Foundation Reference Module also introduces the Party pattern. The Party pattern consists of the Party class and its two specializations, Role and Entity. Parties can participate in actions typically in a specific role carried out by a real world entity such as a person or an organization. Parties can also be related to one another through relationships such as the relationship between a patient and his/her primary care provider. Both participations and relationships are covered by the PartyAssociation pattern which relates the source class (an action or another party) to a party.

Figure 8 - CIMI Party Pattern

Entity Patterns

The Entity hierarchy introduces a number of important entities such as Person and Organization which may be further specialized as needed. Note that an entity may play a number of roles. For instance, a person may be a practitioner one day and a patient the next.

Figure 9 - CIMI Foundation Module Entity Hierarchy

Common Foundation Types

The CIMI Foundation Reference Module also introduces a number of common types that all descend from Locatable. They are shown below:

Figure 10 - CIMI Party Package

The CIMI Clinical Reference Model Module

The CIMI Clinical Reference Model module includes the classes and structural patterns derived from those classes upon which all CIMI archetypes are built.

The CIMI Role Patterns

The CIMI Clinical Reference Model Role pattern builds upon the CIMI Foundation Reference Model Role pattern as shown below. It introduces the FamilyMembership and HealthCareRole patterns and defines two role specializations of the HealthCareRole: a HealthCareConsumerRole (e.g., a patient) and a HealthCareProviderRole (e.g., a care providing organization). Figure 11 - CIMI Role Patterns

The CIMI Clinical Statement Pattern


The CIMI InformationEntry Pattern forms the core of the CIMI model. The InformationEntry class is a specialization of the ENTRY class from the Foundation Reference Model module. It represents a statement about some aspect of a health care process. The InformationEntry pattern also includes relevant attribution metadata for the information contained in the entry such as information about the authoring of the statement (please refer to the Attribution/Provenance Patterns section below).

The InformationEntry pattern has a number of specializations including ClinicalStatement,  Encounter, and AdverseEventReportEntry. In the future, it is expected that clinical entries such as EpisodeOfCare and CarePlan will also specialize InformationEntry directly.


The CIMI ClinicalStatement pattern is an example of a composition pattern that contains a statement topic (StatementTopic) and the situational context for that topic (StatementContext). Clinical statement structures are stable structures. Their expressivity derives from the topic and context that compose the clinical statement. Clinical Statements may either be Indivisible Clinical Statements or Composite Clinical Statements such as laboratory panels.

Figure 12 - The Information Entry and ClinicalStatement Pattern

Compositional Approach to Clinical Statement Design

To illustrate how a clinical statement is composed, consider a clinical statement documenting a proposal made by a clinical decision support system for a procedure to be performed. It is modeled as follows:

The combination of a ClinicalStatement with a Procedure topic and a Proposal context defines a ProcedureProposalStatement. This composition can be expressed programmatically as:

class ProcedureProposal extends ClinicalStatement<Procedure, Proposed>

Where the first parameter represents the topic parameter ‘T’ and the second represents the context parameter ‘C’ of the ClinicalStatement<T,C> class.

Represented graphically, we get:

Figure 13 - Composition of Clinical Statement

StatementTopic and StatementContext

The StatementTopic abstract class currently has three specializations:

  1. Finding, an abstract class, which is further specialized by the Assertion and EvaluationResult statement topics
  2. Act, an abstract class, which is further specialized by a number of procedure, medication, and encounter statement topics
  3. Event, a topic for non-clinical events such as tornadoes and earthquakes which adversely impact the health of the patient. The event type attribute is constrained to the event hierarchy in SNOMED-CT and is currently experimental in CIMI.


Note for the January 2017 ballot cycle we limit the scope of the model to the statement topics presented below. More topic specializations will be added over time.

Figure 14 – Clinical Statement Topics

The StatementContext abstract class has the following three specializations:

  1. FindingContext - The FindingContext class aligns with the SNOMED Situation with Explicit Context for findings and provides the context for the EvaluationResult and Assertion topics of a clinical statement. For instance, a statement about findings may state that the finding was present or absent.
  2. EventContext - At this time, specializations of the EventContext have not been defined. It is anticipated that EventOccurrence and EventNonOccurrence specializations will be introduced.
  3. ActionContext - The ActionContext class aligns with the SNOMED Situation with Explicit Context for procedures and provides the context for the Act topic of a clinical statement. For instance, a statement about a procedure may specify the procedure has been proposed, ordered, planned, performed, or possibly not performed.

Figure 15 - ClinicalStatement Contexts

Figure 16 - Finding Contexts

Figure 17 - Action Contexts

StatementTopic and StatementContext have the following characteristics:

  1. They are reusable components that can be assembled to form clinical statements. For instance, one can coordinate the Procedure statement topic with the Proposal statement context to represent a ProcedureProposal. The Procedure statement topic may also be paired with the Order statement context to create a ProcedureOrder statement.
  2. They represent groupings of attributes aligned with the SNOMED CT Concept Model. For instance, the Procedure statement topic is aligned with the SNOMED CT Procedure Concept Model. The Performance context aligns with the Situation with Explicit Context Concept (SWEC) Concept Model.
  3. They provide  a mechanism to state presence or absence of a finding as well as performance or nonperformance of an action. For instance, the pairing of the Procedure topic with the NonPerformance context allows expression of a procedure that was not performed.

The CIMI ClinicalStatement pattern aligns with the SNOMED CT Situation with Explicit Context Concept Model as defined in the SNOMED CT Editorial Guide[6]. The attributes are as follows:

CIMI Clinical Statement Pattern vs. V3 Clinical Statement Pattern

HL7 version 3 includes two variants of the Clinical Statement pattern - the Normative Clinical Statement Model (COCS_DM000000UV) with the associated Common Message Element Types (CMETs) published in the 2016 Normative Edition, and the Clinical Statement model that forms the “right hand side” of the Clinical Document Architecture (CDA) R2 RMIM. The latter is based on an earlier version of the RIM (version 2.07). While there are some differences between the models; for instance, the CDA uses an older version of negation attributes; the comments here apply to both versions of the v3 Clinical Statement unless otherwise indicated.  

The CIMI InformationEntry class described above maps most closely to the v3 Clinical Statement itself. ClinicalStatement specializes InformationEntry which specializes ENTRY. COMPOSITION is comprised of CONTENT that may be either ENTRYs or SECTIONS. This provides a similar structure to CDA, where document Sections may contain Clinical Statements related by Entry actRelationships. Outside of CDA, Clinical Statements are referenced as a CMET from a containing model, so the structure is driven from the containing model.

The CIMI Clinical Statement itself maps most closely to the various Act clones in the Act Choice structure of the Clinical Statement Model. In v3, there are specific Act clones defined in the model for Statements such as Observation, SubstanceAdministration, Procedure, Supply, etc. along with a generic Act and an Organizer. (There are a few more specific clones in the current normative edition model than in CDA). However, CIMI does not subclass Clinical Statement itself - specializations are handled by subclassing the StatementTopic and StatementContext of a ClinicalStatement.

Specializations of StatementTopic allow CIMI to define attributes appropriate a specific kind of clinical statement. StatementTopic is further specialized by FindingTopic, ProcedureTopic and EventTopic. As the model matures, there is the possibility of many more ClinicalStatement types than is currently supported by the v3 Clinical Statement pattern.

StatementContext encapsulates several context related concepts that are handled by attributes in version 3. StatementContext is further specialized by FindingContext, ActionContext and EventContext. ActionContext includes information that in version 3 would be represented by attributes such as moodCode and actionNegationInd (in the normative model). FindingContext has attributes that fulfill the role of valueNegatinInd. (Note, in the older CDA Clinical Statement, there is only one negation attribute: negationInd). The contextStatus attribute in CIMI plays a similar role to ActStatus in version 3, but can vary based on the specific specialization of ActionContext.

This definitional pattern means the CIMI Clinical Statement pattern provides an extensible structure for a variety of clinical content, but less specific definition as to the various clinical statements that can be represented than v3 does.

Both CIMI and v3 allow Clinical Statements to nest and to reference other Clinical Statements, but the mechanism to support the relationships are different. Version 3 uses entryRelationship actRelationships to associate one Clinical Statement with another. The 2016 Normative Edition model adds an ActRelationship choice to support references to external Clinical Statements.  In CIMI, related Clinical Statements are typically defined explicitly as attributes in the model where they are needed. They may be either compound or individual Clinical statements.

Overall, the primary difference between Clinical Statement as represented in CIMI, and as represented in v3 is the approach to specialization and context. However, they are capturing the same clinical business concepts and it should be possible to map from models that represent the CIMI Clinical Statement Pattern to version 3 Clinical Statements.

The CIMI Attribution/Provenance Patterns

In the CIMI model, provenance information is represented by the Attribution class. The Attribution class provides a pattern for the capture of provenance information such as the what, who, when, where, why, and how associated with a particular activity – e.g., provenance attributes about the verification of a clinical statement.

CIMI currently includes two attribution patterns:

  1. Attribution information as a part of the clinical statement – In this pattern, the ClinicalStatement pattern contains a number of attributes of type Attribution (e.g., ClinicalStatement.authored and ClinicalStatement.verified). This pattern provides a consistent way to capture attribution information that extends beyond simply the agent of an activity (e.g., the author). When attribution is part of the ClinicalStatement model, any change to the attribution for an activity will result in a version change.
  2. Attribution information external to the clinical statement - CIMI allows the capture of provenance information external to the clinical statement through the Provenance class. The provenance class includes the Attribution class and pointers to one or more clinical statements (the Provenance.target attribute). This pattern allows the modification of provenance information of a clinical statement without impacting its version.

Figure 18 - Provenance Patterns

The CIMI Assertion and EvaluationResult Pattern

CIMI defines a number of specializations of the Finding Statement Topic. Of these, the two most mature specializations are Assertion and EvaluationResult.

The assertion model is used to capture information about a unary clinical finding,  whereas the evaluation result model is a binary structure used to capture a question and its answer. An evaluation result consists of an observed characteristic (sometimes referred to as ‘the question’) and a value for the observed characteristic (sometimes referred to as ‘the answer’). At this time, a number of specializations for Assertion have been proposed (DetailedAssertion, BradenScaleAssessmentResult, FindingSiteAssertion, and WoundAssertion) and we anticipate additional specializations in the future (e.g. assertions about device use). Two specializations of Evaluation Result are provided in the reference model: LaboratoryTestResult and PhysicalEvaluationResult. From these, a number of core archetypes are provided such as QuantitativeLaboratoryTestResult and CodedLaboratoryTestResult. These archetypes constrain the result attribute of EvaluationResult to a Quantity and a Concept respectively. Please refer to the archetypes for more examples of such constraints.

For more information on the proper usage of these classes, please refer to the Style Guide section below.

Both models are shown below.

Figure 19 – The Assertion Statement Topics

Figure 20 – The EvaluationResult Statement Topics

The CIMI Adverse Event Pattern (Experimental)

The CIMI adverse event model is currently under development with the participation of the Hl7 Patient Care Working Group and consists of six patterns:

  1. ReportableEventEntry represents an information entry for the reporting of adverse events. It references an entry in the patient record (AdverseEventEntry)
  2. AdverseEventEntry represents an entry in a patient record documenting an adverse event.
  3. ReportedActivity is used to report an activity believed to be either temporally or causally associated to an adverse event.
  4. WorkflowBreachAdverseEvent is a specialization of ReportedActivity for the documentation of activities that represent undesirable or unexpected deviations from normal workflow and which may be associated with zero (near miss) or more adverse outcomes. Such entries are valuable for process improvement and for medical-legal reasons.
  5. AdverseFindingAdverseEvent is an adverse event entry that focuses on an untoward clinical finding and which can optionally be tied to a ReportedActivity.
  6. ClinicalStudyAdverseFinding is a special case of AdverseFindingReportEntry in the context of a clinical study where the adverse finding may or may not be caused by the study intervention.

Figure 21 – The AdverseEventReporting Statement Topics

The CIMI Adverse Reaction Pattern

The CIMI Adverse Reaction pattern is an untoward clinical assertion resulting from the exposure to a substance such as a rash or anaphylactic shock. It way be immune-based such as an allergic response to a medication or the result of some non-immune-based intolerance to a substance. Adverse reactions often expose underlying adverse sensitivities to substances such as allergies or intolerance.

Figure 22 – The AdverseReaction Statement Topics

The CIMI AdverseSensitivityToSubstance Pattern

This pattern is used to model allergies or intolerances to one or more substances.

Figure 23 – The AdverseSensitivityToSubstance Statement Topics

The CIMI Procedure Pattern

The ProcedureTopic hierarchy defines Act clinical statement topics. Some proposed specializations including LaboratoryProcedure, ImagingProcedure, SpecimenCollection, and SurgicalProcedure are presented here though these models are still incomplete at this time but serve as examples of clinical statements about actions and the expression of ‘negation’ patterns in CIMI (e.g., ProcedureNotPerformed is composed of the Procedure statement topic and the NonPerformance statement context).

The ModifyTargetAction topic is used when an action statement modifies another action statement. For instance, a request may be made to cancel an order or to discontinue the current administration of a medication.

Figure 24 - Procedure Topics

The CIMI Encounter Pattern (Experimental)

The CIMI Encounter package introduces the following four ProcedureTopic patterns:

  1. Admission
  2. Discharge
  3. Transfer
  4. Referral

It also introduces the Encounter class which is a  specialization of InformationEntry.

Figure 25 - Encounter-Related Topics

CIMI Pharmacy Patterns

The CIMI Pharmacy Patterns is currently under development in collaboration with the HL7 Pharmacy Working Group. It supports the expression of medication-related clinical statements such as medication administration, medication dispense, medication request, and medication statement.

Figure 26 - Pharmacy-Related Topics

CIMI Patient Education Pattern

The CIMI Patient Education pattern consists of two classes:

  1. PatientRelatedEducation is the statement topic for Patient Education clinical statements.
  2. PatientEducationPerformed is the performance context for patient education activities. Other patient education contexts will be introduced over time.

Figure 27 - Patient Education Topics

CIMI Entities

Cimi entities represent material entities such as substances, medications, devices, or people as well as non-material entities such as organizations. Entities may be actors in participations. Entities and their related structures are shown below:

Figure 28 – The Entity Hierarchy Excluding Location

Figure 29 – The Location Hierarchy

Common CIMI Data Structures

Common CIMI Data Structures are reusable components shared by a number of other classes. They are used to define component structures necessary in the construction of CIMI patterns. Examples include structures such as timing structures, Anatomical Location, Reference Range, and so on. For more information on these structures, please refer to the diagrams below and to the CIMI Logical Model Specification.

Figure 30 - Other Data Structures

Figure 31 - Timing Structures

Association Classes

Association classes allow the qualification of relationships and are useful when a relationship between a source and one or more InformationEntry targets specifies additional attributes. The Association Class pattern is illustrated below:

Figure 32 - Party and Related Structures

12)  An Introduction to CIMI Archetype Hierarchies

Note to readers: this submission does not include an archetype library as the CIMI reference model upon which such library is based is still currently evolving. The material presented below is intended to describe CIMI’s use of archetypes to define detailed clinical models from underlying reference model patterns. Descriptions of the actual archetype hierarchies defined in CIMI will be postponed to the May 2018 ballot cycle.

Cimi archetypes include complete “detailed clinical models” fit for use as well as their ancestors in a hierarchy of constraints. At the top of this hierarchy are CIMI top-level archetypes from which all downstream CIMI archetypes are derived.

CIMI Top-Level archetypes introduce the following constraints:

Each archetype in a hierarchy is by definition consistent with all its ancestors.

Top Level Value Set Constraints

Top level archetypes often constrain the range of coded attributes by binding them to intentionally defined value sets. For instance, the top-level archetype on the StatementContext pattern constrains its context attribute to the intentional value set resulting from the expression < 288529006 |Context values (qualifier value)|. Any specialization of this archetype must define value set constraints on the context attribute consistent with this intentional definition. That is, all downstream value set constraints must be subsets of the value set expansion that result from the evaluation of the above expression. The top-level archetype on the ActionContext pattern specifies the following constraint on the context attribute: < 288532009 |Context values for actions (qualifier value)|. The specified constraint is valid because the concept 288532009 is properly subsumed by the concept 288529006. In turn, the specialization proposal of ActionContext further constrains the attribute context to the following expression: = 385642001 |Under consideration (qualifier value)| (i.e., a value set consisting of a single code). This too is a valid constraint since this one-code value set is subsumed by all parent value sets defined above it.

This is illustrated below:

Figure 40 - Progressive applications of Attribute Range Constraints

Archetypes constraining attribute types

The CIMI EvaluationResult Statement Topic pattern specifies the result of an evaluation has as its type the abstract class DataType. Doing so enables modelers to constrain the type of the EvaluationResult.result attribute into any valid specialization of DataType. Such an archetype pattern allows modelers to define families of models entirely within the archetype layer of the CIMI model such as a QuantitativePhysicalEvaluationResult archetype which constrains the result attribute to a Quantity type (a valid subtype of DataType). Similarly, modelers may wish to create a CodedPhysicalEvaluationResult which constrains the result attribute of EvaluationResult (or any of its reference model specializations) to a Concept. Further archetype specializations can be defined. Note a subtype cannot relax a parent constraint. For instance, an archetype specialization of CodedPhysicalEvaluationResult cannot set the type of the result attribute as DataType since DataType is the supertype of Concept and such a constraint would loosen rather than tighten the parent constraint. This is illustrated below:


Figure 41 - Progressive applications of Attribute Type Constraints

Archetypes as templates

As described earlier in this document, the ClinicalStatement reference model pattern is one of the core patterns of the CIMI model. However, the ClinicalStatement (including its two specializations IndivisibleClinicalStatement and CompoundClinicalStatement) pattern only becomes meaningful through the archetype patterns derived from it.

The StatementTopic, StatementContext, and ClinicalStatement classes serve as the reference model patterns for three top level archetype hierarchies:

  1. The StatementTopic archetype hierarchy is the parent hierarchy for all clinical statement topic archetypes such as the Procedure, Assertion, and EvaluationResult archetypes. Each archetype in this hierarchy further constrains the StatementTopic reference model pattern.
  2. The StatementContext Archetype hierarchy is the parent hierarchy for all clinical statement context. Much like the statement topic hierarchy, the statement context archetype hierarchy defines the set of statement context archetypes such as the Performance, NonPerformance, Order, Plan, Proposal, Absent, and KnownOrSuspectedPresent context archetypes which specialize the more general top-level StatementContext archetype.
  3. The ClinicalStatement archetype hierarchy lays out the compositional framework for the definition of specific clinical statements through the inclusion of the correct specialization of the statement topic and statement context archetypes. For instance, while an archetype on the ClinicalStatement pattern states that the topic must be constrained to be an archetype on the StatementTopic pattern and the context must be an archetype on the StatementContext pattern, a specialization of the ClinicalStatement archetype, such as ProcedureProposal, for instance, may constrain the parent ClinicalStatement archetype pattern by specifying that the topic must be Procedure (a valid specialization of the StatementTopic pattern) and the context must be the Proposal archetype (a valid specialization of the StatementContext pattern). Hence, rather than defining ClinicalStatement specializations in the reference model, all specializations are defined as constraints on the parent ClinicalStatement archetype within the archetype layer of the model.

This approach is illustrated below:

Figure 42 - The Clinical Statement-Statement Topic-Statement Context Pattern

The act_statement archetype definition is shown below:

IndivisibleClinicalStatement[id1.1.1] matches {

  topic matches {

        use_archetype Act [id4.0.1,



  context matches {

        use_archetype ActionContext [id5.0.1,




HL7 Cross-Paradigm Specification: CIMI Logical Models, Release 1 (PI ID: 1253)         Page

January 2018 Ballot        © 2018 Health Level Seven International.  All rights reserved.

[1] http://www.openehr.org/releases/AM/latest/docs/AOM2/AOM2.html

[2] http://www.openehr.org/releases/AM/latest/docs/ADL2/ADL2.html

[3] http://www.omg.org/spec/AML/

[4] http://www.openehr.org/releases/BASE/latest/docs/bmm/bmm.html

[5] http://www.openehr.org/releases/AM/latest/docs/ADL2/ADL2.html

[6] https://confluence.ihtsdotools.org/display/DOCEG