From: DHSC
Assessment date: 04/05/23
Stage: Alpha
Result: Met
Service provider: NHS England
Service description
This service aims to solve the problem of a user (an Adult with Mental capacity) who wants to request proxy access to support another adult with mental capacity when using their GP services. This can include; ordering repeat prescriptions, booking GP appointments, speaking to GP staff on the patient’s behalf and reviewing information within the patients’ medical record. Our application service provides the GP practice with all the information required to set up a proxy relationship within the clinical IT systems and the contact details of both the proxy and the patient so they can be contacted easily when required.
Service users
This service is for…
- Proxy (Adult with mental capacity)
- Patient (Adult with mental capacity)
- GP Practice Team
Report contents
- Understand users and their needs
- Solve a whole problem for users
- Provide a joined-up experience across all channels
- Make the service simple to use
- Make sure everyone can use the service
- Have a multidisciplinary team
- Use agile ways of working
- Iterate and improve frequently
- Create a secure service which protects users’ privacy
- Define what success looks like and publish performance data
- Choose the right tools and technology
- Make new source code open
- Use and contribute to open standards, common components and patterns
- Operate a reliable service
1. Understand users and their needs
Decision
The service met point 1 of the Standard.
What the team has done well
The panel was impressed that:
- the team has done extensive research with both patients, their proxies and GP practice staff using both surveys, individual and paired interviews
- the team has a good understanding of the different roles at a GP practice staff and the varied needs if a new digital service centralises the application process for proxy
- the supporting guidance for staff has been tested and iterated on based on usability testing. It is ready for a Private Beta test
- research is planned with interested community groups and representative charities such as Age UK to get their expert view of the current issues patients face setting up proxy access, and for testing the new application route
What the team needs to explore
Before their next assessment, the team needs to:
- research and test for the needs for wider population that want proxy access. Currently the service is limited to the small number of people who are applying for proxy access for another mentally competent adult registered at the same GP Practice. This cohort is very small therefore the digital service isn’t easing the burden of proxy registration in most instances for GP Practice staff
- research the barriers of registering for proxy access when either the proxy or the patient spends significant time outside the UK
2. Solve a whole problem for users
Decision
The service met point 2 of the Standard.
What the team has done well
The panel was impressed that:
- the team engaged with a group of around 50 practice staff to understand the process of getting proxy access at a variety of GP surgeries
- the team understood that, to provide a better service, they will need to integrate with GP IT systems. The team have begun research on this although this won’t be in the MVP
- the team have done extensive work to understand the problem space, what is happening, why and how the various user groups have been impacted
- the team have considered and strengthen the previous research findings and journey maps with related pain points to help scoping the work and creating the to-be service blueprint, the product roadmap and the assumptions to test and validate during research
- the team have a clear vision of the service ecosystem - the service designer has created a visually compelling map describing the connection between services, systems, components and people involved in the service
- the team is collaborating, communicating and working with other teams within the organisation to make sure that the service is not working in isolation with adjacent services
- the team have clearly identified constraints that are limiting the ability to solve the whole problem for users. The team has highlighted areas of the service that need to be explored further during Beta and or possibly by other teams or new piece of work
- the clear direction for the applicant that if they choose to have medical record access this could take longer for the application to be triaged and accepted
- the messaging gives a time expectation which should reduce anxiety and follow up communications with the GP Practice
What the team needs to explore
Before their next assessment, the team needs to:
- be sure that this is definitely the right problem to be solving. The team are working on a very tight deadline due to a commitment by the Secretary of State and, by their own admission, would have prototyped a much larger range of approaches if the team had more time
- understand the value of creating a truly end-to-end service and decide how much the service should extend into the part of the journey currently owned by the GPs
- undertake further research with patients and staff to validate the assumption that proxy initiating the process and making the application is the right approach
- prototype unhappy paths and critical journeys and consider the edge cases and connected risks
- research and explore more about applying for proxy access when proxy and patient are not registered in the same GP practice
- research the journey of someone who hasn’t been set up with NHS Login and therefore has to leave the journey to register for that before proceeding
- show evidence from research that the original patient has been happy with the end-to-end service route of someone becoming their proxy
3. Provide a joined-up experience across all channels
Decision
The service met point 3 of the Standard.
What the team has done well
The panel was impressed that:
- the team has engaged with GP practices to understand internal processes and systems to identify problems that the new online design application needs to address
- the clear messaging in the application for proxy access and giving the applicant options for what to ask for
- giving the proxy applicant clear instructions in the final screen and email confirmation
- the guidance for the practice staff has considered their language, and is reflective of the fact that different practices have varied levels of standard access for proxies
What the team needs to explore
Before their next assessment, the team needs to:
- focus on widening the kinds of proxies available with this NHS digital application process
- research if the proxy access extends to 3rd party Apps the patient might use to manage their healthcare which have been integrated into the NHS App
- show evidence that the end-to-end journey works for people with low digital skills, neurodiversity and other access needs
- make sure that research includes the offline parts of the service and that the learning from testing the online journey can provide improvements to the offline journey
4. Make the service simple to use
Decision
The service met point 4 of the Standard.
What the team has done well
The panel was impressed that the team:
- has created a service using the common components and patterns of the NHS design system to enable patients to register for proxy access
- has the right composition of content, service and interaction designers working together with the user researchers in making sure that the service is intuitive and aligned to user needs
- has shown good examples of how design and content have changed and improved based on feedbacks
- has documented very well the design process including hypothesis to test or tested and decisions around design improvements
What the team needs to explore
Before their next assessment, the team needs to:
- do more usability testing of the end-to-end journey including the part after the application is submitted, accepted and when the proxy user accesses the app after the GP has triggered the notification into their system
- do more research with proxy users that don’t have an NHS login to uncover any gaps and provide appropriate support
- connect with user researcher and designers in other government departments who have developed similar services to learn from them
5. Make sure everyone can use the service
Decision
The service met point 5 of the Standard.
What the team has done well
The panel was impressed that the team:
- has conducted research with users with accessibility needs and are iterating based on those findings
- has clearly articulated their use of the digital inclusion scale in this alpha
- the content designer is thoroughly following the GDS framework to write for all users in every touchpoint of the service
What the team needs to explore
Before their next assessment, the team needs to:
- demonstrate research has been done with staff with low digital confidence, considering this is a change to how they receive an application.
- carry out research with both proxy and patients who represent the potential audience for the service, including people with access needs and low digital skills
- continue to understand and design for the lower end of the digital inclusion scale and for non-native speakers' users to uncover potential issues in both online and offline routes of the service
- book an accessibility audit and make sure that issues and recommendations identified are acted upon
6. Have a multidisciplinary team
Decision
The service met point 6 of the Standard.
What the team has done well
The panel was impressed that:
- the service team has a good mix of technology and UCD focused roles that can enable the accelerated
- the service team has a service owner and knows what to escalate to them
- the team know what team they need for private beta and expect to bring on a performance analyst
- the team have a large panel of SMEs to work with
7. Use agile ways of working
Decision
The service met point 7 of the Standard.
What the team has done well
The panel was impressed that:
- the service is team is well organised. Work is split over two JIRA boards: one for the developers and one for the project team
- the service team have chosen appropriate task management approaches for different tasks. The project team has been using kanban as they are more task oriented whereas dev board is scrum based and more granular
- the team has a wide-reaching communication strategy and is actively engaged with stakeholders outside of the immediate project area including presenting to the British Medical Association
8. Iterate and improve frequently
Decision
The service met point 8 of the Standard.
What the team has done well
The panel was impressed that:
- the service team iterated design concepts and heavily iterated content which is appropriate given the nature of the service
- has rigorously captured risky areas where they did not test and iterate due to time limitations
What the team needs to explore
Before their next assessment, the team needs to:
- test and, if necessary, iterate parts of the service that weren’t sufficiently iterated in alpha. Prioritise areas of the service where you have risky assumptions
9. Create a secure service which protects users’ privacy
Decision
The service met point 9 of the Standard.
What the team has done well
The panel was impressed that:
- the Service has been designed and built with due security considerations for data, Infrastructure and application
- infrastructure development is automated using Terraform. This also lends a secure deployment
- as the Service is exposed to the public internet, there are considerations for DDoS, BOT and API security (Akanmai)
- key and Secret storage / management in Azure Key vault
- scan profiles used for GitLeaks to ensure repository assets does not contain secrets and keys
- static codes scanned for vulnerability implementing SonarQube
What the team needs to explore
Before their next assessment, the team needs to:
- the infrastructure build involves the use of Terraform (IaaC). This is a great approach. However, this must be secured to ensure vulnerabilities are not introduced via the codes. TFLint implementation in the pipelines ensures code errors are identified during the build process prior to deployment
- in addition, Infrastructure configurations should be checked implementing Chekov in the automation pipelines. This ensures that infrastructure vulnerabilities are identified during the promotion process from build to test and deployment
- alternative solutions for Terraform and Infrastructure vulnerability checks can be explored by the project team
- whilst Akanmai mitigates distributed denial-of-service (DDoS), BOT and application programming interface (API) security, it is does not prevent OWASP linked vectors. The project team must put in place a mitigation for OWASP threats prior to Beta phase
10. Define what success looks like and publish performance data
Decision
The service met point 10 of the Standard.
What the team has done well
The panel was impressed that:
- the service team have thought about what success and failure looks like, how to measure it and how to integrate this measurement into the service
- the service team have thought about how to capture feedback about the entire user journey including the parts their MVP service does not cover
What the team needs to explore
Before their next assessment, the team needs to:
- ensure that they research the current amount of proxy access requests to create a baseline that their service can be measured against
11. Choose the right tools and technology
Decision
The service met point 11 of the Standard.
What the team has done well
The panel was impressed that:
- the reuse of the NHS App as a wrapper for the Proxy Application Service
- the reuse of NHS Login for the Proxy application Service. This aligns the authentication and verification process with existing approach for NHS products and services
- integrations with Gov Notify, API Management (NHSUK) and PDS
- cloud first approach with automation and quality checks built into the solution
- monitoring capabilities built into solution by implementing Azure Monitor
What the team needs to explore
Before their next assessment, the team needs to:
- a containerised solution with Azure Instance Container would have mitigated technical debt, efficiency and cost of running an Azure App Service
- user and Acceptance testing to be carried out in the Beta Phase to ensure both usability and accessibility tests are concluded, and mitigations actioned
- the Proxy Application Service should also undergo a performance test to ensure that performance metrics with breakpoints are identified and mitigated
- a dry run of the Disaster Recovery process should be concluded in the Beta phase to ensure that recovery times and data are aligned to set targets. Also, Business Continuity plans should be tested for effectiveness
12. Make new source code open
Decision
The service met point 12 of the Standard.
What the team has done well
The panel was impressed that:
- project code repository resides in GitHub and actively used in the project development process
- automated pipelines used to build, test and deploy codes. This is then promoted via the pre-production environments to production
What the team needs to explore
Before their next assessment, the team needs to:
- once a stable codebase is achieved, this should be open to other government departments for reuse and sharing
13. Use and contribute to open standards, common components and patterns
Decision
The service met point 13 of the Standard.
What the team has done well
The panel was impressed that:
- open standards implemented, hence the ability to reuse and integrate seamlessly with existing services and tools for example Terraform, NHS App, NHS Login, API Management, PDS and Gov Notify
What the team needs to explore
Before their next assessment, the team needs to:
- the use of Open-Source tools for Terraform code and Infrastructure configuration review / quality checks
14. Operate a reliable service
Decision
The service met point 14 of the Standard.
What the team has done well
The panel was impressed that:
- technology and tools available within the technology radar used for the Proxy Application Service
- a Support model designed for use with the Proxy Application Service.
What the team needs to explore
Before their next assessment, the team needs to:
- service operating model should be checked for risks and issues, which should be mitigated or added to the risk register at the Beta phase.
Leave a comment