Creation and Curation of FHIR Profiles - process and governance

Creation and Curation

The focus wasn't on the technical process of creating profiles (using tools like Forge), but on the governance of the creation process. How does one ensure that the created artefact (a profile in this case) has a sufficiently high maturity for it to be used in production? How does one ensure participation and input from all stakeholder groups ?

To skip directly to the summary of the best practices around the Creation of artefacts (covered below in a separate section), go to 07:03 in the video. To skip directly to the summary of the best practices around the Curation of artefacts (also covered below in a separate section), go to 22:05 in the video.

Creation of FHIR Profiles

When looking at the process of creating new FHIR profiles one can look at the process of the creation of FHIR artefacts in general. HL7 itself has quite an elaborate process for the creation of production-ready (normative) artefacts. In general, FHIR distinguishes 3 phases in the lifecycle of an artefact: draft, active and retired. Multiple 'Maturity Levels' have been introduced, with a set of well-defined criteria as to when a new maturity level has been reached. Other projects use different maturity models. Quite a few use some form of test event to drive the maturity of the artefacts forward, through hackathons or sprints.

Some FHIR projects focus on the 'draft' stage of the artefact, to ensure that the underlying requirements have been well described. care should be taken not to develop a profile which (partially) already exists.

In general, the best practices around the creation of profiles can be summized as follows:

• Process
  • Create a maturity model - QA criteria, test events, input from specific stakeholder groups
  • Use test events to advance the maturity level - Sprints, connectathons, etc.
  • Use a 24/7 issue tracker - Resolve issues as they arise, short cycles
  • Occasionally Freeze a coherent set of artifacts - Versioning, formal approval process
• Governance
  • Monitor/adjust process - Ensure proper representation of all stakeholder groups

Curation of FHIR Profiles

When one doesn't define ones own profiles, but one has a responsability to curate the profiles as created by others, the situation looks a bit different. In general (see image below) Organisation1 usies its own process to define an artefact, and at some point in time sends the arefact to Organisation2 for approval/wider use. Organisation2 will have to determine at what maturity level it's going to accept the proposed artefact, given that e.g. there may be issues around the scope or the overall quality of the proposed material.

In order to ensure participation by representatives of Organisation1 in the curation process one could make it mandatory for those that propose a profile for curation also commit themselves to participate in the curation process. If one proposes a profile for curation, one will have to accept that the scope of the profile may change (mostly: the scope will be widened), so the resulting profile (as accepted by Organisation2) may have to be profiled by Organsisation2 for it to be useful in its own (more narrow) context.

In general, the best practices around the curation of profiles can be summarized as follows:

• Ensure participation of those proposing acceptance of an artifact (“third-party”) in the curation process itself (both governance TAG_BODY actual curation)
• Decide: co-development (get involved early), or curate ‘final version’ created by third-party
• Curated/accepted artifact may differ from the one used by third-party - third-party to use constrained version of accepted artifact

Most large projects (be they coordinated by a vendor-consortium, an HL7 affiliate or a national health IT organisation) will end up having to deal with a mixture of curation and creation.

-Rene

PermaLink to this page: http://www.ringholm.com/column/FHIR_Profile_creation_curation_best_practices.htm

Index of columns:

• HL7 Version 3 Tooling (Nov 16, 2022)
• Bye bye IHE XDS and CDA. (Sep 01, 2021)
• Combining the best of IHE XDS with HL7 FHIR (Jun 27, 2019)
• FHIR DevDays and the year in review (Dec 27, 2018)
• Creation and Curation of FHIR Profiles - process and governance (Dec 14, 2017)
• Impact of the GDPR on the use of interoperability standards (Jun 27, 2017)
• Next XDS Release (Oct 27, 2016)
• Five years of FHIR (Aug 11, 2016)
• Update from the trenches on CDA R2.1/R3 and HL7v2. (Oct 15, 2015)
• Most often implemented IHE Profiles (Jun 08, 2015)
• Mapping HL7v2 messages to FHIR. (Apr 13, 2015)
• Recent and Future developments of the DICOM standard (Mar 06, 2014)
• Documenting the history of HL7 (Sep 03, 2013)
• Interoperability Standards - the no-sales pitch (Jul 09, 2013)
• CDA Implementation Guides - (not) invented here (Apr 17, 2013)
• Usage of IHE Profiles (Feb 25, 2013)
• 10 year anniversary - Dutch Ringholm HL7 v2 training courses. (Feb 19, 2013)
• HL7 Connectathons (Sep 09, 2012)
• Frequency of use of HL7 message types (Jul 24, 2012)
• Reflections on the HL7 membership model - the affiliate life cycle (Dec 28, 2011)
• RFH (Resources for Health): HL7 version 3 taken to the next step (Aug 18, 2011)
• Timezone Hotel (Mar 29, 2011)
• The changing role of HL7 country organizations (Jul 16, 2010)
• How to lower the hurdle for HL7 v3 implementers (Jan 21, 2010)
• The HL7 roadmap for CDA R3 and the CCD (Jan 17, 2009)
• HL7 based Tree inventory system (Jan 30, 2007)
• Workflow Bribery (Sep 15, 2006)

---

About Ringholm bv

Ringholm bv is a group of European experts in the field of messaging standards and systems integration in healthcare IT. We provide the industry's most advanced training courses and consulting on healthcare information exchange standards.