This page is part of the Canonical Resource Management Infrastructure Implementation Guide (v1.0.0-ballot: STU1 Ballot 1) based on FHIR R4. . For a full list of available versions, see the Directory of published versions

Content Lifecycle

Knowledge artifacts go through a lifecycle, typically following a similar pattern found in software:

The Publication Status value set is used to track the lifecycle of an artifact:

• draft: The artifact is in development and the contents of the artifact may change without changing the version.
• active: The artifact is published and the contents of the artifact may only change in accordance with the versioning policy of the artifact.
• retired: The artifact is retired and no longer in active use, typically because it has been superseded by a newer version of the artifact.

To ensure stable resolution of dependencies of an artifact throughout its lifecycle (including stable value set expansion), a version manifest can be used to allow resolution of unversioned canonical references in the artifact and its dependencies. See the Version Manifest discussion for more information on how the Manifest Library profile supports stable resolution of dependencies.

Grouping Knowledge Artifacts

There are a few use-cases for groups of knowledge artifacts:

1. During the authoring lifecycle
2. Distribution of published artifacts

For the authoring lifecycle, a FHIR Package is used. This is compatiable with

HL7 FHIR Publishing tools. In the FHIR Package a corresponding ImplementationGuide resource is used to represent the package, as it has a packageId, a proposed packageScope, and references to all artifacts in the package. Additionally, the following query could be used to see what package a particular artifact is part of:

/ImplementationGuide?resource={artifact.resourceType}/{artifact.id}

If a single ImplementationGuide is returned, the package is the packageId. If multiple are found and the packageId varies, or if no ImplementationGuide resources are found, then it is not known what package the artifact is from.

See more about publishing

For distribution, an Artifact Library (FHIR Library) is used.

This can be created following the $package operation and paramaters to define requirements for the group. See more about distribution APIs.

Components vs dependencies

A component artifact is an artifact that is designated specifically as part of a collection, whereas a dependency is an artifact that is referenced by another artifact. The distinction is drawn to ensure that dependencies can always be calculated by tracing artifact dependencies, whereas components always need to be specified (i.e. they are the designated components of the collection).

In addition, component artifacts can be owned meaning that the lifecycle of the component artifact is entirely controlled by the containing collection, as opposed to the artifact having its own lifecycle.

A collection of artifacts is specified using a CRMIManifestLibrary. The components of the collection are identified with relatedArtifact entries of type composed-of. The isOwned extension is used to designate whether a component is owned (i.e. managed entirely as part of the collection).

The dependencies of a collection can be stated explicitly using relatedArtifact entries of type depends-on, but because dependencies can always be inferred from the components, this listing is typically calculated. The $data-requirements operation can be used to calculate the dependencies of an artifact.

Non-canonical definitional resources

This implementation guide defines profiles for several resources that can be used in a definitional context:

• Location
• Group
• PractitionerRole
• Medication
• MedicationKnowledge
• Substance

Artifact Scope

The scope of an artifact is the package context in which it is authored, tested, and evaluated. This is typically specified by the implementation guide or package in which the artifact is published and distributed, and corresponds to the package id and base canonical url for the implementation guide. For example:

hl7.fhir.uv.crmi@http://hl7.org/fhir/uv/crmi

For knowledge artifacts that are authored and published as part of a FHIR Implementation Guide (i.e. a content IG), the scope of the artifact is implied by the base canonical of the artifact URL. However, the scope of an artifact can be overridden using the cqf-scope extension.

The scope is important for determining the manifest (which dictates the expansion parameters used to resolve unversioned canonical references). The manifest for a given scope is either the implementation guide (if the scope corresponds directly to an implementation guide), or the manifest library identified by the package and url.