Discovery

NHS login supports three levels of identity verification. For more information read How NHS login works.  For example, reading generic condition information may only require a P0, whereas viewing a medical record to order a repeat prescription will require a P9.

NHS login can support different types of authentication.  For more information see the EIS (External Interface Specification).

The combination of verification and authentication is referred to as the Vector of Trust.

If you have your own method of verification and authentication, and this is to be used alongside NHS login, you need to make sure this meets the appropriate standard in DAPB3051 Appendix D, p23.

If your own (in-house or other) method gives access to the same data as using NHS login will then you need to have the same Vector of Trust.

Technical teams can find step-by-step information on setting up the connection to NHS login in our NHS login developer documentation.
NHS login offers sandpit and integration test environments. Find out more about the environments and how you can make use of them at our 'Compare NHS login environments' webpage.   

In the Discovery phase, you must develop a proof of concept in the sandpit environment.  The sandpit is a copy of our production code environment. Building a proof of concept in the sandpit will help you learn how to integrate with NHS login, and understand where it will fit within your service. To get set up in the sandpit, complete and submit the Sandpit Environment Request Form. 

Your test data to use in the sandpit  will be sent to you when your test account is set up.

At the end of the discovery phase, you will be demonstrating your proof of concept as a live demo or a video at your Preparation call and then at your Product Demonstration call.

If you have prepared a video or recording, ensure you still have access to your live environment during the call so that you can demonstrate any additional requests.

The live demo or video using an NHS login from your test data set (supplied by NHS login) will need to show:

• an NHS login account holder registers for your product. They do not agree to share their data from NHS login with you. They are re-directed from NHS login back to your product and an appropriate message is shown. See the 'Sharing information with your service' webpage for more details 
• an NHS login account holder registers for your product. They agree to share their data from NHS login with you. They are re-directed from NHS login back to your product as a logged in user
• a user who has already created an account in your product using their NHS login, signs in again using NHS login
• a user who has already created an account in your product using their NHS login, signs in again using NHS login. They then navigate to the NHS login settings page
• where applicable, show an NHS login user at P5 navigating your product as a logged in user. Ensure that data, such as the NHS Number, is not shown to the user
• where applicable, show an NHS login user uplifting their P5 account to a P9 account to access features that require a P9 in your product. For example, book an appointment at P5 and manage that appointment at P9
• where applicable, a demonstration of your native (in-house or other such as Google or Facebook) sign up and sign in flow. Include any use of a biometric facility
• where applicable, show how your product works with a proxy or delegated access user

For more detailed information on the user journey requirements, see User Journeys Required for Assurance. 

The NHS login button

Before you begin the integration process it is essential to understand how the NHS login button fits within your service. 

To help you decide how and where in your user journey to add the  NHS login button and avoid any delays to your integration caused by incorrect use, it is mandatory that you adhere to our button guidelines.

Technical information and support

Technical teams can find step-by-step information in our NHS login developer documentation.

Sign up to use our developer support slack channel.

For any other support, please email [email protected].

Review our forms and documents library to get an understanding of the documents that we will ask you to complete in the Integrate stage. The documents include how you will evidence our assurance and legal requirements.

Partners have, on average, taken 3 to 4 months to go live with NHS login. This does not mean 4 months of continuous effort and some partners have gone live within 6 weeks. 

The expertise you will need to call upon to be successful is:

• Developer
• Testing
• Project management
• Technical Architecture
• Data Security and Information Governance
• Commercial / Legal / Contract advice

We recognise that organisations are often managing multiple projects and other priorities and that you may need time to decide when it is best to begin your integration with NHS login.

If you decide that NHS login may not be for you at this time, contact us at [email protected]. You can re-apply for NHS login at any time.

Complete the 'Prepare for your Product Demonstration Call' and 'Declare Data Security and Information Security' sections in the DOS. Ensure you answer every question and provide the documents requested. It will make sure you have everything in place that you need to begin integration. You must be prepared to talk about all of your answers on the Product Demonstration Call.
If your product has a dependency on the IM1 PFS API (to display data in your user interface from the GP record), and you are working with the IM1 team or a 3rd party supplier to connect to the API (you are not live), do not apply for a Product Demonstration call until your application has been approved by the GP IT suppliers.

Architecture, Data Flow Diagram and User Journey requirements

To successfully complete the product demonstration checklist you will need to provide an architecture diagram, a data flow diagram and user journeys. 

NHS login user journeys

The Data Flow diagram should include:

• the NHS login scopes being requested and the downstream usage of these data items
• your diagram does not need to include a detailed representation of the OIDC flow between your service and NHS login, only a representation of the scopes being received from NHS login
• an end-to-end account of data transferred from the user, through each service or touch point via your product
• the data items being handled during this flow
• all internal or external services that utilise the data items provided (either by the user or NHS login) to offer additional functionality to your service i.e. SMS providers. There is no template provided for this as each organisation integrating with NHS login, will have its own bespoke method of showcasing this activity

The Architecture diagram should include:

• where your users start - for example: NHS App, web portal, mobile app
• how to sign up and how to log in - for example: NHS login, Facebook, Google, Apple/Android
• access points for different cohorts - for example: the public, healthcare staff, support and helpdesk staff, developers
• external dependencies - for example: any external services or APIs such as SMS, IM1, PDS FHIR, Salesforce, other payment solutions
• hosting status and location, including whether the service is hosted on the Cloud or on-premise data centre and the location of where it is hosted - for example: if using the Cloud, AWS EU-West2 (London), or for the data centre, UK or elsewhere.

Please note: NHS login partners that have more than one Client ID will need to provide an architecture diagram for each one. 

If there are any areas you are unsure about, contact us and we can support you to complete the section before submitting it to us. Don't wait until the Product Demonstration Call if you are unsure of anything.

We will contact you to arrange the call. We may decide that you are not ready to integrate with NHS login. In this case, we will tell you what the next steps are.

The next step is to attend the to attend Preparation and Product Demonstration calls and then move to the integrate stage.