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
 
(47 intermediate revisions by the same user not shown)
Line 1: Line 1:
==Notes to reviewers==
+
[[CIMI_Quality_Modeling_Collaboration|Return to CIMI CQI/FHIM Collaboration page]]
  
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:
+
==Core Requirements for the CIMI Reference Model==
  
* Extend the RM beyond its current state but minimize breaking changes
+
* The CIMI Reference Model shall provide the core expressivity required to author CIMI archetypes.
* Address the shortcomings identified during our last few CIMI calls
+
* The CIMI Reference Model shall limit its expressivity to those metamodel constructs required for archetype development and delegate domain-specific expressivity to the archetypes constructed based on the reference model. In this respect, the CIMI Reference Model functions as a metamodel, asserting the foundational building blocks that are then constrained in archetypes. At its core, the CIMI Reference Model:
* 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.
+
** shall support the representation of 'classes' which may contain 'simple attributes' and 'complex attributes'.
* 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.
+
** shall support the layered application of constraints in archetypes through archetype specialization in ADL
 +
** may support the enforcement of model constraints beyond those provided by ADL 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.
  
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.
+
==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 tradeoff that occurs between reference model expressivity and constraints on expressivity as expressed using ADL. A concise reference model that avoids domain-specific structures and 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 at the Reference Model level greatly constrains this expressivity. It would introduce the core classes of the domain and the specific relationships that exist between them and then 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 fundamental 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 expressivity occur exclusively at the archetype level in order to support alternative representations of such domain-specific constructs.
 +
 
 +
== Changes Since Last Version ==
 +
Version as of July 27, 2016 1:47 pm ET
 +
 
 +
=== Recent Updates ===
 +
 
 +
* Addition of a new complex 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 for Recent Updates ===
 +
 
 +
* Provides an extensible mechanism for adding meta model attributes in the reference model that can be further constrained in archetypes. 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 specifying the ITEM_GROUP ''kind'' in an archetype definition - a property that can be leveraged in tooling to enforce archetype constraints that cannot be enforced using ADL.
 +
* Ultimately supports the definition of a small and compact core reference model with parametrizable properties, thus enabling the delegation of domain-specific expressivity (structural and semantic) to 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. Yet, this approach is analogous to the FHIR Structure Definition approach.
 +
* Constraints and validation rules need to be defined outside the OpenEHR specification (i.e., cannot leverage ADL to enforce constraints) and no formalism has been proposed to do so at this time. As described earlier in this document, this is a consequence of the need to express domain-specific construct at the archetype rather than at the reference model level.
  
 
==Introduction to Reference Model Components==
 
==Introduction to Reference Model Components==
Line 20: Line 50:
 
! Notes
 
! Notes
 
! Examples
 
! Examples
|-
 
|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 behavioral groups 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
 
|Abstract 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
 
|ITEM
|Abstract type for an item in a CONTENT ENTRY.
+
|An abstract metamodel component such as a class or an attribute of a class in UML
|This set is partitioned into ITEM_GROUP, a recursively nested structure, and ELEMENT.
+
|The ITEM class is required in order to support the recursive nesting of containers within containers that may also contain elements.
|A complex data type. A simple attribute.
+
|N/A
 
|-
 
|-
 
|ITEM_GROUP
 
|ITEM_GROUP
|A collection of other ITEM_GROUPs or individual ELEMENTS.
+
|A composite 'container' structure that can hold other containers or elements.  
|ITEM_GROUP is used to define new Cluster-types in CIMI
+
|ITEM_GROUP is analogous to a class in UML.
| Complex data types such as an Address type or an AnatomicalLocation structure.
+
|a Procedure class
 
|-
 
|-
 
|ELEMENT
 
|ELEMENT
|A simple attribute type with a DATA_VALUE type.
+
|A non-composite item typically part of a container.
|Leaf level item typically used to define new simple attributes in an archetype.
+
|ELEMENT is analogous to a UML class attribute.
|Observation type, address line, procedure performance date, patient birthdate, etc...
+
|a ''method'' attribute of type CODED_TEXT in the Procedure class
|-
 
|NAME
 
|DESCRIPTION
 
|NOTES
 
|EXAMPLES
 
 
|}
 
|}
  
== UML Representation of the CIMI Reference Model ==
+
== The CIMI Reference Model ==
Version as of July 13, 2016 23:35 am PT
 
  
=== Some important notes about this version of the model ===
+
=== BMM 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.
+
To find the latest BMM file for the CIMI Reference Model, please follow the link below:
* 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:
+
[https://github.com/cnanjo/archetypes/blob/master/Current_RM/CIMI-RM-4.0.bmm BMM File]
  
* 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'.
+
=== UML Representation of Reference Model ===
* 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:
+
====Core Reference Model====
  
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.
+
Narrative to be added...
  
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<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 duplicated in the ENTRY_GROUP for each child CLINICAL_STATEMENT ENTRY.
+
[[File:CIMI_locatable_v2.gif]]
  
Composite orderables such as complex meds would most likely be modeled using the CLINICAL_STATEMENT<COMPOSITE_STATEMENT_BODY> approach rather than 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.
+
[[File:CIMI_core_reference_model_v2.gif]]
  
A note about ISO 13606:
+
====Complex Data Types====
  
Note that this model, as it is currently defined, stays fairly close to ISO 13606:
+
Narrative to be added...
* 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.
+
[[File:CIMI_datatypes_v2.gif]]
  
 +
====Primitive Types====
  
[[File:CIMI_core_reference_model_v2.gif]]
+
Narrative to be added ...
 +
 
 +
[[File:CIMI_primitives_v2.gif]]
 +
 
 +
====How CIMI Datatypes Align with FHIR====
 +
 
 +
Narrative to be added ...
 +
 
 +
=== Proposed Metadata Attributes ===
 +
 
 +
{| class="wikitable"
 +
|+CIMI Archetype Metadata Attributes
 +
! style="text-align:left;"| 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.
 +
|}
 +
 
 +
=== Tentative Value Sets ===
 +
 
 +
{| class="wikitable"
 +
|+Container Kind
 +
! style="text-align:left;"| 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 knowledge definitions
 +
|N/A
 +
|-
 +
|7
 +
|knowledge_definition
 +
|http://cimi.org/valueset/container_kind
 +
|An atomic knowledge definition
 +
|N/A
 +
|}

Latest revision as of 17:54, 12 August 2016

Return to CIMI CQI/FHIM Collaboration page

Core Requirements for the CIMI Reference Model

  • The CIMI Reference Model shall provide the core expressivity required to author CIMI archetypes.
  • The CIMI Reference Model shall limit its expressivity to those metamodel constructs required for archetype development and delegate domain-specific expressivity to the archetypes constructed based on the reference model. In this respect, the CIMI Reference Model functions as a metamodel, asserting the foundational 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 'complex attributes'.
    • shall support the layered application of constraints in archetypes through archetype specialization in ADL
    • may support the enforcement of model constraints beyond those provided by ADL 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.

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 tradeoff that occurs between reference model expressivity and constraints on expressivity as expressed using ADL. A concise reference model that avoids domain-specific structures and 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 at the Reference Model level greatly constrains this expressivity. It would introduce the core classes of the domain and the specific relationships that exist between them and then 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 fundamental 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 expressivity occur exclusively at the archetype level in order to support alternative representations of such domain-specific constructs.

Changes Since Last Version

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

Recent Updates

  • Addition of a new complex 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 for Recent Updates

  • Provides an extensible mechanism for adding meta model attributes in the reference model that can be further constrained in archetypes. 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 specifying the ITEM_GROUP kind in an archetype definition - a property that can be leveraged in tooling to enforce archetype constraints that cannot be enforced using ADL.
  • Ultimately supports the definition of a small and compact core reference model with parametrizable properties, thus enabling the delegation of domain-specific expressivity (structural and semantic) to 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. Yet, this approach is analogous to the FHIR Structure Definition approach.
  • Constraints and validation rules need to be defined outside the OpenEHR specification (i.e., cannot leverage ADL to enforce constraints) and no formalism has been proposed to do so at this time. As described earlier in this document, this is a consequence of the need to express domain-specific construct at the archetype rather than at the reference model level.

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
ITEM An abstract metamodel component such as a class or an attribute of a class in UML The ITEM class is required in order to support the recursive nesting of containers within containers that may also contain elements. N/A
ITEM_GROUP A composite 'container' structure that can hold other containers or elements. ITEM_GROUP is analogous to a class in UML. a Procedure class
ELEMENT A non-composite item typically part of a container. ELEMENT is analogous to a UML class attribute. a method attribute of type CODED_TEXT in the Procedure class

The CIMI Reference Model

BMM Model

To find the latest BMM file for the CIMI Reference Model, please follow the link below:

BMM File

UML Representation of Reference Model

Core Reference Model

Narrative to be added...

CIMI locatable v2.gif

CIMI core reference model v2.gif

Complex Data Types

Narrative to be added...

CIMI datatypes v2.gif

Primitive Types

Narrative to be added ...

CIMI primitives v2.gif

How CIMI Datatypes Align with FHIR

Narrative to be added ...

Proposed Metadata Attributes

CIMI Archetype 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.

Tentative Value Sets

Container Kind
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 knowledge definitions N/A
7 knowledge_definition http://cimi.org/valueset/container_kind An atomic knowledge definition N/A