Proposed CIMI Reference Model
- 1 Core Requirements for the CIMI Reference Model
- 2 Rational for above requirements
- 3 Introduction to Reference Model Components
- 4 UML Representation of the CIMI Reference Model
Core Requirements for the CIMI Reference Model
- The CIMI Reference Model shall provide the core expressivity required to author CIMI archetypes. In this respect, the CIMI Reference Model functions as a metamodel, asserting the building blocks that are then constrained in archetypes. At its core, the CIMI Reference Model:
- shall support the representation of 'classes' which may contain 'simple attributes' and 'nested classes'.
- shall support the layered application of constraints in archetypes through specialization
- may support the enforcement of model constraints in tooling based on metadata explicitly captured in the model
- The CIMI Reference Model shall support the expressivity needs of domain archetypes aimed at modeling a patient EHR as well as CDS and CQI knowledge artifacts.
- The CIMI Reference Model shall limit its expressivity to those metamodel constructs required for archetype development and delegate domain-level expressivity to archetypes constructed from the reference model.
Rational for above requirements
CIMI wishes to support iso-semantic domain representations of clinical constructs in order to support the variable ways in which clinical information manifests itself in various contexts. In order to support this goal, CIMI defines a foundational model, devoid of domain-specific semantics, that can be used to construct domain-specific archetypes. CIMI also plans to define a set of 'canonical' or 'preferred' models. This set will be comprised of the preferred model selected from each family of iso-semantic models.
The CIMI Reference model must be able to support recursive class-attribute relationships such as those found in clinical object graphs. For instance, a Procedure archetype is a class that contains a number of attributes that define the characteristics of a Procedure. Some of these attributes may be classes such as a device used to perform the procedure. This class, in turn, will contain other attributes, some of which may be complex types such as the manufacturer of the device.
The reference model must also support an author's ability to define a specialization of Procedure such as a LaboratoryProcedure. A generic metamodel coupled with ADL constraint can support this mechanism. That is, the metamodel must support the addition of new attributes to the class while ADL constraints may also constrain certain attributes out (by making their occurrence 0..0) and/or formally define their terminology bindings.
Unfortunately, there is a requirement trade off that occurs between reference model expressivity and constraints on expressivity as expressed using ADL. A concise reference model that avoids domain semantics is highly expressive. By supporting the representation of classes that specify a number of attributes or can reference other classes, any structure can be built. On the other hand, a reference model that defines explicit domain structures greatly constrains this expressivity (it introduces the core classes of the domain and the specific relationship that exists between them) but can leverage those structures in ADL constraints. For instance, one may define a structure to represent complex types and another that defines, say, a clinical statement. One can now explicitly relate the two constructs in the reference model for this relation to manifest itself in the archetypes (e.g., a statement can contain clusters but not vice-versa). On the other hand, in a more basic domain-independent reference model that expresses a potentially recursive nesting of containers with attributes, one cannot prevent a complex type from referencing a statement (also a container) using ADL alone. Such validation must be done outside of the OpenEHR framework in tooling and compilers. Yet, this tradeoff may be a necessary cost if one wishes to ensure that all domain-specific expressions occur exclusively at the archetype level in order to support alternative representations of such domain-specific constructs.
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 27, 2016 1:47 pm ET
- Addition of new complext data type CODED_NAME_VALUE to support name value types where the name is a CODED_TEXT and the value is a DATA_VALUE
- Addition of a new metadata attribute to ITEM with cardinality 0..* of type CODED_NAME_VALUE
- Provides an extensible mechanism for adding meta model attributes beyond those currently provided by the OpenEHR Basic Meta Model Specification (BMM). These metadata attributes are primarily intended for tooling.
- Allows the definition of additional meta model metadata attributes without changing and re-versioning the reference model.
- Supports the requirement for additional CLUSTER types in the reference model in order to allow validation, translation, and compilation without needing to introduce them explicitly in the reference model.
- Ultimately supports the definition of a small and compact core reference model, thus enabling greater expressivity at the CIMI core archetype level.
Disadvantage of Proposed Approach
- Metamodel attributes are specified at the archetype level alongside clinical attributes but are contained within the metadata container.
- Constraints and validation rules need to be defined outside the OpenEHR specification (i.e., cannot leverage ADL to enforce constraints). No formalism has been proposed to do so at this time.
UML Representation of Reference Model
Proposed Metadata Attributes
|Attribute Name||Allowed Values||Scope||Description|
|container_kind||cluster, composition, section, statement, statement_group, knowlege_definition, knowledge_definition_group||ITEM_GROUP||Specifies the kind of ITEM_GROUP container for tooling and validation purposes.|
|is_abstract||true, false||ITEM_GROUP||Specifies whether an archetype is abstract and must be further constrained or whether the archetype can be used as a fully constrained schema for clinical instance data generation.|
Tentative Value Sets
|Code||Preferred Name||Code System||Description||Parent|
|1||cluster||http://cimi.org/valueset/container_kind||A grouping for a dependent structure or complex data type||N/A|
|2||composition||http://cimi.org/valueset/container_kind||A grouping that holds the content of a document||N/A|
|3||section||http://cimi.org/valueset/container_kind||A grouping representing a section in a document||N/A|
|4||statement_group||http://cimi.org/valueset/container_kind||A grouping representing a collection of clinical statements||N/A|
|5||statement||http://cimi.org/valueset/container_kind||A single clinical statement||N/A|
|6||knowledge_definition_group||http://cimi.org/valueset/container_kind||A grouping representing a collection of clinical statements||N/A|
|7||knowledge_definition||http://cimi.org/valueset/container_kind||An atomic knowledge definition||N/A|