The CIMI Style Guide        4

Modelling Style        4

Quality Criteria        4

Scope of Clinical Models        5

Model Granularity, Reuse, and Composition        5

Iso-semantic Models        6

Terminology Binding        7

Terminology Binding Guidelines        8

Semantic Model Binding        9

Semantic Model Range Binding        9

Value Set Binding        9

Modelling Layers        9

Topic Patterns        11

Assertion        11

Assertion Subtypes        12

Assertions        12

Finding Site Assertion        12

Evaluation Result        13

Evaluation Subtypes        15

Laboratory Test Result        15

Physical Evaluation Result        15

Procedures        17

The CIMI Style Guide

The purpose of the CIMI style guide is to provide guidance to clinical modelers on the use of the CIMI model to represent clinical information. The CIMI style guide documents preferred modeling styles and conventions, approaches to terminology bindings, and describes the usage of the key patterns to address important clinical use cases (e.g., how to model a panel or problem list in CIMI). Please note for the May 2017 ballot cycle, we are primarily focusing on the core reference model, the clinical reference model, and three patterns of clinical models: evaluation, assertions, and procedures, and related archetypes.

Modelling Style

In this section, we provide a brief introduction to the following CIMI modelling principles:

• Quality criteria
• Scope of clinical models
• Model Granularity, Reuse, and Composition
• Iso-semantic models
• Terminology Binding
• General principles

Quality Criteria

The following quality criteria have been proposed for all CIMI models:

CIMI models:

• Shall satisfy the URU principles – that is, they will be

• Understandable (cohesive and coherently expressed)
• Reproducible, Reliable, and Reusable (consistency)
• Useful (fit for purpose)
• Up-to-date (currency)

• Shall be clinically accurate
• Shall be clinically valid, as demonstrated by prior or concurrent use
• Shall be evidence-based, as demonstrated by peer reviewed studies
• Shall be adequate to express required clinical statements
• Shall maintain contextual integrity (when transformed into iso-semantic models) (ditto)
• Shall maintain semantic fidelity (when transformed into iso-semantic models) (ditto)
• Shall be clear and precise, minimizing the potential for:

• Misinterpretation
• Misuse or inconsistency in use

• Shall be suitable for easy implementation and avoid cognitive overload of users
• Shall be developed with robust versioning and review controls

These criteria will be assessed through clinical and technical reviews and through pilot implementations.

Scope of Clinical Models

The following principles have been proposed to assist in determining the inclusion or exclusion of information within a CIMI clinical model

The following information will be included in CIMI clinical models:

• Information considered to be directly relevant to the clinical concept being modelled
• Information describing the who, what, when, where, and how of the clinical concept being modelled
• Information represented using either pre-coordination or post-coordinated in the structure – for example, the body location of a diagnosis
• Information not described in the exclusion list below
• Information necessary to determine computable bindings and nominal ranges within standardized clinical terminologies, where appropriate
• Information necessary to determine computable meanings and units of measure for non- terminological elements, where appropriate

The following information will be excluded from CIMI clinical models:

• Information specific to an implementation use-case - for example, recordkeeping metadata  (unless the model is specifically designed for this purpose)
• Information used for administrative purposes only – e.g. financial details (unless the model is specifically designed to include such information)
• Information specific to a local environment (e.g. to satisfy local legislation requirements)
• Information considered not to be directly related to the clinical concept being modelled
• Information better captured in terminologies and ontologies such as the classification of a medication in a medication hierarchy or concept definitional expressions

Model Granularity, Reuse, and Composition

The granularity of the CIMI model is defined in several layers. The Core Reference Model specifies the primitive and complex types. The Foundational Reference Model defines the foundational constructs from which all clinical patterns are derived. The Clinical Reference Model defines the specializations of the foundational construct relevant in the clinical domain. Archetypes then constrain these structures to define families of objects that differ purely on the constraints they apply to underlying patterns.  In a good design, archetype constraints are applied progressively in order to ensure greater consistency at the leaf-level archetypes through the progressive tightening of constraints.

The CIMI model takes a compositional design approach where structures originating from different hierarchies are assembled to form the final product. The Clinical Statement pattern described in the architectural section is an example. The Object Oriented modeling principles of cohesion and coupling apply. Component structures are designed to maximize cohesion and loose coupling. Such an approach enhances consistency, ease of use, ease of maintenance, extensibility, and ease of archetype development through reuse.

Composition should be favored when:

• Specializations would require multi-inheritance or mixins - a ProcedureProposal has both Procedure and Proposal components
• The components can be reused - a ProcedureProposal and a MedicationProposal both share the proposal attributes
• The components favor cohesion and loose coupling - a statement context is a structure that aligns with the context of SNOMED-CT Situation with Explicit Context and cleanly wraps its attributes into a single class that can be reused consistently in different use cases
• The components are not foreign to the clinical modelers who use them to assemble their models
• The patterns defined by these more granular components are understandable to clinical modelers. For instance, it is considered to be good clinical practice for instances of these data items to be observed, evaluated or performed together using the same who, what, when, where, and how information. For example, systolic and diastolic blood pressures may be included together within a single ‘Blood Pressure’ evaluation panel.

Iso-semantic Models

The CIMI Working Group recognizes it is unlikely a one-size-fits-all approach will accommodate the wide variety of clinical and implementation use cases. As such, the CIMI architecture supports alternate representations of the same model to address the requirements of specific use cases. While, generally, such variations in expressivity are not recommended (CIMI defines a ‘preferred’ set of models), it is sometimes inevitable.  For instance, interface models may have different modeling requirements than persisted models or logical models.

The CIMI architecture should thus support the definition of iso-semantic models, sets of semantically equivalent models differing primarily in their structure and terminology pre-coordination.

CIMI also intends to support the ability to transform models into their iso-semantic counterparts. In particular, CIMI aims to support:

• The ability to transform CIMI models to/from iso-semantic representations in other languages/standards (e.g. CDA, openEHR, ISO13606, DCM, CEM), through a common logical model intermediary
• The ability to transform CIMI models between iso-semantic representations using a different split between terminology pre-coordination and structure
• The ability to transform models into physical representations that can become the basis for system implementations that better support record exchange and computability.

Once identified, iso-semantic model sets will be defined by the following:

• A “preferred” model providing the most fully articulated representation of the information
• Associated models with identical semantics but different structures
• Formal rules for transforming the associated model features into the preferred model features; e.g.,

• Turning a pre-coordinated concept (e.g., suspected Lyme disease) into a set of explicitly bound attributes(Lyme disease + suspected)
• Turning a concept binding (sphygmomanometer) into an associated class characterized by that binding (device + type = sphygmomanometer)

Iso-semantic models can be defined in:

1. The reference model - Such models typically differ in their core structure
2. The archetype layer - Such models typically differ in the constraints they apply to an underlying structure that supports some variability (typically through a design by constraints modeling approach)

Iso-semantic models varying in their degree of pre-coordination can generally be addressed at the archetype layer through attribute occurrence constraints. For instance, the FindingSiteAssertion reference model pattern specifies two attributes: a bodyLocation and a bodyLocationPrecoord. Two iso-semantic models can be derived - one obtained by constraining out bodyLocation and using a pre-coordinated term for the body location. Another variant of the same model may constrain out bodyLocationPrecoord and post-coordinate the body location in the model.

Iso-semantic reference model classes can be introduced using reference module extensions but this use case will not be described in this document.

Terminology Binding

Terminology binding refers to “the assertion of a relationship between the information model and the terminology” [CIMI Glossary]. This binding involves attaching terminology concepts, reference sets or expressions to a node or link in an information model.

There are four main use cases motivating terminology binding to CIMI models:

1. To support the management and quality control of clinical model libraries, including:

1. Searching model libraries (using the meaning of the models and their contents)
2. Identifying semantic overlap between models
3. Identifying inconsistency of model interdependencies (e.g. the meaning of a constrained archetype is not subsumed by the meaning of the base archetype)

2. To determine the iso-semanticity of two or more instances of models that are semantically equivalent, but structurally different; and to be able to transform between these iso-semantic representations, including:

1. Models using a different level of pre-coordination versus structure
2. Models making different modelling design choices (e.g. Representing a laboratory test method as a data element, versus a CLUSTER containing data elements)

3. To enable querying over data instances of iso-semantic model representations (as described above)
4. To support data validation and semantic interoperability (e.g. exchanging data between systems that use different native information structures)

1. By confirming instance data conforms to the semantic specification
2. By supporting the construction of valid description logics for instance classification and application of decision support and other analytic tools

It is proposed these use cases be met by the fulfilment of the following requirements:

1. A standard, reproducible methodology for defining the meaning of each node in the model using an association with a terminology
2. A standard, reproducible methodology for defining the valid set of values of each coded data element in the model (either explicitly or as a constraint expression)
3.  A standard, reproducible methodology for establishing semantic relationships between nodes in the same model, such as through SNOMED-CT Template syntax
4. Terminology bindings allowing the values to be represented in a way agnostic to the degree of pre-coordination versus structure
5. Terminology bindings enabling the transformation between iso-semantic representations of the same model
6. Terminology bindings allowing consistency to be checked within models and between models related by specialisation or slot filling

Terminology Binding Guidelines

All finalised CIMI Clinical Models shall:

• Include a semantic “concept binding” for each data element in the model to a terminology concept (expression or pattern) which represents the meaning of the data element
• Include a “value binding” from each node of type CODED_TEXT to a terminology reference set indicating the valid values for the node – either defined intentionally using a constraint expression, or extensionally as a list of terminology components

All finalised CIMI Clinical Models may (where appropriate):

• Include a constructor binding on appropriate container-type nodes (e.g. ENTRY, CLUSTER) in the form of a terminology expression to help determine its iso-semanticity with other model representations

Semantic Model Binding

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. CIMI is designed to align closely with the SNOMED CT Concept Model with particular influence from the Situation with Explicit Context expression semantics. If the CIMI attribute aligns with the SNOMED CT concept model, attributes will be bound to descendants of Concept model  attribute ID 410662002 | Concept model attribute (note, children of Unapproved attribute (attribute) ID 408739003 should not be used). If there is no attribute binding (e.g. temporal attributes such as “start time”) then CIMI will use descendents from the “observable entity” domain if an equivalence exists.

To support terminology bindings to SNOMED CT components not available in the international release, CIMI will develop a SNOMED CT extension in the CIMI Namespace (namespace id: 1000160). This namespace has been allocated and registered by the SNOMED International.

Semantic Model Range Binding

Value bindings will use SNOMED CT wherever possible – however, where the values are outside the scope of SNOMED CT, other terminologies (e.g. LOINC answers) may be selected (on a case-by-case basis).

When a data element is further refined as a specialization (e.g. skin assessment site is a body location), the value set range must come from the range of the parent data element (e.g. skin assessment site is a subtype of body location).

Value Set Binding

Work is currently being done within the HL7 Vocabulary work-group to define terminology binding semantics that remain valid across multiple implementation domains (V2, V3, C-CDA, FHIR and CIMI).  CIMI is an active participant in these efforts and it is our intent to align CIMI Value Set bindings as closely as possible to this effort.

Modelling Layers

In order to ensure consistency among models, all CIMI clinical models will be based on one or more predefined reference model patterns (top row in table) and corresponding top level archetypes (lowest row in table). These modelling patterns are shown below. The first-layer of Clinical Models, developed based on these modelling patterns, will (wherever possible) be free of specific use-case context, specialty context, care-setting context and implementation-purpose context. Additional levels of context will be added progressively, to enable a maximum level of reuse and consistency between these context-dependent models.

Figure 1: CIMI Modelling Layers

Topic Patterns

The topic patterns CIMI has developed to date include EvaluationResult, Assertion, and Procedure. They are described below. Future patterns discussed in this guide will include  medication administration, encounter, etc. These patterns provide the foundational structure for detailed clinical model archetype instances. The archetype instances can be visualized at models.opencimi.org.

Assertion

The Assertion Pattern is used to represent a clinical finding. Assertions may:

• assert the presence (or absence) of a condition in a patient, for example:

• ChestPainAssertion asserts the presence of chest pain
• ChestPainAbsenceAssertion asserts the absence of chest pain
• EdemaAssertion asserts the presence of edema

The assertion pattern is as follows:

• Key = a code meaning “assertion”
• Code = a code representing what’s being asserted (“rash”, “auto accident”, “hypertrophy”, etc.)

Another pattern that could have been selected is an isosemantic EvaluationResult:

• Key = a code meaning EvaluationResult
• Code = what’s being evaluated (“rash”, “auto accident”, “hypertrophy”, etc.)
• Result  = “present” or “yes”

The rationale for selecting the first pattern is twofold:

1. It was judged to be most consistent with the semantics of terminologies informing CIMI semantics.   The “key” and “name” form a “question”/”answer” or “test”/”result” pair.  In cases of measurements this is more obvious.  For example, in a heart rate measurement model the “key” or “test” is “heart rate measurement” (or the question is “what is the heart rate measurement?”) and the “result” captures “60 bpm”, “70 bpm”, etc. (the answer, or result).  Given this, in the first pattern the “key” is “assertion” (or the “question” is “what is being asserted?”) and the “Code” holds the “result”/”answer” (the thing being asserted).
2. In the second pattern, if the key is “EvaluationResult”, the Code is “rash”  and Result is “present’ then the meaning of the Code (to fit the “question”/”answer” or “test”/”result” paradigm) is actually “evaluation of whether there is a rash” not “rash” as a condition in the patient.  The latter, however, is the meaning of the concept in a terminology such as SNOMED CT.  In contrast, in the first pattern the code populating “result” is consistent with the SNOMED meaning.  Thus, the first pattern and not the second facilitates mappings to standards. The problem here, the result is either “present” or “absent” and in CIMI, presence and absence is modeled using the context class in alignment with the SNOMED CT Situation With Explicit Context.

The pattern followed the conclusions of the HL7 TermInfo effort.  The HL7 TermInfo project^[1] sought to specify guidelines for using SNOMED CT concepts within the HL7 Reference Information Model.  The group followed the reasoning of 1) above.  Hence, using the first pattern aligns the CIMI pattern with the TermInfo effort.

Assertion Subtypes

There are two BaseAssertion subtypes: Assertion and its subtype, FindingSiteAssertion. Note that the reference model introduces two additional subtypes of BaseAssertion: DeviceAssertion and RiskAssertion but these models are not fully defined at this time.

Assertions

Assertions affirm the existence of clinical conditions, diseases, symptoms, etc. in the patient.   A specific Assertion extends BaseAssertion with any additional qualifiers necessary for the specific data element.  It also constrains the name code of Assertion to a code representing the condition or disease being asserted.  Table 2 shows the example of WoundAssertion.  Other examples are CoughAssertion, NauseaAssertion, and DiabetesMellitusTypeOneAssertion, etc.

The following table provides examples of correctly modeled assertions:

Table 1: Assertion Examples

Finding Site Assertion

A FindingSiteAssertion is an assertion about a finding found on the body. This assertion is a “design by extension” assertion because it contains the additional properties of findingSite and findingSitePrecoordinated which are used to capture the body site affected by the condition.

The FindingSiteAssertion encourages post-coordination. The example below illustrates FindingSiteAssertions. The model intentionally aligns with the SNOMED CT Clinical Findings concept model.

Table 2: Finding Site Assertion Examples

Evaluation Result

An evaluationResult model is a model documenting a characteristic of a patient or a patient-related clinical-value based on a characteristic of the system being observed. An evaluation result may hold the name of a “test” in the key property (e.g., “heart rate evaluation”, “serum glucose lab test”, etc.) and the test result value in the “result” property.  Viewed another way, the evaluation result key holds a "question" (e.g., "what is the heart rate?", "what is the serum glucose?") and the “result” holds the answer. Any archetype (a laboratory test, a vital sign, a questionnaire question, etc.) that fits this pattern of a name and a value is modelled with the EvaluationResult pattern.

EvaluationResults can be further constrained to define families of detailed clinical models that share common structural characteristics. For instance, the result attribute of the EvaluationResult model can be constrained at the archetype level to QUANTITY, or CODED_TEXT, for instance, thus defining families of DCMs whose results are quantitative and nominal, respectively. The QUANTITY data type consists primarily of a numeric (real) value and a unit of measure.  The unit of measure is captured by a code. QUANTITY evaluations are often constrained to a valid “unit of measurement” value set (e.g., “length units of measure”, “mass units of measure”, etc.).  The graphic below is a mindmap of the quantitative physical evaluation result.

Figure 2: Quantitative Physical Evaluation Result

The ORDINAL data type consists primarily of a code with an inherent ordering within a set of codes.  An example of an ORDINAL component is “severity”.  The value set for severity includes codes for “mild”, “moderate”, and “severe”.  The codes would have properties or relationships that capture the ordering among them, i.e., “mild” < “moderate” < “severe”.

Coded Text is used when the answer is drawn from a set of coded values. Hair color, urine description, cardiac rhythm, and cervical consistency are examples.  In each case, the coded values are adjectives describing the property.

Most archetypes constraining EvaluationResult will specify an observable code for the characteristic to be evaluated (blood glucose, skin moisture, etc.) in the key property and the appropriate range of answers for that characteristic’s result value, whether a set of  coded concepts, a quantitative dimension, or some other type. They may also further constrain other properties (body site, specimen), and they may introduce subordinate evaluations (e.g., exercise state).

When using the EvaluationResult pattern it is important to note it does not represent the procedure used to obtain the result. CIMI delineates the act from the description of the state uncovered by the act. The act of evaluating or assessing is captured by the Procedure pattern.

At least three use cases exist pertaining to use of the EvaluationResult pattern (for example, the capture of the result of a heart rate evaluation).  

1. The most common use case is to capture the results of the evaluation and retrieve them for display, calculations, trending, decision support, etc.  In this case, documenting the process of capturing the value may or may not be important and if relevant, it would be captured using the Procedure pattern (e.g., through the ProcedurePerformed clinical statement archetype).
2. In certain circumstances, the desire might be just to document a heart rate evaluation was performed – regardless of the value of the resulting evaluation. In this case the Procedure pattern is used.  For example, a protocol may dictate heart rate evaluations be taken according to a time schedule, and an application monitoring protocol compliance may query to ensure that the evaluations were taken.  In this case, the evaluation values are inconsequential.  Note, in this case one may query for evaluation procedures matching the given criteria or for any evaluation result indicating the procedure was performed in cases when the evaluation procedure is not recorded. However, it is very important to note the absence of evaluation results does not necessarily indicate a procedure was not performed.
3. Finally, in certain circumstances it might be desirable to explicitly document a heart rate evaluation was not performed.  Again, an example may be a protocol requires heart rate evaluations be taken; users need a way to note exceptions to the protocol and monitors of the protocol need a way to detect the exceptions. In these cases, one should document this fact using a clinical statement such as ProcedureNotPerformed which combines the Procedure topic with the NonPerformance context.

Evaluation Subtypes

Laboratory Test Result

A LaboratoryTestResult archetype contains properties specific to the lab evaluation process. These may include information about the physical process (e.g., specimen) as well as process management information (e.g., status).

Physical Evaluation Result

A PhysicalEvaluationResult archetype contains properties specific to the clinical evaluation process. These include information about the physical examination process (e.g., patient position, body site).

Table 3: Physical Evaluation Examples

Guideline: Assertion versus Evaluation

In most cases, the decision between using the evaluation result pattern and the assertion pattern is intuitive and straightforward.  “Urine color”, for example, is clearly best modeled as an evaluation – the property being evaluated is the color of the patient’s urine and the value (data) of the evaluation is the set of codes representing the colors that may be observed.   To model urine color as an assertion would require the creation of a large number of pre-coordinated concepts – the key would be “assertion” and data would be populated by a set of codes such as “amber urine” (meaning “the patient has amber urine”), “clear urine”, etc.

However, this highlights any evaluation model may be transformed into an assertion model.  (Conversely, any assertion model may be transformed into an evaluation model.)  In the case of urine color, the decision is intuitive.  But in other cases, the decision is less clear.

For example, “heart rhythms” (bradycardic, tachycardic, etc.) may be modeled as multiple assertion models (bradycardia, tachycardia, etc.) or as a “heart rhythms” evaluation model whose data is constrained to a value set (containing “bradycardic”, “tachycardic”, etc.).

The general guideline is if it is most natural to think of the data element as a noun – as a condition or state that exists in the patient – model as an assertion or set of assertions.  If the statement about the patient is most naturally thought of as a name/value pair (i.e., a noun representing the property and an adjective representing the value), such as “hair color” = (“black”, “brown”, “blonde”), then model it as an evaluation. However, it is important to note both styles are allowed and the true determinant of their use is whether a result for a given criteria other than true/false, present/absent is specified.

This discussion highlights the importance of iso-semantic models. Even if one model or set of models can be agreed upon for the storage model (e.g., assertion models for “bradycardia” and “tachycardia” instead of an evaluation model with “bradycardic” and “tachycardic” as values), inevitably there will be use cases (data entry, messaging, reporting, etc.) for the other model and a need to identify cases where different modeling patterns describe semantically identical phenomena: these patterns are iso-semantic.  An essential (as of now unfulfilled) requirement is for a mechanism of identifying iso-semantic models, managing iso-semantic groups, and transforming between them.

It should be noted, the Assertion vs. Evaluation topic is solely concerned with the structure and schema pattern used to capture clinical information.  Choosing Assertion vs. Evaluation patterns has nothing to do with whether the information being captured is subjective vs. objective.  

Procedures

Procedure models are used to represent actions taken related to the care of a patient such as  peripheral IV placement, delivery of a warm blanket, dressing change, ambulation, patient education, etc.

The CIMI Procedure is a base class for a number of anticipated specializations such as surgical, imaging, and laboratory procedures.  The CIMI Procedure Model is aligned with the SNOMED CT Procedure Concept Model when such an alignment exists.

A number of clinical statement archetypes that reference Procedure as the topic of the statement have been introduced to illustrate (1) a proposal for a procedure, (2) the performance of a procedure, and (3) a procedure that has not been performed. Note these clinical statements are composed by the association of the appropriate context with the Procedure topic, namely, the Proposal, Performance, and NonPerformance statement contexts.

As the procedure reference models are still evolving, archetypes for procedures are yet to be modeled and will be described in the Sept. 2017 ballot.