NHSBSA Overseas Healthcare Cost Recovery Beta Reassessment

From: DHSC
Assessment date: 07/09/2023
Reassessment date: 25/04/2025
Stage: Beta reassessment
Result: Met at reassessment
Service provider: NHSBSA

Service description 

The Cost Recovery Service is responsible for supporting Overseas Visitors Managers (OVM) at hospital Trusts across the UK to report patient, entitlement and the treatment costs incurred by EU citizens when temporarily in the UK, to the NHSBSA. As the ‘competent authority’ in the UK, the NHSBSA is then responsible for claiming back those costs from each respective Member State country, based on EU Regulations. 

Service users 

This service is for:  

• Overseas Visitor Managers – employed by hospitals across the UK to ensure that the relevant details of EU overseas visitors are captured when they receive treatment at their hospital. They are then responsible for ensuring that these details are reported to the NHSBSA.  

• Cost Recovery Officers and Liaison Officers at the NHSBSA – administer information and support OVMs to report treatment costs.  

• Internal Claims Officers at the NHSBSA – schedule, collate and generate treatment cost claims to be sent to each Member State country for payment, and deal with any subsequent contestations.     

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 did not meet point 1 of the Standard. 

What the team has done well 

The panel was impressed that: 

• the team created user personas and profiles of users with varying Trusts settings to better understand their high-level user needs and pains 

• the team has carefully considered how to address potential biases in user research methodology for BSA users, given their smaller population size 

• the team has adopted a wide range of user research methodologies, including co-creation workshop and collaboration with team members 

What the team needs to explore 

Before their reassessment, the team needs to:  

• conduct accessibility testing with users, including users who use assisted tools or are neuro divergent. The service team may consider conducting accessibility testing with individuals who may not be direct service users but have accessibility or have neuro-diverse needs. This can be achieved by providing them with relevant scenarios and the persona background of typical service users during the accessibility testing sessions 

The panel acknowledged the team’s dedication to improve accessibility aspects of the service, despite challenges in recruiting users with accessibility needs. To address recruitment challenges, the panel recommends sourcing participants from existing survey or research, reaching out to accessibility and neurodiverse networks, external charity networks, or using external recruiters. The panel recommends refining the research invitation text to make it clearer to participants how their involvement can enhance the accessibility of the service, as well as highlighting how their personal information will be kept confidential to increase confidence and boost the response rate for research participation 

• collaborate as a service team to ensure that the entire service is accessible to users with diverse abilities, without limitations imposed by third-party application 

• conduct user research to understand the user needs around the transition from the legacy system to the new system – this will help shape the onboarding strategy and improve understanding of the end-to-end journey of the new service   

• conduct user research to gain insights into offline journeys to understand user needs and assessing the impact when the service is unavailable 

• continue to conduct user research throughout Private Beta phases with the closed group of Trusts, including moderated usability testing for both the OVM Portal and Ops System (in additional to relying on feedback from User Acceptance Testing).  This ensures that the service continue to meet user needs in the real environment before its Public Beta release  

• conduct user research to understand the end-to-end journey of the service. While previous development cycle included separate user research efforts with distinct focuses, it is crucial to conduct user research for the end-to-end journey of this service, which comprises of multiple sub-journeys and spans across two portals. This will help ensure that the service aligns with the overall user needs and expectations 

• conduct user research to assess the service’s compatibility with various devices and browsers 

Before their next assessment, the team needs to: 

• work with someone like a performance analyst to define metrics and identify problems that require further research    

Reassessment

Decision 

The service met point 1 of the Standard. 

What the team has done well 

The panel was impressed that: 

• the team has adopted a wide range of user research methodologies, including contextual enquiry and accessibility testing 

• the team has conducted accessibility testing with proxy users, including users who have learning difficulties, are neurodivergent, have English as a second language. 

• the team has conducted user research to understand the user needs around the transition from the legacy system to the new system 

• the team has done usability testing and used survey results to assess the service’s compatibility with various devices and browsers   

What the team needs to explore 

Before their next assessment, the team needs to: 

• keep collaborating with users to make sure a smooth onboarding experience for everyone on the new system.  Currently, the multi-factor authentication process may be an obstacle for some people, such as those with no access to work mobile phones 

• work together as a service team to make sure that the entire service is accessible to users with a wide range of abilities, without restrictions caused by third-party applications 

• continue to find and test with genuine users with access needs 

• understand how front-line staff capturing patient information impacts the data quality and the subsequent patient journey. More research in collaboration with relevant teams can help to highlight pain points and improve the service 

• continue to work with a performance analyst to collaboratively define key metrics for the service. This will help the team identify specific areas where further research is needed 

• put in place a regular review of the different feedback to gain a more complete understanding of user needs. This will help prioritise insights effectively and ensure a continuous cycle of improvement. Currently it is not clear how the different sources of insights are brought together systematically 

2. Solve a whole problem for users 

Decision 

The service did not meet point 2 of the Standard. 

What the team has done well 

The panel was impressed that: 

• the service team considered and ruled out a smaller minimum viable product (MVP), as it would have only solved half the problem outlined in the project aim  

• the service team is engaged with parts of the process that it does not own or control through external forums and internal networks, and can feedback to these parts if there are problems or recommended changes  

• the team has balanced the user needs of the OVMs, Liaison Officers and BSA staff, with the business needs of ultimately recovering money to the UK in a more efficient way, as demonstrated through their key performance indicators (KPIs) and design focus        

What the team needs to explore 

Before their reassessment, the team needs to: 

• research the beginning of the journey in a private beta pilot to ensure that entering data works for users in real scenarios. The user research survey shared showed that 36% of people used pen and paper to record claims information, but it was not clear how much manual input method was assessed during usability testing. The team needs to ensure that the service works well for users regardless of how they are inputting the claims data 

Before their next assessment, the team needs to: 

• demonstrate, using performance data and continued user research, that the service delivers a more efficient cost recovery while meeting users' needs       

Reassessment

Decision 

The service did not meet point 2 of the Standard  

What the team has done well 

The panel was impressed that: 

• the team is aware of the steps that happen in trusts before OVMs use the service 

• the team learned which external systems and processed have direct impact on the success of the CRS and acted upon with adding some features to the service and with sharing insights with NHS England 

• the team had done a survey to capture feedback from users   

What the team needs to explore 

Before their next assessment, the team needs to: 

• consider what they can do to improve the whole journey for users outside of the scope of a like-for-like replacement of the current system 

• examine ways to reduce the amount of manual entry for OVMs and whether bulk or automated uploads are a possibility 

• outline how the scope and capability boundaries of the service are informed by user needs and how users conceive of the whole journey, rather than by existing business or process divisions 

• consider a more reliable and robust research method both quantitative and qualitative to understand how users navigate the service from end-to-end to capture in-depth findings 

• have a better knowledge and understanding of the patients' needs; what’s their role and experience in the ecosystem 

  Reassessment

  • This service was subsequently reassessed offline and the service standard point was met on 04/03/2025

3. Provide a joined-up experience across all channels     

Decision 

The service did not meet point 3 of the Standard. 

What the team has done well 

The panel was impressed that: 

• the team showed plenty of examples of physical touchpoints users will access throughout their journey – for example the EHIC cards, emails and other data formats. This demonstrated a good understanding of the context in which users are operating in  

What the team needs to explore 

Before their reassessment, the team needs to: 

• create a service blueprint that shows the journey of a claim, including touchpoints with other systems such as DHExchange and RINA, as well as the printed and postal journey. On this blueprint, it would be helpful to show which systems are in the control of the BSA or this service team, and which are out of scope but form part of the journey 

• consider if the number of different channels used could be reduced, for example if the information in DHExchange could be held within the service  

Before their next assessment, the team needs to: 

• test users’ understanding of sending a claim to RINA versus printing a claim, and update the current content design on this page if your research shows that this could be clearer. The panel found it confusing to have options for ‘print’ and ‘download’ as it is not clear which to click to submit the claim to RINA 

• test users’ understanding of the systems used or what happens next when they hit submit or print, for example in a private beta survey, one participant has responded to a question about MedBens with ‘what is MedBens?’. Ensure that content is iterated if this testing shows that anything is unclear 

Reassessment

Decision 

The service met point 3 of the Standard.   

What the team has done well 

The panel was impressed that: 

• the team has examples of touchpoints throughout their journey such as EHIC cards and emails. This demonstrated a good understanding of the context users work in 

• the team has created a service blueprint that shows the journey of a claim, including touchpoints with other systems included in the printed and postal journey    

What the team needs to explore 

Before their next assessment, the team needs to: 

• test that users can identify when a claim needs to be posted and that they understand and can be confident that this process has been completed 

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 panel was pleased to hear that deviations from standard design patterns have clear rationales which have informed the design. For example, we discussed how the interface questions have been sequenced to match the sequencing of data on physical artifacts users will be rekeying information from, such as the EHIC card  

• the panel was pleased to hear the analysis that has taken place regarding understanding the failures of the legacy system. The panel appreciated that the legacy system cannot provide full reporting data to support this analysis so were pleased to learn that the team had conducted more manual analysis to understand the quick wins a new system could provide, such as the areas of data validation to reduce the number of contestations  

What the team needs to explore 

Before their next assessment, the team needs to: 

• ensure content is iterated to meet the standard and meet user needs. For example, in the resubmission demo users will see the content "from s3 bucket the next day". This is technical language which is unsuitable for this audience, and this occurs at multiple points within the service. Title case is also often incorrectly utilised. The team do not have a full-time content designer. The service is significant in scope and the language being used is highly technical. If this content is not carefully designed this service will not achieve its intended purpose. The team acknowledge involvement of content design has sometimes come too late and retrospective improvements would have significant impacts on delivery. The team must increase the level of support they have from a content designer to ensure this does not continue going forward   

• clearly demonstrate specific examples of insights from user research that have influenced a design change. While the service team’s slides contained considerable statistics into the breakdown of users they spoke with, the team are advised to clearly structure slides to show:  
  
  • 1) what design was tested  
  • 2) quotes from participants which articulate an identified usability challenge  
  • 3) the design iterations that took place to address this challenge  
  • 4) the rational for the solution they went with  
  • 5) results from testing this new solution    

5. Make sure everyone can use the service     

Decision 

The service did not meet point 5 of the Standard. 

What the team has done well 

The panel was impressed that: 

• the panel appreciated that the service is designed for users with preforming highly specialised tasks and for this reason the use of subject matter specific language on the whole had a clear rationale  

What the team needs to explore 

Before their reassessment, the team needs to: 

• conduct research with users with access needs and ensure the service has a DAC audit before bringing the service to the reassessment 

• collect and present at reassessment data which demonstrates the new system has had a tangible impact on reducing the number of contestations and be able to tell a clear story as to how their design decisions have created that change. The team have conducted an unorthodox private beta phase. Currently the service has not been tested with live data in an unmoderated setting. Therefore, currently the service team lack evidence to fully support and validate the service they have designed  

• explore if 30 minutes is sufficient for users when using the service in a formal private beta phase, using the production environment to process real claims with a closed user group. As the service has not been through a formal private beta phase, the team do not have any insight into if this is sufficient for users to complete the task. The team are strongly advised to monitor this metric specifically in the beta phase, as this could inform the prioritisation of some technical alterations the team have in their backlog to make this more usable   

Reassessment

Decision 

The service met point 5 of the Standard. 

What the team has done well 

The panel was impressed that: 

• the team managed to overcome the difficult challenge of recruiting participants with access needs by engaging with third party recruitment agencies, accessibility and neurodiverse networks and charities  
• the team conducted both remote and in-person research with users with learning difficulties and physical disabilities and made some changes based on findings 
• the team has done an accessibility evaluation of the service using automated tools to capture issues to resolve 
• the team has engaged with an external agency to get the DAC report and fixed major issues   

What the team needs to explore 

Before their next assessment, the team needs to: 

• focus on making sure that the service meets WCAG 2.2     
• continue research with non-native English speakers and with users with dyslexia and ADHD who might find overwhelming and difficult navigating and understanding the content of the service 
• engage with the design community to understand if other teams have worked on a similar project to learn from 

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 good knowledge management in place, including recorded walkthroughs, design history in Confluence and guides for new team members 

• discipline and project leads attend wider meetings with the OHS space to keep up with changes where there is overlap that might affect this service, for example keeping up to date with changes in RINA and adding additional meetings where needed  

• the team is making use of existing BSA teams in their public beta phase by drawing on the BSA Support team for post-production support  

What the team needs to explore 

Before their next assessment, the team needs to: 

• get more content design support and involve the content designer earlier on it the process. In the session, it was outlined that the content designer is shared with another team and only reviews the content after user testing. The panel feels the service would benefit from a full-time content designer who is involved in the design research process, so that content is proactively iterated rather than reactively fixed 

• include DHSC policy team members in the testing of the service    

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 using the scrum framework with daily standups, and sprint planning, retros and sprint reviews with stakeholders for every sprint cycle     

What the team needs to explore 

Before their next assessment, the team needs to: 

• ensure that all parts of the team contribute to prioritisation meetings   

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 team had plenty of examples of changes based on feedback from user testing, for example the team has paused work on the messaging function when it emerged that there was little user need  

• the team could clearly articulate the process of spotting something to be improved, adding it to the backlog and prioritising it    

What the team needs to explore 

Before their next assessment, the team needs to: 

• ensure that performance data from the service is shared with the whole team to spot opportunities for improvement     

9. Create a secure service which protects users’ privacy 

Decision 

The service did not meet point 9 of the Standard. 

What the team has done well 

The panel was impressed that: 

• the team has taken system users such, as OVM, Lead, Claims & Laison Officers security into consideration with permission levels and Multifactor Authentication (MFA) 

• the team have deployed AWS security profile to include WAF and Shield etc to ensure threats such as OWASP, DDoS and rate limitation are contained 

• the team have deployed Git Leaks, SonaQube for static code analysis and pipeline security 

What the team needs to explore 

Before their reassessment, the team needs to: 

• complete a full threat analysis for application, infrastructure and database layers 

• since the solution infrastructure is an Infrastructure as Code (IaC) deployment, there should be a security perimeter to ensure that vulnerabilities are picked up prior to deployment. To implement the default GitLab vulnerability scans, the GitLab runner with docker or Kubernetes executor should be deployed 

• ensure technical clarity and implement IaC code security using industry standard tool and patterns 

• ensure IT Health Check (ITHC) medium vulnerabilities (JavaScript libraries with known vulnerabilities and the API allowing unauthenticated and unauthorised access) are remediated and show evidence of this at reassessment 

• ensure there is a stable codebase for the application, infrastructure and database for a full ITHC and threat modelling. This is not currently the case as there are technical debt codebase with secrets at the present time 

• enable AWS container scan to ensure all container images are scanned prior to deployment to Registry   

Reassessment

Decision 

The service did not meet point 9 of the Standard. 

What the team has done well 

The panel was impressed that: 

• The team has performed full treat analysis using STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of service, Elevation of Privileged)  threat model.      

• the team has employed GitLab tools to ensure code is secure and free of vulnerability before deployment. The tool would block deployment if any vulnerability are discovered  

• the team has remediated all previously identified ITHC vulnerabilities 

• the team has ensured that the codebase is stable, and all current secrets, certificates and keys are all in AWS secrets manager and key management service respectively   

What the team needs to explore 

Before their next assessment, the team needs to: 

• consider alternate design to ensure patient’s sensitive data is protected. The design allows OVM to download data including patient’s personal information such as name, surname, DOB to their local system 

 get 2 medium treats identified to be fixed as a priority 

Reassessment

• This service was subsequently reassessed offline and the service standard point was met on 04/03/2025

10. Define what success looks like and publish performance data 

Decision 

The service did not meet point 10 of the Standard. 

What the team has done well 

The panel was impressed that: 

• the team has carefully considered how to measure parts of the service that they can control, as well as the overall service outcome, for example overall costs recovered and cost per transaction as well as benefits to the OVMs  

What the team needs to explore 

Before their reassessment, the team needs to: 

• ensure the Google Analytics set up is working as expected in the production environment when used in real scenarios in a closed private beta with 10 Trusts 

• start measuring the service against the outlined key performance indicators (KPIs) by calculating the percentage of times the service meets the service level agreements (SLAs) outlined, for example calculate if a new account is created within 3 days 90% of the time 

Before their next assessment, the team needs to:   

• continue to find ways to feed performance data to internal and external teams for awareness and discussion    

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 choice of application, infrastructure and database is reliable and future proof. 

• the infrastructure development is automated as Infrastructure as Code (IaC) 

• there is consideration of automation and the use of continuous integration and continuous deployment (CICD) pipelines 

• there is a good choice of tools for logging and monitoring – for example Cloud watch, Data Dog 

• the technical stack for data migration from Oracle MedBens Database to Postgres is future proof and impacts performance 

• there is good use of Open-Source tools, for example Data Dog and GitLeaks etc 

• there are effective security tools selected and deployed for the solution 

What the team needs to explore 

Before the next assessment, the team needs to: 

• explore tools to obscure personal identifiable information deploying tools such as Data Loss Prevention (DLP) 

• explore tools that scans for IaC vulnerabilities, for example Checkov. 

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 team considered and deployed GitLab to open source the codebase 

What the team needs to explore 

Before their reassessment, the team needs to: 

• ensure the CICD pipeline is fully automated to deploy the full codebase 

• ensure that the codebase does not include secrets, keys, certificate references  

• ensure that the CICD process supports effective update of codebase and release of new features. 

Reassessment

Decision 

The service met point 12 of the Standard. 

What the team has done well 

The panel was impressed that: 

• the team has ensured that both frontline repositories are now open and backend repository will be in open in next 2 to 3 weeks  

• the team has ensured the codebase doesn’t have any secrets key or certificate reference     

• the team has ensured the CICD pipeline is fully automated       

What the team needs to explore 

Before their next assessment, the team needs to: 

•  ensure backend repository is open    

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 has used of open standards, tools and common components, for example CICD pipelines, branching strategy. These are supported by a wider community and lends the opportunity for reuse in other government projects 

• the high-level design (HLD) of the architecture presents the use of patterns and approach that is widely accepted. For example, the high availability architecture pattern for multi-zone provision, database and application fronted by load balancers, private & public subnets. 

What the team needs to explore 

Before the next assessment, the team needs to: 

• explore open standards tools for improved IaC security. 

14. Operate a reliable service 

Decision 

The service did not meet point 14 of the Standard. 

What the team has done well 

The panel was impressed that: 

• the team has considered Disaster Recovery Strategy for implementation. This strategy includes key metrics for monitoring 

• the choice of tools and technology stack can meet the service requirements and future proof. For example, the choice of database (Postgres), reliable architecture in multiple zones, security profile, application build in Java, monitoring profile and analytics 

• the deployment of reliable monitoring and logging tools to include Cloud Watch, Data Dog etc. This provides the opportunity to analyse logs effectively to inform the understanding of the service such as resource usage, latency and alarms 

• there is a clear service management plan in place with escalation outlay and resolution times 

• there is a cadenced for ITHC in the documentation  

What the team needs to explore 

Before their reassessment, the team needs to: 

• ensure a Disaster Recovery exercise is completed, and the metrics reviewed for remediation where required, prior to reassessment 

• ensure a Business Continuity plan is produced and tested before prior to reassessment. This is important irrespective of the criticality of the service 

• ensure the service has a stable codebase, which has been tested for vulnerabilities and bugs, prior to reassessment 

• ensure all Performance test issues are remediated prior to reassessment 

• ensure the DAC Accessibility (WCAG 2.1 minimum AA) and Usability test are completed and remediations actioned prior to reassessment 

• ensure all secrets, certificates and keys are appropriately stored, using the AWS Secrets Manager and AWS Key management Service (KMS) 

• remediation of Acceptance test issues and a review of the test strategy to ensure that changes are easily deployed. 

Before their next assessment, the team needs to: 

• explore if using DHExchange notifications for updates is sufficient and meets user needs for the live service. 

Reassessment

Decision 

The service met point 14 of the Standard. 

What the team has done well 

The panel was impressed that: 

• the team’s CICD process performs container dependency, license and secrets detection using GitLab security tools    

• the team has addressed Performance issues found during testing  

• the team has tested disaster recovery 

• Recovery time objective (RTO) was 2.5 hours is better than planned 4 hours 

• Recovery point objective (RPO) is published as 4 hours, however with 5-minute snapshots, in practice only 5 minutes data would be lost in the event of system failure 

• the team has implemented continuous monitoring of the performance as well as usage cost of the system. 

    

What the team needs to explore 

Before their next assessment, the team needs to: 

• consider testing disaster recovery at regular cadence      

• consider confirming RTO time achieved are acceptable to the users of the system