Buy a Prescription Prepayment Certificate beta assessment

The Prescription Prepayment Certificate (PPC) service is a sub-service of Help with NHS costs. A user can save money on the cost of prescriptions by paying a set price for a three month or twelve month certificate.

Service Standard assessment report

Buy a Prescription Prepayment Certificate

From: Central Digital and Data Office
Assessment date: 28 November 2018
Stage: Beta
Result: Met
Service provider: NHS Business Services Authority

The service met the Standard because:

  • the panel was impressed by the amount of user research this team has carried out over the course of private beta
  • the Service team demonstrated that they are an empowered team in most areas with good support from senior staff. The assessment panel was impressed with the fact that the team were 100% permanent staff
  • the team has clearly put effort into the resilience of the service and has good arrangements in place for out of hours support
  • the team demonstrated good analysis of data about the current service to frame the vision for the new product

To pass the next assessment, the service team must:

  • be empowered to decide when and how they release to production. The panel felt the Change Approval Board (CAB) process could become a barrier to meeting user needs and iterating the product in beta. Therefore, the team must be empowered to decide how and when they release to production.

About the service

Description

The Prescription Prepayment Certificate (PPC) service is a sub-service of Help with NHS costs. A user can save money on the cost of prescriptions, currently £8.80 per item, by paying a set price for a three month (£29.10) or twelve month (£104) certificate.

The service issues a certificate to the user to be shown at the pharmacy when collecting medication. The user makes a declaration on the prescription form to indicate that they hold a PPC and do not need to pay for their prescription items. A user can collect as many prescriptions as required during the term of the certificate without needing to pay.

Service users

Citizens who are not otherwise exempt from paying prescription charges in England, between the ages of 16 and 60.

Detail

User needs

The panel was impressed by the amount of user research this team has carried out over the course of private beta. They’ve researched with 101 participants in this phase and as a result, have developed a solid understanding of their users and their needs. They’ve created some useful artefacts to represent what they’ve learnt, including personas and an experience map. It was also evident that the whole team was involved in the research process, both in terms of observing sessions and attending playbacks.

The panel was particularly impressed by the range of different methods the team has used to recruit users, including leaflet drops in pharmacies and pop-ups at public venues. This has enabled them to recruit a good range of participants, in a variety of contexts and using a range of devices.

The panel is confident that the team has tested the full end-to-end user journey, from awareness to buying to actually using the certificate to collect a prescription. They’ve done this by using a range of different research methods to capture usability issues, metrics and feedback at different points in the service. For example, they run an end of service survey, as well as a survey after users have picked up a prescription. They also regularly receive data from their contact centre to get an indication of common user questions and complaints.

The team has made a great effort to include those with access needs in their research. They were able to test with 25 users with access needs, including blind users, deaf users and those with anxiety and autism.

The team was able to give some examples of how they’d iterated the service based on user testing, such as adding a ‘finish’ button to the done page and increasing the number of messages about the removal of the plastic card. The team were also able to give examples of how they’ve iterated the service based on testing with those with access needs, such as those who use screen readers.

Team

The service team demonstrated that they are an empowered team in most areas with good support from senior staff. The assessment panel was impressed with the fact that the team was 100% permanent staff. This is very unusual in the public sector and demonstrates that the NHS is taking the building of digital capability seriously.

The team includes, service owner (product owner), delivery manager, user researcher, designer, business analyst. They also have three developers who operate in tandem with Capita who manage the platform.

There are plans to recruit a full-time content designer which the panel fully endorses and recommends they also look to recruit a full-time performance analyst which will really help the team build and measure against agreed metrics in public beta.

The team has worked well to understand the users of the service and showed good evidence that they are building on the impressive numbers of users researched with (alpha 80 users, beta 101 users). 100,000 users in private beta. And during private beta 97% of users were satisfied. Out of 25,000 users surveyed. This is great to build on.

The team is co located and operates agile ceremonies which include daily stand-ups, retros and well attended show and tells. The team is fully empowered by the board, and the service owner who is also the product owner reports into the board which gives the team air cover to get on with iterating the Buy a Prescription Prepayment Certificate service.

The panel felt that the team were unable to demonstrate that they were meeting standard 5. Demonstrate that the service can be iterated frequently. The team needs to demonstrate that they are able to improve the product on a frequent basis without impediment. Currently, the team need to inform a Change Approval Board of the changes that are going to be made in the sprint. This will be predetermining what will be built rather than building to user needs. The panel felt that this would hamper fluidity of changes to live.

Technology

The service uses internal shared platforms for sending emails and accepting payments, and the panel was pleased to hear that the team plans to start using GOV.UK Notify in the next few weeks and GOV.UK Pay next year. The team described how they can use feature flags to hide one of the payment options if an external provider is unavailable, allowing users to still complete the journey using the other option. The team has clearly put effort into the resilience of the service and has good arrangements in place for out of hours support.

The service has been successfully scaled to handle anticipated spikes in traffic when it receives publicity, but it has taken several hours to do that. The team should extend their load testing to better understand the constraints of the service and consider how they would handle a sudden and unexpected increase in traffic.

The team described a multi-faceted approach to security and privacy, including vulnerability scanning as part of their pipeline, fraud detection around direct debits, responding promptly to reported issues and a considered approach to storing and using personal data.

The team is constrained in how quickly they can iterate and put improvements to the service in front of users by a change approval process which normally involves five days’ notice of releases to production and involves people from multiple teams. Releases are happening only every three weeks at the moment and the panel was shown iterations in the assessment which had not yet been deployed to production. Although expedited release approval processes also exist, they are the exception rather than the rule and still require sign-off from people outside the team. The team must be empowered to decide how and when they release to production, using a trust and verify approach to technical governance rather than gatekeeping.

Given the plans the team had in place at the time of the alpha assessment 17 months ago to start to use public cloud infrastructure, the panel is disappointed to find that this service is still running on Capita private infrastructure. The team has taken some steps to mitigate the impact on users of continuing to use this infrastructure, such as writing transaction data to a second database alongside the main Oracle one so that users can complete the journey even while the Oracle database is unavailable during backups and releases. However, the change approval process described above is in part a result of remaining on this infrastructure. The team is not fully in control of the timing of their move to a public cloud provider, being dependent on the availability of people from outside the team to work on it, but as current plans stand they expect to complete this move in the next year.

Although the team has made a snapshot of their application code public, they are not yet allowed to code in the open. The team understand the value of doing this and described their journey towards being able to do it, including support they’ve received from GDS and taking a lead on it internally themselves. The panel strongly encourages the NHS Business Services Authority to enable teams to follow the current guidance on making source code open and reusable.

Design

The panel was pleased to see the service team has taken a holistic view of buying a prescription prepayment certificate, looking at not only the online experience but also considering the offline experience at pharmacies, and the call-centre experience.

The service team has made use of the GOV.UK design patterns to present information in a clear and consistent way, giving users the confidence that this is an official NHS service. However, the team has implemented the old version of GOV.UK elements, rather than the design system, which has resulted in an inconsistent experience.

The NHS is creating a design system for use by all NHS.UK services. While this design system is not ready for use by services such as Buy a Prescription Prepayment Certificate, there should be an ongoing conversation between the service team and the design system team to ensure design direction adheres to NHS.UK standards.

The service team were able to talk through different iterations of previous approaches, for example, changing the service’s name, splitting the page down into one thing per page, searching for and selecting an address, and various updates to content. However, some areas could be improved:

  • repeating the service name across every page of the application is unnecessary and adds to visual clutter
  • the visual hierarchy of the pages could be significantly improved, for example by making form labels bold; adjusting the spacing between form elements, labels and hints; and enhancing the separation of headings, content and form fields
  • none of the pages has a backlink on them, which makes navigating back through the journey difficult for users. The service should offer backlinks regardless of technical constraints
  • the prepayment start date language is confusing with a mix of content styles creating an inconsistent experience. The service should split the back-dated, today and later options to make it more transparent for citizens and use familiar language
  • the provision of a paper prescription, offered offline via the call centre, was not available via the online channel. The service should offer a selection of delivery methods: text, email, post and direct download

The service team highlighted the dependency on Capita Pay360 for taking payments. This dependency presents issues concerning accessibility and usability. The service team acknowledged the payment process would be enhanced by eliminating Capita and replacing with GOV.UK Pay. The service team are planning this change, but there is a dependency on another project within the NHS Business Services Authority.

The service team can be applauded for putting accessibility at the front and centre of their service’s design, having engaged not only the Digital Accessibility Centre (DAC) but also conducted more than 25 user tests with users with access needs and an additional 16 with users with assisted digital needs, and iterating upon their findings.

Analytics

The team demonstrated good analysis of data about the current service to frame the vision for the new product. They also very sensibly used this data to manage the rollout to users during private beta.

100k users have used the private beta compared to a population of 2.1M users per year = 3k-4k per day. The data analyst working with the team has also identified that around 800k patients could potentially have benefitted from PPC.

The team has access to really useful dashboards, using Shiny, to visualise findings from user research.

Currently, the team works closely with the NHS Business Services Authority’s Customer Insight team where the data analysts are based. The team demonstrated effective working between the user researcher and data analyst, ensuring the analyst was embedded through regular ceremonies including stand-ups and story writing.

The service is currently recruiting for a performance analyst into the team as a full-time role, rather than calling on the customer insight team.

The team demonstrated a good understanding of user behaviour through performance analysis:

  • the team used Google Analytics to identify keywords to understand what users search for when looking for PPC. There’s an opportunity to identify keywords from wider sources than referrals to the service
  • distribution of traffic over time - low points at the weekend, peak earlier in the week. Mornings busier than afternoons, with busy lunchtimes
  • on the beta site, 46% of users are using mobile devices
  • there is some evidence that some older users ‘explore’ the service, but do not complete

In addition to the Service Standard’s KPIs, the service is focusing on:

  • applications by channel and payment method
  • reducing duplicate certificates
  • reducing multiple exemptions - ie users purchasing a PPC when they are eligible for another exemption
  • Direct Debit usage. Since the design was iterated to facilitate Direct Debit, there has been a sharp increase in this metric
  • duration of exemption purchased

The team would like to integrate Google Analytics data into the Shiny dashboards.

The Panel queried that the page load time for the service homepage was at the lower end of ‘average’. The team explained that this may be caused by a redirect from the legacy service and API calls to the underlying database.

The team is discussing a Performance Platform dashboard with the Performance Platform team for the beta service.

Recommendations

To pass the next assessment, the service team must:

  • be empowered to decide how and when they release to production

The service team should also:

  • review a wider set of search keyword data (GDS to advise) to enhance search engine optimisation
  • look to improve page load time
  • extend load testing to better understand the constraints of the service and how they could handle a sudden and unexpected increase in traffic
  • migrate the service to public cloud in the next year
  • continue to work towards coding in the open

It is recommended the latest design patterns should be used for consistency and to benefit from the learnings and improvements from across the community.

Next Steps

You should follow the recommendations made in this report before arranging your next assessment.

This service now has permission to launch on a GOV.UK service domain. These instructions explain how to set up your *.service.gov.uk domain.

Submit feedback

Submit feedback about your assessment.

Get advice and guidance

The team can get advice and guidance on the next stage of development by:

Digital Service Standard points

Point Description Result
1 Understanding user needs Met
2 Improving the service based on user research and usability testing Met
3 Having a sustainable, multidisciplinary team in place Met
4 Building using agile, iterative and user-centred methods Met
5 Iterating and improving the service on a frequent basis Not met
6 Evaluating tools, systems, and ways of procuring them Met
7 Managing data, security level, legal responsibilities, privacy issues and risks Met
8 Making code available as open source Met
9 Using open standards and common government platforms Met
10 Testing the end-to-end service, and browser and device testing Met
11 Planning for the service being taken temporarily offline Met
12 Creating a simple and intuitive service Met
13 Ensuring consistency with the design and style of GOV.UK n/a
14 Encouraging digital take-up Met
15 Using analytics tools to collect and act on performance data Met
16 Defining KPIs and establishing performance benchmarks Met
17 Reporting performance data on the Performance Platform Met
18 Testing the service with the minister responsible for it Met
Published 23 January 2020