FHIR Community Process

This page documents the FHIR Community process

Summary

The FHIR Community Process (FCP) describes a common process where a variety of Community Consensus Development Organizations (CCDO) work in different parts of the overall FHIR Community to create sub-communities that work together to solve particular interoperability problems using FHIR. The usual end-product of this process is one or more published FHIR implementation guides that are subject to ongoing maintenance.

Many CCDOs are formal Standards Development Organizations, with their own extensive governance requirements, but not all are, or need to be. A variety of organizations publish FHIR specifications, each that represents a different set of stakeholders and approaches. Almost all of the organizations have overlaps in membership and stake holder communities, but bring their own value proposition.

The goals of the FHIR Community Process are:

• ensure a consistent overall approach for the community to deal with
• allow for a variety of approaches to developing FHIR sub-communities (reflecting a variety of needs)
• minimise incompatibilities between the different projects (which naturally have overlapping and diverging aspects)

Organizations that follow the FCP may label their marketing material, specifications, and other documentation with the "FHIR Community Process" icon (yet to be developed). Note that any organizations may develop and publish FHIR specifications without following this process, but they cannot use the FHIR Community Process stamp of approval.

Note that there may be still be competition between the organizations as they vie to represent the community; such competition is both good and bad for community - good, in that it helps keep the community honest, and bad, where the same problem may be solved with incompatible specifications.

Major open issues

• what is the relationship between this general process and Gemini?
• what is the relationship between this general process and JIC?
• what is the right way to handle relationships across countries?
• who owns the coordination committee?

HL7 as a CCDO

HL7 plays 2 roles in this community:

• Provides the FHIR Platform and defines the rules of the FCP
• Acts as a CCDO along with many other organizations

In addition, the HL7 Affiliates are also candidates for CCDOs, and may sign up to CCDO agreements. Note that due to the loose arrangements between HL7 and the affiliates, there is no common process fore affiliates to follow, and each Affiliate chooses to be a CCDO; if they choose to be, they must provide their own CCDO document (as described below)

HL7 pledges not to use it's role as the FHIR Platform owner to unfairly advantage it's own standing as a CCDO. Note that as an open membership organization, HL7 processes in this regard are necessarily open and transparent.

Note: HL7 has not actually made this pledge at this time.

Signed up CCDOs

The following organizations have committed to follow the FCP:

• todo....
• candidates: IHE HL& CEN SNOMED Carequality CarinHealth CommonWell ONC Infoway + many others

This means that at least some of their activities follow this process, and are published as FCP Specifications

New Projects

New projects may be brought forward by any participant in the community (individual, company, government agency, NGO) whether they are a CCDO or not. Candidate projects are identified and brought forward to whichever CCDO is nearest, whether or not it is the most appropriate. CCDOs should maintain active outreach with the community around them to ensure early discovery of potential projects. One a candidate project is identified, participating CCDOs bring it to the FCP Coordination Committee.

FCP Coordination Committee

The FCP Coordination Committee is a group whose membership consists of representatives from all participating CCDOs that have committed to the FCP. The role of the committee is to act as a clearing house for the FCP process - all new FCP projects are proposed to the committee for review, to ensure that all CCDOs are informed abotu what work is taking place. The coordination committee does not have veto rights over any particular CCDO project, but CCDOs commit to doing their best to minimise overlaps.

Further (draft) details about the proposed FCP Coordination Committee:

• The committee has a leadership and secretariat chosen from amongst the CCDOs by the committee on an annual basis. Initial candidates: Grahame Grieve (term limited to 1 year) + HIMSS
• All deliberations are open to public (minutes, proposals, discussions etc on publicy available web resources). Only CCDO representatives can take part directly
• Committee maintains it's own processes to describe how proposals work etc.
• An additional role of the committee leadership is to maintain out reach to key community bodies such as [GDPR](https://www.gdhp.org/) and [JIC](http://www.jointinitiativecouncil.org/) (note that the coordination committee has a different set of members than JIC (non SDOs) but their roles overlap; hence the need for a formal relationship)
• maintains a web site where approved projects are published

Project Proposals

Project proposals made to the CCDO include information such as:

• scope / description
• proposed license
• reference to CCDO documented engagement process
• identified dependencies, overlaps, and other related projects

Project Development

Once a project is announced, development begins.

• CCDOs must have a documented policy that describes how the development process is governed
• the license and IP contribution requirements must be clearly documented
• there must be a way for anyone to comment, and contribute IP to the project
• Input into the issue resolution, formal ballot and work prioritization decision and project leadership maybe restricted to a sub-community based on CCDO policy or membership (or government obligations). Such rules must be clearly documented
• Community engagement strategies must be clearly documented (e.g. meetings, teleconferences/webexs, wikis, email lists, chat lines etc), and in particular, how to be notified of significant project events must be documented
• how the community support (particularly the secretariat) is provided and funded must be clearly documented
• potential conflict of interests must be made public to the community

The overall cycle of development follows these general steps:

• development of scope and intent
• recruitment of interested parties (marketing - CCDOs undertake to help each other in this process)
• repeated cycles of
  • publishing draft specifications
  • open community discussion
  • testing the specification at community events
• those repeated cycles gradually fill out the detail and the community agreements become more robust
• (optional) formal review cycle (or ballot) - last call for comment
• publication of milestone release - usually, a FHIR implementation Guide, but other outputs are possible if they better capture the community agreements
• restart the process

The CCDO project documentation must include a simple document that describes how this general process is manifested in their internal processes (though it may do by referencing into existing CCDO process documentation)

Project Transfer

Projects may be transferred between CCDO members. This might be done because

• a project is growing beyond the capacity of the initiating CCDO to provision support for it,
• a project initiated at a national level proves to have strong international interest
• the project has entered a different stage of it's natural life cycle, and a different CCDO is appropriate (e.g. HL7 or the FHIR Foundation might be the CCDO of last resort for long term maintenance)

Nothing about the FCP process requires such transfer to occur, but projects following the FCP process are much more ready to transfer between CCDOs, and the FCP process may make the advantages of such a transfer more obvious.

Project Output

Most FCP projects produce FHIR implementation guides as their primary output, which capture the agreements made by the community that partakes in the project. Other possible outputs include ISO standards, wiki documentation, or working software. Each FCP project must have clearly documented expectations regarding what the outputs are (note that these may change over team, but the community must be consulted when they do).

When the project produces Implementation Guides, the Implementation Guide should have the FCP Icon somewhere on the home page. In addition, the Implementation Guide must conform to the rules documented for FHIR Ig publishing Requirements. Note that HL7 provides tooling to produce implementation guides that meet these requirements, but it is not required to use the tooling. Additional rules for FCP IGs:

• The license must be clearly documented in the IG. If other encumbrances exist, these must be documented as well
• the FCP version release strategy must be followed (to be documented)
• how to raise issues against the IG must be clearly documented
• how to report security issues must be clearly documented
• the IGs should be published at their canonical URL (or linked to from there)

Ongoing Maintenance

CCDOs are responsible for providing ongoing maintenance of their projects and published IGs. If CCDOs close projects, or if the CCDO itself is closed or ceases to act as a CCDO, it is expected to make arrangements internally or with other CCDOs to take over management of the project and/or it's outputs.