e-RS Common Assurance Process (CAP)

Your organisation must have a contract agreed by one or more NHS Commissioners to provide services to the NHS.

To get access to the NHS e-Referral Service, your organisation must have an Organisation Data Service (ODS) code.

ODS holds details of all healthcare organisations, including developers. Each organisation in ODS has a unique ODS code - sometimes referred to as an Application Service Provider (ASP) code

During the onboarding process, the ODS code you provide represents you as either:

• a developer onboarding a commercial product

• an end user organisation (EUO) developing a product in-house

If you're not sure what your ODS code is, you can:

• search for an existing ODS code by organisation name or geographic location

• get a new ODS code by applying for one

To get access to the NHS e-Referral Service, your organisation must have a Health and Social Care Network (HSCN) connection.

To get an HSCN connection:

• make sure you have an ODS code

• see Connecting to HSCN

To get access to the NHS e-Referral Service, your organisation must complete the necessary Data Security and Protection Toolkit (DSPT). 

As a software developer, you might come into contact with patient data, for example, when supporting your end users.

To ensure you have controls in place to keep patient data private and secure, you must complete the DSPT.

When completing the DSPT, you need to state your organisation profile. Use:

• ‘NHS Business Partner’ - if your system directly processes patient data on a regular basis, for example, a GP system

• ‘Company’ - if your software only has technical access to patient data, for example, a middleware system

To complete the DSPT:

• make sure you have an ODS code 

• see Data and Security Protection Toolkit (DSPT)

To get access to the NHS e-Referral Service, your organisation must have a valid use case.

You must discuss your use case with us on an engagement call.

As well as confirming your use case is appropriate for the e-Referral Service HL7 V3 API, we will walk you through the assurance process outlined below.

Contact [email protected] to arrange your engagement call.

We hold an engagement call with you to confirm that:

• you can meet the preliminary requirements

• you have a suitable use case

Then we assign someone to your onboarding process.

After we assign someone to your onboarding process, you can submit your scope documents for review. These are:

• Release scope definition (RSD) - download an RSD template

• Clinical safety case, including Hazard log - download clinical safety case report and clinical safety hazard log templates

As a developer of healthcare software, your clinical risk management process must conform to the DCB0129 standard.

As a health and care organisation using healthcare software, your clinical risk management process must conform to the DCB0160 standard.

If your software is classed as a medical device, you need to comply with the relevant legal requirements. For more details see Medical devices: software applications (apps)

To proceed to stage 3, you must submit an initial 'Clinical safely case report' covering these headings:

• Introduction

• System Definition / Overview

• Clinical Risk Management System

• Clinical Risk Analysis

as well as an initial Clinical Safety Hazard log.

Note: You might have existing documentation that covers these areas. If so, you can submit that to us and we will review it.

The Release Scope Definition and Clinical Safety Case might need to be refined through a review process with us.

Once we sign off the Release Scope Definition and Clinical Safety Case (including Hazard Log), we issue a ‘Scope Authority to Proceed (ATP)’ to stage 3.

Note: At this point, request access to the Integration environment ahead of testing in Stage 4. You can find guidance on how to do this at Path to Live environments.

Following the issue of the Scope Authority to Proceed (ATP), you need to complete further documentation as described in the following guidance documents:

• Detailed Design, as defined in Release Scope Definition (RSD)

• e-Referral Service Requirements Traceability Matrix (RTM)

• PDS RTM

• IG RTM

• Updated Clinical Safety Case, including Updated Hazard Log

You must update the RTMs either with comments where appropriate, or with reference to the Detailed Design.

The RTMs should record what elements of the requirements are in scope for the solution and how you will meet the requirements.

You might need to update your documentation after a review with us.

Once we sign off your documentation, we issue you with a 'Design and System Test ATP' to stage 4.

Following the issue of the Design and System Test Authority to Proceed (ATP) to step 4, you need to provide further documentation:

• Integration Test Specification / Scripts and Updated Requirements Traceability Matrices (RTMs)

• Integration Test Report (including Validated Messages)

• Ready for Operations (RFO) / Volume & Performance (V&P) Test Plan and Specification

• RFO / V&P Test Report

• Penetration Test Report - penetration testing must be conducted to CHECK standards, annually and before any significant changes

• Updated Clinical Safety Case Report and Hazard Log

Subject to the requirements of the onboarding engagement, we might also conduct witness functional and non-functional testing and produce the following documentation:

• Functional Witness Test Report

• Non-Functional Witness Test Report

You must present the updated Clinical Safety case at Clinical Safety Group (CSG). Once approved, we issue a 'Clinical Authority to Release (CATR)'.

Once we sign off your other documentation, we issue a 'First of Type (FOT) Development Milestone Achievement Certificate (DevMAC)'. This is your authorisation from us to proceed with a deployment to your First of Type, or trial, sites.

In this stage, we look for successful deployments and that you resolved any issues before further rollout.

You must document a Site Readiness Checklist and ensure that the Entry Criteria are complete, prior to deployment to a First of Type (FOT) site or sites.

14 days after Business Go Live (BGL) your Deployment Verification Period (DVP) starts.

You must review any deployment issues that arise and address them.

If necessary, you must update your Clinical Safety case and Hazard Log.

Following a successful FOT deployment period, you must present the Clinical Safety case at Clinical Safety Group (CSG) a second time. When it’s approved, we issue a 'Clinical Authority to Release Full Roll-Out Approval (FRA CATR)' .

Once you have addressed all the issues, we arrange a Deployment Verification Closedown Call.

We review the outcome of your FOT deployment period with you and once we are satisfied that you have addressed all the issues , we issue a ‘Full Roll-Out Approval (FRA) Development Milestone Achievement Certificate (DevMAC)’

At this point we grant Full Roll-Out Authority to you.