PDS FHIR API now supports AAL2 authenticators in healthcare worker access mode

Personal Demographics Service (PDS)
, ,
1

Hi folks, dropping a line let you know of a change we’ve made to healthcare worker access mode.

In healthcare worker access mode, applications can make more complex searches and update patient records, but only if an end user is present and suitably authenticated with a smartcard or modern alternative.

Previously, this was limited to our strongest authenticators (those at authenticator assurance level AAL3 – ‘very high’).

Now, users can use our full range of authenticators when accessing the API, including those at assurance level AAL2 – ‘high’).

Here’s a full list of authenticators:

  • Smartcards (AAL3)

  • Windows Hello (AAL3)

  • Security keys (AAL3)

  • iPad app (AAL3)

  • Passkeys (AAL2)

  • NHS.net Connect (formerly NHSmail) (AAL2)

  • Microsoft Authenticator (AAL2)

This change is part of our strategy to give health and social care organisations more choice in what authenticators they can use, lowering costs and improving the user experience.

What you need to do

Step 1: Decide if AAL2 is suitable for your application

This depends on the risk profile of your application and also on which other national APIs you need to access.

You should use AAL2 if possible. This will give your users more flexibility and make your application more attractive to your customers.

For more details, see Choosing an assurance level.

If you decide to stay at AAL3, you do not need to take any further action.

Step 2: Change your software

What you need to do depends on which security pattern you use.

Combined authentication and authorisation

If you use combined authentication and authorisation, when you trigger the authorisation journey, you’ll need to specify acr_values=AAL2_OR_AAL3_ANY.

Separate authentication and authorisation

If you use separate authentication and authorisation, when you authenticate the healthcare worker with CIS2 Authentication, and in particular when you make an authentication request, you’ll need to specify acr_values=AAL2_OR_AAL3_ANY.

Step 3: Tell your customers

Your customers will want to know that the change is happening, and when, so they can consider whether to take advantage of using other authenticators.

You might want to include a link to our guide to CIS authenticators in any communications you send to them.

If you have any questions about this change, we’ll be monitoring this thread to answer questions

2

Good morning @Matthew_Beswick
Thanks for the update, a couple of questions:

  1. For the purposes of reviewing the implications of this as part of our wider range of API interactions is there a good source on what level is required for different APIs?

The link you provide for CIS2 authenticators guide links out to the page I’ve attached but it seems incomplete i.e. EPS prescription tracker is on there but not EPS requesting, its not mega clear if PDS is on there, I suspect its listed as Demographic spine service but that isn’t marked as AAL2.

https://digital.nhs.uk/services/care-identity-service/applications-and-services/cis2-authentication/websites-and-apps-you-can-access-with-nhs-cis2-authentication#nhs-services

Obviously we could go through documentation for each API we currently have and all roadmapped ones to determine what levels they need but a high level overview would be useful.

  1. Is there any advice on best practice if we need to potentially support multiple AAL levels?
    i.e. a user is going to do something on PDS (AAL2) then something on EPS (AAL3) in the same session, should there be guidance offered at point of sign in, should we just force re-auth if they try to do EPS and have logged in as AAL2, how should this be conveyed to a clinical user who won’t really understand aal levels?

  2. And is there any advice on the general roadmap here, are we expecting most things to end up on AAL2 over time?

Thanks,
Liam