Applied: Assure clear definitions up front(FHIR-41896)
Applied: Spelling corrections in Naming Conventions section(FHIR-41870)
Applied: No content in this ModelInfo section of Using CQL(FHIR-41869)
Applied: Provide more context in examples(FHIR-41868)
Applied: Clarify that an artifact may only be owned by one parent(FHIR-41785)
Applied: missing content: Distribution client capabilities(FHIR-41695)
Applied: Document conventions used in the IG(FHIR-41328)
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 table lists the resource types that are considered artifacts, along with a categorization of those artifacts and the relative priority of consideration of those items in this implementation guide.
Artifact Category
Description
Resources
Knowledge Artifacts (Primary)
Representing decision support rules, quality measures, logic libraries, and activity definitions
Note that CompartmentDefinition is not profiled in this implementation guide because only HL7 can define CompartmentDefinition instances.
(profiled) For Entity-related Domain Definition Artifacts such as Organization, Location, Practitioner, Patient, and CareTeam, this implementation guide uses profiling to address references to these types of resources in the definitional space (i.e. when a PlanDefinition references a particular type of CareTeam for example, the canonical reference would be to a profile of the CareTeam resource.
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
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.
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
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.
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.