Difference between revisions of "FHIR Community Process"
| Line 1: | Line 1: | ||
This page documents the FHIR Community process | This page documents the FHIR Community process | ||
| − | Organizations | + | = 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. | 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. | ||
| Line 16: | Line 27: | ||
HL7 plays 2 roles in this community: | HL7 plays 2 roles in this community: | ||
| − | * Provides the FHIR Platform and defines the rules of the | + | * Provides the FHIR Platform and defines the rules of the FCP |
| − | * Acts as a | + | * Acts as a CCDO along with many other organizations |
| − | HL7 pledges not to use it's role as the FHIR Platform owner to unfairly | + | 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'''. | Note: '''HL7 has not actually made this pledge at this time'''. | ||
| − | = Signed up | + | = Signed up CCDOs = |
| − | The following organizations have committed to follow the | + | The following organizations have committed to follow the FCP: |
* todo.... | * todo.... | ||
| − | * candidates: IHE HL& CEN SNOMED Carequality CarinHealth CommonWell ONC Infoway | + | * 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 | + | |
| + | 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 (while getting going) + 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/) | ||
| + | * 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 | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
= Process Support for community Maturation = | = Process Support for community Maturation = | ||
Revision as of 06:21, 20 March 2019
This page documents the FHIR Community process
Contents
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 and HL7 affiliates
- who owns the coordination committee?
The HL7 pledge
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
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 (while getting going) + 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/)
- 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
Process Support for community Maturation
How to get involved in the community
Minimum Process Support
- all FHIR Community Process work items must be open to everyone to comment.
- control over issue resolution, work prioritization may be limited to paid members
