DOS onboarding

In order to be reading this welcome pack, you’ll already have registered at least one account with the NHS Developer and Integrations hub, and you’ll have selected the Immunisation FHIR API for onboarding.

The API-M onboarding documentation is excellent and it is strongly recommended you absorb that before continuing.

As well as completing the DOS process for the immunisation FHIR API the following extra steps are suggested:

• start with the immunisation FHIR API sandbox to get a feel for the data structures and how it is returned
• use Postman as a mechanism for testing your data structures are correct. We have a generic Postman collection you can obtain from the OAS
• you’ll then be able to use your own test data to ensure it matches your own requirements
• once you’re fully accepted and comfortable with Postman, you’ll be able to request INT access from our product manager

• what are the purposes and use cases of your product? (Which disease types are involved?)
• demonstrate conformance with version 5.0 of the data model
• amend and Retry details
• generation of error reports from batch submissions are processed
• technical conformance requirements
• uploading of risk log for the Immunisation FHIR API
• compliance with the read endpoint requirements
• demonstrate how the use of vaccination records obtained from the API is tolerant of data population
• declare how the system checks search responses for potential issues
• declare how the system audits interactions
• demonstrate your PDS trace process prior to API interactions
• compliance with the data model and payload content
• compliance with the create endpoint requirements
• compliance with the update endpoint requirements
• compliance with the delete endpoint requirements
• confirm the ID allocated by the API will be the primary ID for all interactions
• declare your role based access controls ensure only appropriate access to vaccination interactions
• via the API endpoints
• declare your controls for onboarding new sites and users
• demonstrate how the system will handle errors gracefully

Aims:

• clearly defined DOS onboarding process for the immunisation FHIR API
• examples of the DOS structure and the context of the questions to be answered

Outcomes:

• articulated onboarding process with links for a consumer to follow for the immunisation FHIR API
• consumer understanding of the DOS onboarding sections with example questions for the immunisation FHIR API

Overview

The Digital Onboarding process consists of the owner of the connecting system providing answers to a set of questions regarding their use of the Immunisation FHIR API. In support of these submissions there is the opportunity to upload relevant files. It is also recommended that a single vaccination event record is taken through as many of the questions in the process as possible including for other endpoints e.g. use the same record for evidence for create, then read, then update and then delete.

Use cases

The Use Cases for which the API is to be used must be approved. Additionally, the disease types for which they apply must be selected for consideration. A completed Hazard Log (excel document) and Clinical Safety Case (word document) for the Immunisation FHIR API must be uploaded.

Demonstrate compliance with the read endpoint requirements

A description of how the system will use the read endpoint is required (i) Does your system automatically synchronise the read record with the local record? (ii) Demonstrate how the system synchronises changes for both a standard record and a sensitive patient record Do you notify users of differences between the read record and the local record? (iii) Demonstrate how the system handles changes in the UI for i) a standard record ii) a sensitive patient record (iv) Demonstrate how you respond to a read error where your record is current but the NHS England held record has been deleted e.g. patient right to be forgotten deletion?

Demonstrate tolerance of the absence of data population

Describe the system’s tolerance for the absence of data items which are required or mandatory to be supplied but are not mandated in the FHIR UK Core profile. This includes (i) the absence of data items which are required or mandatory but are not mandated in the FHIR UK Core profile. (ii) The absence of elements to support sensitive patient records. (iii) FHIR elements included in payloads which are not explicitly stated as must not be populated in the data model valid for FHIR UK Core. (iv) additional FHIR elements according to
FHIR general guidance for example the presence of unspecified extensions.

Declare how the system checks search responses for potential issues

A FHIR search response may ignore unrecognised search parameters and return the response according to known / supported parameters only. A search response may contain an operationOutcome with information about the processing of the response. The system must assess and describe the best implementation approach for its use cases. The system response to the bundle.link element must also be described and any UI implications specified.

Declare how the system audits interactions

Describe how all transactions undertaken using this API are audited. Provide details of (i) what you capture in audit logging (ii) the audit retention policy (iii) how it is ensured that audit logs are tamper proof (iv) how audit logs can be used to support incident investigation.

Technical conformance requirements for providers of vaccination events

The following points need to be addressed (i) Confirm that you will implement controls to ensure that vaccination records are only submitted by CSV or API and that the API will be the only routine method for provision of these records (ii) Describe the process for the transition from batch record submission to the Vaccinations FHIR API and the controls to ensure that a record is sent only by one method and routine use of batch is ceased (iii) Describe your process for enabling an exceptional batch transfer file in a controlled manner when authorised to do so.

Differences for vaccine types between Create, Read, Update, Delete and Search Endpoints

For all endpoints, make it clear if there are any differences in compliance between vaccine types.

Read endpoint

This API handles patient records and it is essential that the patient is correctly identified prior to vaccination event capture or subsequent maintenance of the record and that accurate patient details are supplied via the API. The following must be demonstrated :- (i) Show that you are compliant with the requirements to use the latest NHS Number in all interactions and to protect sensitive data for s-flagged patients so as not to compromise their safety (ii) Does the system ensure a patient trace is performed as required prior to any interactions with the API? (iii) Show that you are compliant with the requirements to use the latest NHS Number in all interactions and to protect sensitive data for s-flagged patients so as not to compromise their safety. (iv) Demonstrate error handling and retry process if an NHS Number changes between trace and API interaction (v) Demonstrate you use the patient’s current NHS Number when PDS notifies you that the patient NHS number has been changed from that in your local record (vi) Demonstrate error handling and retry process if an NHS Number changes between trace and API interaction.

Compliance with the data model and payload content

Confirm you have implemented the required data/FHIR profile specification for the Vaccinations FHIR API and give details of any optional variances e.g. Provide details of any non-compliance with any parts of the FHIR specification e.g. a) Data types b) SNOMED terminology c) Cardinality of the data model d) Length format of values e) Optionality of the data model (ii) It is expected that additional elements will not be populated and a case for their inclusion can be provided if they are integral to their implementation of the API.

Create endpoint

Compliance with the create endpoint requirements

Variants to be described and submitted e.g. (i) with / without NHS Number (ii) Provided per vaccine type Additionally confirm that records are generated with a single unique identifier (value and system combination).

Update endpoint

Compliance with the update endpoint requirements
Provide evidence to demonstrate compliance with the requirements of the UPDATE endpoint

Delete endpoint

Compliance with the update endpoint requirements

Provide evidence to demonstrate compliance with the requirements of the UPDATE endpoint

Confirm the ID allocated by the API will be the primary ID for all interactions

All records will have a unique value assigned by the Immunisation FHIR API. Confirm that the IDs from Immunisation History API will not be used and are either not stored in your system
or there is a mechanism to replace them once in production). The system will need to obtain event IDs (immunization.id) to use for update, delete or read interactions for existing vaccination event records held locally and submitted to NHS England prior to onboarding to this API. Demonstrate how your system will obtain event IDs (immunization.id) to use for update, delete or read interactions for existing vaccination event records held locally and submitted to NHS England prior to onboarding to this API.

Confirm role-based access controls ensure only appropriate access to vaccination interactions via the API
endpoints

It is the responsibility of the connecting application to ensure that the API is used only by end users who have a legitimate role and reason for the transaction (i) Confirm you will implement controls to only update or delete records for which you are a data controller (ii).
Upload evidence of user or role-based access controls.

Declare your controls for onboarding new sites and us

Describe controls to ensure that organisations using your system are only enabled to access the API where they conform to your approved use case and conformance standards, ncluding processes to disable an organisation if they no longer meet the approved use case or conformance standards.

Demonstrate how the system will handle errors

Demonstrate that the system can handle known errors in an appropriate manner to minimise impact of the error wherever possible and support efficient resolution of errors via the information present to the user / logged by the system whilst also handling unknown errors gracefully.