1. Home

HL7 FHIR Governance

++ THE PROCESS DESCRIBED ON THIS PAGE IS SUBJECT TO CHANGE! ++

The members of the Program Board (The Program Board Plan d'action eSanté/Actieplan eGezondheid) decided in January 2020, whenever a project wants to  use HL7 FHIR, concerning how the content is expressed in the HL7 FHIR standard, it shall follow the flow as explained on this page.

As a general guideline we strive to regard this process as being an enabling factor for projects.
This flow leverages the existing public structures and the HL7 Belgium organisation. As shall be clear from the information on this page, the project itself is considered a driving agent.

As the process describes a standard from HL7, it shall be noted this process uses two actors supported by HL7 Belgium:

The HL7 Belgium FHIR validation team:
This is a group of experts, when needed supplemented with members from the WGSE.
Its members have sufficient technical/content knowledge of and experience with the HL7 FHIR standard to judge and technically validate the technical correctness of any FHIR artefact that is presented.
Following the HL7 principles, this is open for industry and non-industry people to join provided they have the sufficient knowledge as described above and can commit to regular meetings and preparatory work.
The secretariat of the HL7 Belgium FHIR validation team is shared with HL7 Belgium.
This group meets on a regular basis (for now this once every two weeks)

A HL7 Belgium Workgroup:
This is a group of experts that can deliver FHIR artefacts based on functional use cases and data model.
A HL7 workgroup centers on specific content/projects and works with project members in the governance described on this page.
Following the HL7 principles, this is open for industry and non-industry people to join provided they have the sufficient knowledge as described above and can commit to regular meetings and preparatory work.
The secretariat/coordination of HL7 workgroups is shared with HL7 Belgium.
This group meets according to its needs.

The following graph gives a high level overview of the process, please scroll down for detailed information.

Important notice:
For readability reasons, the flow is described here in consecutive steps.
In many cases of course, when a deliverable is being reviewed it can mean challenging a previous step.
This is fully expected to happen to guarantee the quality of the final deliverables and to ensure everything remains compliant with the international standard.

Step 1:Start

Step 1.1: Signal the initiative (Responsible: The project)

Important preliminary remark concerning the project proposal:

  • This proposal will be read by multiple actors in step 2. As such, it shall be noted most of this proposal in the context of the standardization effort is informative but important nevertheless to  understand the context of the flow.
    Naturally, the use cases and  logical data model  are normative project inputs  and will have to reach a sufficient maturity before any standardization can happen - the project might continue to further define these after the initial sending of the project proposal. (Cfr. step 3.1)
    If they are not fully mature at the time of creating the initial proposal they shall be clearly marked as 'example' or 'draft' in the proposal.

The project (i.e. the goverment and/or industry stakeholder that wants to realize a new flow) creates its proposal. It  shall be a maximum of 5 pages and consists of these parts: 

In the style of a management summary the project proposal shall include:

  • Sponsor and contact details (i.e. the driving organisations and mail/telephone information of key contact persons)
  • A description of the care process (i.e. what is the added value and/or the problems that this project solves)
  • The concrete business use cases
  • Clear identification of the different actors in the process
  • The actual transactions that will take place: what information (logical datamodel) is send where
  • Any existing related project or flow (e.g. it is expected a different region will do the same flow)

This proposal shall also include:

  • A proposal which international standards the project wants to use (e.g.  SNOMED-CT terminology, FHIR resources, FHIR REST API...)
  • Expectations towards use of infrastructure/technology (e.g. use of RSW/RSB/Vitalink, use of REST,...)
  • Expectations towards adoption and use

As the project is considered the leading agent in this flow, the proposal shall also include:

  • If the project contains open questions concerning what will be actually exchanged, the proposal shall include the parties that will work on this. (Cfr. step 3)
  • A proposal how the project will contribute to workgroups to propose creation and/or evolutions of FHIR profiles. (Cfr. step 3)

Some real life examples can help you on your way.

The proposal is to be send to two parties: the eHealth Platform Standards Department via message-structure@ehealth.fgov.be and to HL7 Belgium  via hl7belgium@gmail.com

Step 2: Review

Step 2.1 and step 2.2 happen concurrently.

Step 2.1: Quality review of signal (Responsible: WGSE)

The eHealth Platform Standards Department will do a quality review of the proposal and might leverage its WGSE (The Working Group Structuring of Elements: a group of eHealth Platform and its stakeholders defining the structure of technical messages used to transport information.) This step does not imply a  value  judgment of the proposal.

When quality is deemed sufficient, the proposal is send to the Program Board.

Step 2.1.1: Adoption decision by Program Board B (Responsible: Program Board Actionplan)

The Program Board B reviews the proposal and decides whether this project is to be adopted in the Action Plan. 

The Program Board sends a complete report of its review and decision to the project.

Adoption status means this project will be supported by interoperability tests, training will have to be scheduled, homologationcriteria will be impacted and some extra support possibly goes to current infrastructures, services or legal initiatives.

If the project is adopted it means the Program Board works together with the project on these criteria by step 4.3

If the project is not adopted step 4.3 is skipped.

Step 2.2: Review by HL7 Belgium FHIR Validation team (Responsible: HL7 Belgium)

HL7 Belgium FHIR Validation team reviews the approach of the proposal in the context of its expertise.

The HL7 Belgium FHIR Validation team is ideally placed to evaluate whether the project is sufficiently defined to go to step 3. When it considers the project is not yet sufficiently defined in the proposal, it will ask the project for an updated version of the proposal.

HL7 Belgium Validation team gives its feedback to the project and works together with the project to have workgroup meetings in step 3 and decides with the project whether it is efficient to advance directly to step 3.2.

Step 3: Towards a standard proposal

Workgroup meetings take place to determine the actual datamodel of the data exchanged and the proposal how to do this using HL7 FHIR resources.
As mentioned supra, step 3.1 might be skipped if HL7 Belgium considers its criteria met to start the HL7 workgroup.

Step 3.1: Defining the project and its content (Responsible: The project)

If the project is still in its early phase (i.e. the project still has to discuss many non-data model related matters), these meetings are under the umbrella of the project where HL7 experts might attend to help give some guidance towards HL7 standards.

Minimum deliverables of step 3.1 are a collection of structured use cases and the logical datamodel.
In case of projects following a REST architecture, the project is also responsible for the creation of a Swagger file to help other parties to implement. The Swagger deliverable is not a required deliverable to go to step 3.2 but the project nevertheless shall make it available by the start of step 4. The Swagger file is not a FHIR artefact and as such shall not be validated by the FHIR validation team but remains the responsibility of the project.

If step 3.1 takes place, it is expected to flow naturally into step 3.2

Step 3.2: Datamodel and development of standard (Responsible: HL7 Belgium)

Workgroup meetings take place, organised as HL7 Workgroups, to work towards a HL7 FHIR proposal.

This work might include, but is not limited to creation of FHIR datamodels, profiles, creation of supporting FHIR artefacts like ValueSets and CodeSystems and publication of these on a temporary location. (e.g. as a draft on a FHIR register or in a draft Implementation Guide) In other words, the output of 3.2 are technical FHIR artefacts.
These technical FHIR artefacts shall be made available using tooling according to the HL7 FHIR specification. The above mentioned draft on a FHIR register or draft Implementation Guide shall be understood as: this will take the form of draft publishing on a  public registry such as Simplifier and/or creation of an Implementation Guide that is published on Github. 

Step 4: Review of the standard proposal

Depending on the complexity of the work, step 4.1 and 4.2 might happen concurrently.
Step 4.3 is skipped when the project is not adopted by the Program Board.
If the project is not adopted by the Program Board and there is no added value to have a federal approach, step 4.2 is skipped. (An approach that is only validated by HL7 Belgium might however become or evolve to a federal standard in the future.)

Step 4.1: Validation of standard proposal of the project (Responsible: HL7 Belgium FHIR Validation team)

HL7 Belgium FHIR Validation team reviews and validates the work done in step 3. If it did not yet happen in step 3.2, HL7 Belgium Validation team will check the correct use of the FHIR artefacts and if all deliverables are present to have a working approach.

Step 4.2: Quality review of standard proposal of the project (Responsible: WGSE)

The quality of the proposal as generated in step 3 is presented and reviewed by WGSE.

Step 4.3: Check on adoption criteria by Program Board (Responsible: Program Board Actionplan)

The program board B follows up on its criteria of adoption together with the project. During this follow up it might happen the program board detects certain aspects or details that are not yet covered or were not yet detected. As such, step 5.2 might  have to wait.

Step 5: Publication

For projects  that are not adopted by the Program Board and do not have added value for a federal approach, only step 5.1 happens.

Step 5.1: Validation to publish as a HL7 community standard (Responsible: HL7 Belgium)

The standard is published via the website of HL7 Belgium. (i.e. minimally, the website points to the location where the publication is done - this might be an international FHIR registry or the FHIR Implementation Guide artefact) In case step 5.2 does not happen immediately, this HL7 standard might however be still considered to become or to evolve to a federal standard in the future.

Step 5.2: Validation to publish as a HL7 federal standard (Repsonsible: WGSE)

The standard is published via the website of eHealth Platform Standards. (i.e. minimally, the website points to the location where the publication is done - this might be an international FHIR registry or the FHIR Implementation Guide artefact)
It shall be clear the fact alone something is published as a federal standard does not automatically imply any legal requirement by any party (vaults, industry,...) to immediately implement something.