Capability statement for a terminology service supporting artifact authoring and evaluation use cases. A server can support more functionality than defined here, but this defines the minimum expectations.

Capability statement for a repository service supporting additional authoring and content workflow capabilities for FHIR-based knowledge artifacts above the basic ShareableArtifactRepository.

Capability statement for a repository service supporting additional publishing capabilities for FHIR-based knowledge artifacts above the basic ShareableArtifactRepository.

Capability statement for a repository service supporting minimum required capabilities to share FHIR-based artifact specifications. See the Publishable and Authoring Artifact Repository capability statements for more comprehensive support for publishing and authoring workflows.

The approve operation supports applying an approval to an existing artifact, regardless of status. The operation sets the date and approvalDate elements of the approved artifact, and is otherwise only allowed to create ArtifactAssessment (Basic or cqf-artifactComment extensions in R4) resources in the repository.

Describes the differences between two knowledge artifacts in FHIR Patch format by recursively resolving dependencies to get a holistic diff.

Creates a clone version of a knowledge artifact, as well as for all resources it is composed of.

Determines the effective data requirements for the artifact, including known components and dependencies, and optionally informed by a version manifest.

See $package and $data-requirements

Creates a draft version of a knowledge artifact, as well as for all resources it is composed of.

The definition of a value set is used to create a simple collection of codes suitable for use for data entry or validation.

If the operation is not called at the instance level, one of the in parameters url, context or valueSet must be provided. An expanded value set will be returned, or an OperationOutcome with an error message.

Packages a specified canonical resource for use in a target environment, optionally including related content such as dependencies, components, and testing cases and data.

See $package and $data-requirements

This operation definition is a copy of the CRMI Data Requirements operation but declaring conformance to the CRMI Artifact, Artifact Version Bindable, Artifact Endpoint Configurable, and Manifestable operation profiles.

The release operation supports updating the status of an existing draft artifact to active. The operation sets the date element of the resource and pins versions of all direct and transitive references and records them in the program’s manifest. Child artifacts (i.e. artifacts of which the existing artifact is composed) are also released, recursively.

The review operation supports applying an review to an existing artifact, regardless of status. The operation sets the date and lastReviewDate elements of the reviewed artifact, and is otherwise only allowed to create ArtifactAssessment (Basic or cqf-artifactComment extension in R4) resources in the repository.

This operation definition is a copy of the CRMI ValueSet/$expand OperationDefinition that declares conformance to the CRMI Canonical Version Bindable and CRMI Pageable operation profiles

Retrieves a FHIR package given the package id and version.

The CRMI Computable Library profile defines the must support elements for a computable library used to support artifact logic

Defines a computable value set as one that SHALL have an expression-based definition (i.e. a value set defined intensionally using expressions of the code systems involved) and MAY have an expansion included. The expression-based definition SHALL be represented in only one of three ways; using the compose element, using the expression extension, or using the rules-text extension to provide a step-by-step process for expanding the value set definition

The CRMI Evaluation Result Parameters Profile supports using the dataAbsentReason extension to indicate null evaluation results from operations.

The CRMI Execuable Library profile defines the must support elements for an executable library used to support artifact logic

Defines an expanded value set as one that SHALL have an expansion included, as well as a usage warning indicating the expansion is a point-in-time snapshot and must be maintained over time for production usage. The value set expansion specifies the timestamp when the expansion was produced, SHOULD contain the parameters used for the expansion, and SHALL contain the codes that are obtained by evaluating the value set definition. If this is ONLY an expanded value set, a computable definition of the value set must be obtained to compute the updated expansion.

Represents the definition of a group of subjects, suitable for use in various contexts, such as a cohort definition, a recommendation inclusion or exclusion criteria, the members of a study, or a population criteria

Supports the specification of expansion parameters to be used with the implementation guide

Defines and supports the definition of a manifest used to establish specific versions of dependencies used in a collection of knowledge artifacts

Represents the definition of a medication, suitable for use in various contexts

Represents the definition of medication knowledge, suitable for use in various contexts

The CRMI Module Configuration Library profile supports configuration of the data requirements for a module for a given endpoint. This is useful to provide endpoint-specific configuration of the queries to be used to gather data to satisfy the data requirements for a given module

The CRMI Module Definition Library profile defines the must support elements for a library that communicates the effective data requirements and dependencies of an artifact (or set of artifacts). This is most commonly used as the result of a $data-requirements operation, but could also be persisted statically as a way to persist the calculation of effective data requirements for a specific artifact and input parameters

Profile for operations where artifact endpoint configuration can be specified.

• artifactEndpointConfiguration: Configuration information to resolve canonical artifacts
  • artifactRoute: An optional route used to determine whether this endpoint is expected to be able to resolve artifacts that match the route (i.e. start with the route, up to and including the entire url)
  • endpointUri: The URI of the endpoint, exclusive with the endpoint parameter
  • endpoint: An Endpoint resource describing the endpoint, exclusive with the endpointUri parameter

Processing semantics:

Create a canonical-like reference (e.g. {canonical.url}|{canonical.version} or similar extensions for non-canonical artifacts).

• Given a single artifactEndpointConfiguration
  • When artifactRoute is present
    • And artifactRoute starts with canonical or artifact reference
    • Then attempt to resolve with endpointUri or endpoint
  • When artifactRoute is not present
    • Then attempt to resolve with endpointUri or endpoint
• Given multiple artifactEndpointConfigurations
  • Then rank order each configuration (see below)
  • And attempt to resolve with endpointUri or endpoint in order until resolved

Rank each artifactEndpointConfiguration such that:

• if artifactRoute is present and artifactRoute starts with canonical or artifact reference: rank based on number of matching characters
• if artifactRoute is not present: include but rank lower

NOTE: For evenly ranked artifactEndpointConfigurations, order as defined in the OperationDefinition.

Profile for knowledge artifact operations.

This establishes input parameters when the operation is involked at the resource type level. The parameters are used to identify or specify the resource for the operation.

• url: artifact URL* for the resource
• version: artifact version* for the resource
• identifier: business identifier for the resource
• resource: instance of a canonical resource

*The artifact URL for canonical resources is .url, for non-canonical resources, it is the extension artifact-url. The version for canonical resources is .version, for non-canonical resources it is the extension artifact-version.

NOTE: When invoking canonical operations using any combination of url, version, and identifier:

• if there is one-and-only-one matching resource, the operation should apply, otherwise an error state.
• if resource is specified then url, version, and identifier should be ignored.

Operation where default artifact version(s) can be specified.

NOTE: Artifacts include FHIR Canonical resources and the resources specified as non-canonical resources, such as: Medication, Substance, MedicationKnowledge, and Group.

• artifactVersion: Specifies a version to use for a artifact resource if the artifact referencing the resource does not already specify a version. The format is the same as a canonical URL: [url]|[version] - e.g. http://loinc.org|2.56
• checkArtifactVersion: Edge Case: Specifies a version to use for a artifact resource. If the artifact referencing the resource specifies a different version, an error is returned instead of the package. The format is the same as a canonical URL: [url]|[version] - e.g. http://loinc.org|2.56
• forceArtifactVersion: Edge Case: Specifies a version to use for a artifact resource. This parameter overrides any specified version in the artifact (and any artifacts it depends on). The format is the same as a canonical URL: [system]|[version] - e.g. http://loinc.org|2.56. Note that this has obvious safety issues, in that it may result in a value set expansion giving a different list of codes that is both wrong and unsafe, and implementers should only use this capability reluctantly.

Operation where default canonical version(s) can be specified

NOTE: This profile is here for backwards compatibility, see ArtifactVersionBindableOperation profile as a successor.

• canonicalVersion: Specifies a version to use for a canonical resource if the artifact referencing the resource does not already specify a version. The format is the same as a canonical URL: [url]|[version] - e.g. http://loinc.org|2.56
• checkCanonicalVersion: Edge Case: Specifies a version to use for a canonical resource. If the artifact referencing the resource specifies a different version, an error is returned instead of the package. The format is the same as a canonical URL: [url]|[version] - e.g. http://loinc.org|2.56
• forceCanonicalVersion: Edge Case: Specifies a version to use for a canonical resource. This parameter overrides any specified version in the artifact (and any artifacts it depends on). The format is the same as a canonical URL: [system]|[version] - e.g. http://loinc.org|2.56. Note that this has obvious safety issues, in that it may result in a value set expansion giving a different list of codes that is both wrong and unsafe, and implementers should only use this capability reluctantly.

Operation where default manifest to resolve canonicals can be specified

• manifest: Canonical reference to a Library resource where related-artifacts are used to define the versions of canonical resources.

Operation that is pageable

This establishes input parameters when the operation might return paging.

• offset: Pagination offset
• count: Number of items per page

Supports declaration of the ActivityDefinition metadata required by HL7 and other organizations that share and publish activity definitions with a focus on the aspects of that metadata that are important for post-publication activities including distribution, inclusion in repositories, consumption, and implementation.

Supports declaration of the CapabilityStatement metadata required by HL7 and other organizations that share and publish capability statements with a focus on the aspects of that metadata that are important for post-publication activities including distribution, inclusion in repositories, consumption, and implementation.

Defines and enforces the minimum expectations for publication and distribution of a code system, typically as part of an artifact repository or implementation guide publication

Defines and enforces the minimum expectations for publication and distribution of a concept map, typically as part of an artifact repository or implementation guide publication

Supports declaration of the GraphDefinition metadata required by HL7 and other organizations that share and publish graph definitions with a focus on the aspects of that metadata that are important for post-publication activities including distribution, inclusion in repositories, consumption, and implementation.

Supports declaration of the ImplementationGuide metadata required by HL7 and other organizations that share and publish implementation guides with a focus on the aspects of that metadata that are important for post-publication activities including distribution, inclusion in repositories, consumption, and implementation.

Supports declaration of the library metadata required by HL7 and other organizations that share and publish libraries with a focus on the aspects of that metadata that are important for post-publication activities including distribution, inclusion in repositories, consumption, and implementation.

Supports declaration of the Measure metadata required by HL7 and other organizations that share and publish measures with a focus on the aspects of that metadata that are important for post-publication activities including distribution, inclusion in repositories, consumption, and implementation.

Defines and enforces the minimum expectations for publication and distribution of a naming system, typically as part of an artifact repository or implementation guide publication

Supports declaration of the OperationDefinition metadata required by HL7 and other organizations that share and publish operation definitions with a focus on the aspects of that metadata that are important for post-publication activities including distribution, inclusion in repositories, consumption, and implementation.

Supports declaration of the PlanDefinition metadata required by HL7 and other organizations that share and publish plandefinitions with a focus on the aspects of that metadata that are important for post-publication activities including distribution, inclusion in repositories, consumption, and implementation.

Supports declaration of the Questionnaire metadata required by HL7 and other organizations that share and publish questionnaires with a focus on the aspects of that metadata that are important for post-publication activities including distribution, inclusion in repositories, consumption, and implementation.

Supports declaration of the SearchParameter metadata required by HL7 and other organizations that share and publish search parameters with a focus on the aspects of that metadata that are important for post-publication activities including distribution, inclusion in repositories, consumption, and implementation.

Supports declaration of the StructureDefinition metadata required by HL7 and other organizations that share and publish structure definitions with a focus on the aspects of that metadata that are important for post-publication activities including distribution, inclusion in repositories, consumption, and implementation.

Supports declaration of the TerminologyCapabilities metadata required by HL7 and other organizations that share and publish terminology capabilities with a focus on the aspects of that metadata that are important for post-publication activities including distribution, inclusion in repositories, consumption, and implementation.

Defines and enforces the minimum expectations for publication and distribution of a value set, typically as part of an artifact repository or implementation guide publication

Enforces the minimum information set for the activity definition metadata required by HL7 and other organizations that share and publish activity definitions

Enforces the minimum information set for the capabilitystatement metadata required by HL7 and other organizations that share and publish capability statements

Enforces the minimum information set for the code system metadata required by HL7 and other organizations that share and publish code systems

Enforces the minimum information set for the concept map metadata required by HL7 and other organizations that share and publish concept maps

Enforces the minimum information set for the graph definition metadata required by HL7 and other organizations that share and publish graph definitions

Enforces the minimum information set for the implementation guide metadata required by HL7 and other organizations that share and publish implementation guides

Enforces the minimum information set for the library metadata required by HL7 and other organizations that share and publish libraries

Enforces the minimum information set for the measure metadata required by HL7 and other organizations that share and publish measures

Enforces the minimum information set for the naming system metadata required by HL7 and other organizations that share and publish naming systems

Enforces the minimum information set for the operation definition metadata required by HL7 and other organizations that share and publish operation definitions

Enforces the minimum information set for the plan definition metadata required by HL7 and other organizations that share and publish plan definitions

Enforces the minimum information set for the questionnaire metadata required by HL7 and other organizations that share and publish questionnaires

Enforces the minimum information set for the search parameter metadata required by HL7 and other organizations that share and publish search parameters

Enforces the minimum information set for the structure definition metadata required by HL7 and other organizations that share and publish structure definitions

Enforces the minimum information set for the terminology capabilities metadata required by HL7 and other organizations that share and publish terminology capabilities

Enforces the minimum information set for the value set metadata required by HL7 and other organizations that share and publish value sets

The Software System device profile is used to capture software details about the various systems used in authoring, testing, packaging, or evaluation of a knowledge artifact

Represents the definition of a substance, suitable for use in various contexts

Which endpoint this module configuration is for

Which artifact this module configuration is for

A module definition library that contains the effective data requirements for an artifact (i.e. the calculated data requirements for the expressions directly referenced by the artifact structure).

Indicates whether the endpoint of the configuration library on which it appears supports using a POST for search

Specifies the software systems used in the packaging and testing of knowledge artifacts. Specifically to support explicitly stating which versions of the various software components were used in the authoring, packaging, and testing.

FHIR canonical plus knowledge artifact resource types.

Behaviors of ‘experimentalBehavior’ parameter application in the $release operation.

Behaviors of ‘version’ parameter application in the $release operation.

Behaviors of ‘experimentalBehavior’ parameter application in the $release operation.

Behaviors of ‘version’ parameter application in the $release operation.

Cohort definition for antenatal care

Quick check questionnaire

Quick check questionnaire

Before each contact, during the Quick Check, the health worker should check whether the woman has any of the danger signs listed here – if yes, she should be referred to the hospital urgently; if no, the normal contact should be continued as normal

Before each contact, during the Quick Check, the health worker should check whether the woman has any of the danger signs listed here – if yes, she should be referred to the hospital urgently; if no, the normal contact should be continued as normal

Percentage of pregnant women with first ANC contact in the first trimester (before 12 weeks of gestation)

Percentage of pregnant women with first ANC contact in the first trimester (before 12 weeks of gestation)

Set of codes representing all activities used in the implementation guide

Set of codes representing all concepts used in the implementation guide

This library is an example of an artifact manifest for the DT-01 PlanDefinition from the ANC-Mini IG.

Example of a Software System Device instance for describing tooling that was used to process artifacts. This resource is typically referenced from the crmi-softwaresystem extension

Codes representing possible values for the Danger Signs - Central cyanosis element

Codes representing possible values for the Danger Signs - No danger signs element

Before each contact, the health worker should check whether the woman has any of the danger signs listed here – if yes, she should refer to the hospital urgently; if no, she should continue to the normal contact

Codes representing possible values for the Danger signs element

Group Valueset with codes representing possible values for the Danger signs Codes Grouper element

Group Valueset with codes representing possible values for the Danger signs Codes Grouper element

Group Valueset with codes representing possible values for the Danger signs Codes Grouper element

Example Parameters resource demonstrating the use of data-absent-reason extension to indicate a null evaluation result.

Example Group Definition illustrating the use of an expression to define group membership.

This library is used as an example module definition in the FHIR Quality Measure Implementation Guide

Example MeasureReport illustrating use of MeasureReport as a test case.

Example of a Medication resource illustrating use as a definitional artifact.

Example of a MedicationKnowledge resource illustrating use as a definitional artifact.

Example Publishable Terminology Capabilities to describe an environment capable of expanding LOINC value sets, but not RxNORM value sets

Example Shareable Terminology Capabilities to describe an environment capable of expanding LOINC value sets, but not RxNORM value sets

Example of a Substance resource illustrating use as a definitional artifact.

Example Group illustrating use of the cqf-testArtifact extension to build a set of test data for an artifact.

This library defines terminologies and functions commonly used in FHIR-based CQL artifacts.

This library defines terminologies and functions commonly used in FHIR-based CQL artifacts.

This library defines terminologies and functions commonly used in FHIR-based CQL artifacts.

This library defines terminologies and functions commonly used in FHIR-based CQL artifacts.

This library defines terminologies and functions commonly used in FHIR-based CQL artifacts.

This implementation guide demonstrates the use of the expansion parameters extension

This library is used to populate the prefetch template for Recommendation 10 (Endpoint-specific)

Example patient 1 in the test case group

Example patient 2 in the test case group

Example Publishable Activity Definition for a recommendation to order a medication

Basic conformance statement for a Library Evaluation Service. A server can support more functionality than defined here, but this is the minimum amount

A mapping between the FHIR and HL7 v3 AddressUse Code systems

This implementation guide demonstrates end-to-end capabilities for computable clinical practice guidelines following the World Health Organization SMART IG approach

Limited implementation of the Populate Questionnaire implementation

Example of a Publishable GraphDefinition

Search by resource identifier - e.g. same as the read interaction, but can return included resources

SNOMED CT is a concept-based, scientifically validated terminology that provides a unique and permanent concept identifier that can be included in multiple HL7 data types including CD and CE. The concepts are managed to avoid “semantic drift” so the meaning remains constant. If the concept is found to be ambiguous or the meaning changes, the concept is inactivated but still retained and the identifier is never reused. SNOMED CT’s concepts are interrelated hierarchically and using description logic. SNOMED CT concepts have a unique “fully-specified name”, a preferred term, and, optionally, synonyms. The description languages include English and Spanish.

SNOMED CT is a concept-based, scientifically validated terminology that provides a unique and permanent concept identifier that can be included in multiple HL7 data types including CD and CE. The concepts are managed to avoid “semantic drift” so the meaning remains constant. If the concept is found to be ambiguous or the meaning changes, the concept is inactivated but still retained and the identifier is never reused. SNOMED CT’s concepts are interrelated hierarchically and using description logic. SNOMED CT concepts have a unique “fully-specified name”, a preferred term, and, optionally, synonyms. The description languages include English and Spanish.

Example Shareable Activity Definition for a recommendation to order a medication

Example Shareable Activity Definition for a recommendation to order a medication. The medication uses the artifact-reference extension to a corresponding medication identified by artifact-url and artifact-version extensions

Basic conformance statement for a Library Evaluation Service. A server can support more functionality than defined here, but this is the minimum amount

A mapping between the FHIR and HL7 v3 AddressUse Code systems

This implementation guide demonstrates end-to-end capabilities for computable clinical practice guidelines following the World Health Organization SMART IG approach

Limited implementation of the Populate Questionnaire implementation

Example of a Shareable GraphDefinition

Search by resource identifier - e.g. same as the read interaction, but can return included resources

If the woman came to the facility with a specific health concern, select the health concern(s) from the list

Codes representing possible values for the Specific health concern(s) element