A Fast Overview of the CIMI Model

The CIMI Reference Model Modules

The CIMI Reference Model consists of the following three modules:

1. : The CIMI Core Reference Model
2. : The CIMI Foundation Reference Model
3. : The CIMI Clinical Reference Model

The Core Reference Model contains the following packages:

1. Core: Core introduces the LOCATABLE class, the parent type for most CIMI classes. It also introduces ASSOCIATION_CLASS the abstract parent for all CIMI Association classes.
2. Primitive Types: Primitive_Types introduces the CIMI primitive types and two generic container types - Array (which may eventually be deprecated in CIMI) and List. All primitive types derive from the type 'Any'
3. Data Value Types: Data_Value_Types introduces the CIMI complex types. Note that CIMI complex types do not exactly coincide with FHIR types as some CIMI complex types are defined further down in the CIMI inheritance hierarchy under the CLUSTER type (e.g., Address). All data value types derive from the type DATA_VALUE. The CIMI Data Value type hierarchy is important when used for both type inferencing and within constraints intended to be tighted in children archetypes (equivalent to a UML redefine on a type). For instance, if a class attribute in the reference model is of type TEXT, archetypes may further constrain TEXT to either CODED_TEXT or PLAIN_TEXT depending on model requirements.

The Foundation Reference Model contains the following packages:

1. Foundation: The Foundation package introduces three very important specializations of the LOCATABLE class, which form the top three CIMI Clinical Reference Model hierarchies:
   • COMPOSITION - a class representing a document such as a patient record or a knowledge document. Compositions are composed of document content entries.
   • CONTENT - a class representing the content of a document. Content may either be a SECTION which supports nested content or an ENTRY. CIMI Clinical Statements are types of ENTRYs and they are thus first level document content items.
   • CLUSTER - a class representing a data structure which is not a first level entry in a composition. What this means is that document entries can reference cluster specializations but CLUSTER types cannot be entered into a record as a first level document entry. For instance, a document may contain an address but the address must first be referenced by an entity (e.g., a person) associated with a clinical statement - a type of ENTRY and specialization of CONTENT - (e.g., subject of information).
2. Party: The Party package introduces the PARTICIPATION class used in CIMI to represent the participation of actors (ACTOR) acting in a specific capacity (ROLE) in the performance of an activity. PARTY_RELATIONSHIP relates one PARTY (ACTOR/ROLE) to another.

The Clinical Reference Model contains a number of packages and classes that make up the CIMI Reference Model. The packages are not listed in this overview but are accessible from this tool under the package viewer (top-left frame of this documentation).

The CIMI Clinical Statement Pattern

The CIMI Clinical Statement is the main unit of clinical information in the CIMI model and the only specialization of ENTRY defined in the CIMI Clinical Reference Model at this time. Most of the other classes in CIMI are data structures that descend from CLUSTER and are referenced either directly or indirectly by the CIMI Clinical Statement classes

The Clinical Statement Pattern is a compositional pattern whereby the information that makes up a clinical statement is composed through the assembly of several classes. They are described below:

• The statement topic class contains attributes relevant to the topic of the clinical statement. Statement topics may be acts such as clinical procedures, findings such as patient conditions, or events such as natural disaster events. Note that the topic hierarchies follow the SNOMED hierarchies of Finding, Procedure, and Event.
• The statement context class contains attributes relevant to 'mood' of the topic. For instance, a 'Procedure' topic, when combined with a 'Performed' context indicates that the statement is about a procedure that has been performed. If the 'Proposal' context were selected instead, the statement would be about a proposed procedure such as a procedure proposed by a clinical decision support system. Similarly, a finding such as Diabetes may be associated with a context of 'Absent' or 'Known Present'.
• The Attribution class provides detailed information about activities relevant to the Clinical Statement class such as the authoring, verification, signing, and recording of a clinical statement.
• The SubjectOfInformation attribute is a type of participation and represents the subject of the statement which may or may not be the subject of the record (i.e., the subject of the composition).

The clinical statement pattern aligns with the SNOMED-CT Situation with Explicit Context Concept Model. Thus, clinical statements are examples of SNOMED-CT situations with explicit context. It is important to note that the association of a statement topic with a statement context in the Clinical Statement Pattern occurs at the level of the Archetype in the form of typing constraints. For instance, a ProcedureProposalStatement is a Clinical Statement where the topic is equal to Procedure (a specialization of StatementTopic) and the context is equal to Proposal (a specialization of StatementContext). Such constraints are specified in archetypes using the Archetype Definition Language (ADL).

Adding Constraints to Reference Model Patterns to Form Detailed Clinical Models

A single reference model class or related classes (often referred to as a reference model pattern) can be used to define a family of detailed clinical models through the progressive application of constraints. For instance, the Clinical Statement Pattern, the Statement Topic pattern, and the Statement Context Pattern can be constrained in ADL to form a large number of detailed clinical models representing laboratory test results. A simplified version of the process is described:

1. The LaboratoryTestResult class, a specialization of StatementTopic in the CIMI Reference model is used as a starting point. It specifies an attribute called 'result' of type 'DATA_VALUE' (the supertype of all CIMI Complex Types)
2. An archetype is developed to restrict the 'result' attribute type to 'QUANTITY'. It is called QuantitativeLaboratoryTestResult. This archetype is the parent archetype for a large number of quantitative laboratory test results. Other archetypes may be developed for other result types such as CODED_TEXT or COUNT if needed.
3. Another archetype is then developed from the QuantitativeLaboratoryTestResult archetype which constraints the value set bindings for all relevant coded fields in the archetype to values consistent with a hematocrit measurement. Such constraints may be applied directly to the QuantitativeLaboratoryTestResult or progressively. The progressive application of constraints allows the definition of subsets or families of detailed clinical models all sharing a base set of common constraints.
4. Starting from the SuspectedOrKnownPresent StatementContext specialization, an archetype is developed that constrains the 'context' attribute to the SNOMED-CT context value code of 'Known Present'. The archetype is then named KnownPresentContext. This archetype may be reused for any laboratory test result.
5. An archetype is developed on the IndivisibleClinicalStatement pattern called HematocritLaboratoryTestResultStmt which constrains the topic to the Hematocrit archetype defined above for the StatementTopic class and the statement context to the KnownPresentContext archetype.

The archetype development and application process is illustrated below:

Archetype hierarchies define families of detailed clinical models with higher level archetypes defining sets that subsume the sets defined by lower level archetypes.