CIMI Practitioners' Guide

<<<CIMI Practitioners' Guide is under construction>>>
<<<WORKING-DRAFT for stakeholder verification-and-validation>>>
<<< NOT FOR OFFICIAL USE>>>

Executive Summary

Shared clinical-information requires computable semantic-interoperability for clinical decision support and population-based reasoning. SOLOR is the foundation of the collaborative IIM&T model-driven-development tool-enforced methodology to construct consistent, traceable and re-usable HL7 FHIR, CDA, V2 and V3 messages plus JSON APIs, NIEM etc. specifications, implementation guides, implementation-artifacts and component-based architectural building-blocks, such as HSPC SMART . The evolving IIM&T methodologies, and, technologies and federated governance are the key-facets to efficient-and-effective shared-data and plug-and-play Healthcare Information Technology (HIT) interoperability. The Federal Health Information Model (FHIM), Clinical Quality Initiative (CQI), Clinical Decision Support (CDS) and Clinical Information Model (CIMI) teams are refactoring, harmonizing, and integrating the FHIM Domain Classes, Clinical Quality Framework (CQF) and CIMI Logical Information Model (LIM ), Architectural Framework (aka Reference Architecture) and Detailed Clinical Models (DCMs) for efficient-and-effective HIT Platform-Specific Model (PSMs ) interoperable-implementations.

The CIMI-sponsored HL7 IIM&T project is working in alignment with other HL7 workgroups, The Open Group Healthcare Forum and HSPC with a computable semantic-interoperability goal and objective to minimize the need for traditional and expensive Extraction, Transformation and Load (ETL) mappings and tools. These standardized artifacts are collectively referred to as the HL7 Clinical Logical Information Model (CLIM); where, CLIM is a package of CIMI architectural-framework harmonized LIMs (e.g., SOLOR, FHIM, QUICK, DCM, eCQM, KNART and CDA, V2, V3, FHIR (US CORE, QI Core, Profiles and Extensions), etc.) and Platform-Specific Models (PSMs). Traditional LIM-and-PSM development-strategies are typically incomplete and inconsistent.

The CIMI-sponsored HL7 IIM&T project is working in alignment with other HL7 workgroups, The Open Group Healthcare Forum and HSPC with a computable semantic-interoperability goal and objective to minimize the need for traditional and expensive Extraction, Transformation and Load (ETL) mappings and tools. These standardized artifacts are collectively referred to as the HL7 Clinical Logical Information Model (CLIM); where, CLIM is a package of CIMI architectural-framework harmonized LIMs (e.g., SOLOR, FHIM, QUICK, DCM, eCQM, KNART and CDA, V2, V3, FHIR (US CORE, QI Core, Profiles and Extensions), etc.) and Platform-Specific Models (PSMs). Traditional LIM-and-PSM development-strategies are typically incomplete and inconsistent; where, the Figure 2 IIM&T Model Driven Development Strategy and the subsequent article address this problem.

Clinical knowledge content is a critical part of modern healthcare platforms, therefore, the needs of managing (authoring, reviewing and maintaining) clinical content in a deterministic and accountable way is crucial. This article describes the requisite methodology-and-technologies including FHIM, CQF, KNART, LEGO and DCM clinical-content structures, SOLOR environment of Termlogic terminology-editor and Ontologic terminology-server, STAMP configuration management versioning and SIGG (MDHT, MDMI) tools, which use the CIMI Architectural Framework of reference models, principles and methodology to better achieve plug-and-play HIT interoperability.

1. IIM&T is Integrated Information Model Tools, Hl7 Project# 1316. IIM&T collaborates in the development, standardization and use of IIM&T architectural framework and reusable artifacts producing HL7 and ISO standards. http://www.hl7.org/special/Committees/projman/searchableProjectIndex.cfm?action=edit&ProjectNumber=1316
2. HSPC is Healthcare Services Platform Consortium, a provider-led and vender involved collaboration among 200-300 government, industry and academic healthcare leaders dedicated to establishing a scale-able, truly interoperable SMART data-services, component and application system-architecture for HIT. See http://hspconsortium.org/
3. SMArt (Substitutable Medical Apps, reusable technologies) platform architecture at https://www.healthit.gov/policy-researchers-implementers/substitutable-medical-apps-reusable-technologies
4. Governance involves change control, configuration management and version control; where, CLIM governance is generally federated. That is, local development organizations govern their own artifacts and may wish to provide versions to HL7. Appropriate HL7 workgroups govern HL7 artifacts and ballots. Similarly, FHIR governance is generally federated; where, local development organizations govern their own artifacts and may wish to provide versions to HL7. At HL7, FHIR-compliant reusable-artifacts are governed by the FHIR workgroup’s HL7 artifacts and ballots.
5. Information Model: (in software engineering) a representation of concepts, relationships, constraints, rules and operations to specify data semantics for a chosen domain of discourse. It can provide sharable, stable, and organized structure of information requirements for the domain context. Logical Information Model (LIM): (in systems engineering) a representation of information, organized in terms of classes and relationships and is independent of any particular technology (database) platform. The logical information model can become the basis of a physical data model and inform the design of a database. Logical information and physical data models (i.e., PSMs) are very different in their objectives, goals and content.
6. platform-specific model (PSM) is a model of a software or business system that is linked to a specific technological platform (e.g. a specific programming language, operating system, document file format or database). Platform-specific models are indispensable for the actual implementation of a system.
7. The Open Group Healthcare Forum collaboration is among industry stakeholders, regulatory bodies, other standards-setting organizations, and other consortia concerned with healthcare interoperability.

Goal

Methodology

Governance

• To encourage Information Model consistency, traceability and reuse:
  • CIMI collaborates with other workgroups and organizations, which are governed apart from HL7.
  • These projects are voluntarily being harmonized using CIMI Principles and Reference Models (e.g., PC, CQI, CDS, EHR, HSPC, etc.).
  • Externally-developed CIMI-compliant information-models can be donated to HL7 for
    • HL7 configuration management, peer review and standardization.

Collaboration Projects

• CIMI Project 1316, Integration of Information Models and Tools (IIM&T), [Steve Hufnagel & Nona Hall, facilitators]
  • See http://www.hl7.org/special/Committees/projman/searchableProjectIndex.cfm?action=edit&ProjectNumber=1316
• FHIM integration of CIMI Clinical BMM & Archetypes (Patterns) *1 [Galen Mulrooney]
• US Core / QI Core integration of CIMI BMM & Archetypes (Patterns) *1 [Claude Nanjo]
• Patient Care Project 1253 "CIMI Clinical Model Proof of Concept" (Skin Wound Assessment)
  • See http://www.hl7.org/special/Committees/projman/searchableProjectIndex.cfm?action=edit&ProjectNumber=1253
  • content *1 [Jay Lyle and Susan Matney]
  • Terminology/SNOMED Expressions *1 [Jay Lyle and Susan Matney]
  • SOLOR (SNOMED extension including LOINC and RxNorm) *1 [Keith Campbell and Susan Matney]
• Clinical Decision Support Workgroup's Quality measures *2 [Ken Kawamoto and Claude Nanjo]
• Refine PROCEDURE and CONTEXT based on Pilots *1 (Galen Mulrooney and Claude Nanjo)
• Family Planning Annual Report (FPAR) – HSPC pilot with ACOG *3 [Stan Huff, Susan Matney]
• Device interfaces MDEpiNet. *3 [Julia Skapik]
• FHIR JET (Joint Exploratory Team) *3 Nona Hall, IPO, VA,

Milestones

• 2010-05 – CIMI became an IHTSDO workgroup
• 2016-01 – CIMI became an HL7 workgroup
• 2016 Jan-Sep – CIMI-sponsored HL7 IIM&T investigative study
  • CIMI Final Report: https://1drv.ms/w/s!AlkpZJej6nh_k9dlCRdJv51X0tFp9A
• 2016-08 ONC, FHA and IPO sponsored IIM&T Technical Forum
• 2016-09 CIMI-sponsored HL7 IIM&T Project *1316
  • HL7 Project Scope Statement: https://1drv.ms/w/s!AlkpZJej6nh_k_1Hi-yFatfOvK8-gQ
• 2017-01 HL7 comments-only ballot
  • See https://1drv.ms/f/s!AlkpZJej6nh_k_gcfdRN95Q8rmJDsQ
• 2017-05 HL7 Informative Standard
• 2017-09 HL7 Standard for Trial Use (STU)
• 2018-09 HL7 Standard for Trial Use (STU)
• 2019-09 HL7 Normative Standard
• NOTES:
  • Added domains can add-to BMM.
  • Added use-cases can add-to Reference Architypes, DCMs and FHIR profiles and extensions.

Communications

To inculcate the reuse of CIMI's principles, methodology, architecture, and artifacts (e.g., CLIM, FHIR and CDA profiles and extensions):

• collaboration with other projects and organizations. (see "References" below)
• informative and useful CIMI web-site and wiki (see "References" below)
• Free for use CIMI artefacts and open-source tools (see "References" below)
• "The CIMI Practitioners' Guide" is intended for non-modelers.
• "The CIMI Architecture, Methodology and Style Guide" is in each ballot package and is intended for modelers.
• CIMI Newsletters are published before and updated during each workgroup meeting.

Acronyms

“When I use a word, it means just what I choose it to mean — neither more nor less.” [Alice in Wonderland, Lewis Carroll]

• BMM is CIMI Basic Meta Model components of the CIMI Reference Model (Architecture), used to harmonize the independently-developed Information models
• See http://wiki.hl7.org/index.php?title=CIMI_Practitioners%27_Guide
• CDA is HL7 Clinical Data Architecture. See http://www.hl7.org/implement/standards/product_brief.cfm?product_id=258
• C-CDA is HL7 Consolidated CDA. See http://www.hl7.org/implement/standards/product_brief.cfm?product_id=379
• CEM is Intermountain Clinical Element Models See http://www.opencem.org/*/
• CDS is HL7 Clinical Decision Support workgroup. See http://wiki.hl7.org/index.php?title=Clinical_Decision_Support
• CIMI is HL7 Clinical Information Model Initiative. See http://wiki.hl7.org/index.php?title=Clinical_Information_Modeling_Initiative_Work_Group
• CIMI Principles See http://wiki.hl7.org/index.php?title=CIMI_Practitioners%27_Guide
• CIMI Reference Models (aka Information Architecture) See http://wiki.hl7.org/index.php?title=CIMI_Practitioners%27_Guide
• CLIM Package of SOLOR, FHIM, CQF, CIMI DCMs, used to generate FHIR Profiles and Extensions, contains Federated CIMI-harmonized Clinical Logical Information Models, where, independent organizations maintain the component models and HL7 periodically configuration manages, ballots and standardizes them.
• CQF is ONC Clinical Quality Framework. See http://wiki.hl7.org/index.php?title=Clinical_Decision_Support
• CQI is HL7 Clinical Quality Initiative workgroup. See http://wiki.hl7.org/index.php?title=Clinical_Quality_Information
• DAF is ONC Data Access Framework (US Core). See http://wiki.siframework.org/Data+Access+Framework+Homepage
• DCM is CIMI Detailed Clinical Models. See http://www.opencimi.org/model-browser
• FHIM is Federal Health Information Model; where, FHIM specifies healthcare domains and their data modules and their data elements.
  • See http://FHIMS.org
• FHIR is HL7 Fast Healthcare Information Resource standard and workgroup. See http://wiki.hl7.org/index.php?title=FHIR
• HcDir is ONC-FHA Provider Healthcare Directory. See http://wiki.siframework.org/Provider+Directories
• IIM&T Is CIMI-sponsored HL7 Integration of Information Models & Tools Project.
• See http://wiki.hl7.org/index.php?title=CIMI_Practitioners%27_Guide
• JET is DoD-VA Joint Exploratory Team.
• KNART is CDS Knowledge Artifact. See http://www.hl7.org/implement/standards/product_brief.cfm?product_id=337
• MDHT is SIGG Model Driven Health Tool. See https://projects.eclipse.org/proposals/model-driven-health-tools
• MDMI is SIGG Model Driven Message Interoperability.
  • See http://www.omg.org/mdmi/ and http://www.omg.org/spec/MDMI/
• NIEM is National Information Exchange Package. See https://www.niem.gov/
• QI Core is FHIR Quality Improvement Core Implementation Guide . See https://www.hl7.org/fhir/qicore/qicore.html
• QUICK is CQI Quality Information and Clinical Knowledge logical model, used to specify eCQMs and FHIR QI Core.
  • See https://www.hl7.org/documentcenter/public_temp_315E0F18-1C23-BA17-0C73398BA144AB5D/wg/cqi/Defining_eCQMs_Using_CQL.pdf
• RI is SIGG-MDMI Referent Index. See https://github.com/MDMI/ReferentIndexContent
• SIGG is FHA Standards Implementation Guide Generator
• SOLOR is VA’s SnOmed LOinc, Rxnorm; where, HSPC hosts the SOLOR project to provide the terminology foundation for model development.
• VSAC is NLM Value Set Authority Center. https://vsac.nlm.nih.gov/

IIM&T References

“It is not the critic who counts; not the man who points out how the strong man stumbles, or where the doer of deeds could have done them better. The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood; who strives valiantly; who errs, who comes short again and again, because there is no effort without error and shortcoming; but who does actually strive to do the deeds; who knows great enthusiasms, the great devotions; who spends himself in a worthy cause; who at the best knows in the end the triumph of high achievement, and who at the worst, if he fails, at least fails while daring greatly, so that his place shall never be with those cold and timid souls who neither know victory nor defeat.”

 <<Theodore Roosevelt, Apr 23, 1910, Sorbonne, Paris, France>>

Supporting documents

• HL7 IIM&T Project Scope Statements https://1drv.ms/f/s!AlkpZJej6nh_lIQOuPJcL2rf5BVoXQ
• IIM&T Technical Forum Summary https://1drv.ms/w/s!AlkpZJej6nh_k9gyRVADgOvM5SlJkQ
• IIM&T Briefing Slides https://1drv.ms/p/s!AlkpZJej6nh_k9dE-b_DAO8HSNNT6Q
• IIM&T Newsletters http://wiki.hl7.org/index.php?title=CIMI_Newsletters
• IIM&T Reports https://1drv.ms/w/s!AlkpZJej6nh_k9dQ2qQnRuQM8gbu8A
• CIMI web-site https://www.opencimi.org
  • CIMI BMM Browser http://models.opencimi.org/cimi_doc/
  • CIMI Architype-Model Browser https://www.opencimi.org/model-browser
• CIMI Wiki http://wiki.hl7.org/index.php?title=Clinical_Information_Modeling_Initiative_Work_Group
  • CIMI Minutes http://wiki.hl7.org/index.php?title=CIMI_Minutes
  • CIMI Ballot Materials https://drive.google.com/drive/folders/0ByrVwEEPQjMyazNLMUNFZ2YtNk0
  • CIMI Modeling, Architecture, Methodology and Style Guides http://wiki.hl7.org/index.php?title=CIMI_Modeling,_Architecture,_Methodology_and_Style_Guides
  • CIMI Practitioners Guide to HIT Interoperability http://wiki.hl7.org/index.php?title=CIMI_Practitioners%27_Guide
• US CORE Wiki https://oncprojectracking.healthit.gov/wiki/display/TechLabSC/DAF+Home
• Skin and Wound Assessment Pilot Wiki http://wiki.hl7.org/index.php?title=PC_CIMI_Proof_of_Concept
• SNOMED CT: http://ihtsdo.org/index.html
  • Expression Constraint Guide https://confluence.ihtsdotools.org/display/DOCECL/Expression+Constraint+Language+-+Specification+and+Guide

Acknowledgement

Collaboration that Grows with a Strong SME Base

• the contents of this Guide came from
  • CIMI Co-Chairs
  • Linda Bird BIT, IHTSDO
  • Galen Mulrooney, FHA and VA contractor
  • Richard Esmond, PenRad LLC
  • Stanley Huff, Intermountain Healthcare
• Members of the following SDOs
  • IHTSDO, POC: Linda Bird BIT
  • HL7 Work Groups (PC, CDS, CIC, EHR, SOA, Vocab)
  • The Open Group Healthcare Forum, Jason Lee POC
  • ISO/CEN, POCs: Gerard Freriks, William Goossen, Gary Dickinson
• Federal Agency staff and contractors
  • Department of Defense, Veterans Administration, Interagency Program Office
  • Federal Drug Agency, Center for Disease Control
  • Office of the National Coordinator (ONC), Office of Science and Technology (OST)
  • Federal Health Architecture (FHA)
• Members of the following Healthcare Organizations
  • Intermountain Healthcare, Kaiser Permanente, Mayo, MITRE, PenRad, Inc., Results4Care
  • HSPC and other interested parties
• Faculty, Staff and Students
  • Duke University
  • The University of Utah

Architectural Framework

To encourage Information Model consistency, traceability and reuse:

• CIMI collaborates with other workgroups and organizations, which are governed apart from HL7.
• These projects are voluntarily being harmonized using CIMI Principles and Reference Models (e.g., PC, CQI, CDS, EHR, HSPC, etc.).
• Externally-developed CIMI-compliant information-models can be donated to HL7 for
  • HL7 configuration management, peer review and standardization.

CIMI Principles

CIMI Principles are peer reviewed and voted on at workgroup meetings.

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.

CIMI Reference Models

• Reference: Jan 2017 CIMI Architecture, Methodology and Style Guide from Ballot

The CIMI Architecture consists of the three Basic Meta Model (BMM) Reference Model layers and two Archetype layers shown here.

The CIMI Reference Model is expressed using the OpenEHR Basic Metamodel (BMM) Language. The archetype layers are expressed using the OpenEHR Archetype Definition Language (ADL). While reference model modules define classes, attributes, and class hierarchies, the archetype layers only specify progressive constraints on the reference model but do not introduce new classes, attributes, and class-class relationships.

1. The CIMI Core BMM Reference Model provides the core granularity of the CIMI model and introduces its top-level classes such as the DATA_VALUE class and the LOCATABLE class. This reference layer module defines the CIMI primitive types and core data types.
2. The CIMI Foundational BMM Reference Model is closely aligned to ISO13606 and the OpenEHR Core Reference Model. It defines foundational CIMI clinical documents and clinical record patterns. It also introduces the PARTY, ROLE, and PARTY_RELATIONSHIP patterns and defines the top-level CLUSTER class for complex CIMI type hierarchies. CQI Knowledge Artifacts may also leverage this layer.
3. The CIMI Clinical BMM Reference Model consists of the classes derived from existing CIMI archetypes, the FHIM, QUICK, vMR, and QDM. This layer defines the set of 'schematic anchors' (to borrow Richard Esmond's term) or core reference model patterns from which all CIMI archetype hierarchies and ultimately Detailed Clinical Models (DCMs) derive. Requirements for this layer come from FHIM, vMR, QDM, QUICK, FHIR US Core, SDC, etc...
   1. The 'goal' is to define the reference models with low FHIR transformation costs where feasible noting that we will inherently have some divergence due to the different requirements underlying both models.
   2. Galen points out that, FHIM’s expressivity will not carry over to CIMI DCMs given the models' different requirements (e.g., FHIM includes finance and accounting).
4. The CIMI Foundational Archetype Patterns define the top-level constraints on the CIMI Reference Model. These typically consist of attribute formal documentation and high level attribute semantic and value set bindings. Archetypes at this layer will provide the foundational requirements for future US Core and QI Core profiles. Future pilots will explore the generation of US Core and QI Core archetypes from these CIMI archetypes.
5. The CIMI Detailed Clinical Model Layer represents the set of leaf-level constraining profiles on the foundational archetypes to create families of archetypes that only vary in their finest terminology bindings and cardinality constraints. This layer is intended to support clinical interoperability through an unambiguous specification of model constraints for information exchange, information retrieval, and data processing.

From layers 1-5, we define the set of transformations (e.g., SIGG (MDHT, MDMI)) to generate the corresponding FHIR profiles including the US Core and QI Core profile sets. Note that FHIR profiles can be generated from the various levels of the archetype hierarchy depending on requirements. The lower down in the hierarchy, the more prescriptive the profile is in terms of constraints. Much like ADL Archetypes, FHIR profiles can be layered.

It is important to note that some FHIR profiles may be derived from the Foundational Archetype Layer (e.g., US Core, some QI Core profiles, some CQIF profiles on PlanDefinition, Questionnaire and ActivityDefinition, etc...) and others from the DCM Layer (e.g., bilirubin, HgA1c, etc...). In other words, the arrow for FHIR Profiles stems out of the outer box rather than the last of the inner boxes (the DCM box).

BMM Hierarchy

The CIMI Reference Model is done in UML and contains three Basic Meta-Model (BMM) hierarchical layers of Pattern structures aka Clinical Pattern structures:

1. Each Pattern contains a single class or group of related classes that can be constrained by ADM or AML archetypes in order to define a family of related and consistent Detailed Clinical Models (DCMs), such as types of
   1. Lab Orders,
   2. Procedures,
   3. Skin Wounds, etc.
2. The three layer CIMI Reference Model contains modular sets of (Clinical) Patterns, which can be used to create leaf-level DCMs:
   1. Core BMM Reference Model Level-1 defines core types and two root classes:
      1. Data Types
      2. Data Value Types
      3. LOCATABLE class, from which the majority of CIMI domain classes derive and
      4. ASSOCIATION_CLASS from which we derive
   2. Foundational BMM Reference Model Level-2 defines the foundational underpinnings of the CIMI model.
      1. This structure aligns with the ISO 13606 EHR and the OpenEHR Reference Models.
      2. The Foundation Reference Model defines the top-level hierarchies to derive lower-level classes and clinical patterns:
      3. CLUSTER,
      4. COMPOSITION,
      5. CONTENT,
      6. PARTY,
      7. ACTOR,
      8. ROLE,
      9. PARTICIPATION, and
      10. PARTY_RELATIONSHIP.
   3. Clinical BMM Reference Model Level-3 builds upon the Level-1 Core and Level-2 Foundation to specify the Level-4 CIMI Preferred Archetypes aka Semantic Anchors for DCMs.
3. The CIMI Core and Foundational reference modules provide the core semantics, structure, and granularity of the CIMI model.
4. the CIMI Clinical Reference Model module provides an intuitive domain semantic-anchor view for DCMs.
5. This modular approach allows for
   1. additional, domain-specific Level-3 Reference Archetypes and Level-4 Patterns
   2. alternate iso-semantic patterns to be introduced at the appropriate level in the model.
   3. Over time, it can be expected that the layers will hierarchically become more stable
      1. Level-1 Core BMM purposely being most stable.
      2. Level-2 Foundation BMM might change, such as when new underlying taxonomy-structures are added.
      3. Level-3 Clinical BMM might change, such as when new clinical disciplines and data-structures are added.
      4. Level-4 Reference Archetypes changing, such as when new domains are added.
      5. Level-5 DCMs under a constant-state of flux, such as when new information-exchange requirements are added.
   4. If change occurs, it should be backward-compatible with-respect-to lower layers and legacy-DCMs.

Archetype Hierarchy

The CIMI archetype hierarchies form the second part of the CIMI model. These hierarchies serve two primary purposes:

1. They enable the progressive application of constraints on reference clinical patterns including the specification of terminology constraints that assign formal meanings to both model attributes and their range.
2. They allow for the definition of sets of models whose members vary solely based on the constraints they apply to a common underlying reference model pattern. Archetypes can specialize more general archetypes in ADL. They do so by progressively constraining the underlying reference model pattern in a manner that is consistent with and not contradictory to the constraints specified in archetypes higher up in the hierarchy. Examples of constraint refinements are listed below:
   1. A top-level archetype restricts the range of Ingredient.substanceCode to the set of all concepts subsumed by the SNOMED CT concept ‘Pharmaceutical/biologic product’. A downstream specialization of this archetype restricts the Ingredient.substanceCode to ‘Metoprolol’.
   2. A top-level archetype assigns the SNOMED CT concept ‘Procedure site (attribute)’ as the semantic binding of the attribute Procedure.site. A downstream specialization of this Detailed Clinical Models (DCMs), highly specific models that enable the interoperable exchange of clinical information, typically reside at the leaf-level of CIMI archetype hierarchies. The cumulative constraints applied on a DCM are intended to be precise enough to allow for the unambiguous exchange of interoperable clinical information and thus constitute highly specific constraints on the underlying reference model pattern.

Introduction

Core Modeling Principles

The following principles guide CIMI’s modeling approach:

1. CIMI favors a design by specialization over a design by constraint approach. This approach is summarized as follows:
   1. if a class has a number of specializations, each requiring a different set of attributes, common attributes are represented in the parent class while child attributes are added to the appropriate specializations. An alternative approach may be to include the union of all attributes in a single class and constrain attributes out at the archetype level.
      1. The former approach is preferred over the latter except in certain cases.
      2. For instance, if a specialization differs from its parent by a single attribute, the inclusion of the attribute in the parent class may be preferred over the creation of a new class.
2. CIMI generally favors the definition of explicit attributes in the reference model over the slicing of lists in archetype definitions. The attribute subset pattern is achieved by defining a multi-cardinality attribute in the reference model and specifying subsets of the list elements in archetypes.
   1. For instance, one may specify that the LOCATABLE class, the supertype of all CIMI classes, has an attribute called participation of type PARTICIPATION and whose cardinality is 0..*.
   2. In an archetype, one may then constrain the participation attribute in the following manner.
      1. The first element of the list represents the author.
      2. The second element represents the data enterer.
      3. The third element represents the location where the authoring activity took place.
      4. The fourth element of the list represents the system where the information was recorded.
      5. While such subsets are allowed in both UML and ADL, CIMI generally avoids their use and favors the explicit representations of such subsets as full-fledged attributes in the model. For instance, CIMI explicitly adds an attribute for the
         1. agent of an activity,
         2. the location of an activity,
         3. the entity involved in the performance of the activity, and so on.
   3. The motivation for this approach stems from the fact that CIMI is a logical model rather than a physical model and favors greater reference model expressivity over physical patterns that enable better economies of structure.
3. CIMI may offer a number of variants for a given attribute.
   1. For instance, CIMI defines bodyLocation: AnatomicalLocation and bodyLocationPrecoord:
      1. CODED_TEXT to support both a coded and a post-coordinated anatomical location.
   2. Similarly, Assertion.dueToCode:CODED_TEXT and Assertion.dueTo:
      1. ClinicalStatement allow users to link an assertion to another clinical statement or simply define its type to be CODED_TEXT.
   3. Archetypes will need to specify a single property in such cases in order to avoid semantic collision.

Model Restructuring Guidelines

1. Align/Harmonize CLIM (SOLOR, FHIM, CQF, CEMs, DCMs, FHIR)
   1. Simplify models (managing complexity) to provide real-world clinical-data interoperability by
      1. Separating the CIMI Reference Model into 5 layers
         1. Eliminate duplication and separate structure from semantics #### using SOLOR terminology with SNOMED Expression
         2. Reference BMM is constructive consisting of more specific sub-classes of the higher-level models; and where
         3. ADL or AML Archetypes are constrained subclasses of the Reference BMM Semantic Anchors.
         4. Conceptual Mind Maps are used to present the big-picture
         5. BMM UML is used to derive the FHIM-DCM touchpoints
         6. Clinical Archetypes
   2. Restructure FHIM, DCMs, CQF in-accordance-with CIMI BMM “Semantic Anchors”
      1. The CIMI Core, Foundational and Clinical Reference Model BMM; where,
      2. Semantic Anchors are BMM leaves (FHIM-DCM and CQF-DCM touch-points) used to specify DCMs
   3. Modify the models so they’are semantically consistent
      1. Align CIMI BMM with FHIR Core, US Core and FHIR data types
      2. Eliminate duplication and separate structures from semantics, using SOLOR terminology with SNOMED Expressions
      3. Each lower-level model (Reference BMMs and Architype models has to be consistent ; where,
         1. they provide clinically-specific building blocks for the “leaf” DCM archetypes that will actually be used for defining/constraining clinical data in FHIR, CDA, etc.  
         2. Reference BMM is constructive consisting of more specific sub-classes of the higher-level models; and where
         3. ADL or AML Archetypes are constrained subclasses of the Reference BMM Semantic Anchors.
         4. As an example: The Data classes associated-with EvaluationResult-Quantitative-Lab includes SerumGlucose Class and its value sets
      4. The advantage is that the above maximize interoperability and minimize tooling mapping requirements
         1. Ideally, the CIMI logical model leaf nodes are FHIR Structure Definitions and no mapping is required.
   4. Document and Communicate CIMI Reference Architecture (BMM and Architypes)
      1. with further explanation and justification of
         1. Modes’ complex layers and how they specifically fit together and are all needed
         2. How the models and tools provide real-world clinical data interoperability
      2. In support of Federated model development and governance

Terminology Alignment

Information models are often developed independently of clinical ontologies. As a result, many information models align poorly with the terminologies or ontologies upon which they ultimately depend for their formal semantics. Moreover, by not explicitly specifying the model’s semantics, the meaning of the model is left open for interpretation during implementation further hindering interoperability. In an effort to better align models of use with models of meaning, the Clinical Information Model is designed to align closely with the SNOMED CT Concept Model wherever such an overlap exists. In CIMI, the model’s formal semantics are specified through terminology bindings defined at the archetype level. These terminology bindings occur at three levels:

1. To define the relationship between the attribute and its class. CIMI model attributes are aligned with their corresponding SNOMED CT concept model attributes when such a correspondence exists.
   1. An example in the CIMI Finding Assertion Model, the body site data element aligns with the SNOMED CT concept 363698007|Finding site (attribute)|from the SNOMED CT Clinical finding concept model.
2. To define the semantics that the attribute can contain. CIMI model attribute ranges are aligned with the ranges specified for their corresponding SNOMED CT concept model attribute when such a correspondence exists. Using the example above, the range for the Body Site is the range defined in the SNOMED CT technical guide for Finding Site Anatomical or acquired body structure | 442083009 (<<)
3. To define the post-coordinated representation of some of the semantics of the archetype using the SNOMED CT concept model. CIMI preferred models favor post-coordination in the model rather than in the terminology.
   1. In some cases, CIMI archetypes may be associated with SNOMED CT expressions, provided that the expression conforms to the constraints specified for the flattened archetype.
   2. For instance, a CIMI Clinical Statement may be associated with a SNOMED CT Situation with Explicit Context expression or a pre-coordinated code.
   3. We are currently investigating the use of SNOMED CT Templates for such bindings

Core-BMM (2017-01 HL7-Ballot)

The CIMI Core BMM Reference Model provides the core granularity of the CIMI model and introduces its top-level classes such as the DATA_VALUE class and the LOCATABLE class. This reference layer module defines the CIMI primitive types and core data types.

Foundation-BMM (2017-01 HL7-Ballot)

The CIMI Foundational BMM Reference Model is closely aligned to ISO13606 and the OpenEHR Core Reference Model. It defines foundational CIMI clinical documents and clinical record patterns. It also introduces the PARTY, ROLE, and PARTY_RELATIONSHIP patterns and defines the top-level CLUSTER class for complex CIMI type hierarchies. CQI Knowledge Artifacts may also leverage this layer.

Clinical-BMM 2017 Working-Draft

• The CIMI Clinical BMM Reference Model consists of the classes derived from existing CIMI archetypes, the FHIM, QUICK, vMR, and QDM. This layer defines the set of 'schematic anchors' (to borrow Richard Esmond's term) or core reference model patterns from which all CIMI archetype hierarchies and ultimately Detailed Clinical Models (DCMs) derive. Requirements for this layer come from FHIM, vMR, QDM, QUICK, FHIR US Core, SDC, etc...
  • The 'goal' is to define the reference models with low FHIR transformation costs where feasible noting that we will inherently have some divergence due to the different requirements underlying both models.
  • Galen points out that, FHIM’s expressivity will not carry over to CIMI DCMs given the models' different requirements (e.g., FHIM includes finance and accounting).

Clinical_Statement Overview

Clinical_Statement (Top View)

Clinical_Statement-Topic

Clinical_Statement-Association

Clinical_Statement-Context

Clinical_Statement-Data_Packages

Foundation Archetypes

CIMI_Foundational_Architype_Patterns_Mind_Map.jpg TBD when materials are available from CIMI WG

• The CIMI Foundational Archetypes Patterns define the top-level constraints on the CIMI Reference Model. These typically consist of attribute formal documentation and high level attribute semantic and value set bindings. Archetypes at this layer will provide the foundational requirements for future US Core and QI Core profiles. Future pilots will explore the generation of US Core and QI Core archetypes from these CIMI archetypes.

Detailed Clinical Models (DCMs)

• The CIMI Detailed Clinical Model Layer represents the set of leaf-level constraining profiles on the foundational archetypes to create families of archetypes that only vary in their finest terminology bindings and cardinality constraints. This layer is intended to support clinical interoperability through an unambiguous specification of model constraints for information exchange, information retrieval, and data processing.

Skin-Wound DCM ( 2017 Working-Draft)

• Patient Care Workgroup Telecom (2017-02-09-1000 ET)
• Attendees: Jay, Susan, Richard, Claude, Steve

1. Skin Wound content & scope
   1. Braden
   2. Skin Assessment
   3. Wound Assessment, with Pressure Ulcer specialization
   4. No Skin Risk Assessment (out of scope)
2. Schedule
   1. Feb 13: Requirements UML and Terminology spreadsheet finished
   2. Feb 13 to Mar 3 - VA verification and validation of spreadsheet
      1. Diagram
      2. Data-Element and Value-Set Spreadsheet
   3. Mar 8: Presented at LOINC conference by Susan

UML (2017-02-10)

Mind Map (2017-02-10)

Legends

UML

• UML models are being used for CIMI BMM; where, UML relationships are shown above:
• Many figures were done in the FreeMind open-source Mind Maps; where, the legend, download information and basic structure are given below.

Mind Maps

Tools

FHA sponsored FHIM and SIGG (MDHT and MDMI) have the capability for generating FHIR implementation models. With the adoption of CIMI information requirements (informed by FHIM), SIGG can generate CIMI archetypes and FHIR Structure Definitions (FSDs) and compare them to their source archetypes to confirm the process.

• FHIM & MDHT could then serve as one of the “translator” tools.
• MDMI can serve as one of the "mapping" tool.
• Part of the tool authoring activity is to add new SOLOR terminology content as necessary to meet requirements derived from existing specifications; where,
  • there is a versioning and publication step between the SOLOR box/layer and the CLIM box/layer. 
  • there is a versioning and publication step between the CLIM box/layer and MDHT/MDMI; where, the arrows metaphor conveys the publication step. 
• IHTSDO workbench with ISAAC plugin authoring tools are in the SOLOR box/layer. 
• ADL workbench, enterprise architect UML tool, etc. need to be able to import SOLOR content, so they can build the profiles using the SOLOR terminology foundation…

• SOLOR (SnOmed LOinc, Rxnorm) terminology authoring project can provide the terminology foundation for FHIM, CQF, DCMs and FHIR profile and extension development. SOLOR creates Lightweight Expression of Granular Objects (LEGOs) with description-logic semantics aka SNOMED expressions; where, SOLOR can be treated as a single, coherent terminology systems that covers essential healthcare domains.
• FHIM is FHA's Federal Healthcare Information Model, which is a high-level logical healthcare model, which covers approximately 36 clinical domains and has been vetted by Federal Agency SMEs and clinicians. Details are available at www.FHIMS.org
• CIMI is Clinical Information Model Initiative which defines Terms-of-Reference AKA Principles, modeling style guidelines, a CIMI Core Reference Model, Reference Archetypes, Patterns and Detailed Clinical Models (DCMs); where, a CIMI Model is a clear, complete, concise, correct and consistent logical semantic-and-syntactic description of a healthcare concept, which can be instantiated as a computable implementation object that is interoperable among systems.
• CQF is Clinical Quality Framework to support Continuous Quality Improvement (CQI) with a Quality Improvement and Clinical Knowledge or QUICK data model, Clinical Quality Language (CQL) supporting clinical decision support (CDS) and clinical quality measures (CQM).
• FHIR defines a set of "Resources" that represent granular clinical concepts; where, CIMI's CLIM and tooling can be used to create consistent FHIR and other implementation paradig profiles and extensions. SIGG creates FHIR Structure Definitions (FSDs); where, FHIR tools can convert FSDs into FHIR Resource extensions and profiles. FHIR Core Resources, Profiles and Extensions can be managed in isolation, or aggregated into complex documents.

The following is a list of authoring tools that might be pertinent to investigate as we develop CIMI tooling:

• Terminology Browsers
  • IHTSDO browser
• Value Set Editors
  • art-decor
  • Apelon
  • National Library of Medicine Value Set Authority (VSAC)
• CIMI Model Authoring Tool
  • ADL 2.0 web based archetype and template editors
  • Results 4 Care tool for online authoring of clinical content for Detailed Clinical Models
  • Results 4 Care UML template and Model creation / validation tool for Detailed Clinical Models
  • [Spanish ADL Authoring Tool from Spain (Gerard Freriks to provide info)]
• FHIR Profile Editors
  • Firely Forge FHIR profile editor
  • Model Driven Health Tools (MDHT)
• CIMI to FHIR Profile Conversion
  • Model Driven Message Interoperability
  • FHIR "logical model" work
• CIMI (mini)RM UML
  • Sparx Enterprise Architect Project 3.0.5 EAP
  • BMM Extension

References

• 2016 CIMI-Sponsored HL7 IIM&T Investigative Study
  • HL7 Project Scope Satement: https://1drv.ms/w/s!AlkpZJej6nh_k9dYlvNWaZ3DLPKSYg
  • Briefing Slides: https://1drv.ms/p/s!AlkpZJej6nh_k9dE-b_DAO8HSNNT6Q
  • Final Report, Sep 2016: https://1drv.ms/w/s!AlkpZJej6nh_k9dQ2qQnRuQM8gbu8A
  • Technical Forum Summary, Aug 2016: https://1drv.ms/w/s!AlkpZJej6nh_k9gyRVADgOvM5SlJkQ
  • Preliminary Report, Aug 2018 https://1drv.ms/w/s!AlkpZJej6nh_k9YPmsR8Hl6zTlQ0NQ
  • Note that many networks block the use of clickable links; where,
    • You must copy the link into a browser to access the content.
    • If links don’t work on a VPN (e.g., DoD and VA networks), try accessing them directly (without VPN)
• Jan 2017 CIMI Architecture, Methodology and Style Guide from Ballot
• Clinical Element Models (CEMs)
  • CEM Browser
  • ClinicalElement CIMI Browser Models published in a web browser, processed by ADL workbench and available as ADL, XML, JSON, graphical tree, etc
  • GitHub CIMI Models managed in Git version control repository: GitHub
  • Browser pubs periodically refreshed from GitHub & may be out of synch
• CIMI Overview Slides by Stan, 5/19/16
• CIMI Reference model requirements
• CIMI Artefacts on GitHub
• CIMI Wiki@Mayo (2010-2015)
• CDS WG Wiki
• CDS Standards Wiki
• CQI wiki
• Clinical Observation Modelling by Walter Sujansky Jan 31, 2017
• EHR WG Wiki
  • EHR Immunization Profile with mapping to FHIM, CIMI, FHIR
• FHIM website
• HSPC website
• FHIR Website
• FHIR Infrastructure Wiki
• ISO 13606 Information architecture for communicating EHRs
  • Part 1: Reference Model and Data types
  • Part 2: Archetype Object Model v2.0
  • Part 3: Terminologies
  • Part 4: Information security
  • Part 5: Messaging
• ISO 13940 ConSys, ISO 13967 HISA, SIAMM
• ISO 13972 Detailed Clinical Models(DCMs)
  • Detailed Clinical Models: A Review, 2010
  • Detailed Clinical Models: Representing Knowledge, Data and Semantics in Healthcare Information Technology
• MDHT website
• MDMI website
• MAX Artefacts
  • MAX Video
• Open Group Healthcare Forum
• OpenEHR and ADL language and tools
  • OpenEHR Reference Model (RM)
  • OpenEHR ADLWorkbench tool
  • OpenEHR Clinical Knowledge Management (CKM) repository
• Patient Care Wiki
• SNOMED Training Materials
• STAMP Overview, 1/15/17
• VOCAB Wiki

Jan - Sept CIMI Investigative Study / Task Force Supporting documents

• HL7 Project Scope Statement
• Briefing Slides
• Briefing Slides Notes Pages
• Aug 2016 Preliminary Report
• Aug 2016 Technical Forum Summary
• Sep 2016 Final Report
• Work Breakdown MPP
• Work Breakdown PDF
• Work Breakdown XLSD
• CIMI Practitioners’ Guide

Appendix A: CIMI Overview (Slides)

Our IT objective is to make the appropriate data available when it is needed, where it needed and how it is needed. We plan to integrate existing models, with semantically-consistent computable-data, including provenance data (who, what, when, where, why, how) across different platforms, e.g., population health, Clinical Decision support, EHR patient documentation systems, etc. using tooling to generate various implementation styles, including HL7 Fast Healthcare Interoperable Resources (FHIR).

Problem: Skyscraper Analogy

• BLUF (Bottom Line Up Front): As is: no shared terminology content (floor 1), no shared information models (floor 2), then they are building from the 3rd floor up. No shared value from the 3rd floor up. 
• Future State: shared terminology content (floor 1), shared information models (floor 2), sharable value built on floors above. 
• In a perfect world the following would be done concurrently and with close collaboration
  • Recommended Solution Part 1: We integrate SOLOR into FHIM, Concurrently, resolving SOLAR gaps
  • Recommended Solution Part 2: We integrate CIMI, FHIM and CQF 
  • Recommended Solution Part 3: We follow Agile refinement cycles through pilots and implementations
  • Recommended Solution Part 4: We develop adequate documentation, test cases, fixtures and supporting resources
• In the real world, we are asking:
  • the Federal Partners to provide resources to make efficient and effective progress in the near, mid and long term.
  • the Federal Partners to work together to deliver—in an ongoing way—a single integrated terminology system (SOLOR), that meets all US regulatory equirements, while simplifying implementation for developers.
  • the FHA to facilitate Federal Partner governance and configuration management of this work
  • The ONC OTS to endorse this initiative and facility resources
  • We are asking the IPO to provide coordination and facilitation
  • We are asking HL7 to facilitate
    • international, commercial and academic peer review and
    • ballot governance and configuration management.
    • Coordination of an ISO ballot (this will be several years from now)
• Analogy of the Challenge: Today’s efforts occur as if we’re always trying to build the ultimate skyscraper, starting on the 3rd Floor.
  • Inconsistencies exist/become extended producing transformational (mapping) efforts = models, models everywhere
  • The problem is that today’s healthcare systems do not capture information and its context consistently, and consequently, they cannot easily share-or-merge information from different sources to create a computable operational-picture (aka longitudinal patient-records, care plans, clinical knowledge and other shared healthcare information across time, multiple care locations and differing contexts).
  • If continued and unchecked, even the best of implementation accelerators, like FHIR with its extensions and profiles, allow far too much implementation variation; where, each project often creates, from scratch, yet, another information model, e.g. through a mapping exercise.
  • The missed opportunity is to leverage a shared logical Reference Information Model minimizing the duplicative-work, avoiding inconsistencies and avoiding the necessity to engage these SMEs, these resources and our larger community. This is the “models, models everywhere phenomenon ”.
  • As an example, Standards, in general, use different formats and rules for ‘simple’ things like: name, address, dates. Resulting in EHR-systems that after decades cannot uniformly exchange this ‘simple’ ubiquitous data; let alone ‘complex’ clinical health data.
    • the HL7 EHR Interoperability workgroup, in its analysis “Record Entry Lifecycle Event Metadata using FHIR,” found substantial provenance (who, what, when, where and how) inconsistencies among FHIR resources .
      • http://wiki.hl7.org/index.php?title=EHR_Interoperability_WG
    • The SOLOR/LEGO team found FHIR tries to define things such as attributes for anatomy, that are not based on a particular model of anatomy, and thus you get semantic overlap, with the burden of reconciliation, which may not even be possible, if left to the end user.

SOLOR Standardizes Terminology

• Gentamicin is an example of the non-consistant terminologies
• Why we can simplify now?
  • Licensing models have changed so we can implement native standards
  • LOINC and SNOMED are integrating content via a shared logical model
  • RxNorm can be extracted into a shared logical model
  • SNOMED + LOINC + RxNorm + post-coordination provides comprehensive coverage for typical clinical data representation requirements 
• In distinguishing terminology and model capability: Concrete Example
  • In SOLOR / RxNorm = description of dosage of penicillin and what it means;
  • With the use of the FHIM it will tell you if its part of substance administration and/or adverse event.
  • RxNorm doesn’t do that
• CIMI can offer a DCM that providers can use in the detailed execution of a particular domain

Integrated Model Stack

As shown in this figure,

• each model contributes to an Integrated Model Stack, the proposed operational architecture involves the definition of clinical knowledge in the form of formally modeled information artifacts that could be used in compose-able health records, care plans and other shared clinical data.
• the combination of SOLOR, FHIM, CIMI DCMs and CQF KNARTs while complementary fulfill a different information modeling contribution.
• SOLOR is SNOMED with an extension for LOINC and RXNorm.
• FHIM is Federal Health Information Model
• CIMI DCMs is Clinical Information Model Initiative Detailed Clinical Model
• CQF KNARTs is Clinical Quality Framework Knowledge Artefacts

Federated Information Model Development

Consistent FHIR extensions-and-Profiles can be achieved by:

• Following CIMI Principles and Reference Architecture (see principles and Architectural Framework sections)
• Using Model Driven Development tools, such as SIGG (MDHR, MDMI) (see tools section)
• Governance and Configuration Management of artefacts. (see Governance section)

Federated Software Development

• Ideally, implementers can meet Project Needs by reusing FHIR Extensions and Profiles, from a FHIR Artefact repository
• Alternately,
  • CLIM models can be refined to meet requirements,
  • Tools (e.g., SIGG) can use CLIM models to create needed implementation FHIR artefacts.

Federated FHIR Extensions-and-Profiles Development-Lifecycle

High Level Architectural View

• The High-Level Architectural-View slide shows how CIMI-FHIM-SOLOR-CQF Integration enables Consistent “Foundational Health Information” and “Common Clinical Information” to support Computable Semantic-Interoperability in “Continuum of Care” Implementations and aggregated, portable and computable patient-records, care plans, clinical knowledge and other shared healthcare information.
• The top Business Architecture typically includes:
  • Legal, ethical requirements, policies and rules
  • Societal/organizational (e.g., cities, states and countries) requirements
  • EHR-system requirements
    • Vocabulary (Shared: Syntax, words, phrases)
    • Ways to present and enter data via screens, forms, etc.
    • Notions about archiving/documentation/information security
    • Care quality measurement and improvement through clinical knowledge
• The center Information architecture, includes:
  • FHIM, EHRS-FM and CQF, which consolidate Health domain requirements
  • CIMI and LEGO; where, LEGO is the Q&A subset of CIMI, using the CIMI Observation Model and Description Logic.
  • Other Info Models, e.g., CQF, SDC, DAF, V2, CCD, etc. –
  • SOLOR Terminology and Value Sets based on SNOMED-CT expressions.
• The bottom Solution Architecture includes:
  • EHR-systems with CCDA, FHIR, NIEM, JSON API, RDF, HL7 V2 & V3 interfaces among EHR-system Services.
  • Supporting services (Terminologies, Terminology servers (e.g., SOLOR), Value set servers, Protocol servers, Clinical guideline servers, clinical decisions support servers, Presentation/data input services, Exchange services)
  • Technical Infrastructural services: networks, internet, information security,
  • Hardware and Software

IIM&T Software Development "on FHIR"

1. The Figure shows potential Use-Case processes and products; where,
   1. Path 1 7  8 represents the ideal case; where, reusable FHIR-based components are available.
   2. Path 1  2  3  4  7  8 is when new requirements are met locally; but, HL7 Items A-C are not updated.
   3. Path 1  2  3  4  5 6  7  8 is when new requirements are met locally; and, HL7 Items A-C are updated.
   4. Step 9 is periodically done to configuration manage, version control, publish and standardize HL7 Items A-C.
2. Our objectives are
   1. CLIM and FHIR artifacts are tool based and feely available .
   2. To produce quality documentation and training videos to enable:
      1. 1, 2, 3, 4 done by Clinical Business-Analysts
      2. 2, 3 and 4 governance done by the organizations doing the work
      3. 5, 6 and 9 governance done by the appropriate HL7 workgroups
      4. 7 and 8 done by Software Developers
3. At the January HL7 Workgroup meeting CIC requested further clarification / detail of the Figure to indicate where and how clinicians can efficiently participate in the process.
   1. As an example, when Michael van der Zel does Business Analysis / FHIR Development, he generally follows these steps:
      1. Understand and document the business process (aka Use-Case) (Figure, process 1)
      2. Detail the process into steps
         1. EHRS-FM might help determine functional requirements and their conformance criteria
         2. Determine the needed information for each of the process steps (inputs and outputs)
         3. EHRS-FM can help because it has a mapping to FHIM and FHIM has a mapping to FHIR
         4. FHIM might also be used directly
         5. Find existing models and terminology (DCM, FHIR, etc., (Figure, Items A. and C.)
         6. Create / adjust / profile DCM or terminology, if needed (Figure, processes 2 & 3)
         7. Find mapped FHIR resources or map / create / profile FHIR Resources from DCM logical models identified in previous steps. (Figure, process 4)
         8. Use existing FHIR implementation to realize the system (deploy the profiles) (Figure 1, process 7 and Item C)
         9. Do Connecthatons (Figure, process 8)
   2. Michael believes the process analysis step is very important and should be made explicit; where, CIMI’s CLIM is about logical models that are transformed (using predefined mappings) to implementation models (FHIR profile Resources). For the transformation of CLIM, we will explore the use of the SIGG and FHIR tooling. So, we intend to express CLIM as FHIR Logical Models AKA FHIR Logical Structure Definitions), using SIGG tooling, and then use FHIR mapping to generate FHIR resource profiles, analogous to what ClinFhir (David Hay) is doing. For testing software, Michael thinks the Connectathons are very important.
4. Following the Figure, a software (SW) project will follow some combination of these use case steps:
   1. Do Business and FHIR Analysis to determine system requirement-specifications and conformance criteria (Figure 1, process 1); where, EHRS-FM might be used; because, it is traceable to CLIM (FHIM) and CLIM will be traceable to FHIR.
      1. Note that the HL7 Service Aware Interoperability Framework (SAIF) Enterprise Compliance and Conformance Framework (ECCF) can be used to maintain a project’s requirements-specifications, design and test artifacts.
   2. Maintain the FHIM, CIMI, CQF, etc. models (Figure 1, process 2) to meet the requirements; where, these models may be updated and bound to SOLOR . This work can be done with an UML tool or the OpenEHR ADL workbench.
   3. Maintain SOLOR (SNOMED with extensions for LOINC and RxNorm shown as Figure 1, process 3). If appropriate SOLOR concepts which do not exist, can be added using the IHTSDO workbench with ISAAC plugin. Processes 2 and 3 are closely related and may iterate back and forth or may be done simultaneously.
   4. Use SIGG (MDHT, MDMI) to generate the needed implementation artifacts (e.g., FHIR structure definitions for profiles or extensions, CDA or NIEM IEPD specifications can also be done).
   5. Governance involves change control, configuration management and version control; where, CLIM governance is generally federated. That is, local development organizations govern their own artifacts and may wish to provide versions to HL7. Appropriate HL7 workgroups govern HL7 artifacts and ballots.
   6. Similarly, FHIR governance is generally federated; where, local development organizations govern their own artifacts and may wish to provide versions to HL7. At HL7, FHIR-compliant reusable-artifacts are governed by the FHIR workgroup.
   7. Develop software components are generally done by commercial, government and academic organizations and their contractors. HL7 provides artifacts, documentation and training to empower these efforts.
   8. Test and use software components is generally done by commercial, government and academic organizations and their contractors.
   9. Periodically, CIMI and FHIM artifacts are balloted as HL7 and/or ISO standard, which include the set of clinical domain information models (e.g., FHIM covers 30+ domains), CIMI DCMs with SOLAR derived terminology value-sets. Having standard requirements-specification conformance criteria traceable to FHIR implementation artifacts can maximize efficiency and effectivity of multi-enterprise clinical-interoperability. These tool-based standardized clinical interoperability artifacts can be augmented with business, service and resource requirements-specifications conformance-criteria models and implementation artifacts. HL7 and its workgroups have identified best-practice principles and tools supporting its clinical-artifacts, which can provide standardized approaches for government, industry and academic organizations to adopt, train and use. These standard use-cases, conformance criteria models and implementation artifacts can be used and maintained within an HL7 Service Aware Interoperability Framework (SAIF) and Enterprise Compliance and Conformance Framework (SAIF) to support specific business use-cases, process models, acquisitions and/or developments.

FHIR Clinical Reasoning

• In the September 2016 ballot cycle, CQF balloted the FHIR-Based Clinical Quality Framework (CQF-on-FHIR) IG as an STU (Standard for Trial Use). This guidance was used to support the CQF-on-FHIR and Payer Extract tracks in the September 2016 FHIR connect-a-thon. The guidance in the FHIR STU was prepared as a Universal Realm Specification with support from the Clinical Quality Framework (CQF) initiative, which is a public-private partnership sponsored by the Centers for Medicare & Medicaid Services (CMS) and the U.S. Office of the National Coordinator for Health Information Technology (ONC) to identify, develop, harmonize, and validate standards for clinical decision support and electronic clinical quality measurement.
• Part of the reconciliation for the CQF-on-FHIR IG September ballot involved incorporating the contents of the IG as a new module in FHIR, the FHIR Clinical Reasoning module.

The Clinical Reasoning module provides resources and operations to enable the representation, distribution, and EVALUATION_RESULT of clinical knowledge artifacts such as clinical decision support rules, quality measures, order sets, and protocols. In addition, the module describes how expression languages can be used throughout the specification to provide dynamic capabilities. Clinical Reasoning involves the ability to represent and encode clinical knowledge in a very broad sense so that it can be integrated into clinical systems. This encoding may be as simple as controlling whether a section of an order set appears based on the specific conditions that are present for the patient in content in a CPOE system, or it may be as complex as representing the care pathway for patients with multiple conditions.

• The Clinical Reasoning module focuses on enabling two primary use cases:
  • Sharing - The ability to represent clinical knowledge artifacts such as decision support rules, order sets, protocols, and quality measures, and to do so in a way that enables those artifacts to be shared across organizations and institutions.
  • EVALUATION_RESULT - The ability to evaluate clinical knowledge artifacts in the context of a specific patient or population, including the ability to request decision support guidance, impact clinical workflow, and retrospectively assess quality metrics.
• To enable these use cases, the module defines several components that can each be used independently, or combined to enable more complex functionality. These components are:
  • Expression Logic represents complex logic using languages such as FHIRPath and Clinical Quality Language (CQL).
  • Definitional Resources describe definitional resources, or template resources that are not defined on any specific patient, but are used to define the actions to be performed as part of a clinical knowledge artifact such as an order set or decision support rule.
  • Knowledge Artifacts represent clinical knowledge artifacts such as decision support rules and clinical quality measures.
• For 2017, the Clinical Quality Framework initiative will continue to develop the FHIR Clinical Reasoning module and related standards. Specifically, the reconciled changes to the CQF-IG will be applied to the FHIR Clinical Reasoning module and published as part of FHIR STU3 in March 2017. The QI Core profiles will be updated to derive directly from US Core, and the QUICK tooling will be updated to provide conceptual documentation, as well as logical models suitable for use in authoring and evaluating CDS and CQI knowledge artifacts. The CQF initiative is actively working with multiple groups to continue to refine and implement the resources and guidance provided by the FHIR Clinical Reasoning module, including the National Comprehensive Cancer Network, the Centers for Disease Control and Prevention, and the National Committee for Quality Assurance.

SIGG (MDHT, MDMI) Tool

While the overall development plan for SIGG (MDHT, MDMI) has not changed, the timeline and/or path must shift in 2017. FHA will need to cease developmental funding of SIGG this month (January) due to other emergent priorities and the SIGG team is wrapping up final development activity and the documentation component in preparation for disengagement. If the JIF proposal is accepted or the IPO can provide for further development under the FPG JET moving forward, then the SIGG is prepared to continue SIGG development unabated.

Currently the SIGG and the components of the SIGG are being used, and extended, in the following projects:

1. FHIR Proving Ground IPO Jet – MDMI Models are being developed for DoD DES native format and the VA eHMP native format to provide data in conjunction with existing MDMI Models for FHIR Profiles. The use case is a complete round-trip starting with a FHIR query from a FHIR Server, accessing a native server with its native access language, and returning the result to the FHIR service as a FHIR payload. This project has extended the use of SIGG to include not only payload Semantic Interoperability but also a prototype for query Semantic Interoperability. Additionally, there was an alternative approach to the SIGG that was evaluated in this process, and the SIGG was selected as the superior solution.
2. SAMHSA / AHIMA Case Definition Templates – The SIGG tooling, also branded as the SAMHSA Semantic Interoperability Workbench, is being extended to let Subject Matter Experts define and build special purpose templates for clinical pathways. The resulting templates are called Case Definition Templates. In the selection of the appropriate tooling for the project, 11 other products were evaluated.
3. HL7 Structured Documents CDA on FHIR Working Group – The SIGG is being used by the working group to replace manually developed spreadsheets using automatically generate spreadsheets from the CCDA and FHIR MDMI Models. This will support the iterative development process of the Working Group as well as providing more detailed and precise information for the community.
4. VA VLER – The use of the SIGG is being investigated by VA Subject Matter Experts to replace a process that uses manually development spreadsheets for mappings between VLER and CCDA data formats.
5. HL7 FHIR RDF Working Group – Current members of the SIGG team and the HL7 FHIR RDF team are exploring how components of the SIGG and the SHEX / RDF technology can be coupled together to provide even broader capabilities.