Onboarding process for APIs

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.

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, such as the relevant access mode for your application

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.

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 using the ODS portal
• get a new ODS code by applying for one - you can do this at any time, not only during onboarding

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:

1. make sure you have an ODS code (see step 3)
2. then see Connecting to HSCN

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:

1. make sure you have an ODS code (see step 3)
2. then see Data and Security Protection Toolkit (DSPT)

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.

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).

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.

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.

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:

1. make sure you have an ODS code (see step 3)
2. complete the Service Desk Registration Form - you’ll find this embedded within the SCAL, on the ‘Supplier and Product information’ tab
3. email it to the NHS Digital National Service Desk

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.

Once we’re happy with your SCAL, we will send you a copy of the Connection Agreement to sign. This is a legal document that sets out your obligations.

If you have previously signed a Connection Agreement, we will re-issue the existing document. In some cases you might need to re-sign it.

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.

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.