HL7_XPARADIGM_CIMI_LM_R1_I1_2018JAN
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.
3) CIMI and Other HL7 Standards and Initiatives 6
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
The CIMI Core Reference Model Module 14
The CIMI Foundation Reference Model Module 19
The CIMI Clinical Reference Model Module 22
The CIMI Clinical Statement Pattern 23
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 Encounter Pattern (Experimental) 43
CIMI Patient Education Pattern 44
Common CIMI Data Structures 48
12) An Introduction to CIMI Archetype Hierarchies 50
Top Level Value Set Constraints 51
Archetypes constraining attribute types 52
Version | Date | Author | Amendment History |
0.1 | 2012-09-13 | Linda Bird | First draft for comment |
0.2 | 2012-10-26 | 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. | |||
0.3 | 2016-11-16 | Susan Matney | Draft for ballot comment |
0.4 | 2016-11-23 | Claude Nanjo | Integration of architectural sections |
0.5 | 2016-11-25 | Susan Matney | Edits |
0.6 | 2016-11-27 | Jay Lyle | Edits |
0.7 | 2016-11-29 | Claude Nanjo | Review of style guide section and edits |
0.8 | 2017-03-15 | Claude Nanjo | Review of comments and final updates to the documentation based on new artifacts. |
0.9 | 2017-03-22 | Claude Nanjo | Incorporating Patrick’s changes |
1.0 | 2017-07-26 | Claude Nanjo | Updates for September ballot. |
1.1 | 2017-07-27 | Joey Coyle | Updates to “An Introduction to CIMI Archetype Hierarchies” matching new reference model and adl. |
1.2 | 2017-07-28 | Lorraine Constable | Updates for September ballot - applying approved changes from May ballot. |
1.3 | 2017-07-28 | Claude Nanjo | Integrated most comments from May Ballot. |
1.4 | 2017-12-4 | Claude Nanjo | Updates for January submission |
Table 1: Version History
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.
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:
At a high level, the transformation of CIMI models into FHIR profiles can be achieved as follows:
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.
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.
CIMI Clinical Models are defined through two closely integrated OpenEHR syntaxes:
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:
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.
The following principles guide CIMI’s modelling approach:
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:
| Anatomical or acquired body structure | 442083009 (<<)
The CIMI model consists of structural patterns and the constraints applied on those patterns:
The CIMI model is persisted in a format conforming to two OpenEHR specifications:
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.
The CIMI Reference Model is a layered model designed to be modular and currently consists of three layers:
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.
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.
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.
The CIMI archetype hierarchies form the second part of the CIMI model. These hierarchies serve two primary purposes:
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:
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:
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.
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 introduces three core reference model hierarchies:
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 |
Boolean | Boolean | -- | boolean |
Real | Real | -- | decimal |
Byte | -- | byte | Byte |
Integer | Integer | -- | integer |
Character | Character | -- | -- |
String | String | -- | string |
URI | -- | anyUri | uri |
List<T> | -- | -- | -- |
Array<T> | -- | -- | -- |
Any (root type) | -- | -- | Element |
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.
Figure 4 - CIMI Primitive 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 |
Date | date | -- |
Time | time | -- |
DateTime | dateTime | -- |
Instant | instant | |
IntegerType | -- | Count |
UnsignedInteger | UnsignedInt | |
PositiveInteger | PositiveInt | |
Quantity | -- | Quantity |
Duration | -- | Duration |
IntervalValue<T> | -- | Period, Range |
PlainText | string | -- |
CodedText | -- | CodeableConcept |
Concept | Coding | |
CodeSystem | ||
UriType | uri | -- |
GpsLocation | -- | |
ParsableContent | Base64Binary, Markdown | -- |
Multimedia | -- | Attachment (partial match) |
OrdinalConcept | -- | -- |
Ratio<T> | -- | -- |
DataType (root type) | -- | Element |
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 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.
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
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
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
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 includes the classes and structural patterns derived from those classes upon which all CIMI archetypes are built.
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 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
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
The StatementTopic abstract class currently has three specializations:
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:
Figure 15 - ClinicalStatement Contexts
Figure 16 - Finding Contexts
Figure 17 - Action Contexts
StatementTopic and StatementContext have the following characteristics:
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:
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.
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:
Figure 18 - Provenance Patterns
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 model is currently under development with the participation of the Hl7 Patient Care Working Group and consists of six patterns:
Figure 21 – The AdverseEventReporting Statement Topics
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
This pattern is used to model allergies or intolerances to one or more substances.
Figure 23 – The AdverseSensitivityToSubstance Statement Topics
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 package introduces the following four ProcedureTopic patterns:
It also introduces the Encounter class which is a specialization of InformationEntry.
Figure 25 - Encounter-Related Topics
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
The CIMI Patient Education pattern consists of two classes:
Figure 27 - Patient Education Topics
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 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 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
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 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
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
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:
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,
CIMI-CORE-Act.act.v1]
}
context matches {
use_archetype ActionContext [id5.0.1,
CIMI-CORE-ActionContext.action_context.v1]
}
}
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
[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
