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 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:
|COMPOSITION||A general type for a document structure that can contain heterogeneous content||This structure is generalized beyond just a document about a single patient. It may also be a definitional artifact targeting a cohort of patients. Hence, it does not specify the subject of the record in the reference model.||Discharge summary, History & Physical, Order Set, ECA Rule, Questionnaire|
|CONTENT||Abstract node representing a document content item. Content items may be containers such as a section or a single entry in the record or document.||CONTENT should support nested structures such as sections within sections or composite actions in a CDS knowledge artifact. Note that this is an abstract structure and is intended to be further specialized. Also note that the cardinality is such that a document may have several top level sections.||A section in a document, an orderable item in an order set, a clinical statement.|
|CONTENT_GROUP||Concrete type representing a potentially nested content container structure within a document.||Note that the name CONTENT_GROUP rather than SECTION is used in order to support a broader range of document types and content containment structures.||A section in a document, an action container in a knowledge document that supports different types of selection behaviors.|
|ENTRY||Concrete type representing a content entry in a document such as a clinical statement in a patient record or a recommended action in a CDS knowledge document.||Intended to be specialized in more than one way.||In CIMI, ENTRY is the abstract superclass for the STATEMENT class. In CDS, ENTRY may be specialized into the ACTION type of CDS Knowledge Artifacts.|
|STATEMENT||Abstract type for Clinical Statements.||This type is the entry point into the CIMI Clinical Statement hierarchy. It must support composite statements such as a composite orderable or a laboratory panel, for instance. Note that this set of statement is partitioned into two concrete types, an indivisible statement and a composite statement.||A laboratory result. A laboratory panel.|
|INDIVISIBLE_STATEMENT||Concrete type representing an atomic statement.||Statement may extend beyond clinical statement, hence the more general name STATEMENT rather than Clinical Statement.||A simple lab result or other quantitative observation.|
|COMPOSITE_STATEMENT||A potentially nested structure that represents a collection of indivisible statements.||Based on both CIMI and CDS/CQI requirements for composite statements that may be recursively nested.||Lab panels or composite medication orderables such as an OST.|
|ITEM||Abstract type for an item in a CONTENT ENTRY.||This set is partitioned into ITEM_GROUP, a recursively nested structure, and ELEMENT.||A complex data type. A simple attribute.|
|ITEM_GROUP||A collection of other ITEM_GROUPs or individual ELEMENTS.||ITEM_GROUP is used to define new Cluster-types in CIMI||Complex data types such as an Address type or an AnatomicalLocation structure.|
|ELEMENT||A simple attribute type with a DATA_VALUE type.||Leaf level item typically used to define new simple attributes in an archetype.||Observation type, address line, procedure performance date, patient birthdate, etc...|