NHS BSA: Residency Checker for EHIC/GHIC/PRC
A process to support confirmation of UK residency for entitlement to healthcare in an European Economic Area (EEA) country or Switzerland.
Tier 1 Information
1 - Name
Residency Checker for EHIC/GHIC/PRC
2 - Description
A UK European Health Insurance Card (EHIC) or UK Global Health Insurance Card (GHIC) allows UK residents to get state healthcare in the European Economic Area (EEA) and some other countries, that cannot reasonably wait until their return to the UK. A Provisional Replacement Certificate (PRC) gives the same level of cover where an applicant has applied for a UK GHIC/UK EHIC and it has not yet arrived. (https://www.nhsbsa.nhs.uk/get-healthcare-cover-travelling-abroad/where-you-can-use-your-card#:~:text=both%20a%20UK%20GHIC%20and,in%20Iceland%2C%20Liechtenstein%2C%20or%20Norway)) The purpose of the residency check is to support confirmation that applicants are ordinarily and legally resident in the UK.
3 - Website URL
N/A
4 - Contact email
Tier 2 - Owner and Responsibility
1.1 - Organisation or department
NHS Business Services Authority
1.2 - Team
Overseas Healthcare Services (OHS)
1.3 - Senior responsible owner
Head of Operational Services
1.4 - External supplier involvement
Yes
1.4.1 - External supplier
The external supplier will not be disclosed due to FOIA (2000) Section 31a - risk that disclosure could harm efforts to prevent or detect fraud.
1.4.2 - Companies House Number
The external supplier will not be disclosed due to FOIA (2000) Section 31a - risk that disclosure could harm efforts to prevent or detect fraud.
1.4.3 - External supplier role
The external supplier undertakes checks to indicate UK residency, which are accessed via an API.
1.4.4 - Procurement procedure type
Call off from a framework.
1.4.5 - Data access terms
The supplier is only permitted, for the purposes of providing the residency check service to NHSBSA OHS, to combine NHSBSA OHS personal data or debtor data with personal data or debtor data it holds independently of NHSBSA OHS call-off agreement, or which is derived from a third party for the purposes of NHSBSA OHSs call-off agreement - provided that such processing is carried out in accordance with such instructions as NHSBSA OHS notifies the supplier in writing from time to time. NHSBSA OHS does not authorise the supplier or any other contractor to combine NHSBSA OHS personal data or debtor data with personal data or debtor data it (or they) holds independently NHSBSA OHSs call-off agreement, or which is derived from a third party for any purpose including the provision of services to third parties except as expressly permitted by the previous paragraph. The Supplier must seek the written consent of the Customer before any customer data is stored, processed, handled, or transferred outside of the UK.
Tier 2 - Description and Rationale
2.1 - Detailed description
The purpose of the residency check is to support confirmation that applicants are ordinarily and legally resident in the UK.
Basic customer details including name, D.O.B and address are shared with the third party supplier across an API. The API returns some information that supports confirmation of residency. This information is scored by NHSBSA using a scoring matrix which is automated to indicate a confidence level for UK residency. A pass means that residency can be confirmed, a fail means that the application system with automatically generate an email to the customer to request them to provide evidence of residency. The email contains a detailed description of the types of evidence that can be submitted and includes a link, which the customer can click on to upload images of the evidence required directly to their record on the application system.
2.2 - Scope
The automated tool is used for all EHIC, GHIC and PRC applications to help ensure that only UK residents receive entitlement. There are no similar schemes that these services could be confused with. Once the automated tool has been used during the application process for a particular customer, it would not be used again in other parts of the process. It is possible in some circumstances where a complaint occurs, a further residency check may be undertaken, however this is not automated and would be carried out by a human using a web portal provided by the third party supplier, with an end decision taken by a human.
2.3 - Benefit
To ensure tax money is spent on those that have an entitlement to receive the benefit and this tool helps ensure this entitlement is only provided to eligible UK residents. This ensure that any costs incurred are as legitimate as possible.
2.4 - Previous process
There was no prior process for GHIC. For EHIC the application system only checked that the post code the customer declared for their address was a UK address and issued the card if it was. PRC was previously administered by the DWP and was transferred to NHSBSA in 2018, the automated residency check was implemented for PRC following the transfer to NHSBSA.
2.5 - Alternatives considered
The service receives on average 5-6 million applications each year and it would not be feasible to employ manual checks. The third party residency check is subject to public sector commercial reprocurement guidelines. Alternative forms of data sources have been considered and is an ongoing exercise. Other data has been investigated and discounted due to the risks involved, in particular that much of the data investigated is not sufficiently recent to determine a customer’s current residency status. We are currently investigating using NHS Personal Demographic Service data to either replace the third party supplier or to introduce as a secondary check.
Tier 2 - Decision making Process
3.1 - Process integration
The residency check is built into the customer application process for an EHIC, GHIC or PRC as the basis of entitlement is UK residency for most applicants. Customer enters their personal details and name, dob and address is shared with the supplier via the API and the information returned is scored to provide a confidence rating of UK residency. If a customer passes the residency check their entitlement is issued automatically. If the customer fails the residency check they receive an email asking them to submit documentary evidence to help support their application. Customers are advised what documentary evidence is acceptable as part of the email.
3.2 - Provided information
As the system is automated, no information is required to be provided either to the customer or a user in the event that they pass the check. If the customer fails the check they receive an automated email after they have completed their application advising that they have failed the check and are required to provide some evidence of their residency to support their application, they do not receive any information regarding why they failed the check, however in the event that the customer wishes to query this they can contact the 3rd party provider themselves directly to request that information. NHSBSA do not contact the third party provider to request information on why a customer has failed the residency check. The automated email provides a list of acceptable documentary evidence, and a link so that customers can upload images of their documents directly to the application system which is then linked directly to their record. If a manual check is performed by a decision maker the check will only present a pass or fail rating. When staff perform a manual check after entering the customers details they are presented with two charts, the first chart provides indicators of confidence of residency and non-residency, the second chart is a matrix which has 9 ratings within it. The ratings are categorised as ‘strong’, ‘some’ and ‘none’ with a result of either ‘pass’ or ‘fail’ against them which provides a confidence level to indicate the probability that the customer lives as the address they have declared in their application - this information is used to make a decision on whether to proceed with the application or to ask the customer to provide supporting documentary evidence.
3.3 - Frequency and scale of usage
Volumes vary from year to year which is primarily driven by fluctuations in EHIC and GHIC application volumes which follow a ‘renewal cycle’ as the cards are valid for 5 years, after which they are required to be renewed. For planning purposes anticipated volumes are based on the ‘renewal cycle’ which was significantly disrupted by the travel restrictions enforced during the coronavirus pandemic which has resulted in annual peaks and troughs. In general however, we can expect to conduct 4-5 million checks annually.
3.4 - Human decisions and review
The customer enters their personal details and name, dob and address, it is then shared with the supplier via an API, the information returned is then scored to provide a confidence rating of UK residency. If a customer fails the automated check for a EHIC, GHIC or PRC they are asked to submit documentary evidence to support their application from a pre-defined list of acceptable documents. If the customer is able to submit acceptable evidence their entitlement will be issued. If the customer does not have the required documents they will not be issued the entitlement. Occasionally where the process has resulted in a complaint, a user may conduct a manual residency check using a portal provided by the 3rd party supplier. If the customer passes the check the user will progress the application, if they fail the check the user will revert to the document submission process.
3.5 - Required training
Users are not trained on the automated residency check process as this is built into the application journey, however users are trained on how to conduct a manual residency check using the 3rd party supplier portal. This includes how to use the portal and also security training to prevent data breaches and inappropriate use.
3.6 - Appeals and review
If a customer fails the residency check they are asked to provide documentary evidence of residency to support their application. If they are unable or unwilling to complete the process this way they are able to enter a complaints process, however if residency cannot be proved in any way or a customer refuses to cooperate they will not be issued the entitlement. https://www.nhsbsa.nhs.uk/sites/default/files/2020-03/Overseas-Healthcare-Services-Complaint-Policy-v1.pdf
Tier 2 - Tool Specification
4.1.1 - System architecture
Residency Check within OHS is an API call to a 3rd party supplier.
Within OHS, we have a jumpbox server acting as a proxy between our systems and the Internet where the API call takes place.
When the 3rd party supplier provides an indicator of residency for an applicant at the address provided in their application, a decision is made to determine if the applicant is a UK resident. If they are, then an OHS entitlement is issued. If not, further evidence is requested from the applicant to demonstrate residency in the UK. With these values indicating residency and non-residency at the address provided, they are applied to a PASS/FAIL matrix in combination to decide if the value applied will allow automated issuing of the entitlement or if further evidence is required.
4.1.2 - Phase
Production
4.1.3 - Maintenance
OHS deliver updates as an when required to the jumpbox container and calling services.
The 3rd party supplier provide all maintenance activity on their API
The credential used to generate a Bearer token from the 3rd party supplier’s API is renewed monthly via a change record process.
4.1.4 - Models
There is one model within this tool
1 - Programmatic access which is detailed in this section, where we integrate the API into the service and perform actions based on the response. This is also integrated into our own UI elements where the result of a residency check is displayed.
Tier 2 - Model Specification
4.2.1 - Model name
OHS Residency Check Service
4.2.2 - Model version
v1.0
4.2.3 - Model task
Programmatic access to the 3rd party supplier’s API
4.2.4 - Model input
Applicant’s First Name, Last Name, 1st Line of Address and Postcode
4.2.5 - Model output
An indicator for residency at the provided address and an indicator of non-residency at the provided address, where non-residency indicates the applicant may live at another address in the UK. The indicators provided are either STRONG, SOME or NONE and one of each is provided for residency and non-residency. With these values indicating residency and non-residency at the address provided, they are applied to a PASS/FAIL matrix in combination to decide if the value applied will allow automated issuing of the entitlement or if further evidence is required.
4.2.6 - Model architecture
Within OHS, we have a jumpbox server acting as a proxy between our systems and the Internet where the API call takes place.
When the 3rd party supplier provides an indicator of residency for an applicant at the address provided in their application, a decision is made to determine if the applicant is a UK resident by way of a matrix. If they are, then an OHS entitlement is issued. If not, further evidence is requested from the applicant to demonstrate residency in the UK.
4.2.7 - Model performance
API responds within 5 seconds at most with consistent outliers being reported to the third party supplier.
Accuracy of the responses is expected to accept roughly 93% of all applications. If this percentage drops below 85% then manual reviews of the decision matrix takes place to see if it was a system error or genuine rejections and the third-party supplier is involved where appropriate.
All testing of accuracy of the residency indicators take place against the User Acceptance Testing environment with the supplied test pack that provides an indicator on the expected responses. Any discrepancy between these is reported to the third party supplier. No testing takes place in the production environment as this will require use of PII for testing purposes.
4.2.8 - Datasets
Test Data via a User Acceptance Testing (UAT) Test Pack has been provided by the 3rd party supplier to allow OHS to Test the API in a non-production API endpoint. No live data has been used in the development of the model in OHS.
568 non-live individuals at non-live addresses are detailed in the UAT test pack.
4.2.9 - Dataset purposes
The UAT dataset was used to test the integration fo the API into the OHS service and the residency check indicators are being picked up and acted on correctly.
Tier 2 - Data Specification
4.3.1 - Source data name
GHIC, EHIC and PRC application data. 3rd party data to check residency.
4.3.2 - Data modality
Text
4.3.3 - Data description
Full name, address, date of birth, National Insurance number for applicants and family members. This is the full data captured by NHSBSA. The supplier matches the name, dob and address supplied by NHSBSA to find the customer in their records, following which they provide a confidence rating of residency at the declared address. The supplier does not share their data with NHSBSA that is used to create the confidence rating.
4.3.4 - Data quantities
Test Data via a UAT Test Pack has been provided by the 3rd party supplier to allow OHS to Test the API in a non-production API endpoint. No live data has been used in the development of the model in OHS. 568 non-live individuals at non-live bad addresses are detailed in the UAT test pack.
4.3.5 - Sensitive attributes
Full name, address, date of birth, for applicants and family members.
4.3.6 - Data completeness and representativeness
Application validation ensures that the details are 100% complete.
4.3.7 - Source data URL
N/A
4.3.8 - Data collection
Data is collected via the online application process in the majority of cases, however an assisted digital route is available for customers as an alternative option. The data is collected for the purpose of validating customers entitlement to EHICs, GHICs and PRCs, and subsequent issuing of the entitlement documents.
4.3.9 - Data cleaning
N/A
4.3.10 - Data sharing agreements
The data sharing agreement is in place with the third party supplier.
4.3.11 - Data access and storage
NHSBSA stores customer data for EHIC,GHIC and PRC applicants and the data is accessible to the operational teams and support Digital, Data and Technology Teams who must have access approved by the NHSBSA Service Desk and from a controlled list of authorised users:
- Customer information provided by the customer for the purposes of receiving an EHIC is stored until the 30th of June 2171 if the customer applies for an UK EHIC and has EU Settled Status. This extensive retention period is required in order to determine eligibility of future applicants for the UK EHIC who have derived rights from the current generation of applicants who are covered under the Withdrawal Agreement between the United Kingdom and the European Union. This retention period was agreed in consultation with DHSC.
- Customer data is stored for 48 months after the expiry of the customers UK EHIC if they do not have EU Settled Status.
- Customer data is stored for 48 months after the expiry of the customers GHIC.
- Customer data for PRC applicants is retained for 7 years from the date that the PRC was processed, and 7 years from the date that payment is made or a claim for treatment costs is closed. The supplier is not permitted to retain any customer data shared via the API.
Tier 2 - Risks, Mitigations and Impact Assessments
5.1 - Impact assessment
Data Privacy Impact Assessment has been completed - most recent version at time of writing is Version 9 - completed on 12/3/2024. DPIAs are kept under regular review and are updated as necessary. High Level Summary: We process overseas reciprocal healthcare applications by UK residents working, studying, or retired in the European Economic Area and Switzerland. Claims are processed for emergency treatment where the UK resident does not hold a UK GHIC and UK EHIC. Recommendations and conclusion: Risks have been identified and are being actively managed by the information asset owner. Privacy notices are regularly reviewed and are update as necessary, the latest version can be found at https://www.nhsbsa.nhs.uk/our-policies/privacy/overseas-healthcare-services-privacy-notice
5.2 - Risks and mitigations
There is a risk that the residency check results may not in all cases be 100% accurate. Alternative options to either replace the third party supplier or add an additional check utilising alternative datasets to improve accuracy have previously been investigated however have not proved fruitful to date, however we continue to actively explore further options to improve the accuracy of the residency check. Residency check failures are mitigated by the document request procedure.