Building a patient portal for secondary care bookings

When integrating a secondary care booking system with our Patient Care Aggregator, it is essential to develop and sustain an NHS-themed patient portal where Patients can view, cancel and reschedule an appointment.

This patient portal can be accessed through the native NHS mobile App or a web browser. As the NHS takes a mobile-first approach, the content should adapt to different screen sizes used by patients. This adaptability can be easily achieved by using default styles within the NHS Design System.

It is crucial to adhere to the System Requirement Specification (SRS) provided by the Partner Gateway Team. The following information within this guide serves as supplementary guidance to assist with delivery.
 

Because your patient portal will be 'deep linked' from the NHS App, you'll to follow all the rules for integrating with the NHS App.

For more details, contact us.

Your patient portal must use NHS login to authenticate the patient.

To do this, you’ll need to onboard your product with NHS login. 

NHS login uses the Open ID Connect (OIDC) standard for authentication - once the user has signed in, their browser will include an NHS login token as a header with each request to your portal.

You must authenticate the patient to level P9.

For details, see Integrating with NHS login and, specifically, Single Sign On (SSO).

Your 'view appointment details' page must have a context-sensitive URL that can be provided as a 'deep link' URL to the NHS App to navigate the patient directly to the details for a specific appointment.

The URL will need to include some way of identifying a specific appointment, for example as a RESTful endpoint: 

https://my-booking-system.com/patient-portal/appointment/12345678

You SHOULD include the resource name appointment, document, or questionnaire in the relative path. The resource name SHOULD be in singular form and case sensitive - see appointment in the example above.

You MUST request that your domain name, for example my-booking-system.com, is added to the NHS App’s allow-list. As the allow-list entries are wildcarded, the security controls around preventing users from being able to navigate to other resources within your domain (for example, by guessing or rewriting the URL) are your responsibility and within the risk tolerance level approved by your organisation’s risk owner.

You'll need to pass this ‘deep link URL’ to the Patient Care Aggregator from your Get Appointments API.

See Authentication using NHS login for details of additional headers that are included with all URLs.

Because your patient portal will be 'deep linked' from the NHS App, and therefore forms part of a public service, it's important that your patient portal follows our look and feel guidelines.

Your patient portal pages must be laid out as per our Phase 1 Figma prototype.

The prototype uses the NHS App Design System and aligns with Government Digital Service (GDS) standards. The NHS Design System provides the necessary styling and components to reproduce the designs from the Figmas. The design system handles scaling from mobile to desktop screen sizes and is designed with consideration of the latest Web Content Accessibility Guidelines (WCAG).

Figma prototypes demonstrating user journeys, tested with patients to optimise user experience, are available. These prototypes should be replicated to include content, styling, and navigation.

There are 2 primary user journeys to implement:

• Cancellation of an appointment
• Rescheduling of an appointment

Each journey offers both synchronous and asynchronous paths, depending on the Patient Appointment System (PAS) capabilities of the relevant trust.

The ability for a patient to 'view an appointment' serves as the foundation for both journeys. Additional screens address common errors and fulfil further requirements related to the NHS App and NHS login.
 

Your patient portal must be able to display the details of a specific appointment. The example appointment card in the Figma prototype is GDS compliant and so grammar should be replicated. It should also be noted that:

• The time of an appointment must be converted from Universal Time Coordinated (UTC) to Daylight Savings Time (DST) or British Summer Time (BST)
• When showing the status of an appointment, you should first check the ‘request status’ of the appointment, and show either ‘Pending Cancellation’ or ‘Pending Reschedule’ otherwise show the ‘status’.

Your patient portal must allow the patient to submit a request to cancel an appointment. The user journey is detailed in Figma journey A1 / S1.

If you do not support synchronous cancellation you should use the ‘Request Status’ FHIR extension to an appointment to acknowledge that a request is ‘Pending Cancellation’ but the ‘Status’ of the appointment should not be changed until the request is fulfilled. You should work with the trust to ensure that these requests will be actioned accordingly by the trust.
 

Your patient portal must allow the patient to submit a request to reschedule an existing appointment. The user journey is detailed in Figma journey A2 / S2.

If synchronous rescheduling cannot be supported you should use the ‘Request Status’ FHIR extension to an appointment to acknowledge that a request is ‘Pending Reschedule’ but the ‘Status’ of the appointment should not be changed until the request is fulfilled. You should work with the trust to ensure that these requests will be actioned accordingly by the trust.

You most operate your patient portal at the equivalent of our silver service level or higher.

You must be able to provide reporting. You can choose to do this via one of two available methods:

Method 1 - monthly reporting via manual submission

Reporting via this method provides us with anonymised data that allows us to understand and measure the performance of your integrated patient portal, enabling us to identify opportunities for product and service improvements, and track the benefits being realised.

Reporting submissions via this route are at an aggregated data level into a .csv which is provided on a monthly basis. There may be some room for interpretation in the data requiring ad hoc dialogue with our management information team.

This is a PDF file for monthly reporting. For other formats, contact us.

Method 2 - API integration (preferred)

In this method, reporting data is sent to the Wayfinder Reporting Service API, which can be near real time or batched into intervals. Reporting via this method provides anonymised data at a granular level allowing us to identify and report on feature usage across the product, behavioural patterns and outcomes.

This method expands to events and outcomes providing further opportunity for continuous improvement and for us to continually monitor for iterative improvements. This method provides an open ended data set that allows for analysis of future patterns and requirements as they are surfaced.

More about API integration.