This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "Proposed CIMI Reference Model"

From HL7Wiki
Jump to navigation Jump to search
Line 44: Line 44:
 
=== Disadvantage of Proposed Approach ===
 
=== Disadvantage of Proposed Approach ===
  
* Metamodel attributes should really be defined at the BMM level and proposed additions extend beyond the OpenEHR core specification.
+
* Meta model attributes should really be defined at the BMM level. However, the proposed additions extend beyond the OpenEHR core specification.
* Metamodel attributes are specified at the archetype level alongside clinical attributes.
+
* Meta model attributes are specified at the archetype level alongside clinical attributes.
* Constraints and validation need to be defined outside the OpenEHR specification (i.e., cannot leverage ADL to enforce constraints)
+
* 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.
  
  
 
[[File:CIMI_core_reference_model_v2.gif]]
 
[[File:CIMI_core_reference_model_v2.gif]]

Revision as of 18:10, 27 July 2016

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:

Core CIMI Reference Model Components
Component Name Description Notes Examples
NAME DESCRIPTION NOTES EXAMPLES

UML Representation of the CIMI Reference Model

Version as of July 27, 2016 1:47 pm ET

Proposed changes

  • 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

Rationale

  • 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

  • Meta model attributes should really be defined at the BMM level. However, the proposed additions extend beyond the OpenEHR core specification.
  • Meta model attributes are specified at the archetype level alongside clinical attributes.
  • 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.


CIMI core reference model v2.gif