https://github.com/devices-on-fhir/PoCD-IG README file is an essential reference. These are some key links from that document:

Reminder of the timeline:

  • 2018-08-17: Pre-ballot (and connectathon) content freeze. Publication process begins, including ensuring that content is appropriately flagged for ballot status and there are no last minute QA issues
  • 2018-08-24: Ballot opens
  • 2018-09-24: Ballot closes and initial triage occurs. Note: No substantive changes allowed for normative candidates unless they drop to STU.


General FHIR IG information resources

FHIRImplementation Guides page on hl7.org wiki


Excerpt from page FHIR Implementation Guides relevant to current stage of work:

  • Publishing (once complete)
    • Milestone builds should be published to the canonical location (copying the set generated html files around)
    • The canonical location layout should generally follow the Standard FHIR Publishing Layout Pattern
    • Content to be published on hl7.org or fhir.org must be generated via the FHIR IG publisher

Excerpt from Standard FHIR Publishing Layout Pattern  relevant to current stage of work:

Every FHIR related specification has a {canonical} URL: this is the logical master URL at which the content is published. For example, the canonical URLs are fixed for HL7 published FHIR specifications:

The canonical URL is tied to the master web server that hosts the IG. The {root} directory is the physical directory on the web server that the {canonical} URL points to.

Inside a {specification} the content can be any valid static HTML desired. Javascript is allowed, subject to the limitations noted [todo]

The standard home page is 'index.html'

The main layout is 

{root}\directory.html

A master file that lists the formal releases of the specification - typically, milestone drafts for connectathon support, ballot subjects, and final publications. It should also reference the current build

{root}\{specification}

The current formally published version. e.g. STU1. When there is no formally published version, then this should be the latest milestone draft. After this is formally published as an STU, this is not necessarily the latest copy

{root}\{version}\{specification}

Archived past versions of the specification. 

When you post a formal published version, you post it twice: once to {root} and once to {root}\{version}

  • No labels