FHIR Curation Methodology

Overview of curation process

The FHIR curation guide explains in summary the what, why, how of FHIR curation.

The rest of this document is a more detailed technical explanation of the curation methodology in terms of profiling FHIR resources for the UK.

A new or updated profile is proposed for review/curation by an INTEROPen member.

Profiles are text documents that describe how a FHIR resource is specialised for use in a particular care setting. https://www.hl7.org/fhir/profiling.html

In terms of the CareConnect profiles this context is the exchange of patient data in an UK health and social care context. It is expected that the CareConnect profiles will be further profiled or specialised for use in specific care settings; one such case is the GPConnect program.

Profiles are generally created using Furore Forge tools although this is not strictly necessary. All of the CareConnect profiles created to date are based on DSTU2 resources.

Based on the PRSB FHIR Proof of Concept Evaluation Report and the evolving curation process the profile is reviewed by the curation team (a group of volunteers from the INTEROPen community) on a weekly conference call.


  • Don’t remove or restrict any functionality from base resource unless absolutely necessary
  • As the CareConnect profiles are generic, or parent level, it is expected that the CareConnect profiles would be further profiled for particular use cases and restrictions would be defined in this process an example of this are the GPConnect profiles. https://nhsconnect.github.io/gpconnect/
  • Preferred use of SNOMED CT coding and ensuring adequate system information is included to accurately identify the coding system used for each element.
  • All references are to CareConnect profiles and not to base resources.

Extensions and changes to the profile are scrutinised with the following criteria in mind:

  • Is this the appropriate resource/ profile for the concept? s it already available in a different resource?
  • Is the concept implemented in STU3– if so how? can/should we replicate it?
  • Can systems capture sufficient data to support proposed extension particularly in term of any mandatory data items?
  • Solicit feedback from the wider INTEROPen community.
  • Feedback from the INTEROPen community.

Interested parties (i.e. GP System suppliers) can be invited to discuss feedback on a conference call.

A document outlining the design approach and patterns and change tracking is located here:


Justification for any changes from base resource is recorded in DDM Review Log Google spreadsheets that are available on-line.


Any changes suggested are generally reviewed at a subsequent meeting.

An action log is also maintained and is available here: https://drive.google.com/open?id=1OPDjoqRZXfOwbIYqJb26PFJHyBa3lBZrx0Bt6QpySE0

The differential view provided by some profile viewer tools is generally very helpful with this process.

The PRSB in section 9 of FHIR Proof of Concept Evaluation Report http://interopen.org/content/FHIR%20PoC%20Evaluation%20Report%20FINAL.docx

Suggest a process to for wider collaboration in the assurance process for CareConnect profiles, gathering input from NHS Digital, INTEROPen community, PRSB and HL7 UK.

INTEROPen Vendor Led profiles – not curated by the community

Please see https://docs.google.com/document/d/1nIl4gYHNm3cSz7nnffIQe6yfvf7zOQUTLdg59l4O5iQ

GitHub Processes

CareConnect profiles are managed in the HL7 UK GitHub repository. https://github.com/HL7-UK.

The methodology proposed to manage profiles changes is described here:


GitHub allows managing of branches (i.e. master, develop etc.) and changes within a branch. A gitflow pattern http://nvie.com/posts/a-successful-git-branching-model/ will be used for managing change.

Balloted versions of the profiles will be maintained in the master branch and in-progress versions in the develop and/or feature branches.

GitHub users will be able to clone the repository of Profiles into both their own GitHub account or download them to their own organisations git repositories.

To update a profile a community member would modify the profile in their environment using tools such as Furore Forge and then use git tools to create a Pull Request (PR) to a branch, usually the develop branch.

HL7 UK can accept the Pull Request to update the profile in that branch. A number of Pull Requests could be accumulated into an update to a profile’s version.

A summary of this process here:


Or visually:

Adding or updating the Care Connect Profile Process on GitHub


Copies of versions (most/latest) from both develop and master branches will be made available also in the NHS Digital FHIR server.  https://fhir-test.hl7.org.uk/

The FHIR server provides the tools necessary to view the profiles with differential views whereas on GitHub the profiles will be available in raw text format only but with full version history of each commit.

A proposal for how this could be managed is available here:


Version Management

The version of each profile will be maintained separately.

Within the Master branch, resource versioning follows the Semantic Versioning Specification [http://semver.org/]. Resources carry major version in name (e.g. CareConnect-Patient-2) and major/minor version within the StructureDefinition/Conformance.

A Profile versioning guidance document is being prepared which describes in details the criteria for when a particular changes constitutes a major, minor or patch change.

INTEROPen CareConnect Profile Versioning Guidance


It is expected these guidelines will evolve further based on additional feedback and experience.

FHIR usage tracking

The team tries to track the usage of HL7 FHIR in the UK, currently this limited to NHS Digital.

Implementation Guides, Domain Message Specification and Profile usage are recorded:


A new or updated profile is proposed for review/curation by an INTEROPen member.

Profiles are text documents that describe how a FHIR resource is specialised for use in a particular care setting. https://www.hl7.org/fhir/profiling.html