Digital submissions alpha assessment
The report from the alpha assessment for NHS BSA's digital submissions service on 24 March 2017.
| From: | Central Digital and Data Office |
| Assessment date: | Friday 24 March 2017 |
| Stage: | Alpha |
| Result: | Met |
| Service provider: | NHS Business Services Authority |
The service met the Standard because:
- The service has a dedicated cross-functional team with a deep understanding of user needs
- Plans and resources are in place to build the service in beta and continue with user research
- The team has thought about how to operate the service and provide support to users
About the service
Description
The service enables pharmacists, dispensing GPs and appliance contractors to submit their monthly prescription totals and activity claims to the NHS BSA via a secure digital channel.
Service users
Anyone who is dispensing prescriptions and needs to be reimbursed for it by the NHS.
Detail
User needs
The team fully understood who their users are and used this knowledge to target different user types and produce personas to help plan the interactions for their service, and their research plan.
The team had a good understanding of the user needs of their service users, They had conducted contextual user research with a number of different users to understand the existing process and had carried out several rounds of usability testing with pharmacists in their premises to gain an insight of what the user experience might be.
The research uncovered some clear user needs that were incorporated into the design, for example, users needed:
- the ability to print a postal label so they could send to the correct place and (possible have a record for themselves and include details in the box with the clerical prescription slips)
- to be able to view information about how their submissions are progressing at present they don’t always know what to do
- information on why items are disallowed so they could rectify for future cases with their GPs.
- be able to see all the information they have supplied to NHS business services in one place to avoid complication and save time.
The private beta MVP will test whether these needs are met. So far the user research has not come across any specific accessibility needs but the team will need to plan to design for these in beta and test where possible.
The user groups generally have a high level of digital skills and can access the service, where a small number of users will not it is for specific reasons that cannot be addressed by the service, these users have an alternative.
Team
The service team had a few key challenges at the start of the work:
- To convince the organisation of the merits of working in an agile way
- To convince the organisation about the need to transform the service rather than merely digitising a paper form
- To break down internal organisational silos and present services offered by different organisational units as a seamless, unified service
The panel was pleased to hear that the team successfully achieved these goals by using evidence (user quotes, data), involving stakeholders in research, and creating a compelling vision for the service.
The service benefits from having a dedicated team of permanent staff and guaranteed access to researchers and designers. The team follows the agile best practices of working iteratively, and ‘showing the thing’ through showcases, open days, and webinars.
The team is co-located and is also close to those members of staff who operate the current, non-digital process. This allows the team to gain valuable insight from them about users and processes and also reassures them that transforming the service will not eliminate their jobs.
The team is currently led by a service manager who also acts as product manager. This proved efficient in the alpha phase, but the panel recommends that the team put thought into separating these roles before the service goes live as a live service requires much more operational attention from a service manager and it will likely become hard for her to be effective in both roles.
Technology
The team described their technology choices in depth and provided the reasonings behind them. They were able to sufficiently describe the technical scope of what they plan to build in beta and were able to highlight where their new service will integrate with legacy systems. They were able to provide details of their approach to limiting the impact of integrating with these legacy services and how they are migrating towards modern cloud based tools and platforms.
The team were able to describe how they will build a reliable development and release pipeline for beta. They also provided an outline of their open source policy and intent to open source their code.
The authentication mechanism chosen for the service, though quite unique, is a good choice given their users and service design.
Through user research the team were to identify and mitigate the size of personally identifiable information that they needed to present to their users. It is recommended that the team try to identify how they might obscure this data further.
The team outlined several fraud vectors against the existing form and how the new service is able to mitigate these.
Design
The Digital Submissions team have created a simple, modern, well-designed alpha that adheres to most NHS Digital and relevant GDS design patterns. They demonstrated a user-centred process with design and research fully embedded in the process, and have iterated significant parts of the design based on things they’ve discovered in user research. They showed a great dynamic, and active engagement with the service and its users.
For beta, the I would like to see the team work more on the full end-to-end journey. The service depends on the full adoption of digital prescriptions before it can be fully digital (which will take a while) and in the meantime relies on transitioning between digital and non-digital processes several times before the payment is eventually made to the user. Although the team have gained plenty of insight into the full process throughout their research, they’ve been concentrating testing their alpha with the digital part and haven’t been testing those non-digital transition points to the same extent.
One example of a transition from the digital to non-digital section of the service is the disallowed prescription page. In the alpha this is treated like an error page, but discussion in the assessment revealed that the pharmacist is expected to do carry out an action in response to this page - they need to make sure that whoever is providing the prescription stops prescribing it. The service team should treat this action as part of the user journey, test it, and investigate measuring its success.
The team have experimented with their content design, first referring to paper forms in plain english, then later settling on using their codenames. This is because the team found out that pharmacists currently have to use the paper forms every month and so already know the code names. However, over the lifecycle of the digital submissions service a lot of new pharmacists will start using it who will have only have used a fully-digital prescriptions service and will never have used the paper forms - the code names will be meaningless to them. We’d like to see the team try to incorporate both the codenames and plain english into the content design.
The team have done some accessibility testing, but should do a full audit in beta.
Analytics
The panel was pleased to see that the team has well-formed plans for measuring the success of the service and use the data to make continuous improvements. Beyond user satisfaction, digital uptake and cost per transaction, the team also has plans to use data gathered from phone support volumes and topics, monitor the number of erroneous submissions, and use these to guide the further development of the service.
Next Steps
You should follow the recommendations made in this report before arranging your next assessment.
Please contact the Service Assessment team at least 4 weeks before the date you’d like to hold a reassessment.
Get advice and guidance
The team can get advice and guidance on the next stage of development by:
- searching the Government Service Design Manual
- asking the cross-government slack community
- contacting the Service Assessment team