Pharmacy Returns - Alpha Assessment
The report from the alpha assessment for NHS BSA's Pharmacy Returns service on 28 November 2016.
| Stage: | Alpha |
| Result: | Met |
| Service provider: | NHS Business Services Authority |
The service met the Standard the service because:
- The team have built and continuously iterated a prototype based on ongoing user research to understand and meet user needs.
- The latest version of the prototype has been well received and the new service has the potential to clearly meet user needs and deliver a range of benefits for users.
- A strong digital team is in place and they are working in an agile way to meet user needs.
- The team have developed an approach for the private beta in accordance with the standards
About the service
Service Manager: Susan Airey
Digital Leader: Gill Ayling
Service description
NHS Prescription Services processes around 1 billion prescription items each year, which currently involves a number of paper based activities.
The NHS Business Services Authority (BSA) currently returns over 100k prescription payment requests per month, requesting more information or explaining why a payment cannot be made. This service is a paper and postal process so users (pharmacy; GP practice; dispensing appliance contractor) are asked to provide more information to allow a payment to be made or given a reason why payment for a prescribed items has been disallowed. Currently a printed copy of the prescription and a covering letter is sent to the user in the post. The user then needs to write the missing information or clarification on the copy of the prescription form and return in the post to the Prescription Services processing team. The details are then re-entered into the BSA system in order that payment can be processed. This process adds delay, is a burden on users and can often result in too much information being provided as the user is unclear on what BSA requires.
The digital service removes the paper and postal process so that users can be notified of a non-payment item, be told specifically what further information is required and can then provide this more easily via the new service. This will be a quicker and more user friendly service. For disallowed items, the user is provided with specific information on why.
Overview of service users
Service users are pharmacists, dispensing GPs and dispensing appliance contractors.
Detail of the assessment
Lead Assessor: Julian Dos Remedios
The panel was impressed and would like to congratulate the team on the work and progress achieved so far, the capability that has been put in place and the considered approach to developing a good service for users.
User needs
The team have used a range of user research activities to develop a good understanding of the users of the service. The team have a good understanding of different types of pharmacies, their working practices, and the needs of their staff.
The whole team has been involved in this research, and has used what they’ve learned to shape the service.
The team have good evidence that their prototype service works well for the majority of users.
To understand access needs, the team have made some effort to find potential users who experience a disability or use assistive technologies. And the team plans to commission an accessibility audit of the beta service. In beta the team must also research in context with more pharmacists who experience a disability or use assistive technologies. Pharmacists professional bodies and Human Resources departments in pharmacy multiples should be able to help with recruitment.
To understand assisted digital support needs, the team have identified pharmacies that don’t use electronic prescriptions and that fill in prescriptions by hand. But the team has not yet done specific research with these groups. This was a missed opportunity.
The team has identified a good group of private beta users. But does not have a clear plan for how they will learn from them in private beta. This is a concern, as the team should be using the private beta to establish effective recruitment, onboarding, feedback and learning processes before they scale up in a public beta.
Team
The team demonstrated a detailed knowledge and understanding of the users, context of the service, empathy and recognition of the pressures and demands on their users, and how their service can and will deliver noticeable benefits and help meet user needs. This included a good awareness and understanding of the variations within the user environment, from large multiple location pharmacies, to sole proprietor businesses which may have some different needs, along with a pragmatic understanding of their users’ priorities.
No skills gaps were identified during the Alpha and the current team will be kept in place for the beta, with a recognition that more development resources will be required. The team also acknowledged that there was strong support for the wider organisation and the digital work was seen as a very positive step forward, with significant interest and engagement t from other areas of BSA. Governance was considered proportionate, though securing funding for the next phase did result in some loss of momentum for the team.
Both the service and product manager were particularly knowledgeable, as were the rest of the team, of the service and associated detail and the panel felt this was reflected in the progress made so far.
Technology
For the alpha the team had created a prototype utilising the prototyping kit from the NHS Digital team. This was one of many examples of the team looking outside of their own project to utilise and understand work in other teams across the NHS. This was very good to see.
All members of the development team were civil servants and future recruitment is also aiming to be a permanent not contract basis. Demonstrating commitment to the project and to digital in this organisation.
The team talked about their open sourcing process and how they were going to approach this for the beta. There is a concern that leaving this discussion will lead to closed source code that is hard to subsequently open. The recommendation from the team is to commence the beta build in the open, working with the security teams to identify areas of configuration or security that would be better closed. In principle starting open and closing where strong requirements exist is the prefered model.
The team demonstrated a coherent plan for the technology build into the beta phase, utilising open source technologies already in use across other projects in the department. The panel would recommend looking at the market through G-Cloud to ensure that hosting and other procurements are providing best fit and value for the team, accepting the fact that the department may also be using these products elsewhere.
The team were also able to describe the integration points with existing systems that they require in the beta. Key amongst these was integration with the Smart Card login system. These systems are currently not available to this project pending some integration work by other teams/suppliers. The panel would like the team to consider the delivery timescales of these integrations. There is a concern that the team are focusing on workarounds for the lack of these systems and a large degree of re-work and complexity is being introduced.
This is particularly relevant with the prospect of building a temporary registration system, and the requirement to copy live data between systems by hand. These may be difficult to manage in the short to medium term and also present issues of data accuracy and currency as the team moves into processing actual data. The panel would like to see the team have a clear understanding of when the integrations with the legacy systems will be available and aim to align their own build to meet these timings as much as possible.
Design
The panel were impressed by clear iterations based on user research. It was particularly interesting to hear of cases where what users asked for didn’t really meet their needs, and the team came up with better designs based on actual behaviour and needs. We’d love to see the team blog about these experiences.
The prototype makes good use of existing patterns, in particular the ‘One thing per page’ pattern to keep each screen simple and clean.
We recommend looking into the header area of the design - it’s not clear what service the user is using in the context of a busy day with various different tasks. The account name and logout link is very prominent and taking up a lot of vertical space - are they important enough to the user for this?
GDS recommend against the use of disabled input fields - some users can try and interact with them and be confused, and the lower contrast is harder for some users to read. We recommend just displaying the non-editable data as normal text.
Analytics
The team plan to make their performance data available on the performance platform and have initiated this work. They plan to use Piwik as their solution and will continue to review the data and reporting needs of users through the Beta as they recognise that there are further opportunities that users may not have identified yet. There may also be wider benefits, eg data on time savings for contractors that will translate to cost and efficiency savings for the contractors.
Recommendations
Moving to a private beta the panel felt the development of the service might benefit from the team considering the following further;
-
ensuring the private beta provides enough research and information to support a scalable public beta across England. This will include ensuring the varied needs across locations, size of contractors and other key factors are captured, considered and tested;
-
have an approach in place for making source code open and reusable from the start of beta development;
-
ensure that the delivery project dependencies are aligned and visible so as to reduce the need for rework and workarounds
-
review the risks of using an interim and less liked user journey for registering and managing accounts, given that this will dilute the key benefits for users and could negatively impact on research and overall stakeholder support;
-
not lose sight of the wider strategic benefits and influence that the service can provide, in improving associated services and products, removing some of the potential user pain points before the service is required and showing through delivery and evidenced by user research the impact on users.
-
give priority to research with pharmacies who do not do electronic prescriptions and who fill in prescriptions by hand.
-
in addition to the planned accessibility audit, do more research to ensure the service works well for people with a wide range of access needs (including, but not limited to, screen-reader and magnifier users).