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

3

Hi Liam,

Sorry for the delayed response, your post has only just been brought to my attention.

  1. Currently, the only way to find out which APIs use which AAL is to look at the individual API specs. If you use the link https://digital.nhs.uk/developer/api-catalogue/Taxonomies/cis2-authentication you can at least filter the API catalogue down to just show the APIs that use CIS for authentication. There are a couple of APIs where the AAL isn’t documented. Off the top of my head: PDS FHIR, SCR FHIR and e-RS FHIR and AAL2 and everything else is (currently) AAL3.

  2. We have some guidance on what we call ‘step-up authentication’ at https://digital.nhs.uk/services/care-identity-service/applications-and-services/cis2-authentication/integrate/design-and-build/authenticator-guidance-for-developers#choosing-an-assurance-level

  3. Our plan is to make APIs available with AAL2 where appropriate. But it’s not always appropriate, for example EPS prescribing has been confirmed as requiring AAL3 in order to meet the relevant legal regulations. And we’re unlikely to alter the AAL for any of the legacy (HL7 V3) APIs - unless we get specific requests for it.

4

Correction on (3) - we’re planning to treat HL7 V3 APIs on a case-by-case basis depending on how long they are around for.

5

Good morning Tony,
Thanks the reply, that all makes sense. If we wanted to start supporting step up authentication I assume we’d need to engage with the Care Identity team and do some re-accreditation/compliance checks? I don’t think we’re going to be changing this soon but just want awareness of process in case trusts ask about it.
Thanks,

Liam

6

I’m not sure that stepping up from AAL2 to AAL3 would require any particular compliance checks (it’s just another flavour of the same process), but the CIS2 onboarding team will be able to confirm that.

7

Drop england.nhscareidentityauthentication@nhs.net a line about this. They may wish to see your new workflow/journey evidence, so a chat before you do it is the best way to approach it.