Changes to the HES Patient Identifier (HESID)

What is happening?

The way that HES identifies individual patients is changing. Currently, each activity record in HES is matched to a unique patient by assigning a HESID. Each HESID applies to one and only one patient and one patient may have several different HESIDs as a result of activity across many years, care providers or care types.

Both the HESID itself and the algorithm which allocates the HESID to each activity record have been improved to enable us to link activity records more effectively.

To coincide with the next major release of data in the new year, the old HESID will be replaced by a new field called the PSEUDO_HESID.

For consistency, all HES data including historic Business Objects universes will be updated with the PSEUDO_HESID. The HESID will no longer be available either as a field in Business Objects or in extracts.

Why are we doing this?

Information governance issues had been raised that the current HESID has become a patient identifiable field. Although it does not contain any directly identifiable details such as sex or date of birth, it was believed that as each customer who requests a HES extract receives the same HESID and as the HESID is not encrypted at the 256 bit level, it is not compliant to NHS standards.

Given that the HESID would need to change to address these concerns, it was decided to improve the methodology used to match patients at the same time. Each customer who requests an extract after the update will receive a unique version of the new PSEUDO_HESID called the EXTRACT_HESID.

Will it affect me?

The change to the HESID does not alter the number of activity records in any way. The primary difference is that now more activity records can be matched to a single patient, the number of individual patients has decreased slightly.

If you mainly query HES using Business Objects to generate aggregate reports, such as simple counts of episodes or admissions, you will be largely unaffected. However, if you have requested counts of patients you will need to re-query the data as the number of patients will have reduced slightly.

If you have requested extracts of patient level information but do not use the HESID to link activity records together for the same patient, or if you look at a single year's worth of information in isolation, you are unlikely to be affected.

If you use patient level information to link patients records together and you locally hold and use historic years? data, you will be affected as the HESID you hold will not be compatible with any new data you may request and you will not be able to link activity for the same patient from your historic data to the new data.

All updated historic data will be made available under the usual terms and conditions. To view the service charter and the extract pack please see the Ordering extracts area of this website.

If you already hold extracts containing HESID and require a refresh containing EXTRACT_HESID, we will hold your original query definition and will be able to provide you with an extract containing an EPIKEY to EXTRACT_HESID mapping. You will be required to provide us with your original extract specification reference number(s) of the extract(s) you wish to update. This reference number (ETxxxx) can be found on the cover letter sent with your data. You will also be required to sign and return an Information Governance declaration form (available to download from the Related documents area) before we can proceed.

Technical summary

The new algorithm utilises an additional step in order to link records for the same patient which may have been missed by the old algorithm. The old algorithm used two passes of the data to link patients together, the new algorithm uses three.

The old two-pass algorithm, which is used to derive the HESID, matched records with exactly the same NHS Number, sex and a partial match on date of birth on the first pass. The second pass links additional records if they have a partial DOB match and an exact match of postcode (HOMEADD), local patient ID (LOPATID) and provider code (PROCODE3). The second pass helps to link additional records together where there are data quality issues, such as missing NHS Number.

The new three-pass algorithm, used to derive PSEUDO_HESID, adds an additional step to the first two which, subject to a number of conditions, looks at an exact match of sex, date of birth and postcode. This extra step helps to link patients who may have attended a number of providers and may have a multitude of provider codes and local patient IDs who would otherwise not be matched in step two.

Further information

A full document detailing the change from HESID to PSEUDO_HESID is available from the 'related documents' section above.

If you have any queries or would like further information, please email your request to [email protected] with 'HESID update' in the subject line.