Canonical Resource Management Infrastructure Implementation Guide
1.0.0-ballot2 - Ballot International flag

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-ballot2 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-ballot2
Draft as of 2022-05-17 Computable Name: CRMI

Where possible, new and updated content will be highlighted with green text and background.

The following trackers were applied for this version:

Status: Summary:(Jira Issue)

Non-Compatible changes

  • Applied: Clarify scope of use for the IG(FHIR-42730)
  • Applied: Is output a Library or a Bundle?(FHIR-42592)
  • Applied: Querying by resource id for content in an IG is useless(FHIR-42555)
  • Applied: Shareable shouldn’t be the parent of other profiles(FHIR-41367)

Compatible, Substantive Changes

  • Applied: Use a dataAbsentReason extension to indicate missing results(FHIR-43076)
  • Applied: Add guidance on missing information(FHIR-43075)
  • Applied: Add profile to ParameterDefinition(FHIR-43034)
  • Applied: Add support for artifact manifests in the manifest profile(FHIR-42919)
  • Applied: Package Operation type + examples for different types(FHIR-42804)
  • Applied: CapabilityStatements are too narrow(FHIR-42598)
  • Applied: Exhaustive list isn’t possible(FHIR-42594)
  • Applied: Why only one library per resource?(FHIR-42564)
  • Applied: Define the meaning of Must Support(FHIR-42018)
  • Applied: Add a testArtifact extension(FHIR-41874)

Non-Substantive Changes

  • Applied: Consider requiring the use of a SignatureLevel higher than none(FHIR-42921)
  • Applied: Artifact dropdown doesn’t show all artifacts e.g. operationdefinitions. (FHIR-42803)
  • Applied: All local code systems must be temp or approved by TSMG(FHIR-42601)
  • Applied: Extensions are not discussed in text(FHIR-42600)
  • Applied: Operations not discussed in text(FHIR-42599)
  • Applied: Why does a CRMI terminology service need library?(FHIR-42597)
  • Applied: Explain the profiles(FHIR-42596)
  • Applied: “Distribution client capabilities” isn’t complete(FHIR-42595)
  • Applied: Explain data-requirements operation better(FHIR-42593)
  • Applied: it’s -> its(FHIR-42590)
  • Applied: Explain example(FHIR-42589)
  • Applied: Use ‘[base]’(FHIR-42588)
  • Applied: Explain context of ‘publishing’ better(FHIR-42587)
  • Applied: What are ‘appropraite’ IP rules?(FHIR-42585)
  • Applied: What profile?(FHIR-42584)
  • Applied: Clarify packaging rules(FHIR-42583)
  • Applied: Explain ‘processed as a unit’(FHIR-42582)
  • Applied: There’s no need for operation namespaces(FHIR-42581)
  • Applied: Explain canonical URL pattern(FHIR-42580)
  • Applied: Explain consistency of artifacts(FHIR-42579)
  • Applied: Fix typo(FHIR-42578)
  • Applied: Consider dropping the CQL page(FHIR-42577)
  • Applied: ModelInfo section is empty(FHIR-42576)
  • Applied: Don’t repeat FHIR core spec(FHIR-42575)
  • Applied: Libraries are not required for CQL(FHIR-42574)
  • Applied: Explaing conformance requirement 4.12(FHIR-42573)
  • Applied: Representation in a Library needs clarification(FHIR-42571)
  • Applied: Code URI expectation inconsistent(FHIR-42570)
  • Applied: What is “knowledge artifact CQL”?(FHIR-42569)
  • Applied: Why so much discussion about VSAC in an international spec?(FHIR-42568)
  • Applied: Use a value set avoiding OIDs(FHIR-42567)
  • Applied: Update location of code system URIs(FHIR-42566)
  • Applied: How is the association between a namespace and URI established?(FHIR-42565)
  • Applied: Assert assumption about state transition order(FHIR-42563)
  • Applied: Put versioning stuff together(FHIR-42562)
  • Applied: Explain identifier rules(FHIR-42561)
  • Applied: Better explain library declarations(FHIR-42560)
  • Applied: Clarify language around CQL artifacts(FHIR-42559)
  • Applied: Using CQL shouldn’t be the second entry(FHIR-42558)
  • Applied: Distribution shouldn’t require libraries(FHIR-42556)
  • Applied: Fix “This is compatiable with”(FHIR-42554)
  • Applied: Fix arbitrary capitalization(FHIR-42553)
  • Applied: Presume FHIR understanding or reference(FHIR-42552)
  • Applied: Second diagram is confusing(FHIR-42551)
  • Applied: This isn’t about Clinical Reasoning(FHIR-42550)
  • Applied: Data Repository examples are weird mix of concepts(FHIR-42549)
  • Applied: Increase text size(FHIR-42548)
  • Applied: This is a weird thing to say(FHIR-42547)
  • Applied: Improve authoring knowledge repository and terminology service explanation(FHIR-42546)
  • Applied: Drop ‘clinical’(FHIR-42545)
  • Applied: Fix ordering of sections(FHIR-42544)
  • Applied: Explain Shareable/Publishle/etc.(FHIR-42543)
  • Applied: Use the short dependency summary(FHIR-42542)
  • Applied: Explain non-canonical definitional(FHIR-42541)
  • Applied: context for cqf-artifactComment extension(FHIR-42358)
  • Applied: Clarify Relationship between CRMI and FHIR Clinical Guidelines(FHIR-42357)
  • Applied: Fix targeted link for 19.2 Version Manifest(FHIR-42354)
  • Applied: Fix manifest specification link(FHIR-42352)
  • Applied: Clarify Dependency Tracing(FHIR-42351)
  • Applied: Provide more guidance on versioning(FHIR-42340)
  • Applied: Typo: namepsace(FHIR-42239)
  • Applied: Typo: paramaters(FHIR-42187)
  • Applied: Heading stops mid-sentence(FHIR-42186)
  • Applied: SUSHI should be all-caps(FHIR-42182)
  • Applied: Naming convention correction(FHIR-42083)
  • Applied: Knowledge artifact publication process(FHIR-42082)
  • Applied: Describe “Knowledge Artifact”(FHIR-42080)
  • Applied: In the Home or Introduction, describe “Content IG” and why it is different from typical IGs.(FHIR-42079)
  • Applied: Incomplete sentence “This is compatible with” on 7.1.1 heading(FHIR-42078)
  • Applied: Complete section “Distribution client capabilities”, or remove(FHIR-42019)
  • Applied: Consider bold formatting Conformance verbs(FHIR-42017)
  • Applied: Please reframe material to fit the context and presentation of the IG(FHIR-42016)
  • Applied: The In-Scope/Out-of-Scope image is confusing(FHIR-42015)
  • Applied: A “TODO” should not be in the final published version(FHIR-42014)
  • Applied: Formatting and content issues in the Using CQL page(FHIR-42013)
  • Applied: Links on introduction page seem to be incorrect(FHIR-42012)
  • Applied: Type in description of an artifact(FHIR-42011)
  • Applied: Define the acronym EBM(FHIR-42010)
  • Applied: Correct a number of word misspellings(FHIR-42008)
  • Applied: Packaging typo/correction(FHIR-41962)
  • Applied: Packaging terminologies(FHIR-41961)
  • Applied: Naming convention typo(FHIR-41960)
  • Applied: FHIR Server Clarification(FHIR-41957)
  • 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 ActivityDefinition
Library
Measure
PlanDefinition
Questionnaire
Terminology Artifacts (Secondary) Code systems, value sets, naming systems, and concept maps ValueSet
CodeSystem
ConceptMap
NamingSystem
Conformance Artifacts (Tertiary) Profiles, extensions, structure maps, and artifacts related to defining and testing conformance CapabilityStatement
CompartmentDefinition
GraphDefinition
ImplementationGuide
MessageDefinition
OperationDefinition
Requirements (R5)
StructureDefinition
StructureMap
SearchParameter
SubscriptionTopic (R5)
TerminologyCapabilities
Domain Definition Artifacts (Roadmap) Medications, substances, groups, and other domain-related definitional artifacts ActorDefinition (R5)
CareTeam (Profiled)
ConditionDefinition
ClinicalUseDefinition (R5)
DeviceDefinition
Group (non-canonical definitional)
Location (profiled)
Medication (non-canonical definition)
MedicationKnowledge (non-canonical definitional)
Practitioner (profiled)
PractitionerRole (profiled)
ObservationDefinition
Organization (profiled)
SpecimenDefinition
Substance (non-canonical definitional
Evidence-based Medicine (EBM) Artifacts (Quarternary) Evidence, EvidenceVariable, and other artifacts related to supporting evidence-based medicine Evidence
EvidenceVariable
ResearchDefinition
ResearchElementDefinition
RiskEvidenceSynthesis
Related Resources (Roadmap)   ArtifactAssessment (R5)
Permission (R5)

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
  • 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.
    • 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

IGPackageFHIRComment
.. Canonical Resource Management Infrastructure Implementation Guidehl7.fhir.uv.crmi#1.0.0-ballot2R4
... HL7 Terminology (THO)hl7.terminology.r4#5.3.0R4Automatically added as a dependency - all IGs depend on HL7 Terminology
... FHIR Extensions Packhl7.fhir.uv.extensions#5.1.0-ballot1R5

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.