View raw Markdown
type: resourceresource: CanonicalResource

CanonicalResource

Introduction

Scope and Usage

The CanonicalResource represents resources that have a canonical URL:

As an interface, this type is never created directly - see Resource Interfaces for more details.

Boundaries and Relationships

This interface extends the base DomainResource. The following resources implement this interface:

Other Additional Resources may implement CanonicalResource. See the list here

Notes

Localization

All of the elements reflected on a canonical resource are the assertions as made by the original author/publisher and do NOT reflect divergent local usage expectations. If a system has a need to capture local usage requirements (e.g. local deprecation, local 'active' use past the point of deprecation/retirement by the official source, alternative effective periods, etc.), those assertions should be made in a separate resource (e.g. List, ArtifactAssessment, etc.) that focuses on approval/usage of referenced resources, not on the canonical/metadata resource itself. Alternatively, a separate resource might be defined that 'derives' from the original resource and can have its own properties.

There is however, a possibility of local changes on 'generated' elements such as ValueSet expansions, StructureDefinition snapshots, etc. In this case:

HL7 is developing a [Canonical Resource Management]([%ig crmi%]) implementation guide to define best practices for asserting and exposing local usage expectations of canonical and metadata resources. Readers are invited to consult the current release of that IG for additional guidance.

Version Comparison

Canonical resources may have both a version, and a version algorithm. In normal usage, implementers are strongly recommended to version all the canonical resources that they maintain. The difference between the CanonicalResource version (business version) and the Resource version in .meta.version is discussed on Resource.

The version algorithm allows applications to choose the correct latest version of a resource, since there is no general algorithm that chooses the latest version across all versioning schemes in place.

Implementers are encouraged to use semantic versioning, but may have existing approaches that are already adopted.

[%impl-note%] This mechanism we have for defining version comparison algorithm, where each version of the resource makes its own claim about how version comparison works is inelegant and feels somewhat clunky, but that was the best that the committee identified that would work in all circumstances. Alternative proposals that could be used to address the problem that would be less onerous are welcome. [%end-note%]

StructureDefinition

Elements (Simplified)

Mappings

Implementation Guide

implementationguide-CanonicalResource-core.xml

<?xml version="1.0" encoding="UTF-8"?>

<ImplementationGuide xmlns="http://hl7.org/fhir">
  <id value="CanonicalResource-core"/>
  <name value="CommonCanonicalResourceExtensions"/>
  <title value="Common  Canonical Resource extensions"/>
  <status value="draft"/>
  <date value="2014-04-12T00:00:00.000"/>
  <publisher value="Health Level Seven, Inc. - [WG Name] WG"/>
  <description value="Common extensions for use with the CanonicalResource resource"/>
</ImplementationGuide>

Operations

Full Operations

Resource Packs

list-CanonicalResource-packs.xml

<?xml version="1.0" encoding="UTF-8"?>

<List xmlns="http://hl7.org/fhir">
  <id value="CanonicalResource-packs"/>
  <status value="current"/>
  <mode value="working"/>
  <entry>
    <item>
      <reference value="ImplementationGuide/CanonicalResource-core"/>
    </item>
  </entry>
</List>

Search Parameters

Full Search Parameters