Canonical Resource Management Infrastructure Implementation Guide, published by HL7 International / Clinical Decision Support. This guide is not an authorized publication; it is the continuous build for version 1.0.0-ballot built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/crmi-ig/ and changes regularly. See the Directory of published versions

Home

Official URL: http://hl7.org/fhir/uv/crmi/ImplementationGuide/hl7.fhir.uv.crmi				Version: 1.0.0-ballot
Draft as of 2022-05-17				Computable Name: CRMI

Summary

The Canonical Resource Management Infrastructure implementation guide defines profiles, operations, capability statements and guidance to facilitate the content management lifecycle for authoring, publishing, distribution, and implementation of FHIR knowledge artifacts such as value sets, profiles, libraries, rules, and measures. The guide is intended to be used by specification and content implementation guide authors as both a dependency for validation of published artifacts, and a guide for construction and publication of content.

This implementation guide is based upon work in multiple quality improvement and reporting domains. Various implementation guides have developed similar infrastructure-level profiles for conformance and knowledge artifacts. These profiles are being refactored into universal-realm, domain-independent profiles that can then be re-used in future versions of those specifications, as well as included in future versions of the base FHIR specification.

Scope of Use

This implementation guide defines categories of profiles to represent knowledge capabilities for shareable, computable, publishable, and executable knowledge artifacts Profiles. These categories are proposed as a way to help facilitate management of expectations in the content development lifecycle, as well as address common challenges that have been encountered in the development of knowledge artifacts across the quality improvement spectrum, including guideline development, public health reporting specifications, clinical decision support rules, and quality measures. The expectation is that these same challenges will arise in any knowledge artifact development effort, and that the profiles and solutions proposed here will be useful in addressing those challenges.

Artifacts

An artifact in this implementation guide is a FHIR resource whose primary focus is the representation of context-independent knowledge such as a profile, a value set, a decision support rule, or a quality measure specification, as opposed to FHIR resources such as Patient, Organization, or Observation, that are typically focused on the representation of instance data for patients and other healthcare related entities. Most of the resources types for representing artifacts in FHIR are also canonical resources, and often metadata resources. However, some FHIR resources are not defined by FHIR as canonical resources, but may still be used to represent context-independent knowledge (e.g. Medication, or Substance). The use of the term artifact in this IG applies to both canonical resources as defined by the base specification, as well as these non-canonical definitional resources.

The following is a list of FHIR resource types that are considered artifacts, along with a grouping of resource types according to the following priorities:

• Knowledge Artifacts: Representing decision support rules, quality measures, logic libraries, and activity definitions
• Terminology Artifacts: Code systems, value sets, naming systems, and concept maps
• Conformance Artifacts: Profiles, extensions, structure maps, and artifacts related to defining and testing conformance
• Domain Definition Artifacts: Medications, substances, groups, and other domain-related definitional artifacts
• Evidence-based Medicine Artifacts: Evidence, EvidenceVariable, and other artifacts related to supporting evidence-based medicine
• Related Resources: Resources that are not artifacts but are profiled and/or used in this implementation guide

These groupings are listed in priority order, indicating the relative priority of focus for supporting the artifacts in that group.

Artifact Resource Types

• ActivityDefinition
• CapabilityStatement
• ChargeItemDefinition (not considered in this IG)
• CodeSystem
• CompartmentDefinition (not profiled because only HL7 can define CompartmentDefinition instances)
• ConceptMap
• ConditionDefinition (roadmap item)
• ClinicalUseDefinition (R5)
• DeviceDefinition (roadmap item)
• EffectEvidenceSynthesis (not considered, uses EBM resources)
• EventDefinition (targeted for removal)
• Evidence (not considered, uses EBM resources)
• EvidenceVariable (not considered, uses EBM resources)
• ExampleScenario (roadmap item)
• GraphDefinition
• Group (non-canonical definitional)
• ImplementationGuide
• Library
• Measure
• Medication (non-canonical definitional)
• MedicationKnowledge (non-canonical definitional)
• MessageDefinition (roadmap item)
• NamingSystem
• ObservationDefinition (roadmap item)
• OperationDefinition
• PlanDefinition
• Questionnaire
• ResearchDefinition (not considered, uses EBM resources)
• ResearchElementDefinition (not considered, uses EBM resources)
• RiskEvidenceSynthesis (not considered, uses EBM resources)
• SearchParameter
• SpecimenDefinition (roadmap item)
• SubscriptionTopic (R5)
• Substance (non-canonical definitional)
• StructureDefinition
• StructureMap (roadmap item)
• TerminologyCapabilities
• TestScript (roadmap item)
• ValueSet

Knowledge Artifacts (Primary)

• ActivityDefinition
• Library
• Measure
• PlanDefinition
• Questionnaire

Terminology Artifacts (Secondary)

• ValueSet
• CodeSystem
• ConceptMap
• NamingSystem

Conformance Artifacts (Tertiary)

• CapabilityStatement
• CompartmentDefinition
• GraphDefinition
• ImplementationGuide
• MessageDefinition
• OperationDefinition
• StructureDefinition
• StructureMap
• SearchParameter
• SubscriptionTopic (R5)
• TerminologyCapabilities

Domain Definition Artifacts

• ActorDefinition (R5)
• CareTeam (non-canonical definitional)
• ConditionDefinition
• ClinicalUseDefinition (R5)
• DeviceDefinition
• Group (non-canonical definitional)
• Location (non-canonical definitional)
• Medication (non-canonical definitional)
• MedicationKnowledge (non-canonical definitional)
• Practitioner (non-canonical definitional)
• PractitionerRole (non-canonical definitional)
• ObservationDefinition
• Organization (non-canonical definitional)
• SpecimenDefinition
• Substance (non-canonical definitional)

Evidence-Based Medicine (EBM) Artifacts (Quaternary)

If you are using these constructs in R4, this implementation guide provides an approach to supporting content development lifecycle for these resources. However, the EBM-on-FHIR project has made significant changes to these and other Evidence-Based Medicine (EBM) resources in R5 and moving forward. Contact the EBM-on-FHIR project if you have needs for these constructs in R5.

• EffectEvidenceSynthesis
• Evidence
• EvidenceVariable
• ResearchDefinition
• ResearchElementDefinition
• RiskEvidenceSynthesis

Related Resources

• ArtifactAssessment (R5) // Example: https://fevir.net/resources/ArtifactAssessment/122618
• Citation (R5)
• Permission (R5)
• Obligation (R5)
• Requirement (R5)

How to read this Guide

This Guide is divided into several pages which are listed at the top of each page in the menu bar:

• Home: Summary and background information for the Canonical Resource Management Infrastructure Implementation Guide
• Introduction: Detailed overview of the content management lifecycle and the background for this guide
• Content Management
  • Content lifecycle: Content lifecycle of knowledge artifacts
  • Naming conventions: Naming conventions for a package of knowledge artifacts, including canonical base, url and name, and operation definitions.
  • ​Using CQL: Using Clinical Quality Language as part of knowledge artifacts
  • Testing: Simple testing specification to support defining, distributing, and verifying test cases for knowledge artifacts
  • Packaging: Packaging requirements for canonical resources and knowledge artifacts
  • Publishing: Publishing requirements for canonical resources and knowledge artifacts
  • Distribution: Distribution requirements for canonical resources and knowledge artifacts
  • Dealing with unversioned canonical references: Guidance for the use of version manifests to facilitate version management and support stable behavior of artifacts
• Profiles: List of profiles defined for use by knowledge artifacts
• Extensions: List of extensions defined and used by knowledge artifacts
• Operations: List of operations and operation pattern profiles
• Capabilities: Definitions of services and operations in support of authoring, publishing, and distributing canonical resources and knowledge artifacts
• Downloads: Links to downloadable artifacts for implementations.
• Acknowledgements

Must Support

Certain elements in the profiles defined in this implementation guide are marked as Must Support. This flag is used to indicate that the element plays a critical role in defining, sharing, and implementing artifacts, and implementations SHALL understand and process the element.

In addition, because artifact specifications typically make use of data implementation guides (e.g. IPS, US Core, QI-Core), the implications of the Must Support flag for profiles used from those implementation guides must be considered.

For more information, see the definition of Must Support in the base FHIR specification.

Conformance Requirement 1.1 (Must Support Elements):

For resource instances claiming to conform to CRMI IG profiles, Must Support on any profile data element SHALL be interpreted as follows:

• Authoring systems and knowledge repositories SHALL be capable of populating all Must Support data elements.
• Evaluating systems SHALL be capable of processing resource instances containing Must Support data elements without generating an error or causing the evaluation to fail.
• In situations where information on a particular data element is not present and the reason for absence is unknown, authoring and repository systems SHALL NOT include the data elements in the resource instance. For example, for systems using ‘9999’ to indicate unknown data values, do not include ‘9999’ in the resource instance.
• When consuming resource instances, evaluating systems SHALL interpret missing data elements within resource instances as data not present for the artifact.
• Submitting and receiving systems using knowledge artifacts to perform data exchange or artifact evaluation operations SHALL respect the must support requirements of the profiles used by the artifact to describe the data involved in the operation.

References

Health level seven. Clinical Quality Framework - HL7 Clinical Decision Support Work Group Confluence Page. [Online]. Available from: https://confluence.hl7.org/display/CQIWC/Clinical Quality Framework [Accessed 11 October 2019].

Health level seven. Publishing terminology to the FHIR Ecosystem - FHIR Product Family Confluence Page. [Online]. Available from: https://confluence.hl7.org/display/FHIR/Publishing+terminology+to+the+FHIR+Ecosystem [Accessed 17 May 2022]

Dependencies

Cross Version Analysis

This is an R4 IG. None of the features it uses are changed in R4B, so it can be used as is with R4B systems. Packages for both R4 (hl7.fhir.uv.crmi.r4) and R4B (hl7.fhir.uv.crmi.r4b) are available.

Global Profiles

There are no Global profiles defined

IP Statements

This publication includes IP covered under the following statements.

• The UCUM codes, UCUM table (regardless of format), and UCUM Specification are copyright 1999-2009, Regenstrief Institute, Inc. and the Unified Codes for Units of Measures (UCUM) Organization. All rights reserved. https://ucum.org/trac/wiki/TermsOfUse
  Show Usage
  • Unified Code for Units of Measure (UCUM): Medication/definition-example, PublishableActivityDefinitionExample, ShareableActivityDefinitionExample and ShareableActivityDefinitionExampleArtifactReference
• This material contains content that is copyright of SNOMED International. Implementers of these specifications must have the appropriate SNOMED CT Affiliate license - for more information contact https://www.snomed.org/get-snomed or info@snomed.org.
  Show Usage
  • SNOMED Clinical Terms® (SNOMED CT®): Medication/definition-example, MedicationKnowledge/definition-example, PublishableActivityDefinitionExample, ShareableActivityDefinitionExample and ShareableActivityDefinitionExampleArtifactReference
• Using RxNorm codes of type SAB=RXNORM as this specification describes does not require a UMLS license. Access to the full set of RxNorm definitions, and/or additional use of other RxNorm structures and information requires a UMLS license. The use of RxNorm in this specification is pursuant to HL7's status as a licensee of the NLM UMLS. HL7's license does not convey the right to use RxNorm to any users of this specification; implementers must acquire a license to use RxNorm in their own right.
  Show Usage
  • RxNorm: Medication/definition-example