Accessible autocomplete

[devansXD]

What

Automatically suggest something as a user types.

Why

This has tested really well for our service, helps users narrow down results quicker and assists task completion.

eRS plan to use this as part of the redesign, same NDOP.

Anything else

GOV have lots of services using this already and is part of their own backlog:

MOJ: ministryofjustice/moj-design-system-backlog#32
GOV: alphagov/accessible-autocomplete#329
GOV: https://github.com/alphagov/accessible-autocomplete/issues

[davidhunter08]

Hi @devansXD - is this something eRS are now using?

[devansXD]

@davidhunter08 its at POC stage in development now

[danjohnstonUX]

Looking to include this on the SCRa redesign for a number of issues. Are there any screengrabs of this being used in an NHS context?

[devansXD]

@danjohnstonUX our example on eRS

[devansXD]

@davidhunter08 Another example here from the DVSA styleguide: https://dvsa-front-end.herokuapp.com/library/mts/autocomplete

[Tosin-Balogun]

@danjohnstonUX - Did you use this pattern on SCRa? If so, how did it test?

[danjohnstonUX]

Hi @Tosin-Balogun - Yeah, we implemented this feature for a section of SCRa called 'Reasonable Adjustments'. These are used when a patient has a particular requirement that relates to their treatment. This might involve stating a communication requirement the patient has (such as requiring a sign language interpreter), environmental adjustments (such as ensuring the waiting room is quiet and darkened) or simply recording what a patient's impairment is, to aid the healthcare professional involved in their treatment to better understand any necessary adjustments.

We used accessible autocomplete because there are lots of potential adjustments that can be added, but all of which are clinically coded (rather than freetext) and so it was important we help users find the correctly coded adjustment. We provided users with a list of adjustments, but given the large number, it was deemed appropriate to try accessible autocomplete too.

You can see the example of how we implemented autocomplete here: http://scra-redesign.herokuapp.com/ra-flag_v4/ra-step-3. Each adjustment is categorised, so when searching via the autocomplete input field, you will see a category as well as an adjustment.

We didn't test this with a large amount of users, but those we did test with understood the premise well and successfully added a reasonable adjustment for a test patient. We didn't see much evidence of users preferring to scroll through the list of categories - largely, they would rather search for a key word in the autcomplete field to see what was returned. We also didn't manage to test explicilty for accessibility with users with access needs, though the feature did come through an accessibility audit with DAC. I hope this is helpful, but happy to try and help further if you need.

[Tosin-Balogun]

What

We have implemented the accessible autocomplete/auto-suggest within cervical screening to help users easily identify the screening codes they need without having to remember them from memory.

For example, helping users easily find the needed lab result codes if they don't remember what it is or helping them find the required letter codes if they don't know what it is, see video example below

Screen.Recording.2022-02-15.at.10.23.11.mov

Why

The codes used within cervical screening is huge and users often have to remember many of them and their combinations off hand or using a list.

Due to the volume of the codes needed to generate report outputs, we have opted to add the accessible autocomplete to help reduce the cognitive burden on users and help to find what they want quicker.

It also helps reduce the barrier to entry for novice users who might just be picking up the system for the first time

User feedback

We took the design to usability testing with 8 users, some of their responses have been combined.

We observed that users:

• Understood how to use the feature
• Understood they could type in part of the code if they knew which family letter it belonged, so they typed 'P' and expected it to show them options starting with 'P'
• Understood they could search for the name of the screening code rather than the code, for example users typing "HPV primary" rather than the code
• Appreciated the feature

They said

• P1 - "Oh, that's good, I like that"
• P2 - User liked the autocomplete
• P3 - User remarks they like that it suggest letter codes if they did not know it
• P4 - User understood how to use autocomplete

[oughnic]

For very long lists, hooking up to a FHIR Terminology Server will decouple the vocabulary management from the service or application.
The NHS England Terminology Server is a platinum grade FHIR Terminology service. It contains:

• SNOMED CT - current version and current-1 at a minimum
• Human Phenotype Ontology (HPO) (20201207)
• ICD-10 - including historical versions (4.0 and 5.0)
• NICIP codes - including historical versions (2017-2020)
• OPCS-4 - (4.8, 4.9 and 4.10)
• READ codes (4 byte, V2 and CTV3) - including historical versions (2009-2018)
• UCUM (2.1)
• FHIR® - including all published CodeSystems, ValueSets and ConceptMaps
• dm+d - including historical versions, GTINs, ingredient strength and historical codes

[oughnic]

For very long lists, hooking up to a FHIR Terminology Server will decouple the vocabulary management from the service or application. The NHS England Terminology Server is a platinum grade FHIR Terminology service. It contains:

• SNOMED CT - current version and current-1 at a minimum
• Human Phenotype Ontology (HPO) (20201207)
• ICD-10 - including historical versions (4.0 and 5.0)
• NICIP codes - including historical versions (2017-2020)
• OPCS-4 - (4.8, 4.9 and 4.10)
• READ codes (4 byte, V2 and CTV3) - including historical versions (2009-2018)
• UCUM (2.1)
• FHIR® - including all published CodeSystems, ValueSets and ConceptMaps
• dm+d - including historical versions, GTINs, ingredient strength and historical codes

There is a proposed capability for the NHS Organisation Codes Service.