Skip to end of metadata
Go to start of metadata


  1. Minimize manual operation requirement
  2. Maximize leverage of current FHIR releases publication tools and processes
  3. Be able to create a new published release on demand of both the full set of HL7 Terminology, as well as product line subsets or special collections.
  4. Timing of a published release is ad hoc, ie not schedule by particular dates but driven by other HL7 events and needs for such a release.


The content accessed through as browsable terminology is generated with the use of the FHIR IGPubliser set of tools.  In order to drive this, the HL7 Terminology is actually a FHIR IG "under the covers".  There are a number of special templates and control files that differ from those used for the FHIR IGs coming out of the Gravity and Accelerator projects, but the basic process and tooling is mostly the same.

Because terminology changes frequently, and experience has taught us that terminology releases happen around an order of magnitude more frequently that releases of a Standard or Implementation Guide (IG), the process will be explicitly put into a JIRA workflow in order to have predictable an controllable steps that are also amenable to ongoing automation improvement.   At the current time, the Software Maintenance UTG JIRA Project ("UPSM") is planned to be the home for the release workflow.   Any of the proposals (JIRA Issues) that enter this workflow will have a button which takes a curator or admin to the release workflow (away from the workflow to implement an Issue).   The intent it to have a "permanent" issue for initial control of releases in the same way that we have a "permanent" issue for setting of the voting control parameters;  these issues never transition out of the workflow, but are used as entry points for special control functions in the terminology maintenance.

The base process in place for publishing FHIR Implementation Guides can be found here. 

Design Elements

JIRA workflow and operator functions

  1. Permanent Issue for Control of Publishing Releases
  2. Question:   Should there be an Issue Type in the UPSM for "Published Release" and to 'kick off' the release process, a curator or admin creates a new Issue of this type and works through the steps?
  3. A number of custom fields to hold the information about the release are used to gather the release documentation from the curator.  This includes:
    1. Reason for the release
    2. Release version
    3. Type of release.  Types of releases are:
      1. Full, complete set of HL7 Terminology
      2. V3 only
      3. V2 only
      4. CDA only
      5. FHIR only
      6. Special
  4. Question:  how should the releases be versioned?   If a 3 part semi-semver layout is chosen, what do the clauses signify?
  5. A snapshot and the time of the snapshot of the current GitHUB/UTG content is taken
  6. A local build is triggered to construct the release
  7. The local build integrity and success is checked
  8. Operations are run to create a destination folder for the release under
  9. Operations are run to create a release manifest (List resource) which lists all of the resources in the release
  10. The zip file of the IG is uploaded to the newly created folder and unzipped
  11. Operations are performed to do all of the redirects if this is a Full release
  12. The installed release is spot checked that it looks OK
  13. Operations are run to create the new entry in the releases manifest section of the main home page
  14. Final check browsing to the release via home page is done
  15. Release is finalized

Release pages at

The initial plan is to have the releases under  Under that will be folders for the different types of releases, with the first one to be implemented being "full".

Inside that folder will be labeled folders, one per release.   Decision is not yet made whether they should be named for the date of the release or the release ID.

For use of release IDs, there is a question as to the numbering uniqueness: for instance, will there be a 1.0.0, 1.1.0, 2.0.0 etc for the 'full' as well as for others that have at least one release?  Or should the release ID hold in some way whether it is a full or partial release?

Process and Sequence

The JIRA workflow will be updated to reflect the manual workflow currently documented in the FHIR publication release process (see link above).  Parts of this will be automated as time and development resources permit over the next year.

The generation of a new release also includes the generation of a Published Release Manifest, which is a LIST resource that lists all of the content items (code systems, value sets, concept maps, and naming systems) in the release.  The manifest also contains the information of the tooling and publishing release process versions used to generate the release.   This resource will be in the full downloads package.   Still TBD: should this also be rendered on the release documentation pages?

Open Items that must be addressed (differences from the FHIR release process)

  1.  Specification of the destination end point location (URL server location) for the 'official' release
  2. Addition of the coremif generation into the process so that it happens during the release and is deposited in the appropriate location for download
  3. Redirects to accomplish the correct endpoints when the canonical URL is clicked on
  4. Download package(s) for loading/updating servers in the world

Versioning of Releases

The Terminology Releases will use a 3 part version ID.  Each part is an integer.  The parts are Major.Minor.Patch

The version numbers of the ci build and the releases follow the same scheme

  1. Major Version Number
    1. Beginning number is 1
    2. Pre-release initial debugging is major number 0
    3. Incremented when a new Published Release is done, with a checkpointed snapshot of the GiHub trunk ('master') of the HL7 Terminology to make a published full release
    4. Incrementing sets the minor number back to 0
    5. Incrementing sets the patch number back to 0
    6. The release manifest carries the last ci build version number from which the release was snapshotted
  2. Minor Version Number
    1. Beginning number is 0
    2. Incremented when singificant updates, changes, or enhancements to content (code systems, value sets, naming systems, concept maps) is PUSH'd to the GitHub trunk ('master') content source of truth
    3. Incremented number resets the Patch Number (see next item) to zero
  3. Patch Version Number
    1. Beginning number is 0
    2. Incremented every time there is a commit and push to the GitHub trunk ('master' of the terminology source of truth) subsequent to a Minor Number increment

  • No labels