In my last blog post I talked about Register with a GP going into private beta. Private beta is a working version of a service that’s available to a restricted number of people. It helps us learn about the usability of our service in the real world.
In this post I’ll share what we learned, some of the challenges we faced, and what led to our ultimate decision to stop working on Register with a GP.
Firstly, it helps to know a bit about what GP registration involves.
GP registration in a nutshell
To register with a GP practice, most people either visit the practice and pick up the necessary forms, or download and print them. They fill in the forms at home and bring them back with the required proofs when they’re ready.
GP practices usually ask new patients to provide the following information.
Basic registration information. Personal details that allow the practice to register a new patient and find their medical records (using the standard NHS GMS1 registration form or an equivalent).
New patient information. Information that the practice requests (usually using their own forms) for a range of reasons, including:
- understanding a new patient’s general health and any critical health conditions (before receiving their medical records)
- meeting obligations to collect patient information for the NHS
- understanding whether a patient has any needs they should account for in providing services (such as language assistance)
- understanding whether the patient wants to sign up for online GP services, or if they have given consent to have their medical data shared in appropriate circumstances
Proofs. Practices are allowed to ask for proof of identity and address as part of the registration process, however their processes for this must be non-discriminatory. Practices must follow guidelines, but there isn’t a single rule for all practices to follow.
Understanding the trade-offs
At the end of our alpha phase we thought that a digital GP registration service could provide value to practices and registering patients by:
- allowing new patients to submit registration applications online
- allowing new patients to provide proofs of identity or address online to practices (where this is required)
- supporting GP administrators by delivering application data directly to GP systems (avoiding the need for them to manually enter the data)
A registration service that is digital from ‘end-to-end’ would involve solutions for all of these things. However, we still didn’t know whether there was a single approach to delivering such a service that could meet the needs of thousands of practices and millions of patients, while also being scalable and sustainable.
This combined the challenges of delivering a transactional service for a large government department and building a common technology platform to meet the same need for many organisations.
Questions we had about the kind of service we should provide included:
Patient information
- Would practices adopt a digital service that doesn’t ask for all the information their current forms do?
- Should we allow practices to customise the service themselves? If so, how can we build something that is both flexible (to meet the needs of practices), and simple to use (for both practices and patients)?
Proofs
- Would registering patients be happy to submit applications digitally if they still have to provide proofs in person at the practice afterwards?
- Would practices be happy to replace documentary proof with a digital process – even if this means investing time and effort in learning new processes or systems?
Data delivery
- Would practice managers and administrators be happy to use a digital registration service if it doesn’t provide data directly to their GP systems?
were just parts of bigger, more fundamental question: ‘can we find an approach that works for enough patients and practices to be worthwhile?’
During private beta – Learn
During private beta – Prove
To scale to a national level, we had to be confident that we could develop a service that would both meet the most common user needs and be readily adopted by a substantial proportion of practices – so we made proving this an explicit goal for our private beta phase. We thought we could learn rapidly about what would work by partnering with practices to trial the service at small scale.
Testing something real in the wild
For our private beta, we created a ‘minimum viable product’ digital service to process real registration applications. A minimum viable product is a version of a service that has just enough features to test with users and check whether those features meet user needs.
Our minimum viable product was a simple online application form that allowed patients to submit applications to register online. Their data was delivered to the practice securely via the NHSmail system. The service asked for the minimum necessary registration information, as well as some new patient information that we knew from our discovery research was important for practices in gaining an immediate understanding of a patient’s medical needs (such as current medications and allergies).
We selected 6 practices from over 150 across England who responded to a call for partners to work with us. Our trial group had practices that served urban and rural populations, had large and small patient lists, contained sole and group practices, and used various providers of GP systems. We wanted to understand whether variety in practice circumstances affected their needs and preferences.
While building the beta service and testing prototypes with users in the labs, we visited the practices and spoke with their managers and staff. We regularly showed them design iterations and working versions of the service so they understood what it would look like for people registering, and what the practices receive from them.
What we learned from the trial
We released our private beta in three of our six partner practices before we decided to stop (one practice withdrew, and we were still waiting to launch in the remaining two). Of these, our service proved to be majorly successful in one practice, where it received dozens of applications per week from patients, and was greeted with enthusiasm by practice staff.
At this practice we found:
- a practice manager and staff who wanted digital to become the default way they received registration applications
- fewer concerns about their capacity to take on new patients, or receiving applications from outside their catchment area than other practices
- no requirement for proofs from patients at registration – so an online application would lead directly to registration
Across the five other practices, we found:
- though keen to provide digital registration options for patients, practice staff tended to see these more as ‘nice to have’ features
- details of offline steps to complete registration (e.g. what kind of proofs were accepted by the practice) could vary significantly between practices – requiring content tailored for each practice
Creating a single, simple interaction
Our private beta trial was intended to help us understand whether a single service could meet the most common user needs across a range of organisations.
We knew from our discovery and alpha research creating a single, simple, seamless digital journey was considered a major benefit of doing things digitally by both patients and practices – meeting expectations they had from their experiences of other digital registration or ‘sign up’ services.
Making the journey complete for patients meant not only accepting applications from them digitally, but handling proofs and confirming registrations in a similar way. Likewise, making the digital journey complete for practice staff meant not only providing applications to them digitally, but saving them time by enabling them to easily transfer data to their systems.
We believe it’s telling that our most successful practice was the one able to create a single, simple digital journey for registering patients. Compared with a combination of online and offline steps, we believe that during GP registration, users are more likely to favour the relative ease and convenience of either a completely offline or completely online journey.
Viewed from this perspective, the success we saw could reasonably be attributed to the practice’s decision not to require proofs from registering patients. However, a Citizen’s Advice research survey we reviewed in discovery showed that this would only account for 12% of practices, whilst 13% asked for either proof of address or proof of identity, and the overwhelming majority (58%) required both.
It might have been possible for us to create a seamless digital journey for practices requiring proofs, however finding a solution for this that was viable for practices with different requirements would present similar if not greater challenges – meaning further research and development effort with no guarantee of finding a solution that worked at scale.
With our private beta seeing mixed success, and the potential to build on that success feeling tenuous, we concluded that we had not achieved our beta goal of finding a way to deliver a single, seamless digital registration journey that could work for patients and practices on a national scale.
Consequently, we agreed with our commissioners to stop working on Register with a GP.
Sharing is caring
Deciding to stop a project isn’t always easy, particularly when your team have spent many months grappling with complex problems in search of viable solutions. However, being able to stop – instead of feeling beholden to a good idea that you’re not sure will work – is part of what makes phased agile approaches a responsible way for the public sector to ‘think big’ without overcommitting.
As part of our retrospective and review of the project, we are asking ourselves how we might have reached this outcome sooner. Undoubtedly, there are ways we may have been able to engage more rapidly or effectively – and by inspecting our approach we can hopefully draw useful lessons for future projects.
That said, we also have a lot of good work and learning that we can share and build on. We’ve developed design patterns for transactional services that we didn’t have before – and are already sharing this with other service teams and our Standards team to help support others developing digital services for the NHS.
Ultimately, it helps to feel like you’ve made the right decision for the right reasons, and to know that what you’ve learned in the process can help others. Over the coming weeks and months, we will be working out how best to share what we learned so that others within the NHS network can benefit from our efforts.
