Canonical Resource Management Infrastructure Implementation Guide
1.0.0 - STU1
Canonical Resource Management Infrastructure Implementation Guide
1.0.0 - STU1
This page is part of the Canonical Resource Management Infrastructure Implementation Guide (v1.0.0: STU1) based on FHIR (HL7® FHIR® Standard) R4. This is the current published version in its permanent home (it will always be available at this URL). For a full list of available versions, see the Directory of published versions
This page documents the conformance expectations of an artifact repository service to support authoring, publishing, and distribution of FHIR-based knowledge artifacts including questionnaires, decision support rules, quality measures, guidelines, and reporting specifications, as well as their associated terminologies and data element descriptions.
This implementation guide is not advocating for any particular central authority for content repositories, rather the intent is to propose a capability statement that enables publishers to build consistent and interoperable repositories for sharing knowledge artifacts.
This implementation guide is not prescriptive about authentication or authorization, but strongly recommends that these capabilities be addressed through standard mechanisms, as described in FHIR standard security mechanisms. In addition, though knowledge artifacts typically do not include patient-specific information, test data for knowledge artifacts can sometimes be derived from or based on real patient information. In this cases, care must be taken to ensure the data is scrubbed to remove any possibility of violating patient privacy or security.
This page defines three levels of artifact repository capabilities:
Note that the Publishable and Authoring repositories build on the Shareable repository, so that Shareable describes the minimum basic capabilities of an artifact repository, and the Publishable and Authoring repositories build on that to support additional, more sophisticated use cases.
In addition, the repository capabilities described here are intended to conform to and facilitate artifact management as described in the Artifact Lifecycle topic of this implementation guide. In particular, artifact status is a key element and care must be taken to ensure that artifact status can only transition as specified in the Artifact Status topic.
The following conceptual actions support artifact authoring, searching, publication, and distribution. In this section, each of these actions are described conceptually, and then the capability statements segment these actions into the shareable, publishable, and authoring repositories to support the various use cases for an artifact ecosystem.
NOTE: These are conceptual actions that can be performed in a variety of ways. The purpose of the capability statements is to describe how these actions are actually performed in an API, as either a FHIR RESTful interaction (create, read, update, delete), or FHIR operation (e.g. $package).
The ShareableArtifactRepository capability statement defines the minimum expectations for an artifact repository that provides basic access to shareable artifact content:
The CRMIShareableArtifactRepository capability statement captures these requirements formally, while the following sections provide a narrative description of them.
Note that the shareable artifact repository defined here supports only the knowledge artifacts that are the primary focus of this implementation guide:
Repository support for other types of artifacts SHALL follow the same pattern established for these artifacts.
contains modifierexact modifiertext modifierAND and OR search parameters for all search parameters, as defined in the composite search parameter topic.Note that for servers that support write capabilities, the
versionelement of an artifact is a business version, and is independent of resource versioning. Artifact repositories that support write capabilities may wish to implement resource versioning as well as artifact (business) versioning to ensure auditability of changes, however, this is an implementation decision and does not impact the conceptual support for artifact versions (because each different version of an artifact will necessarily be a different resource instance in the server. Note also that R6 has introduced additional capabilities to better support resource versioning for servers that provide such support.
For each type of knowledge artifact supported by a ShareableArtifactRepository:
read by the server-defined id for the artifactsearch using the _id search parametersearch interaction by:
See the CRMIShareableArtifactRepository capability statement for a formal description of these requirements.
The PublishableArtifactRepository capability statement builds on the ShareableArtifactRepository and expresses additional functionality that SHOULD be provided in support of providing published FHIR artifacts including additional searching and packaging capabilities:
The CRMIPublishableArtifactRepository capability statement captures these requirements formally, while the following sections provide a narrative description of them.
Note that the publishable artifact repository defined here supports only the knowledge artifacts that are the primary focus of this implementation guide:
Repository support for other types of artifacts SHALL follow the same pattern established for these artifacts.
For each type of knowledge artifact supported by a PublishableArtifactRepository:
create or put interaction
active status and must conform to at least the appropriate shareable and publishable profiles for the artifactupdate interaction
active status and update is only allowed to change the status to retired and update the date (and other metadata appropriate to indicate retired status)delete interaction
retired statusThe AuthoringArtifactRepository capability statement defines additional capabilities that are required to support content authoring workflows in a shared environment. For systems that do not exchange in progress content, or support external review/approval processes, these capabilities are not required to be exposed:
draft artifacts (the Submit, Revise, and Withdraw actions)The CRMIAuthoringArtifactRepository capability statement captures these requirements formally, while the following sections provide a narrative description of them.
Note that the authoring artifact repository defined here supports only the knowledge artifacts that are the primary focus of this implementation guide:
Repository support for other types of artifacts SHALL follow the same pattern established for these artifacts.
For each type of artifact supported, an AuthoringMeasureRepository:
create or update interaction
update interaction
delete interaction
The Review and Approve actions are supported via operations, rather than interactions, because they have a specific set of input parameters and are only allowed to make certain updates to the artifacts. Although an
updateinteraction could be used in theory, this would place a higher burden on the client to ensure the updated resource was only affecting appropriate elements, something the server must validate anyway.
The Release action is supported as an operation because it is specifically asking the server to perform a series of processes involving updating statuses, dates, and potentially versions on multiple artifacts, all within the same operation. Multiple
updateinteractions could in theory be used to support this, this would place a higher burden on the client to ensure the release processing was followed appropriately for the artifact and all child artifacts, recursively. In addition, all these updates would need to be performed as part of a single transaction, and the server would need to validate the transaction updates anyway.
The Draft action is supported as an operation because it involves not only creating a new version of an artifact, but any child artifacts, recursively. This could be done in theory by the client reading all relevant artifacts and creating new resources, but an operation simplifies implementation for the client.
The Clone action is supported as an operation because it involves not only creating a copy of the artifact, but any child artifacts, recursively. This could be done in theory by the client reading all relevant artifacts and creating new resources, but an operation simplifies implementation for the client.
IG © 2022+ HL7 International / Clinical Decision Support. Package hl7.fhir.uv.crmi#1.0.0 based on FHIR 4.0.1. Generated 2024-05-31
Links: Table of Contents |
QA Report
| Version History |
|
Propose a change