The logical id of an existing Resource to package on the server.

A canonical reference to a Resource to package on the server.

The version of the Resource

A business identifier of the Resource.

A desired capability of the resulting package. computable to include computable elements in packaged content; executable to include executable elements in packaged content; publishable to include publishable elements in packaged content.

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.

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.

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.

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, code systems and other canonical resources identified as depends-on related artifacts in the manifest library have the same meaning as specifying that code system or other canonical version in the system-version parameter of an expand or the canonicalVersion parameter.

Paging support - where to start if a subset is desired (default = 0). Offset is number of records (not number of pages)

Paging support - how many resources SHOULD be provided in a partial page view. If count = 0, the client is asking how large the package is.

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)

True to indicate that the resulting package SHOULD only include resources that are defined in the implementation guide or specification that defines the artifact being packaged. False (default) to indicate that the resulting package SHOULD include resources regardless of what implementation guide or specification they are defined in.

An endpoint to use to access content (i.e. libraries, activities, measures, questionnaires, and plans) referenced by the artifact. If no content endpoint is supplied the evaluation will attempt to retrieve content from the server on which the operation is being performed.

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.

A TerminologyCapabilities resource describing the expected terminology capabilities of the target environment. For example, an environment may be capable of processing specific types of value set definitions, but not others (e.g. LOINC panel definitions, but not SNOMED hierarchies).

Indicates the request method (POST or PUT) that SHOULD be used for entries in the resulting package bundle. If not specified, the request method is at the discretion of the server.

Determines the type of the output Bundle, MAY be either collection, or transaction. If not specified, the output bundle will be a transaction bundle, unless paging is used, or determined to be necessary by the server.

If paging is used, the bundle type SHALL be searchset, and the resulting bundles SHALL conform to the paging guidance here: https://hl7.org/fhir/R4/http.html#paging

It is an error to request a transaction or collection bundle and use paging. Servers are free to return a TOO-COSTLY error if a transaction or collection bundle is requested for a package that is deemed to be too large by the server.

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.

The result of the packaging. Servers generating packages SHALL include all the dependency resources referenced by the artifact that are known to the server and specified by the include parameters.

For example, a measure repository SHALL include all the required library resources, but would not necessarily have the ValueSet resources referenced by the measure.