Proposed CIMI Reference Model
Notes to reviewers
This page has been put up to facilitate review but is a work in progress and is still highly preliminary. The goal of this page is to eventually display the full reference model in both UML and BMM format with an explanation of the model's component structures for broader consumption. Please note that not all parts of the model are currently displayed but they will soon be. Note that when I was developing this model, I had the following goals in mind:
- Extend the RM beyond its current state but minimize breaking changes
- Address the shortcomings identified during our last few CIMI calls
- Stay as faithful as possible to OpenEHR and ISO 13606 - It will make downstream harmonization easier and provide a solid rational for our modeling choices.
- Attempt to make the RM extensible for other needs such as CDS and CQI's desire to develop a logical model (RM + Archetypes) to support declarative and sharable CDS knowledge artifacts on top of the core foundation CIMI is putting in place. This may require loosening the semantics of ISO13606.
This is a first attempt to do so. In order to meet the above requirements, there is a departure on some of the naming conventions of OpenEHR and ISO 13606 as both of these models are centered around the clinical patient record. The goal of the renaming is to support a more general model but it was done in such a way as to not take away from what was already defined for CIMI. The flip side though is that some of the fleshing out will need to be done at the archetype level. However, despite this potential shortcoming, I feel this model offers the closest compromise and provides a solid foundation on which to build our archetypes. Please let me know your thoughts.
Introduction to Reference Model Components
The proposed Core CIMI Reference Model consists of the following components:
UML Representation of the CIMI Reference Model
Version as of July 13, 2016 23:35 am PT
Some important notes about this version of the model
- ISO 13606 'FOLDER' was introduced into the model but renamed to COMPOSITION_GROUP rather than FOLDER in order to relax some of the ISO 13606 semantics. In order to support some of the requirements of CDS Knowledge Artifacts, in particular, the nesting of inlineable order sets into other order sets for instance, we will need to support the potential grouping of COMPOSITIONS. Thomas also mentioned a very similar need for OpenCDS based on implementation experience. 'FOLDER' is a specialization of COMPOSITION_GROUP but was not added in the model since neither CIMI nor CDS/CQI have requested this at this time.
- COMPOSITION was added to support the ability to represent documents such as reports, knowledge artifacts, etc... which may have sections or other types of logical groupings.
- ENTRY_GROUP was added to the model as well. In ISO 13606, ENTRY_GROUP is called SECTION. This is too narrow of semantics for the broader use case so SECTION was made a specialization of ENTRY_GROUP with section semantics. Note that sections may have just a name or may have additional metadata. For instance, in order sets, sections support links to supporting evidence and selection behaviors expressed in CQL. This version of the model supports this need.
- ENTRY is very much like it is defined in ISO 13606 and OpenEHR except that for CDS/CQI we need to generalize it a bit to represent things other than clinical statements. Hence, to support the semantics of a clinical statement, a specialization of ENTRY has been added called CLINICAL_STATEMENT. This will be the parent type for the Clinical Statement hierarchy.
- ITEM_GROUP has been renamed to CLUSTER as requested.
- Three specializations of CLUSTER have been added to the model to support easier ADL constraining in archetypes:
- STATEMENT_BODY represents those CLUSTERs that contain the details of a CLINICAL_STATEMENT. This specialization is introduced in the reference model to support easier constraining within archetypes.
- INDIVISIBLE_STATEMENT_BODY is to be used for clinical statements that are indivisible (done via a constraint on CLINICAL_STATEMENT.body)
- COMPOSITE_STATEMENT_BODY is to be used for clinical statements that can have composite content. A clinical statement with composite content will contain multiple INDIVISIBLE_STATEMENT_BODY parts and could potentially have nested structures. PLEASE NOTE: A clinical statement with composite content is different from a clinical statement that contains other clinical statements. The latter use case is not supported in this reference model (see discussion below).
Four aggregation points and their different semantics:
- COMPOSITION_GROUP: This aggregation is primarily for the use case of folder nesting or more generally, the logical (and potentially nested) grouping of documents. COMPOSITION_GROUP should not be used to represent a 'Composite Clinical Statement'.
- COMPOSITION: This type of grouping supports the grouping of organized sub-content typically found in a document or as a unit of content to be checked into an EHR for instance. It also should not be used to represent composite clinical statements.
- ENTRY_GROUP allows the nesting of ENTRYs up to an arbitrary depth. One can think of the following use cases - Sections in order sets which can be nested (e.g., Medications/Beta-blockers) and which can group related orderables. As mentioned above, such sections may contain additional metadata and not simply a name (e.g., supporting evidence links, available resources, etc...). ENTRY_GROUP can also be used to group clinical statements that make up a problem list or aggregated observations coming from different devices, each of which may have its own provenance information, etc...
- INDIVISIBLE_STATEMENT_GROUP IS PART OF COMPOSITE_STATEMENT_GROUP: In this case, the aggregation is done within a single clinical statement. That is, the clinical statement may have an identifier, provenance information, and other clinical statement metadata that is shared by all items defined in its composite body. Please note that this is very different from an ENTRY_GROUP which may contain a collection of clinical statements, each with its own clinical statement metadata.
A note about Composite orderables, complex meds, and panels:
If a panel consisting of several analytes is resulted from a lab, most likely, all entries contained in the lab results statement will share the same clinical statement details. In this case, one should represent this panel with the CLINICAL_STATEMENT specialization of ENTRY and assign to the statement a COMPOSITE_STATEMENT_BODY. Each analyte is represented using an INDIVISIBLE_STATEMENT_BODY (assuming that each entry is indivisible) nested inside the COMPOSITE_STATEMENT_BODY. The collection of result is treated as a single clinical statement.
If a panel contains results that were resulted from a number of labs, each having their own provenance and metadata (beyond the clinical data for the observation result), then the panel can be represented using an ENTRY_GROUP consisting of a collection of clinical statements originating from multiple sources. Note that in this case, the observation results that make up the panel may not share the same metadata (e.g., originating lab, identifier, etc...). Note that a single composite clinical statement represented with a CLINICAL_STATEMENT<body=COMPOSITE_STATEMENT_BODY> is equivalent (isosemantic) to an ENTRY_GROUP containing a collection of observation result statements which all have identical metadata (i.e., the metadata of the composite clinical statement is replicated (copied) in each child CLINICAL_STATEMENT ENTRY of the given ENTRY_GROUP. Such duplication does not exist with the composite clinical statement (i.e., CLINICAL_STATEMENT<body=COMPOSITE_STATEMENT_BODY>)
Composite orderables such as complex meds would most likely be modeled using the CLINICAL_STATEMENT<body=COMPOSITE_STATEMENT_BODY> approach rather than using the ENTRY_GROUP approach since a composite orderable is a single orderable unit composed of parts. This is different though from a section in an order set that displays four beta-blockers and asks the clinician to pick exactly one. The latter use case would be represented using an ENTRY_GROUP.
A note about ISO 13606:
Note that this model, as it is currently defined, stays fairly close to ISO 13606:
- No composite entries (we use specializations of CLUSTER and ENTRY_GROUP to achieve this aim)
- No new ITEM/CLUSTER/ELEMENT-like structure added to represent the details of a clinical statement
- SECTION as a specialization of ENTRY_GROUP
- Possibly FOLDER as a specialization of COMPOSITION_GROUP (though not explicitly added here)
However, the naming of components was changed when broader semantics are required. ISO 13606 is primarily concerned with the representation of patient EHR. While there is a lot of overlap with knowledge artifacts, there are differences as well. The reference model's semantics were relaxed when the ISO 13606 semantics were too narrow. However, note that this was done primarily in the naming conventions used rather than in restructuring the model.
A note about CDS/CQI requirements:
The proposed reference model will most likely meet or need without CDS/CQI specific additions to the reference model.