Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Requested Version: enter the version requested in the publication request (should be in Requested name for published standard). If this is not specified in the publication request, then talk to the nominated editor. 
  • Stated Milestone: if this is a milestone, the stated version (e.g. "STU 1") - you can get this from the version check in the QA file. If it is not popluatedpopulated, or doesn't match the publication request, consult the editor and/or TSC co-chair
  • Actual Version: copy this from the version specified in the "Version Check" row in the QA page. if there are any errors shown, or it doesn't match the requested version, consult the FHIR Product Director

4. Publishing Integrity

  • fill out the canonical (from the Publication Code row in the QA page, and check that it's the same as http://hl7.org/fhir/{realm}/{code})
    • If this is is a new IG: Look up the URL {canonical}/package-list.json and check that it doesn't exist
    • if this is not a new IG: Look up the URL {canonical}/package-list.json and check that the canonical url and packageId and the name of the IG in the package list agree with the details for the IG (canonical and packageId must be identical, name can vary a little). Also check that there are no single quotes in the description; use ASCII equivalent "'" instead.
  • (up to here)
  • and packageId ( - consult the FHIR Product Directory if it's not 
  • fill out the package id from the Publication Code row in the QA page, and check that the package id the same as hl7.fhir.{realm}.{code}) values from the Publication Row in the qa page 
  • Realm: add the realm code identified in the IG approval page. Check that this is consistent with the stated scope of the ballot and in the TSC approval
  • Code: 
  • now check the qa page (rightmost link on the IG Builds page).
    • check that the packageId and canonical URL in the first line are correct against the spreadsheet, and check that the stated path starts with {canonical}
    • Review any errors in the page, paying particular attention the publication QA checks at the top
    • If there are any errors, refer to the FHIR product Director for approval
    • Once ok, record "yes (N)" in Build QA column, where N is the number of errors
  • in the version column, record the version as stated in the first line (after the {packageId#} part
    • if this is a new IG: the version should be 0.1.0, or as approved by the FHIR Product Director
    • if this is a not a new IG: check that the FHIR Product Director has approved the version
  • in the subdir column, record the subfolder stated in the publication path (in the current entry in the package-list.json file)
  • project team needs to add a new entry if one does not exist since the last ballot
  •  - consult the FHIR Product Directory if it's not. Add the version (#version)
  • fill out the subdir column using the value from the version check row. if the value is ??, consult the FHIR product director
    • If it does not conform to the pattern YYYYMMM (with the date correct) or STU{X}, check with the FHIR product director
    Now review the actual guide (left most link in the IG build page)

5. Content quality

  • Check that the header conforms to the FHIR Implementation Guide Publishing Requirements:
    • check that the header shows the name of the IG and the ballot status correctly.
    • check that the header shows the correct HL7 logo
    • check that the header includes the yellow publish box that displays correctly (don't worry about what it actually says)
    • if all checks out, "yes" in the header column
  • Check that the footer conforms to the FHIR Implementation Guide Publishing Requirements:
    • check that the following items are shown in the footer: packageId, version, FHIR version, publishing committee, history link, propose changes link, Copyright (© 20YY+), generated date
    • if all checks out, "yes" in the footer column
  • Check that the download package is linked (from index or downloads page)
  • check that {registry} and {history} are up to date (git PULL)the QA page Quality Checks section. Specific things to review:
    • Publisher Version is identified, and not reported as out of date 
    • Publication Code: no errors reported
    • Realm Check:  FMG / US Steering committee checks this - can be ignored
    • Version Check: check no errors reported 
    • Dependency checks: no errors / issues identified 
    • HL7 Publication rules: no errors/issues identified 
    • HTA Analysis: this can be ignored (for now)
    • Previous version comparison: can be ignored 
    • Summary: copy to "QA Summary column"
      • if the error count > 0, refer to the FMG co-chairs or the FHIR Product director, unless you are sure that the list is unchanged from FMG approval 
  • Template checks
    • Check template currency (at end of Dependency Checks). The stated version for fhir.base.template must be 'current' or more recent than '0.2.1"
    • If there is no stated template, or it is older than 0.2.1, consult the FHIR product director 
    • record the fhir.base.template version in the spreadsheet
  • IG Review 
    • Open index.html, and check that the header shows the name of the IG and the ballot status correctly

ok. if you get to here, we are good to publish.

Local Build

Now that the main checks have been done, you need to do a local build. To do that, you need a copy of the IG Publisher - see IG Publisher Documentation for assistance

  • clone the github repository to your local drive = {clone}
    • you should call it {packageId}#{version}
    check the package-list.json
    • must include 'category'; if not, editors should consult Grahame
    • ensure package id, version are correct, update date
  • run the IG publisher, clearing the terminology cache (run the publisher.jar -ig {clone} -resetTx -publish {url})
    • where {url} is the url that the guide will be published at , (which is usually {canonical}/{subdir} - the subdirectory from above. If you are not sure about this valid, consult Grahamethe path entered into the spreadsheet above}
  • check that the local {clone}/output/qa.html file matches the CI build qa.htmlhtml 
  • Zip up the folder {clone} as it is to a file named {packageId}#{version}.zip and ftp to ftp://hl7.org/fhir/ig-build-zips

You are now good to publish the IG

...

Publishing the IG

Note: if you are publishing a set of IGs, you can do this part of the process - and all that follows as a batch

  • create a local directory = {root}
  • use FTP to copy the current contents of ftp://hl7.org/fhir to {root}
    • 1 million+ files. Keep this maintained in advance, or give 48 hours + to build it
    • Check with other publishers before making the copy (publishers = Grahame & Lynn)
    • If you keep this maintained, use FTP to sync your copy each time the contents of http://hl7.org/fhir/package-feed.xml changes (subscribe with a feed reader), or as discussed between publishers
  • in your local directory
    • if this is a new IG: create the folder {root}/{realm}/{code}, and copy in {clone}/package-list.json (e.g. to {root}/{realm}/{code}/package-list.json)
    • if this is not a new IG: edit the file {root}/{realm}/{code}/package-list.json and add the entry for the {version} found in {clone}/package-list.json
  • set the date in {root}/{realm}/{code}/package-list.json entry for {version} to today's (US) date using the format yyyy-mm-dd
    • if this is a new IG: copy the contents of {history} into {root}/{realm}/{code} (except for the readme.md file), and edit the name in index.html (replace 'XXXXXX')
  • create the folder {root}/{realm}/{code}/{subdir}
  • copy the content from {clone}/output to {root}/{realm}/{code}/{subdir}
  • mark "yes" in the Copied column

Milestone releases

If you are doing a mile stone release (a STU publication of the IG), some additional steps are required:

  • delete all files and directories in {root}/{realm}/{code}: publisher.jar -delete-current {root}/{realm}/{code} -history {history}
  • re-run the IG publisher: publisher.jar -ig {clone} -publish {url} -milestone
    • check it succeeds
  • copy the content from {clone}/output to {root}/{realm}/{code}. Say "yes" to overwrite any existing files
  • update the package-list.json to set "current": true on the new version, and remove that from any other past published version (but not from the current build entry)check that {registry} and {history} are up to date (git PULL)
  • when all these are synchronised, run publisher.jar -go-publish -source {clone} -destination {root} -registry {registry}\fhir-ig-list.json -history {history} -milestone
    • only add the -milestone part if you are publishing a milestone (from the checks above)
    • If this process fails, you need to resync {root} so that it has the same contents as before you ran it, and then consult the FHIR Product Director, and then repeat 
  • mark "yes" in the Milestone Published column

Finishing the Publication Process

  • Run the IGPublisher on {root}: publisher.jar -publish-update -folder {root} -registry {registry}/fhir-ig-list.jsonNote: if you are doing multiple IGs, you can do this step once for the whole group (do everything to this point for all files), but the remaining steps must be done for each IGcheck the output for the IG(s) being changed: it should report that it changed N files for each published version of the IG (including previously published versions)if problems, consult FHIR product director (and start again from the creating a local root directory)if you are doing a milestone release: use FTP to delete the contents of ftp://hl7.org/fhir/{realm}/{code}: yes, delete all the files
  • use FTP to copy the entire contents of {root}/{realm}/{code} to ftp://hl7.org/fhir/{realm}/{code} - no need to upload files that have not changed
  • mark "yes" in the FTPed column
  • FTP the files {root}/package-feed.xml to ftp://hl7.org/fhir/package-feed.xml and {root}/publication-feed.xml to ftp://hl7.org/fhir/publication-feed.xml
  • check the changes to {registry}/fhir-ig-list.json (use git diff) and fill out any missing information (look for ?? in the changes) - may need to talk to FHIR product director to decide what to put
  • check that the fhir-ig-list.json file is valid using https://jsonlint.com/
  • commit and push the changes to the FHIR IG registry to github to a new branch, let Grahame know, & mark "yes" in the Register IG columnNote: if you are doing multiple IGs, you only need to do the previous 3 steps once
  •  new Publication: [publication name] of the [IG Name] implementation guide: {canonical}/{subdir}
    

    e.g. New Publication: STU Update 3.2 of the QI-Core implementation guide: http://hl7.org/fhir/us/qicore/STU32/

Final steps. note that if you are publishing nore than one IG, you can do the following steps as once for whole set:

  • FTP the files {root}/package-feed.xml to ftp://hl7.org/fhir/package-feed.xml and {root}/publication-feed.xml to ftp://hl7.org/fhir/publication-feed.xml
  • check the changes to {registry}/fhir-ig-list.json (use git diff) and fill out any missing information (look for ?? in the changes) - may need to talk to FHIR product director to decide what to put
  • commit and push the changes to the FHIR IG registry to github to a new branch, let Grahame know, & mark "yes" in the Register IG column