CIMI Principles

Approved

• CIMI Principles - Preferred Modelling Decisions
• Decisions are categorized as [principles], [process guide] or [style guide]
• Versions
  • Mar 24, 2016 Version 12 was CIMI WG approved, pending “class” and “attribute” modeling style examples
  • Mar 31, 2016 Version 13, adds “class” and “attribute” modeling style examples

1. CIMI approved Detailed Clinical Models (DCMs) must be in a CIMI approved syntax: [style]
   1. ADL 2.X. – most current approved version
   2. AML – most current approved version
   3. An alternative syntax must be transformable into the CIMI Preferred syntax, e.g., RDF, LEGO.
2. CIMI approved DCMs must use the most current approved CIMI core reference model. [style]
3. CIMI approved DCMs must use CIMI reference archetypes where applicable. [style]
   1. Reference Archetypes are marked by a reference archetype annotation
   2. Reference Archetypes have names that are all uppercase in the ADL Workbench
   3. Reference Archetypes are Constrained from the CIMI Core Reference Model and can be constrained into a hierarchy of reusable CIMI Patterns to build CIMI leaf DCMs
4. CIMI Clinical Information models support interoperability across a federation of enterprises by supporting transformations among the enterprises’ respective interface standards. [principle], such as
   1. CCDA, FHIR, NIEM, HL7 V2 or V3 messaging
5. CIMI Clinical Information Models support semantic classification. [principle]
   1. E.g., A CIMI hemoglobin lab observation can be classified as a lab observation.
6. CIMI supports iso-semantic alternatives for modeling the same clinical data. [principle]
   1. Iso-semantic models are models that have exactly the same information content, but the models differ in terms of structure and/or the degree of pre or post coordination of concepts that are used in the models.
      1. ACTION: define iso-semantic vs logically/semantically equivalent
   2. Models in a iso-semantic family can use different levels of pre and post coordination. A SNOMED-CT template can be a preferred representation to translate between the iso-semantic families for those parts of the model, which are covered in SNOMED-CT.
7. The default CIMI preferred model is the most explicitly modeled (i.e., post-coordinated) member of an iso-semantic family. [principle]
8. CIMI terminology binding principles:
   1. CIMI models must have complete terminology bindings before the models attain a status of “Complete” or “Ready for Trial Use.” [process guide]
   2. CIMI has obtained and will use a CIMI SNOMED CT Extension to create, track, and submit needed concepts to SNOMED CT. Concepts that are not appropriate for SNOMED CT will be submitted to other standard terminology developers. [process guide]
   3. CIMI models must be bound to standard terminologies: [principle. Subheadings are style guidance.]
      1. SNOMED CT relationship concepts will be used for the parent – child binding relationships.
      2. LOINC codes will be used for observation identifiers.
      3. SNOMED CT codes will be used for non-medication related clinical concepts in value sets.
   4. CIMI will specify one preferred unit of measure for models of physical quantities for use in accessing and storing data via services. SI units are preferred by default.
      1. The CIMI preferred strategy is to use SNOMED CT codes for units of measure in models, rather than a UCUM expression. Each unit of measure must have a single unique mapping to a valid UCUM expression. ### ### This strategy was chosen because it allows units of measure to be specified and constrained in the same manner as any coded field. However, for unit conversion, the related UCUM expression can be referenced from the code, and then UCUM unit conversion libraries can be used to convert to a new unit of measure.
      2. RxNorm codes will be used for medication related concepts temporarily; where, an International standard will be used, when available.
      3. Other standard codes and code systems will be approved as needed.
      4. CIMI model bindings will be informed by the SNOMED CT concept model where appropriate. [principle]
   5. Logical CIMI models will only include identifiers of value sets, not the enumerated list of allowed values. Value sets are configuration controlled separately from CIMI models. [style guide]
   6. CIMI is creating “computable logical models.” CIMI’s definition of “computable logical models” is: [process guidance]
   7. The models are algorithmically process-able (computable). It must be possible for the models to be translated algorithmically from one formal representation to another. CIMI logical models must support lossless round-trip logical transformations through CIMI approved representations.
   8. Hierarchical models classify the structural relationship of the model elements (containment).
   9. Coded elements have explicit binding to allowed value sets of coded values.
   10. Models are independent of any specific programming language, implementation technology, or type of database.
   11. The models must support explicit, unambiguous query statements against data instances.
   12. Models may support inclusion of “processing knowledge” (default values, etc.).
9. One or more examples of logical instance data will be created for each model or class of models. [style guide]
   1. The examples will show both proper and improper use
10. Values for codes and for value set identifiers will always be represented within the model using URIs. [style guide]
11. CIMI preferred Modelling style: [principle]
    1. CIMI archetypes include all valid clinical requirements, regardless of prevalence of use; where, CIMI architypes may exclude source requirements deemed to be implementation-design constraints.
    2. The CIMI preferred models include all possible attributes (maximal set of data elements) for which there is a valid use case; that is, CIMI models are superset reference models. [principle]
    3. CIMI prefers the “class modeling style” or “specialization by constraint style” whereby model nodes are constrained by changing the name of the node or attribute in the model; where, the usual modeling style most archetype modelers use is the Class modeling style; where, not only the names/concepts change; but also, the structure of the model can change.
       1. In the Class modeling style archetypes are specialized by changing the name of a node or add or remove structures.
    4. EXAMPLE: The node has a name and the data field holds for instance a number as result.
       1. <Node: LabTest> has result <a number>. When this gets specialized, the node name changes and so does its meaning
       2. <Node: LabTest Blood Glucose Measurement> has result < a number>
    5. An alternative “attribute modeling style” or “LEGO modeling style” is to constrain nodes by changing the value of an attribute (e.g., SNOMED descriptor) in the model; where, nodes get their meaning from the name they get and/or annotations.
    6. The Attribute modeling style is used because of the fact that the archetypes (clinical models) need more rigor and are constructed using re-usable patterns. In this modeling style the archetype stays fixed.
       1. <Node: NAME> has value <LabTest>
       2. <Node: RESULT> has value <a number>
    7. When this gets specialized the node names are not changed. Only one data field is changed.
       1. <Node: NAME> has value <LabTest: Blood Glucose Measurement>
       2. <Node: RESULT> has value <a number>
       3. [Example provided by Gerard Freriks, March 2016]
12. a clean separation of clinical model semantics [Aug 2016]
    1. using SNOMED, LOINC and RxNORM

Pending

1. ASSERTION vs. EVALUATION_RESULT criteria
   1. from 2017-02-02 CIMI minutes
   2. 'Reasoning' vs. 'Finding', 'Subjective' vs. 'Objective', 'Fact-ish' vs. 'Judgement-ish' categories work > 80% of the time; but, they are not reliable criteria for a small set of "edge cases'.
      1. In most cases it is obvious, when to use ASSERTION (e.g., 'Reasoning', 'Subjective', 'Judgement-ish' things, such as DIAGNOSIS, PROBLEM, COMPLAINT, FAMILY_HISTORY)
         1. The Patient DISCHARGE_DIAGNOSIS is ... (implying the set of findings defining the DISCHARGE_DIAGNOSIS)
         2. John has blue eyes
      2. In the small number of cases, where it is not obvious when to use ASSERTION, CIMI prefers
         1. ASSERTIONS be used when the answer to an EVALUATION_RESULT is 'Present' or 'Absent', 'Yes' or 'No', 'True' or 'False', etc.
      3. Although theoretically possible; but for practical implementation reasons, CIMI does not support round-trip conversion between EVALUATION_RESULT and ASSERTION structures, as shown by the set of ATTRIBUTE vs. EVALUATION_RESULT attributes shown above.

Out of Scope

1. OUT OF SCOPE: Implementations characteristics are out of scope.
   1. CIMI is not directly concerned with wire formats. [principle]
   2. Realms may choose non-CIMI preferred units of measure and terminology for communications; where, it is the realm’s responsibility to have an equivalent concept in their terminology and to produce the mapping to the standard code.
   3. Implementations of user facing point-of-capture and point-of-use applications may use any units of measure or terminologies that they like, as long as communications use CIMI preferred SI units and standard terminologies. [principle, style guide/implementation guidance]
   4. Transformation fidelity (e.g., Millimeters to whole inches may be imprecise, inches to lb. /sq. ft. may be meaningless) and safety as a whole are design specifications, beyond CIMI’s scope.