Care Connect (8)

GPConnect profiles and key national profiles should all be reviewed by the INTEROPen community, as it is essential for vendors who are implementing them on a national scale to influence the design and ensure there is consistency. However, because the Level 2 CareConnect profiles and CareConnect APIs have a basic set of constraints and operations to support UK interoperability, we hope that they can be taken and used by many local areas, vendors and innovative projects to develop new models of care in a way that doesn’t hold back innovation. We expect these projects will share their learning and specifications, and as they develop and scale, we envisage certain rules and patterns and other profiles emerging that may need to be plugged into a curation process so that other regions can pick them up with a degree of confidence that their design has been technically and clinically validated. Some regions may specifically come to INTEROPen for curation first, as they wish to gain further guidance. We will need to support both approaches.

The use of the CareConnect standards we are working with should be covered by existing contracts that Suppliers are working within, together with their customers. Suppliers should, however, be reviewing these and if they believe they are subject to a CCN, should discuss that with their customers. Their customers may then want to discuss this with NHS England, as the current work being done is to satisfy the NHS Contract.

The GP Connect API is the nationally supported mechanism to access GP information. CareConnect APIs are the nationally supported mechanism to develop interoperable exchange interfaces for other use cases; GDEs and LHCREs will implement these as OPEN APIs. The intention is for vendors to align their interoperability interfaces to these specifications so that we can move away from proprietary standards to open ones. All www.INTEROPen.org vendors have signed up to this principle.

The GP Connect API will allow vendors to query GP systems for patients’ summary GP information, as defined by the API. There are different phases to the API implementation; the first includes access to the summary information where the content is uncoded, i.e. HTML only. Another phase will return structured and coded information in FHIR, including content such as medications and allergies. Under GPSoC contractual agreements, GP suppliers must support the GP Connect API, providing a mechanism for relevant third-party systems to access patients’ GP information where needed.

The FHIR profiles used in GP Connect are derived from, or ‘Children’ of, the National CareConnect FHIR profiles, and therefore consistent with them clinically and technically. ‘Child’ profiles are referred to as Level 3 CareConnect profiles or Use Case specific profiles. The National CareConnect profiles are Level 2, or ‘Parent’ profiles. Guide to Level 2 and Level 3 profiles: https://drive.google.com/file/d/1k4ITq_Qdzw-jak_x4RCiGDZ57ZgRxUIG/view

These Level 2 and Level 3 CareConnect profiles have all been ‘curated’ by INTEROPen to be UK-specific localisations of the International STU3 core resources. It is accepted that there may be different versions of the CareConnect profiles (and therefore GPConnect ones) over time to accommodate changes, amendments, new requirements. Guide to curation: https://docs.google.com/document/d/1IbSdRTdWg-ZsbYmkkYZSGV1PVtxNmf7jkx7LneXYa0w/edit?usp=sharing

A basic set of CareConnect APIs also now exists, including a reference implementation: https://nhsconnect.github.io/CareConnectAPI/. These CareConnect APIs use the Level 2 FHIR CareConnect profiles. NHS England and NHS Digital are requiring GDEs and LHCREs to support these for their interoperability needs. INTEROPen plans to work with GDEs and LHCREs to help refine and develop these CareConnect APIs as the exchange use cases become developed.

It should be noted that, at present, the functional scope of GP Connect & CareConnect are not the same. GP Connect includes APIs for Appointment Booking and updating records, which Care Connect does not.

The two target dates are different but we are looking at Trusts to at least have plans in place to implement FHIR based Transfer of Care messages and Open (CareConnect) APIs.

FHIR is an HL7 standard and this initiative appears to have strong industry backing. Indeed, industry was the initial instigators of the decision to move to FHIR.

Priority profiles are already under discussion by various groups within INTEROPen/NHS England/NHS Digital/ PRSB/TechUK and the CCIO/CIO Networks. INTEROPen is acting as a community where these priorities can be defined together.

The FHIR profiles created by INTEROPen members reflect UK standards. However, it is important to understand the curation process used is there to only extend the profiles where necessary to fit local requirements. The curation process takes the FHIR STU3 resource definitions from HL7 International and reviews them to understand where they need to be changed to reflect NHS requirements in England.

This curation process includes not only the NHS but suppliers too, and it is in suppliers’ interests to keep them as close to the international version as possible.

To comply with the requirements of the NHS Standard Contract for ToC, organisations need to ensure they are sending messages:

  • Electronically (no paper or fax) – 2015 NHS Standard Contract
  • Using PRSB standards (AoMRC headings)

Have the capability to send messages:

  • Based on FHIR technology (structured message)
  • Containing coded content when capability available (SNOMED / dm&d)

Useful Links:

PRSB (Professional Records Standards Body):


FHIR messaging:


Load More