The Core Reference Model contains the following packages:
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.
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'
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:
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).
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
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:
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)
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.
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.
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.
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