Test pack for connecting systems

Use the vaccinations test pack to check that your system can connect to and work correctly with vaccinations services. The test pack provides test records and scenarios to help you validate common integration patterns before going live.

Overview

This test pack helps users of the Immunisation FHIR API to validate key Search and Read behaviours using a set of pre-created vaccination records. The scenarios below show how you can retrieve the record using the API.

The test pack supports consumers integrating with the Search and Read endpoints during early development and exploration. It is aimed at test engineers, but may also be useful to business analysts, project leads, and developers who want to understand the available test resources or reduce effort by using pre-created test records.

The test pack is not exhaustive and should be treated as read only. Consumers should not update, delete, or add additional records to the test pack patients. The API team may reset or update the records to preserve the supported scenarios.

If you need additional or bespoke test data, use your application to create your own records or use a testing platform such as Postman.

Test record overview

This table shows the vaccination test data, which you can use to check that your system can search for and read vaccination events correctly.

Patient	Data profile	Description	Primary test page
Patient A	Typical dataset	Realistic vaccination records	Baseline search
Patient B	Minimal dataset	Only required elements populated	Sparse data handling
Patient C	Complex dataset	Expanded elements populated	Handling additional content
Patient D	Multiple records	Multiple vaccinations per type	Sorting/filtering
Patient E	No records	Valid NHS number, no events	Empty bundle
Patient F	Deleted record	Deleted vaccination event	Deletion behaviour

Test scenarios for Search and Read event

This section describes the test scenarios you can use to validate Search and Read events using the test pack.

Scenario 1: Basic search by NHS number (typical record)

Purpose

This scenario provides a simple starting point for testing the retrieval of vaccination records using a patient’s NHS number and vaccine type. The records used in this scenario are representative of how immunisation data is typically populated in practice. They are intended to reflect a realistic and commonly expected level of detail. This scenario is designed as an introductory search to help you familiarise yourself with the structure and content of returned vaccination records.

Record used

Use Patient A for this scenario.

This patient has one vaccination record for each supported vaccination type. The vaccination records are maintained so that each recorded administration date falls within the last 18 months, ensuring the data remains current and relevant for testing.

Technical reference

Scenario 1.xlsx

Scenario 2: Basic search by NHS number and vaccine type (minimal data)

Purpose

This scenario is designed to help you understand how a vaccination record may appear when only the minimum required information has been captured. While most vaccination records will contain a fuller set of information, it is important that consuming systems can handle situations where optional data elements are not present. This scenario allows you to review how your system processes and displays records with limited content, and to consider whether any assumptions are being made about data completeness.

Record used

Use Patient B for this scenario.

This patient has one vaccination record for each supported vaccination type. Each record has been intentionally populated with only the minimum supported elements.

Technical reference

Scenario 2.xlsx

Scenario 3: Basic search by NHS number and vaccine type with complex data

Purpose

This scenario is provided to help you test and visualise a vaccination record where a more complex dataset has been captured. FHIR resources have a flexible structure which is not heavily constrained. While providers are typically expected to populate a core set of information, additional valid content may also be included.

This scenario allows you to review how your system processes and displays vaccination records that contain more populated elements than those shown in Scenario 1. The records include additional content across a number of immunisation elements. This is not intended to represent the maximum possible population of the resource but provides a moderate expansion of the typical dataset. This scenario may help you identify any assumptions your system makes about the structure or completeness of returned vaccination records.

Record used

Use Patient C for this test.

This patient has one vaccination record for each supported vaccination type. Each record contains a more complex population of elements than the records used in Scenario 1.

Technical reference

Scenario 3.xlsx

Scenario 4: Search a patient with multiple vaccinations for a vaccine type

Purpose

This scenario is provided to help you review how multiple vaccination records may appear for a single patient. It can assist when testing scenarios where more than one vaccination record exists and may help you consider how records are displayed, sorted, or filtered within your system.

You may also use this scenario when testing requests that retrieve more than one vaccine type or when applying a date filter as part of the request.

Record used

Use Patient D for this test.

This patient has multiple vaccination records for each supported vaccination type. The dates of vaccination vary across the records and are not the same for each vaccine type. Some records occur on the same day to reflect that a small number of duplicate vaccination records may exist in the data store. This allows you to review how your system handles situations where multiple records may be returned for the same patient.

Technical reference

Scenario 4.xlsx

Scenario 5: Search a patient record with no vaccination records

Purpose

This scenario is provided to support testing of how your system handles a response where no vaccination records are returned.

Record used

Use Patient E for this test.

Searching for this patient should return an empty bundle.

Technical reference

Use the following parameters for the Search API:

patient.identifier - https://fhir.nhs.uk/Id/nhs-number|9733541419
immunization.target - respective vaccine type (for example, 3IN1 or HPV)

Scenario 6: An OperationOutcome returned with a bundle

Purpose

This scenario allows you to test how an OperationOutcome can be returned alongside a successful response. This helps you review how your system reads and handles warning information that may be returned together with the response data.

Record used

Recommended: Patient F (although any of the test pack patients could be used).

It can be triggered by including a vaccine type in the request which the calling system has not been authorised to retrieve. If you are configured to retrieve all vaccine types or cannot easily request a vaccine type for which you are not authorised, you may request that an authorisation be temporarily removed in the INT environment and reinstated after testing.

This scenario allows you to review how warning information can be conveyed without preventing a successful response from being returned.

Technical reference

The OperationOutcome returned depends on permissions for the requested vaccine type.

Search API parameters:

patient.identifier - https://fhir.nhs.uk/Id/nhs-number|9001063152

Note: You can pass any valid NHS number in patient.identifier.

immunization.target - vaccine types separated by a comma (,). Include at least 1 vaccine type for which the supplier does not have access.

Example:

Let's say the supplier doesn't have access to RSV and has access to HPV.

patient.identifier - https://fhir.nhs.uk/Id/nhs-number|9001063152
immunization.target - HPV, RSV

The OperationOutcome will look like:

OperationOutcome

{
            "resource": {
                "resourceType": "OperationOutcome",
                "id": "376a5639-213f-4cf4-abf1-e372978ec6ae",
                "meta": {
                    "profile": [
                        "https://simplifier.net/guide/UKCoreDevelopment2/ProfileUKCore-OperationOutcome"
                    ]
                },
                "issue": [
                    {
                        "severity": "warning",
                        "code": "unauthorized",
                        "details": {
                            "coding": [
                                {
                                    "system": "https://fhir.nhs.uk/Codesystem/http-error-codes",
                                    "code": "UNAUTHORIZED"
                                }
                            ]
                        },
                        "diagnostics": "Your search contains details that you are not authorised to request"
                    }
                ]
            }
        }

Scenario 7: Error handling

Purpose

This scenario allows you to review how your system handles error responses returned by the API. Errors may occur where requests contain invalid parameters, missing information, or values that do not meet the expected format.

Record used

Any of the test pack records may be used when testing error handling scenarios.

Scenario 8: Get a specific record

Purpose

Most use of the READ operation is expected to occur as part of CRUD operation sequences rather than as an alternative to searching. Searching is expected to return the information required in most cases. However, retrieving a specific record may be useful when synchronising a local record with the central record before performing an update.

Record used

Any of the vaccination records included in the test pack may be used for this scenario.

The test pack provides the record identifiers which can be used when performing a READ request.

Last edited: 13 April 2026 2:54 pm