<status value="active"/> <kind value="operation"/> <date value="2026-05-11T04:30:28+00:00"/> <publisher value="HL7 International / Clinical Decision Support"/> <contact> <telecom> <system value="url"/> <value value="http://www.hl7.org/Special/committees/dss"/> </telecom> </contact> <description value="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."/> <jurisdiction> <coding> <system value="http://unstats.un.org/unsd/methods/m49/m49.htm"/> <code value="001"/> <display value="World"/> </coding> </jurisdiction> <code value="data-requirements"/> <comment value="The data requirements operation is used for dependency gathering, as a way to understand the set of dependencies of a given artifact, as well as for data requirements determination, as a way to understand the complete set of data requirements for a given artifact, including terminology usage (code systems, value sets, and direct-reference codes), parameters, dependencies, and data requirements."/> <resource value="ActivityDefinition"/> <resource value="CapabilityStatement"/> <resource value="CodeSystem"/> <resource value="CompartmentDefinition"/> <resource value="ConceptMap"/> <resource value="ExampleScenario"/> <resource value="GraphDefinition"/> <resource value="Group"/> <resource value="ImplementationGuide"/> <resource value="Library"/> <resource value="Measure"/> <resource value="Medication"/> <resource value="MedicationKnowledge"/> <resource value="MessageDefinition"/> <resource value="NamingSystem"/> <resource value="OperationDefinition"/> <resource value="PlanDefinition"/> <resource value="Questionnaire"/> <resource value="SearchParameter"/> <resource value="StructureDefinition"/> <resource value="StructureMap"/> <resource value="Substance"/> <resource value="TerminologyCapabilities"/> <resource value="TestScript"/> <resource value="ValueSet"/> <system value="false"/> <type value="true"/> <instance value="true"/> <parameter> <name value="id"/> <use value="in"/> <min value="0"/> <max value="1"/> <documentation value="The logical id of the canonical or artifact resource to analyze."/> <type value="string"/> </parameter> <parameter> <name value="url"/> <use value="in"/> <min value="0"/> <max value="1"/> <documentation value="A canonical or artifact reference to a canonical resource."/> <type value="uri"/> </parameter> <parameter> <name value="version"/> <use value="in"/> <min value="0"/> <max value="1"/> <documentation value="The version of the canonical or artifact resource to analyze"/> <type value="string"/> </parameter> <parameter> <name value="identifier"/> <use value="in"/> <min value="0"/> <max value="1"/> <documentation value="A business identifier of the canonical or artifact resource to be analyzed."/> <type value="string"/> <searchType value="token"/> </parameter> <parameter> <name value="expression"/> <use value="in"/> <min value="0"/> <max value="*"/> <documentation value="The name of a specific expression to be considered for analysis. If no expressions are specified, the analysis is performed on the entire resource. If expressions are specified, the analysis is performed only on the expressions specified."/> <type value="string"/> </parameter> <parameter> <name value="parameters"/> <use value="in"/> <min value="0"/> <max value="1"/> <documentation value="Any input parameters for the artifact. If the artifact is a logic library, or references logic libraries, parameters defined in this input will be bound by name to parameters defined in the logic library (or referenced libraries). If the logic library is a CQL library, parameter types are mapped to CQL as specified in the Using CQL with FHIR implementation guide. If a parameter appears more than once in the input Parameters resource, it is represented with a List in the input CQL. If a parameter has parts, it is represented as a Tuple in the input CQL."/> <type value="Parameters"/> </parameter> <parameter> <name value="artifactVersion"/> <use value="in"/> <min value="0"/> <max value="*"/> <documentation value="Specifies a version to use for a canonical or 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 Note that this is a generalization of the `system-version` parameter to the $expand operation to apply to any canonical resource, including code systems."/> <type value="uri"/> </parameter> <parameter> <name value="checkArtifactVersion"/> <use value="in"/> <min value="0"/> <max value="*"/> <documentation value="Edge Case: Specifies a version to use for a canonical or 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 Note that this is a generalization of the `check-system-version` parameter to the $expand operation to apply to any canonical resource, including code systems."/> <type value="uri"/> </parameter> <parameter> <name value="forceArtifactVersion"/> <use value="in"/> <min value="0"/> <max value="*"/> <documentation value="Edge Case: Specifies a version to use for a canonical or 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. It primarily exists to deal with situations where specifications have fallen into decay as time passes. If the version of a canonical is overridden, the version used SHALL explicitly be represented in the expansion parameters. Note that this is a generalization of the `force-system-version` parameter to the $expand operation to apply to any canonical resource, including code systems."/> <type value="uri"/> </parameter> <parameter> <name value="manifest"/> <use value="in"/> <min value="0"/> <max value="1"/> <documentation value="Specifies an asset-collection library that defines version bindings for code systems and other canonical resources referenced by the value set(s) being expanded and other canonical resources referenced by the artifact. When specified, the expansion parameters of the manifest are used to provide expansion behavior and canonical resolution for dependencies encountered while processing the operation."/> <type value="canonical"/> <targetProfile value="http://hl7.org/fhir/uv/crmi/StructureDefinition/crmi-manifestlibrary"/> </parameter> <parameter> <name value="include"/> <use value="in"/> <min value="0"/> <max value="*"/> <documentation value="Specifies what contents should be included in the resulting package. The codes indicate which types of resources should be included, but note that the set of possible resources is determined as all known (i.e. present on the server) dependencies and related artifacts. Possible values are: * all (default) - all resource types * artifact - the specified artifact * canonical - canonical resources (i.e. resources with a defined url element or that can be canonical resources using the artifact-url extension) * terminology - terminology resources (i.e. CodeSystem, ValueSet, NamingSystem, ConceptMap) * conformance - conformance resources (i.e. StructureDefinition, StructureMap, SearchParameter, CompartmentDefinition) * profiles - profile definitions (i.e. StructureDefinition resources that define profiles) * extensions - extension definitions (i.e. StructureDefinition resources that define extensions) * knowledge - knowledge artifacts (i.e. ActivityDefinition, Library, PlanDefinition, Measure, Questionnaire) * tests - test cases and data (i.e. test cases as defined by the testing specification in this implementation guide) * examples - example resources (i.e. resources identified as examples in the implementation guide)"/> <type value="string"/> </parameter> <parameter> <name value="artifactEndpointConfiguration"/> <use value="in"/> <min value="0"/> <max value="*"/> <documentation value="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 canonical or artifact reference *starts with* `artifactRoute` * Then attempt to resolve with `endpointUri` or `endpoint` * When `artifactRoute` is not present * Then attempt to resolve with `endpointUri` or `endpoint` * Given multiple `artifactEndpointConfiguration`s * 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* canonical or artifact reference *starts with* `artifactRoute`: rank based on number of matching characters * if `artifactRoute` is *not* present: include but rank lower NOTE: For evenly ranked `artifactEndpointConfiguration`s, order as defined in the OperationDefinition."/> <part> <name value="artifactRoute"/> <use value="in"/> <min value="0"/> <max value="1"/> <type value="uri"/> </part> <part> <name value="endpointUri"/> <use value="in"/> <min value="0"/> <max value="1"/> <type value="uri"/> </part> <part> <name value="endpoint"/> <use value="in"/> <min value="0"/> <max value="1"/> <type value="Endpoint"/> </part> </parameter> <parameter> <name value="terminologyEndpoint"/> <use value="in"/> <min value="0"/> <max value="1"/> <documentation value="An endpoint to use to access terminology (i.e. valuesets, codesystems, naming systems, concept maps, and membership testing) referenced by the Resource. If no terminology endpoint is supplied, the evaluation will attempt to use the server on which the operation is being performed as the terminology server."/> <type value="Endpoint"/> </parameter> <parameter> <name value="return"/> <use value="out"/> <min value="1"/> <max value="1"/> <documentation value="The result of the requirements operation is a _module-definition_ Library that returns the computed effective requirements of the artifact."/> <type value="Library"/> </parameter> </OperationDefinition>

Generated Narrative: OperationDefinition crmi-profiled-operation-example

Profiles: CRMI Operation Profile: Artifact Operation, CRMI Operation Profile: Artifact Version Bindable, CRMI Operation Profile: Artifact Endpoint Configurable, CRMI Operation Profile: Manifestable

URL: [base]/ActivityDefinition/$data-requirements

URL: [base]/ActivityDefinition/[id]/$data-requirements

URL: [base]/CapabilityStatement/$data-requirements

URL: [base]/CapabilityStatement/[id]/$data-requirements

URL: [base]/CodeSystem/$data-requirements

URL: [base]/CodeSystem/[id]/$data-requirements

URL: [base]/CompartmentDefinition/$data-requirements

URL: [base]/CompartmentDefinition/[id]/$data-requirements

URL: [base]/ConceptMap/$data-requirements

URL: [base]/ConceptMap/[id]/$data-requirements

URL: [base]/ExampleScenario/$data-requirements

URL: [base]/ExampleScenario/[id]/$data-requirements

URL: [base]/GraphDefinition/$data-requirements

URL: [base]/GraphDefinition/[id]/$data-requirements

URL: [base]/Group/$data-requirements

URL: [base]/Group/[id]/$data-requirements

URL: [base]/ImplementationGuide/$data-requirements

URL: [base]/ImplementationGuide/[id]/$data-requirements

URL: [base]/Library/$data-requirements

URL: [base]/Library/[id]/$data-requirements

URL: [base]/Measure/$data-requirements

URL: [base]/Measure/[id]/$data-requirements

URL: [base]/Medication/$data-requirements

URL: [base]/Medication/[id]/$data-requirements

URL: [base]/MedicationKnowledge/$data-requirements

URL: [base]/MedicationKnowledge/[id]/$data-requirements

URL: [base]/MessageDefinition/$data-requirements

URL: [base]/MessageDefinition/[id]/$data-requirements

URL: [base]/NamingSystem/$data-requirements

URL: [base]/NamingSystem/[id]/$data-requirements

URL: [base]/OperationDefinition/$data-requirements

URL: [base]/OperationDefinition/[id]/$data-requirements

URL: [base]/PlanDefinition/$data-requirements

URL: [base]/PlanDefinition/[id]/$data-requirements

URL: [base]/Questionnaire/$data-requirements

URL: [base]/Questionnaire/[id]/$data-requirements

URL: [base]/SearchParameter/$data-requirements

URL: [base]/SearchParameter/[id]/$data-requirements

URL: [base]/StructureDefinition/$data-requirements

URL: [base]/StructureDefinition/[id]/$data-requirements

URL: [base]/StructureMap/$data-requirements

URL: [base]/StructureMap/[id]/$data-requirements

URL: [base]/Substance/$data-requirements

URL: [base]/Substance/[id]/$data-requirements

URL: [base]/TerminologyCapabilities/$data-requirements

URL: [base]/TerminologyCapabilities/[id]/$data-requirements

URL: [base]/TestScript/$data-requirements

URL: [base]/TestScript/[id]/$data-requirements

URL: [base]/ValueSet/$data-requirements

URL: [base]/ValueSet/[id]/$data-requirements

Parameters

Use Name Scope Cardinality Type Binding Documentation

0..1

string

The logical id of the canonical or artifact resource to analyze.

url

0..1

uri

A canonical or artifact reference to a canonical resource.

version

0..1

string

The version of the canonical or artifact resource to analyze

identifier

0..1

string
(token)

A business identifier of the canonical or artifact resource to be analyzed.

expression

0..*

string

The name of a specific expression to be considered for analysis. If no expressions are specified, the analysis is performed on the entire resource. If expressions are specified, the analysis is performed only on the expressions specified.

parameters

0..1

Parameters

Any input parameters for the artifact. If the artifact is a logic library, or references logic libraries, parameters defined in this input will be bound by name to parameters defined in the logic library (or referenced libraries). If the logic library is a CQL library, parameter types are mapped to CQL as specified in the Using CQL with FHIR implementation guide. If a parameter appears more than once in the input Parameters resource, it is represented with a List in the input CQL. If a parameter has parts, it is represented as a Tuple in the input CQL.

artifactVersion

0..*

uri

Specifies a version to use for a canonical or 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

Note that this is a generalization of the system-version parameter to the $expand operation to apply to any canonical resource, including code systems.

checkArtifactVersion

0..*

uri

Edge Case: Specifies a version to use for a canonical or 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

Note that this is a generalization of the check-system-version parameter to the $expand operation to apply to any canonical resource, including code systems.

forceArtifactVersion

0..*

uri

Edge Case: Specifies a version to use for a canonical or 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.

It primarily exists to deal with situations where specifications have fallen into decay as time passes. If the version of a canonical is overridden, the version used SHALL explicitly be represented in the expansion parameters.

Note that this is a generalization of the force-system-version parameter to the $expand operation to apply to any canonical resource, including code systems.

manifest

0..1

canonical (CRMI Manifest Library)

Specifies an asset-collection library that defines version bindings for code systems and other canonical resources referenced by the value set(s) being expanded and other canonical resources referenced by the artifact. When specified, the expansion parameters of the manifest are used to provide expansion behavior and canonical resolution for dependencies encountered while processing the operation.

include

0..*

string

Specifies what contents should be included in the resulting package. The codes indicate which types of resources should be included, but note that the set of possible resources is determined as all known (i.e. present on the server) dependencies and related artifacts. Possible values are:

all (default) - all resource types
artifact - the specified artifact
canonical - canonical resources (i.e. resources with a defined url element or that can be canonical resources using the artifact-url extension)
terminology - terminology resources (i.e. CodeSystem, ValueSet, NamingSystem, ConceptMap)
conformance - conformance resources (i.e. StructureDefinition, StructureMap, SearchParameter, CompartmentDefinition)
profiles - profile definitions (i.e. StructureDefinition resources that define profiles)
extensions - extension definitions (i.e. StructureDefinition resources that define extensions)
knowledge - knowledge artifacts (i.e. ActivityDefinition, Library, PlanDefinition, Measure, Questionnaire)
tests - test cases and data (i.e. test cases as defined by the testing specification in this implementation guide)
examples - example resources (i.e. resources identified as examples in the implementation guide)

artifactEndpointConfiguration

0..*

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 canonical or artifact reference starts with artifactRoute
  - 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 canonical or artifact reference starts with artifactRoute: 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.

IN artifactEndpointConfiguration.artifactRoute 0..1 uri

IN artifactEndpointConfiguration.endpointUri 0..1 uri

IN artifactEndpointConfiguration.endpoint 0..1 Endpoint

terminologyEndpoint

0..1

Endpoint

An endpoint to use to access terminology (i.e. valuesets, codesystems, naming systems, concept maps, and membership testing) referenced by the Resource. If no terminology endpoint is supplied, the evaluation will attempt to use the server on which the operation is being performed as the terminology server.

OUT

return

1..1

Library

The result of the requirements operation is a module-definition Library that returns the computed effective requirements of the artifact.

The data requirements operation is used for dependency gathering, as a way to understand the set of dependencies of a given artifact, as well as for data requirements determination, as a way to understand the complete set of data requirements for a given artifact, including terminology usage (code systems, value sets, and direct-reference codes), parameters, dependencies, and data requirements.