FHIR® APIs

Owned by Andrew Turner (Unlicensed)
Last updated: Mar 14, 2023 by Tom Pick (Unlicensed)
3 min read

Upcoming changes

Access to FHIR 4 endpoints will be controlled by OAuth 2.0, and compatible with NHS Login SSO.

Overview

This page outlines the current capabilities deployed to production; please see our FHIR API Roadmap to learn more about upcoming changes.

Customers have access to a full read/write, R4 FHIR endpoint. You can read the R4 FHIR specification here: https://www.hl7.org/fhir/R4

PKB maintains four different types of FHIR API endpoint. Each endpoint is associated with a corresponding pot of data.

This page provides a brief overview of each endpoint type; please see the linked subpages for more information.

Aggregated read-only FHIR endpoint

This is a read-only, R4 FHIR API which aggregates data from all input routes, both FHIR and non-FHIR. The aggregation will perform STU3->R4 mappings as required. Complex access control applies since this contains data from multiple sources.

The data types available from this endpoint will be iteratively expanded over time, starting with Appointments. Please see the roadmap section for details of when other data types will be supported.

Although a Customer can read all data they send to their own Customer FHIR endpoint, such data must always go through the Aggregated FHIR endpoint in order to be made available to other users. Once support for a data type has been added to the aggregator, other system components (e.g. the web interface, Custom REST API, Facade FHIR endpoint) will be upgraded to read from the Aggregated FHIR endpoint, so that these will return data added to a Customer FHIR endpoint, ensuring that these data are available to users who will not be querying the Aggregated FHIR endpoint directly.

See here for more information.

Customer read-write FHIR endpoints

Each customer is allocated 1 dedicated instance for each of their inbound FHIR feeds to PKB. Full read/write support for all REST interactions, for all resource types, available in customer's choice of STU3 or R4. Read/write access to each endpoint is restricted to the customer who owns it.

Although a Customer can read all data they send to their own Customer FHIR endpoint, such data must always go through the Aggregated FHIR endpoint in order to be made available to other users. Once support for a data type has been added to the aggregator, other system components (e.g. the web interface, Custom REST API, Facade FHIR endpoint) will be upgraded to read from the Aggregated FHIR endpoint, so that these will return data added to a Customer FHIR endpoint, ensuring that these data are available to users who will not be querying the Aggregated FHIR endpoint directly.

See here for more information.

Hybrid mail, questionnaires and timeline Facade FHIR endpoint (deprecating)

PKB maintains a Facade FHIR endpoint which provides read-only* access to a) FHIR representations of non-FHIR data in PKB medical records (for data types not yet supported by the Aggregated FHIR endpoint) and b) the aggregation of both FHIR and non-FHIR data (for data types supported by the Aggregated FHIR endpoint). Only a subset of resource types and elements are supported. Complex access control applies since this contains data from multiple sources.

Over time, external API access to this endpoint will be removed as the Aggregated FHIR endpoint will provide richer functionality.

* the standard REST interactions are read-only, but some operations will generate new data as part of their functionality

See here for more information.

Demographics write-only FHIR endpoint (deprecating)

PKB exposes a dedicated endpoint to handle uploads to a custom $process-message operation.

See here for more information.