NHS Digital Weight Management Programme Referral Hub
This is the alpha assessment report for the NHS Digital Weight Management Programme Referral Hub on the 23rd of February 2021.
Service Standard assessment report
NHS Digital Weight Management Programme Referral Hub (DWMP Referral Hub)
| From: | Government Digital Service |
| Assessment date: | 23/02/2021 |
| Stage: | Alpha |
| Result: | Met |
| Service provider: | NHS England and NHS Improvement (NHSE/I) |
Service description
Eligible patients will be referred to the NHS DWMP Referral Hub (Hub) from Primary Care, via the NHS Digital e-Referral System.
Patients will access the Hub via a personalised text message initiated on referral receipt by the Hub or access services through contact via a call centre. Following identify, consent and specific characteristic confirmations patients are triaged and given access to a range of digital weight management services.
Patients are able to self-serve and select the service which best meets their own personal preferences and specific needs.
Service users
This service is for three types of users:
Primary users:
-
External: Primary Care Healthcare professions – those referring patients into the Hub via the e-RS
-
Internal: Midlands and Lancashire NHS Commissioning Support Unit business intelligence analysts, NHS England and Improvement statistical analyst
-
Public Users: Patients (adults) and carers
● aged eighteen years or over
● resident or registered with a GP practice in England
● classified as obese from their current weight and height measurements
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 worked quickly and during discovery engaged with patients, GPs, commissioners, third sector organisations, DWMS providers and LGAs to explore the barriers service users faced when accessing support with weight management
- the team looked at the main findings from the discovery to improve the issues faced by users. GPs don’t have a long time to talk to users, GPs need a way of referring people to services and patients don’t know which is the right service to use. It was decided that a digital referral service would be developed
- the team has found that there are similar services available but these have poor engagement and there is no analytics. The team has researched these services and concluded that an improved simple central service allowing GPs to make referrals would be needed. The service should gather data to track the effectiveness of what works and provide personalised content for different communities
What the team needs to explore
Before their next assessment, the team needs to:
- understand whether the proposed solution will be useful to users
- research conducted to date with external users has been low in numbers. This needs to be increased going forward to ensure a good sample size
- list their risky assumptions along with evidence of the ways that they have been explored and addressed
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 service will provide a way for GPs to refer patients to a choice of weight management providers to get support to lose weight
- the team researched similar services available and gained useful insights that have helped to shape the solution
- the team has spoken to service users and people who work with users to identify key insights. They have addressed some of the insights such as making it clear who provides the service to build trust and reducing the number of touchpoints
- the team has engaged with and collected feedback from a range of stakeholders, providers and GPs
- the team has considered barriers to users accessing the service and thought of ways to address this. The team had clearly tried to focus on a small element of the overall end-to-end journey and to try and deliver value incrementally
- the team had considered various solutions to the problem and began iterating their designs to test with users
What the team needs to explore
Before their next assessment, the team needs to:
- carry out further user research on the feedback loop with GPs after a user has connected with a weight management provider. This will ensure the service covers the end-to-end journey, allowing the team to measure service performance more accurately
- consider how the team can work more in the open during beta so a greater range of users can be engaged in the overall service design
- implement and test “end to end” functionality from receiving the text message, to signing up and choosing a provider
- do more testing to understand the end to end service, get evidence that users understand it and are able to take action without generating more work for GPs with additional enquiries from patients
- explore whether the solution solves the whole problem for patients. Whether they understand their condition, know what they need to do to help improve their condition, understand what to do next and whether they can take action
- the team also needs to make it clear to patients how they will be contacted, how frequently and how they can opt out of being contacted
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 started to include users with access needs in the research
- the team has made some initial enquiries into how the service will work for people without internet access
- the service design considers aspects beyond the digital solution
What the team needs to explore
Before their next assessment, the team needs to:
- explore the whole journey, with examples of different scenarios and different user needs when accessing providers. For example, whether patients know enough to make a decision so that they choose the correct provider and whether when they get to the provider they are able to make use of the help for it to be effective
- ensure the service team is fully empowered to take a user-centred approach to the design of this service. It seems likely that the technical development of the prototype is driving forward the design
- further test the design solution with all users of the service, with a fuller appreciation of the areas that fall outside of the scope of the specific digital hub but are still crucial to a successful weight management programme
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 was considering how to make interacting with the service as simple as possible for users, whether following a happy or unhappy path
- the team was looking at all the parts of the service the user interacts with, including referral via SMS, phone call and an offline letter. The team had also identified scenarios where users might not succeed with the service the first time and had provided a support channel to assist with this
- the team recognised the importance of providing a consistent experience and had ensured their service was branded appropriately
What the team needs to explore
Before their next assessment, the team needs to:
- start their beta by running some usability testing of their prototype with potential users. This is critical. Future iterations of the prototype should align to research questions prioritised for testing
- the team should ensure their prototype has been designed to meet real user needs. For example, on the page in the service where a user selects from the three or four possible service providers, consider what evidence the team has that an accordion component supports the comparison of different options better than a flat list
- explore whether they can do more to create greater consistency with other NHS services. They could, for example, use the NHS design system as the basis for all the components they are using in their service, such as the expander component, and follow the style guidelines around the use of imagery within a service. If the team felt the need to use components outside of those available through the NHS or government design systems, it is recommended that they conduct additional user research to ensure these components meet user needs
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 had considered how their service would meet relevant accessibility standards
- the team had considered how the different channels providing entry points into the service might exclude certain groups
- the team had a plan in place to support research with users who have access needs, low digital literacy or poor internet access
What the team needs to explore
Before their next assessment, the team needs to:
- the team should explore different names for the service and test them with users. Please refer to the relevant service manual guidance on naming services.
- the team should conduct some usability testing with participants who represent the potential audience for their service, including participants with access needs
- the team should ensure they have a plan in place for how they could provide a full assisted digital route through their service and how they will test this with appropriate users
- the team should ensure that the channels they have selected as entry points into their service have been tested with users, alongside other options such as email. They should also explore how introducing a solution such as IVR could impact users with access needs
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 team has all the core programme development roles covered and is working in an agile and iterative way
- the digital team is linked in with the wider programme board and clear governance structures are in place
What the team needs to explore
Before their next assessment, the team needs to:
- explore increasing user research capacity in the team to ensure qualitative data from user surveys can be followed up in an agile manner
- explore ways of working with behavioural insights teams in DHSC and across government to ensure high-level choices such as use of chat-bots will be an effective long-term solution to the problem the team is trying to solve
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 team is clearly working in an agile manner with all project roles assigned and a defined backlog of tasks
What the team needs to explore
Before their next assessment, the team needs to:
- explore more ways of getting the service in front of real users, ensuring that user acceptance testing is built into each sprint cycle throughout the beta
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 had iterated early prototypes based on early user feedback
- the service team has compiled a list of user experience recommendations that will help form part of their backlog for future iterations
What the team needs to explore
Before their next assessment, the team needs to:
- explore options for how the service could update a GPs record on a user’s weight without using GPs time
- consider pausing development on the chatbot feature until there is significant user research to prove this is the most effective nudge technique to engage with hard-to-reach users
9. Create a secure service that protects users’ privacy
Decision
The service met point 9 of the Standard.
What the team has done well
The panel was impressed that:
- the team is following an information governance process that includes Penetration Testing, Security assessment and more
- the prototype is currently making use of Azure’s security features to ensure that data is encrypted in transfer and at rest
- data passed on to third-party components remains accessible to the team in case modifications or deletions are required (for example subject access request)
What the team needs to explore
Before their next assessment, the team needs to:
- have a complete understanding of the risks associated with the service’s storage of personal data, by conducting an internal threat assessment: identifying who would want to steal data or disrupt the service, and how they would proceed. Doing so will help the team build a secure service and will complement external reviews, for example, pen testing
- establish a process to follow in case of a breach: how to find out the root cause (for example bug in the code, compromised deployment process, unauthorised access), how to identify what data was leaked, who to notify, when and how to fix the breach
- be aware that security needs to be ensured at the application level, and not just the platform level. Developers should be familiar with common attack vectors and how to remedy them (for example OWASP)
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 team had considered ease of navigating the service from GP referral and saving GP time on weight management cases as key metrics for success
What the team needs to explore
Before their next assessment, the team needs to:
- draft a plan with an analytics expert about which set of performance data could be published in the beta phase and which platform this could be best surfaced once live
- consider more ways to capture key performance data and analytics on the service in the beta phase, particularly with regards to how service providers are presented on the app
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 service runs on a public cloud and acceptable security settings have, so far, been chosen
- the team uses F#, a mainstream and open-source language, to build the platform and git to manage source code
- the team has built upon the NHS Design System to implement their design
- the team uses GOV.UK Notify
What the team needs to explore
Before their next assessment, the team needs to:
- continue choosing open technology and tools, for instance when monitoring or deployment options are considered
- make sure the code lends itself to upgrade to the latest version of the NHS design system
- not tie themselves to a specific technology provider. For instance by asking themselves questions like: what would we do if the organisation were to move away from Azure for commercial reasons?
12. Make new source code open
Decision
The service did not meet point 12 of the Standard.
What the team has done well
The panel was impressed that:
- the code is hosted in a git repository which can easily be made publicly available
What the team needs to explore
Before their next assessment, the team needs to:
- make the source code open, or seek an exception. The team must seek to address this standard point before booking in the next assessment. For this the team must make the source code open, or seek an exemption
- find a better way to prevent secrets from being added to the code. The panel strongly suggests this because the reason given for not publishing the source code is to protect against any accidental leaking of secrets, such as API keys. On top of preventing openness, this reflects a lack of knowledge of software development security practices
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:
- the service uses the NHS Design system
- the service uses GOV.UK Notify for emails and SMS messages
What the team needs to explore
Before their next assessment, the team needs to:
- join the cross-government frontend community and contribute any insight on app design with the NHS Design System designers
- feed back the changes made to the NHS Design System to its maintainers, in order to improve it for other services that will be built in the future
- consider for instance packaging the CSS/JS/Templates so it’s easy to use with F#, this would probably be helpful to the community
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:
- the team chose Azure, which provides a robust platform-level infrastructure
What the team needs to explore
Before their next assessment, the team needs to:
- build a modern CI/CD pipeline that will enable fast, frequent deployments that can be rolled back in case of problems
- build a complete monitoring stack that will check the health of the application, at the platform level (provided by Azure), but also at the application level (for example smoke tests). The team should refer to the GOV.UK Service Manual and the GOV.UK Tech code of practice for advice
- adopt a mobile-first approach and make sure that front-end performance is decent. Given that nearly all users will be using their mobile devices this is important. The design system includes large assets (such as CSS or fonts). It will be important to make sure that the service is reliable in all circumstances that a user might find themselves in (for example poor connectivity, slow device)