SMART Guidelines Starter Kit
1.1.0 - ci-build
SMART Guidelines Starter Kit, published by WHO. This guide is not an authorized publication; it is the continuous build for version 1.1.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/WorldHealthOrganization/smart-ig-starter-kit/ and changes regularly. See the Directory of published versions
Versioning is critical to ensuring that consumers of the SMART guideline can understand when changes occur how those changes impact their implementations. For this reason, SMART guidelines SHALL follow semantic versioning as prescribed in the Artifact Versioning topic of the Canonical Resource Management Infrastructure IG.
As the guideline moves through the authoring lifecycle, the version and status are updated to reflect the current state:
draft
state, and has an initial version targeting the first version and with a draft label, typically 1.0.0-draft
.active
state, and the -draft
label is removed from the version.draft
state, and the version number is incremented, targeting the next version, typically 2.0.0-draft
(although this is dependent on the level of impact of the changes being targeted for the next release.This process repeats for each release of the implementation guide.
Note that the FHIR publication tooling uses the version
of the implementation guide overall to set the version
element of all the canonical resources in the implementation guide (i.e. all the Library, CodeSystem, ValueSet, StructureDefinition, etc.,.). As such, the version
element of individual resources in the implementation guide should not be set, allowing the publisher to set the versions appropriately.
After publication, any changes to the L3 resources should be tracked.
Tracking changes should include:
Every change should be traceable to a GitHub issue. This allows tracking the change and any approvals/discussions, as well as assisting in creating release notes.
State of each issue: GitHub issues should not be considered "done" when the change is agreed, but only when the change is effectively implemented and tested and the respective criteria is met.
See the publication topic for a detailed discussion of how to create change history and release notes (including known issues).
For some artifacts, the FHIR ImplementationGuide tooling may highlight the differences in the content of the artifacts between two versions. This can be used to track and demonstrate the detailed artifact changes.