FHIR 5.0.0 © HL7.org  |  FHIRsmith 0.8.5  |  Server Home  |  TX Home  |  Capability Statement  |  Terminology Capabilities  |  Operations  |  Problems  |   

TX: CodeSystem artifact-version-policy-codes

Properties

Language en
Defining URL http://terminology.hl7.org/CodeSystem/artifact-version-policy-codes
Version 3.0.0
Name ArtifactVersionPolicyCodes
Title Artifact Version Policy Codes
Status active
Definition

The versioning policy of an artifact (metadata, strict, loose, package)
Publisher HL7 International
Committee cds
Copyright This material derives from the HL7 Terminology (THO). THO is copyright ©1989+ Health Level Seven International and is made available under the CC0 designation. For more licensing information see: https://terminology.hl7.org/license.html
EXT_FMM_LEVEL 3
Value Set Artifact Version Policy

This case-sensitive code system http://terminology.hl7.org/CodeSystem/artifact-version-policy-codes defines the following codes:

Code Display Definition
metadata Metadata A versioning policy that allows non-substantive changes to the metadata elements of an artifact without requiring a change to the value of the version element. Metadata elements are defined as elements that characterize information about the artifact (e.g. description, publisher, useContext, jurisdiction, approvalDate, etc) as defined by the MetadataResource pattern (including elements inherited by the CanonicalResource pattern), except for identity elements (i.e. url, version, and name). Content that makes use of the metadata versioning policy SHOULD still update the date element when metadata content changes. Repositories that host content using metadata versioning SHOULD use cache control headers to ensure downstream systems are aware of the possibility of changes to the artifact.
strict Strict A versioning policy that indicates that any change to the content of an artifact, including non-substantive and metadata changes, requires a change to the value of the version element, with the exception of the `id` and `meta` elements (consistent with FHIR signature requirements) as well as the `status` (to allow for active content to be marked retired), and `lastReviewDate` (to allow for last review date to be communicated) elements. Repositories that host content using strict versioning SHOULD use cache control headers to ensure downstream systems are aware of the possibility of changes to the artifact.
loose Loose A versioning policy that indicates that only breaking changes require a change to the value of the version element of the artifact. Content that makes use of the loose versioning policy SHOULD update the date element when content changes. Repositories that host content using loose versioning SHOULD use cache control headers to ensure downstream systems are aware of the possibility of changes to the artifact.
package Package A versioning policy that indicates that version of the artifact is managed as the version of the package in which the artifact appears. This is a common versioning policy often used when artifacts are published as part of an implementation guide, and is important to consider as it indicates that there may be version changes _without_ corresponding changes in the content of a particular artifact. For example, if an implementation guide includes questionnaires, new versions of that implementation guide may include new questionnaires, but not change existing ones, and in this case, with package-managed versions, the existing questionnaires that had no actual changes would still be published with a new version.