UKHSA Complete UK Pre-entry Health Screening Beta reassessment

From: DHSC
Assessment date: 04/12/2025
Amber review date: 30/04/2026
Stage: Beta reassessment
Result: Green at reassessment
Service provider: UKHSA

Service description

The 'Complete UK pre-entry health screening' service provides a secure, digitised platform for overseas clinic staff (administrators, panel physicians and radiologists) to record data required for a pulmonary tuberculosis screening of visa applicants from high-incidence countries. It clarifies expectations set by the UK Tuberculosis Technical Instructions (UKTBTIs), streamlines reporting to UKHSA, improves data quality and timeliness, enhances fraud detection and supports national TB prevent efforts.

Over 300 international clinics across 6 continents participate in this programme. This enables UKHSA to deliver on its "prepare" strategy: identifying future health threats and building tools to protect against them.

Service users

Primary users – directly interact with the service :

Overseas clinic staff who need to record TB UK pre-entry health screenings on behalf of UK visa applicants:  

• Clinic administrative staff  
• Clinic panel physicians  
• Clinic radiologists   

Secondary users – indirectly or occasionally use the service  

Additional clinic staff who have supportive roles that facilitate the TB UK pre-entry health screening:  

• Radiographers   
• Lab technicians
• IT administrator     

The Heathrow Health Control Unit has backstage roles that minimise risk of UK TB cases rising and supporting service users:  

• Level 1 support agent   

Report contents

1. Understand users and their needs
2. Solve a whole problem for users
3. Provide a joined-up experience across all channels
4. Make the service simple to use
5. Make sure everyone can use the service
6. Have a multidisciplinary team
7. Use agile ways of working
8. Iterate and improve frequently
9. Create a secure service which protects users’ privacy
10. Define what success looks like and publish performance data
11. Choose the right tools and technology
12. Make new source code open
13. Use and contribute to open standards, common components and patterns
14. Operate a reliable service

1. Understand users and their needs

Decision

The service was rated green for point 1 of the Standard. 

Optional advice to help the service team continually improve the service: 

• Conduct more user research (beyond existing survey research) with visa applicants, to better understand their needs when interacting with the service. This is particularly important for any proposed future work concerning digital certification 

• More user research with clinic radiologists (particularly from the beta clinic sites) to understand their experience of the service and user needs, to ensure these are well understood and met 

2. Solve a whole problem for users 

Decision

The service was rated amber for point 2 of the Standard.

This is amber because:  

• The service relies on offline process’ to operate, for example users are expected to use the UK Tuberculosis Technical Instructions to understand next steps, pass work to other members of the team or see screenings in progress by using email or other systems. This could further add to the problem around inconsistency in following instructions or add delays into the system 

Reassessment:

The service was rated green for point 2 of the Standard

3. Provide a joined-up experience across all channels

Decision

The service was rated green for point 3 of the Standard.

4. Make the service simple to use

Decision

The service was rated amber for point 4 of the Standard.

This is amber because:  

• The service currently asks the same set of questions for every journey, meaning users are asked about things that are irrelevant 

• Check input fields do not have relevant labels. For example, on the ‘Enter applicant information’ screen, it asks for multiple things but it is not clear (especially if using a screen reader) what issue or expiry date or address it is asking for. Use the guidance for ‘Asking multiple questions on a page’ 

• The service uses the select component which is a ‘last resort’ pattern, consider if this could be iterated especially for short lists, like visa category 

• Of the poor data quality: the team should investigate opportunities to solve the problem around for poor data quality, for example when a user mishears or mistypes data incorrectly. One example of this could be using an address lookup for UK address 

Reassessment:

Decision 

The service was rated green for point 4 of the Standard. 

5. Make sure everyone can use the service

Decision

The service was rated amber for point 5 of the Standard.

This is amber because:  

• The service relies on JavaScript being enabled which can exclude some users,  use guidance on ‘Building a robust frontend using progressive enhancement’ 

• It is not clear if the ‘page loading’ pattern is accessible. The service should maximise speed of response 

• The service team have not been able to test with assistive technology users from other countries, they have completed testing with proxy users in the UK (using software designed for UK use) to address this, however it is not clear if assistive technology in other countries would work with the service 

• The service team rely on a third party to complete manual accessibility testing; it would be beneficial to bring accessibility skills in house as part of the whole team's responsibility. Read more about accessibility testing in the Service Manual 

• The service is currently partially compliant with issues listed in the accessibility statement, the panel recognise the service team have plans to resolve the issues 

Reassessment:

The service was rated green for point 5 of the Standard. 

6. Have a multidisciplinary team

Decision

The service was rated green for point 6 of the Standard.

Optional advice to help the service team continually improve the service: 

• With funding being a factor, the service team should emphasise the importance of the full multidisciplinary team being available, going into Public Beta 

7. Use agile ways of working

Decision

The service was rated green for point 7 of the Standard.

8. Iterate and improve frequently

Decision

The service was rated amber for point 8 of the Standard. 

This is amber because: 

• The team has successfully demonstrated iterative design based on user feedback however, they have not sufficiently demonstrated the impact of said iterations with quantitative data, which could surface any errors. This needs to be demonstrated by next assessment.

Reassessment:

The service was rated green for point 8 of the Standard. 

9. Create a secure service which protects users’ privacy 

Decision

The service was rated green for point 9 of the Standard.

10. Define what success looks like and publish performance data 

Decision

The service was rated amber for point 10 of the Standard.

This is amber because:  

• There is no performance analysis expertise in the team to lead on the development of a performance framework, to advise on GA4 tracking and to measure and monitor performance of the service 

• There is a lack of developed ways of working with data, whereby data fields and GA4 tracking are considered as part of the development process, success measures are built into the design hypotheses of iterations and quantitative data is used to inform decision-making 

Reassessment:

The service was rated green for point 10 of the Standard. 

Optional advice to help the service team continually improve the service: 

• Develop a performance framework document, outlining the objectives and user needs of the service as well as the KPIs that align to those 

• Conduct statistical tests on quantitative data to ensure any increases or decreases aren’t due to external factors

11. Choose the right tools and technology 

Decision

The service was rated green for point 11 of the Standard. 

Optional advice to help the service team continually improve the service: 

• A notable achievement is the robust implementation of the event-based architecture and the successful addressing of crucial concerns like lost and duplicate messages. However, given that this is a very low-volume service, we propose a review of the current architectural complexity: 

1. Potential simplification: For lower operational costs and simpler maintenance, the design could be simplified by replacing the real-time event stream with overnight or minimum batch processing at an appropriate cadence
2. Alternative data transfer: Instead of a complex event queue, clinics could potentially push completed forms using a simpler, secure mechanism, such as an SSH/SFTP connection 
3. API option: Team should also explore whether a standard, lightweight API endpoint could achieve the same reliable data ingestion with less operational overhead than the current event-based model  

• This discussion is intended to ensure the architecture is scaled to the actual service volume, balancing technical needs with long-term simplicity and cost-effectiveness 

12. Make new source code open

Decision

The service was rated green for point 12 of the Standard.

Optional advice to help the service team continually improve the service: 

• To further enhance collaboration and facilitate future deployment we propose expanding this commitment to include the Infrastructure-as-Code (IaC) used to provision the service 

• This approach should be manageable. While the team must obviously exclude sensitive files (like environment variables, API secrets, and encryption keys), the core IaC files (such as Terraform) that describe the structure and configuration of the servers, databases, and networking components can be released under the open license. This provides immense value to the community without exposing any security-critical information  

• For the open-sourced code and IaC to be usable by other teams developing similar services, we must ensure they are accompanied by robust and user-centric documentation. This documentation should include: 

• A high-level architecture overview: A clear explanation of how the service components fit together (application code, database, networking, and IaC) 

• A comprehensive 'How-To' guide: This guide should include a clear, step-by-step pathway for a new user to successfully deploy and run the service locally or in a sandbox environment. The documentation should provide concrete examples that demonstrate common use cases, such as: 
  - how to spin up a minimal version of this service in AWS using the provided Terraform 
  - how to integrate a new backend API into the existing architecture. 
  - how to run the unit and integration tests locally 

• The team will truly maximise the benefit of their open approach, significantly lowering the barrier to entry for collaboration and reuse 

13. Use and contribute to open standards, common components and patterns 

Decision

The service was rated green for point 13 of the Standard.

14. Operate a reliable service 

Decision

The service was rated green for point 14 of the Standard. 

Next Steps 

This service can now move into a public beta phase, subject to addressing the amber points within three months time and GDS spend approval. 

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