|Additional data items
||The PDS FHIR API includes a number of data items that are not available via the PDS SMSP API, namely:
- alternative names - such as temporary, maiden or nicknames
- alternative contact details - such as work phone or textphone
- death notification status - formal or informal
- pharmacy details
|Business effective dates
Some data items in PDS have "business effective dates" which specify the time period to which they apply - which might be past, present or even future. This concept applies to names, addresses, contact details, emergency contact people, related people and registered GP practice.
The PDS SMSP API includes logic to include only the most appropriate data values, based on the current date.
The PDS FHIR API includes all data values, which provides more flexibility but also requires the calling system to decide which value to use.
We are considering adding a feature to the PDS FHIR API that would allow you to receive just the current data. If you think this would be useful, you can upvote the feature on our interactive product backlog.
With the PDS SMSP API, you must specify the patient's gender in a search. This can cause problems because for some people, the gender held in PDS might not match the gender they identify with. These are edge cases but are important because gender can be a sensitive issue for the people in question.
With the PDS FHIR API, you do not have to specify gender in a search.
|Retrieve by NHS number
With the PDS SMSP API, you must include both the NHS number and the date of birth to retrieve a patient's record.
With the PDS FHIR API, you only need to include the NHS number to retrieve a patient's record, not the date of birth. However, we do recommend you verify that you have the correct patient record, for example by checking the date of birth and other basic demographics, or by using the search function and then checking the NHS number.
The PDS SMSP API includes full details of the registered GP practice - name, address etc.
The PDS FHIR API provides the ODS code for the registered GP practice. If you need the full details, you must get them from the Organisation Data Service (ODS), for example using the ODS FHIR API.
This is a deliberate design decision - our newer APIs are, in some cases, more granular.
||The PDS FHIR API is available on the internet and HSCN. The PDS SMSP is only available on HSCN.
The PDS SMSP API uses TLS MA to authenticate the calling application. You must renew your TLS MA certificate on an ongoing basis which involves a handshake with us.
The PDS FHIR API uses OAuth 2.0 with signed JWTs to authenticate the calling application. You should rotate your JWTs on an ongoing basis but you can do this without our involvement.
The PDS SMSP API uses SOAP and XML, and the payload conforms to HL7 V3, with an NHS Digital ITK wrapper.
The PDS FHIR API is RESTful and conforms to FHIR R4. To call it you make a simple HTTP request to a named endpoint, and the requests and responses are in JSON format. FHIR libraries are available to make it easier to generate requests and parse responses.
|Verify NHS number / cross-check trace
The PDS SMSP API provides a specific function to verify an NHS number, sometimes referred to as a "cross-check trace".
The PDS FHIR API supports this indirectly via search - you search for a patient and then check the NHS number found against your records.
The PDS FHIR API has two test environments:
- a sandbox for early developer testing, which provides canned responses to a limited number of scenarios
- an integration testing environment for formal integration testing, which is pre-loaded with 100+ test patients to cover a wide variety of scenarios
Both environments are self-service - although in the short term, setting up your signed JWT key for integration testing needs our input.
We have tried to make onboarding to the PDS FHIR API as quick and easy as possible. In particular:
- the PDS FHIR API uses our new Digital Onboarding Service, which makes onboarding quicker and more transparent
- the governance and assurance requirements are virtually identical to the PDS SMSP API, and are all self-certified
- if you're migrating from the PDS SMSP API, you won't have to re-submit a PDS Access Request
- we have a dedicated onboarding lead to assist developers who are migrating from the PDS SMSP API