HL7 Terminology (THO), published by HL7 International - Vocabulary Work Group. This guide is not an authorized publication; it is the continuous build for version 7.1.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/UTG/ and changes regularly. See the Directory of published versions
CodeSystem: Artifact Version Policy Codes
The versioning policy of an artifact (metadata, strict, loose, package)
This Code system is referenced in the definition of the following value sets:
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.
|
Description of the above table(s).