We have detected that you are using Internet Explorer to visit this website. Internet Explorer is now being phased out by Microsoft. As a result, NHS Digital no longer supports any version of Internet Explorer for our web-based products, as it involves considerable extra effort and expense, which cannot be justified from public funds. Some features on this site will not work. You should use a modern browser such as Edge, Chrome, Firefox, or Safari. If you have difficulty installing or accessing a different browser, contact your IT support team.
Onboarding process for APIs
Find out how to onboard for an API before your software goes live.
Overview
For most of our APIs you need to get your software approved by us before it can go live. We call this onboarding. The onboarding process can sometimes be quite long, so it’s worth planning well ahead.
We have two onboarding processes:
- the Supplier Conformance Assessment List (SCAL) process, which applies to many of our more recent APIs
- the Common Assurance Process, which applies to some of our older APIs
To find out about onboarding for a particular API, read its API specification in our API catalogue.
Onboard using the Supplier Conformance Assessment List (SCAL) process
For many of our more recent APIs, we use the Supplier Conformance Assessment List (SCAL) process for onboarding.
The SCAL process is intended to be quicker and easier than its predecessor, the Common Assurance Process (CAP).
To onboard using the SCAL process:
1. Confirm your use case
For some of our APIs, you must confirm you have a valid use case. You’ll need to give us details of your product and what it does.
For more details on how to confirm your use case for a particular API, read its API specification in our API catalogue.
2. Get the SCAL template
The SCAL is a document you use to tell us about your product and organisation, and to make various declarations about them.
When you sign the Connection Agreement (see step 12 below), the SCAL becomes part of your legally binding agreement with NHS Digital.
You must also pass the SCAL on to each of the end user organisations that use your product to assist them in evaluating your product.
Note that:
- if your product uses several NHS Digital APIs or services, you’ll have a single SCAL that covers them all
- if you have more than one product, you need a separate SCAL for each product
The SCAL is a spreadsheet with several tabs:
- ‘Guidance & Process’ - explains how the SCAL works
- ‘Supplier & Product information’ - general information and declarations about your product and organisation
- ‘Architecture’ - details about your product’s architecture, so they can be reviewed by end user organisations
- one or more tabs for each API or service that your product uses
You can download a template of the SCAL document to familiarise yourself with the document but you cannot use this version to start onboarding.
To get an appropriate SCAL template for your product, contact us and tell us:
- your developer organisation name
- your application name
- which APIs or services you want to onboard for
- any API-specific information requested in the relevant API specifications
We will either create a new SCAL template for you or find your existing SCAL and add new tabs for the APIs or services you want to onboard for.
3. Provide your ODS code
The Organisation Data Service (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 a developer onboarding a commercial product or as an end user organisation (EUO) developing a product in-house.
You must provide your ODS code in the ‘Supplier & Product information’ details in the SCAL document and you will need it to complete other steps in the onboarding process.
If you're not sure about your ODS code, you can:
- search for an existing ODS code by organisation name or geographic location
- get a new ODS code by applying for one
4. Get a Health and Social Care Network (HSCN) connection
Some of our APIs can only be accessed over the Health and Social Care Network (HSCN), not the internet.
Some of our APIs can be accessed on the internet but require HSCN for NHS smartcard access.
In these cases, you'll need an HSCN connection for:
- integration testing
- production use - if you are also an end user organisation
For more details on whether a particular API requires an HSCN connection, read its API specification in our API catalogue.
To get an HSCN connection:
- make sure you have an ODS code (see step 3)
- then see Connecting to HSCN
5. Complete the 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 Data and Security Protection Toolkit (DSPT).
When you complete the DSPT, you’ll need to state your organisation profile. You should 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 step 3)
- then see Data and Security Protection Toolkit (DSPT)
6. Implement a Clinical Risk Management Process
As a developer of healthcare software, you must ensure you implement a clinical risk management process that conforms to the DCB0129 standard.
For some of our APIs we provide you with a hazard log which you must review and integrate into your own risk log.
For details on how to do this for a particular API, read its API specification in our API catalogue.
7. Check your Medical Device status
You need to check whether your product is considered to be a medical device.
If it is, you need to ensure you comply with the relevant legal requirements.
For more details see Medical devices: software applications (apps).
8. Complete technical conformance testing
For some of our APIs, you need to complete technical conformance testing to demonstrate appropriate use of the API. We sometimes call this solution assurance.
In some cases we use a risk-based approach to solution assurance.
Upon completion, we will generally issue you with a technical conformance certificate.
For details on how to do this for a particular API, read its API specification in our API catalogue.
9. Conduct penetration testing
For most of our APIs, you need to conduct penetration testing before you can go live.
For details on how to do this for a particular API, read its API specification in our API catalogue.
10. Register for service and incident management
In order to receive service updates and raise live incidents, you need to register with our service desk.
You need to do this separately for each API you use.
To register for incident management:
- make sure you have an ODS code (see step 3)
- complete the Service Desk Registration Form - you’ll find this embedded within the SCAL, on the ‘Supplier and Product information’ tab
11. Complete and submit the SCAL
Once you have completed the preceding steps, you need to complete the various declarations in the SCAL.
Send the completed SCAL to us at the appropriate email address. For details on how to do this for a particular API, read its API specification in our API catalogue.
We’ll review your SCAL and send it back for rework if necessary.
Once we’re happy with your SCAL we will keep a copy of it for our records.
12. Sign the Connection Agreement
13. Issue the End User Organisation Acceptable Use Policy
Appendix 1A of the Connection Agreement is the End User Organisation Acceptable Use Policy.
You must issue it to each end user organisation that will use your product. It sets out their obligations in using your product.
If you are an end user organisation developing software for your own use, this policy applies to your own organisation.
14. Get production access
You need to request production access for each end user organisation that uses your product.
For details on how to do this for a particular API, read its API specification in our API catalogue.
Onboard using the Common Assurance Process
For some of our older APIs (including our HL7 V3 APIs), we use the Common Assurance Process (CAP) for onboarding.
The CAP differs for each service. For example, the PDS CAP differs from the EPS CAP.
To find out about onboarding for a particular API, read its API specification in our API catalogue.