Patient Core Records API

This guidance is under active development by NHS Digital and content may be added or updated on a regular basis.

Components

The following components have been suggested to achieve the interoperability tbrough the API outlined in the specification.

FHIR

Technical standard – To support the UK approved technical standard of FHIR R4, represented through UK Core.

Data model

A data model helps in standardising the way data is represented and stored. This consistency is crucial for maintaining data integrity and ensuring that data is handled uniformly across the system. An agreed data model is required to allow the relevant data to be exchanged between systems successfully.

Transport mechanism – RESTful

RESTful services use standard protocols such as HTTP, which are supported by a wide range of platforms and technologies. This promotes interoperability and allows different systems to communicate seamlessly. To create a healthcare interop ecosystem that incorporates the RESTful protocol (where appropriate) would make systems more accessible and integrations would be easier.

API platform

To utilise the API Management platform which would offer integrations to central services as well as an authorisation server that would authenticate and authorise the calling application. The platform would also provide the logging and auditing facilities.

Decisions

Record update

All updates to a record would be in the form of a RESTful POST interaction. The Bundle profile would be the used to contain the data and it would need to be ingested by the receiving system.

Message headers

All interactions would be supplemented with custom message headers which would be used to define the content of the payload. This would aid the receiving system to perform the relevant validation and filing protocol.

Acknowledgements

Background There needs to be an agreed method of acknowledging the ingress of a received payload.

The infrastructure acknowledgement is covered by synchronous HTTP response codes but the business acknowledgements are often sent some time after the API call, so an approach is required to cover eventualities like "not my patient".

The acknowledgements framework is undergoing some discussions and any decisions would be updated here.

back to top