From: DHSC
Assessment date: 28/03/2024
Stage: Beta
Result: Met
Service provider: UKHSA
Service description
Registered medical practitioners (RMPs) in England have a statutory duty to notify suspected cases of certain infectious diseases to the UK Health Security Agency (UKHSA) within 3 days or 24 hours if urgent. The reporting of notifiable infectious diseases is currently a paper based, manual process. This service will make it easier for RMPs to report notifiable diseases in a way that captures information completely and accurately, so that prompt and appropriate public health action can be taken by Health Protection Teams (HPTs).
Service users
External users:
NHS RMPs (Primary & Secondary care)
Private RMPs (Primary & Secondary care)
Locum RMPs (Primary & Secondary care)
NHS Nurses (Primary care)
GP admins (NHS & Private)
UKHSA users:
Business Support Teams /Administrative
Officers
Health Protection Practitioners (HPP)
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:
- a significant number of users had been engaged with prior to the beta assessment (n=549). A very clear overview was provided as to who had been spoken to at each project stage, their role, and what kind of research activity they had taken part in
- a wide range of research methods were used to ascertain an understanding of the users and the proposed service, including the use of scenarios to test the end-to-end journey
- the user groups were clear and presented well in the materials and presentation. The team stressed that although there are user groups outside of scope at present, they have been considered and will be brought into scope in the future
- it was clear that the team has an extensive understanding of user needs across all user groups and that these needs underpin the service design
- user research documentation was very thorough and of high quality. Personas, for example, were living documents that had clearly been iterated over time and were being used to understand gaps in research data
- recruitment has been broad and diverse with regards to accessibility needs, roles and reporting behaviour/experience. There are some outstanding gaps with regards to recruitment e.g. individuals with mobility issues, however, the team is largely aware of these and have plans in place to address them
- proxy users have been spoken with when actual users with needs could not be sourced. This is a resourceful response to challenging recruitment circumstances and should be utilised again, if required, to ensure that all potential user groups are represented
- user behaviour had been considered, with regards to a preference to revert to phone-based reporting, and plans are in place to encourage a change in behaviour and improve uptake of the digital service
- survey data from the pilot was well presented and key analytics were highlighted. The inclusion of comments from users regarding how the service could be improved were particularly insightful and demonstrated a good team understanding of potential next steps to continue to meet user needs
- a very thorough plan for research in the public beta stage was presented. This is an ambitious plan in terms of number of participants and timeframe, particularly given the recruitment issues experienced to date. Although it may feel achievable, the panel would stress that it is important not to overstretch yourself and potentially compromise the quality of the research in favour of the quantity
What the team needs to explore
Before their next assessment, the team needs to:
- test with ESL individuals in usability testing. No research has been conducted with individuals with English as a second language (ESL). While it was acknowledged that participants recruited span ethic groups, this does not mean that these individuals have ESL insight
- consider the age of individuals involved in the research and if this is reflective of the broader user population. Data showed that only one individual over the age of 60 had participated. This seems small considering the types of roles occupied by individuals who are required to report. (For example, in 2022 1 in 10 GPs were over 60)
- prioritise establishing relationships with relevant charities as soon as possible, as these connections can take time to build and manage to prove fruitful in terms of recruitment. There was a lack of clarity about how to recruit potentially ‘hard-to-reach’ individuals, particularly those with access needs not obtainable through a recruitment agency
- Create a plan as to how often customer satisfaction data will be reviewed and analysed by the user researcher and share this with the wider team. It was challenging to get a sense of how the customer satisfaction data will be used moving forward, particularly how such data will be utilised to shape future designs
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 problem statement was clear in that a digital service will save time for users, improving the current journey of downloading the relevant documents, filling them in and sending them to the relevant report processers
- the team were clear with the constraints the project faced. For example, how they had considered the MOD journeys though that was now out of scope
- the team explored how the service application would fit in with the wider parts of the journey process, such as report processing
What the team needs to explore
Before their next assessment, the team needs to:
- consider doing research on how reporters on busy wards such as infectious diseases use the digital service. Journeys and research focus’ mainly on GP’s reporting
- explore how the NHS app could support this service, for example extracting patient data or to keep patients informed of the report that Is inevitably about them and their care. The team did acknowledge it was something they are considering
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:
- research has been conducted with those with assisted digital needs, including individuals lacking digital skills or with limited access to digital technology. Some unhappy paths and barriers to accessing the digital service have been considered and explored through research
- support channels and their suitability have been explored through research.
What the team needs to explore
Before their next assessment, the team needs to:
- consider conducting more research into how patients, as third parties interact with the service. For example, those that are with a reporter while the reporter completes the digital notification report.
- explore unhappy paths in more detail, such as managing a report that has been given the wrong information, what happens when a reporter bulk reports many cases at the end of the day and any other potential issues that could transpire through to the processors. The team did acknowledge this and that it is not part of their primary user journey though they would consider it. If they did this would further support the whole service delivery blueprint and support knowledge transfer for future teams
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 online journey is efficient and timely with effective use of GDS patterns and components
- the team have mapped out the full end to end service delivery, including the offline route into a working blueprint to scope the list of activities and roles that support the new digital service
- the team had made excellent use of UCD collaboration tools and have substantial evidence of many workshops that have informed how they had reached this stage in the service design. This will support any knowledge transfers within team changes
What the team needs to explore
Before their next assessment, the team needs to:
- continue research with those wider user groups and unhappy paths and barriers that these such individuals may face, as in point 1 and 3
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 online journey is efficient, timely and well thought out with clear evidence of an iterative process informed by research
- the team had unmistakable evidence of a respectable number of iterative user flows informed by research
- the team really considered the behaviour of HTP’s reporting and how this would fit into their day, the save and resume ability in the application reflected their good understanding of their primary user
What the team needs to explore
Before their next assessment, the team needs to:
- carry out research with wider user groups such as ESL and those over the age of 60 to reflect a true understanding that everyone who needs to use this service can, as detailed in point 1. No user groups should be excluded
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 risk of operating with a contract UCD team has been acknowledged and an in-house team has been sourced and is due to be onboarded imminently
What the team needs to explore
Before their next assessment, the team needs to:
- ensure that there is a smooth handover and knowledge transfer between the contract UCD team and the incoming internal team
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 are working in the open with regular department wide show and tells
- the team are using show and tells to find ways to collaborate with other teams
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:
- multiple examples were presented to demonstrate how user research has had a direct and tangible impact on the service design – for example, the save and resume function and the development of the disease selection page
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 technical solution to protect user data is sound, data will be encrypted at rest and in transit
- access to application is granted through Microsoft EntraID thus enabling SSO for NHS workforce and hence reducing data leak risk
- access to data is limited to the individual who completed and submitted the form, thus reduces the risk of data leak
- the team has guardrails in place to identify need for penetration testing as part of the application development and release process
- the solution adheres to UK GDPR regulation
What the team needs to explore
Before their next assessment, the team needs to:
- find a way to limit access to the application based on appropriate roles who have the authority to record and report infectious diseases. There is currently a potential for over 1 million NHS workers to record and report infectious diseases
- the team should put in place a process to inform and advise impacted individuals in the unlikely event of patient personal data expose
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 has taken a research-led approach to baselining their metrics and KPIs
- the team are using all data to make continuous improvements to the service
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:
- UKHSA have an internal technical review board and technical design authority who have reviewed and validated the design including from FinOps perspective to ensure efficient use of cloud services
- the team has aligned their technology principles to GOV UK technology principle
- the team is using OpenShift, Azure Postgres, Python amongst others and, have a history of working with these technologies
- the team is thinking ahead and have plans to move away from tactical use of “Azure Postgres” to “Cloud Native PG” to improve the solution from security, reliability and cost perspective
- the team is adhering to cloud first and reuse principle
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:
- the team have made commitment to make code open and, code will be published in GITHUB before public Beta
- the team have licensed the code under the MIT Licence, as per CDDO (Central Digital and Data Office) guidelines
What the team needs to explore
Before their next assessment, the team needs to:
- publish all the documents supporting the open code alongside the code in the GITHUB. The document should include the business functions served by the code step by step instructions to help 3rd parties wanting to (re)use the code
- undertake risk analysis of making infrastructure, network configuration and client frontend repo’s public. Where possible make these repos public
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 team are using micro-framework pattern to web-frontend and backend API development
- the backend APIs should enable reusability of data
- the team have developed Python automation testing with the Behave framework that could re-used across multiple applications
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 entire design is scalable and will support spikes in usage
- the team has ensured that the entire infrastructure can be deployed from ground up in less than 15 minutes in the event of DR
- the team have considered the critical nature of the service and have included load balancer, server and database replica to ensure small recovery point objective (RPO) that will be reduced to zero when Postgres Azure is replaced with OpenShift Cloud Native PG
What the team needs to explore
Before their next assessment, the team needs to:
- explore on how to minimise impact on CMS (downstream system) in the event of a large spike in usage. This is pertinent given the fact that
- the team have planned a Big Bang approach for public beta
- over a million users could potentially submit requests once the service is in public beta
Leave a comment