Common Interface declaration for definitional resources + Warning: Name should be usable as an identifier for the module by machine processing applications such as code generation
Canonical identifier for this {{title}}, represented as an absolute URI (globally unique) + Warning: URL should not contain | or # - these characters make processing canonical references problematic
Common Interface declaration for definitional resources + Warning: Name should be usable as an identifier for the module by machine processing applications such as code generation
Canonical identifier for this {{title}}, represented as an absolute URI (globally unique) + Warning: URL should not contain | or # - these characters make processing canonical references problematic
URL should not contain | or # - these characters make processing canonical references problematic
exists() implies matches('^[^|# ]+$')
2.1.27.6.4.3 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:
If the source of truth is providing expansions, snapshot generation or similar "generated" elements, then it is
not a good idea for downstream servers to update/override them.
If the source of truth is NOT providing those generated elements, then it is reasonable for downstream servers to
generate them (and update them from time to time). If this happens, it is possible that different servers will have
different generated elements. This would not be considered a violation of the guidelines proposed above.
HL7 is developing a Canonical Resource Management 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.
2.1.27.6.4.4 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.
Implementation 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.
2.1.27.6.5 Search Parameters
Search parameters defined by this interface for all implementations. See Searching for more information about searching in REST, messaging, and services.