Removing names is only the start. This guide sets out 12 things to check before you share or reuse health data, from identifiers hidden in documents to re-identification risk, across PDPA, HIPAA and GDPR contexts.
Health data becomes far more useful when it can be shared and reused: for research, for service improvement, for training and evaluating AI, and for working with partners. Almost all of that reuse depends on one step being done well, which is protecting the identity of the people the data describes.
That step is harder than it appears, and the consequences of getting it wrong fall first on patients, who shared their information in trust. This guide sets out twelve things to check. It is written for the people who carry this responsibility in practice: data and analytics leads, privacy and compliance officers, researchers and digital health teams.
This guide offers general information to help you ask good questions. It is not legal advice. Data protection law differs between countries and changes over time, and the terms used in this guide have specific legal meanings that vary by jurisdiction. Please take advice from a qualified adviser on how the law applies to your situation.
Three terms are often used as though they meant the same thing. They do not, and the difference has legal consequences.
Moving to the right reduces the risk to individuals and usually reduces the usefulness of the data as well, because detail and the ability to follow a patient over time are gradually lost. The purpose of the twelve checks is to help you choose the right point on this line for your purpose, and then to confirm that you have really reached it.
The right level of protection depends on what the data is for and who will receive it. Data used by your own analysts inside a controlled environment is in a different position from data sent to a research partner, shared with a technology vendor or published openly. Write down the purpose, the recipient, the fields that are truly needed and the period for which the data will be held. Sending less is the most effective protection available, and a clear statement of purpose is what your ethics and privacy reviewers will ask for first.
Samples, pilots and proofs of concept deserve the same care as a full release. They are often prepared quickly and treated as informal, and that is how identifiable information most commonly leaves an organisation.
Identify every jurisdiction involved: where the patients are, where your organisation is established, where the data will be processed and where the recipient is located. Each may have its own law, such as Singapore's PDPA, Indonesia's Personal Data Protection Law, Thailand's PDPA, GDPR in Europe or HIPAA in the United States, and they define their terms differently. Some also set conditions on health data leaving the country. Agree with your legal adviser which standard you are aiming to meet and how you will demonstrate that you met it. "We removed the names" is not a standard.
If you may need to return to the original patient, for example to add follow-up data, to honour a withdrawal of consent or to act on a clinically important finding, you need pseudonymisation, with a key held securely and separately from the data. If you will never need to link back, a stronger approach may be open to you. This decision shapes everything that follows, including how the law treats the data, so it is best made deliberately at the start. Decide who holds the key, who may use it and under what circumstances. The recipient of the data should not be the holder of the key.
This is the familiar part: names, national identity numbers, medical record numbers, addresses, telephone numbers, email addresses, account numbers and similar fields. HIPAA's list of identifiers is a useful reference even if that law does not apply to you, because it prompts you to think about items that are easy to forget, such as device serial numbers, vehicle registrations and full-face photographs. Check every table and every column, including those that look administrative, because identifiers often appear in fields where they do not belong, such as a comments column.
This is where most de-identification efforts fall short. A laboratory report, a referral letter or a scan carries identifiers in its header and footer, in barcodes and QR codes, in stamps and signatures, in handwritten notes and in the body of the text ("seen with her daughter Mei Ling, who works at the bank next door"). Files carry identifiers in their names and in their metadata, and photographs may record a location. Check that your approach covers all of these, in every language and script that your documents use, and for the identity number formats of each country you work in. A method that performs well on English text may miss a great deal in Bahasa Indonesia, Thai or Chinese.
A person can often be identified without any name or number, through a combination of details that each seem harmless. Exact dates of birth, admission or testing, a postcode or the name of a small clinic, an unusual occupation, a rare diagnosis or an extreme laboratory value can, taken together, point to one individual. The risk is greatest for small populations and rare conditions. Identify which indirect identifiers your data contains and decide how each will be treated, for example by reducing the precision of dates and locations or by grouping ages. Laboratory data requires particular thought, because a long and exact series of dated results can be distinctive in its own right.
Patient records mention people other than the patient: the referring doctor, the reporting pathologist, nurses, family members and emergency contacts. They have rights to privacy as well, and the name of a clinician together with the name of a clinic can also help to identify the patient. Decide how third parties will be treated, and check that your approach finds them.
No method finds every identifier, whether it is a person, a set of rules or an AI model. The responsible question is how many are missed. Take a sample of your own documents, have the identifiers in it marked by people who know what to look for, and measure what proportion your process finds, separately for each type of identifier and each language. In this work a missed identifier matters far more than an unnecessary removal, so that is the figure to watch. Any tool or script provided by another party should be validated in the same way, on your own data, before it is relied upon, and a sample of real output should continue to be reviewed by a person. Performance reported on someone else's documents tells you little about yours.
Whether data can be linked back to a person depends on the data and also on who receives it, what other information they hold or could obtain, what skills and motives they have and what controls are in place. The same dataset may be low risk inside a secure research environment under contract, and high risk when posted on the internet. A common test is to ask whether a reasonably motivated person, using means reasonably available to them, could identify someone. Carry out this assessment, write it down and have it reviewed. For large or sensitive releases, an independent expert review is worth considering, and under some legal routes it is required.
Protection that destroys the value of the data has not solved the problem. If every date is removed, a trend can no longer be analysed. If every patient receives a new random code in each file, their records can no longer be connected. There are established ways to retain usefulness while reducing risk, and the right choice depends on your purpose. Once de-identification is complete, check that the analysis you planned still works and that key results are consistent with the original data. Record what was changed, so that those who use the data understand its limits.
De-identification has to begin with identified data, so whatever performs it, whether a team, a tool or a service, sees the data in its most sensitive form. This is easily overlooked. Ask where that processing takes place and whether it satisfies any requirement for data to remain in the country. Ask whether identified documents are sent to a third-party AI model, and under what terms. Ask who has access, how long the identified copy is kept, and how its deletion is confirmed. Responsibility for de-identification remains with the organisation that holds the data, even when another party's tools are used, so the organisation should stay in control of how and where the process is run.
Technical measures reduce risk and do not remove it, so the remainder has to be managed through agreements and controls. A data sharing agreement should prohibit any attempt to re-identify individuals, restrict onward sharing, limit use to the stated purpose, require security measures, allow for audit and set out what happens if identifiable information is discovered. Access should be limited to named people, and the pseudonymisation key should be held separately under its own controls.
The assessment also needs to be revisited over time. Risk changes as new data is added, as other datasets become publicly available and as tools for linking data improve. Set a date for review, and agree in advance what you will do if something is found to have been missed, including whom you would notify.
JondaX is the health data transformation engine from Jonda Health. It turns clinical documents and data, including laboratory reports received as PDFs, scans and images, into structured and standardised data, and it de-identifies documents as part of that processing. For teams preparing health data for reuse, this means that the step where most efforts fall short, the identifiers inside documents (check 5), is handled within the same pipeline that structures the results, across the languages JondaX supports, with clinical review and quality assurance by Jonda Health's own team.
We would like to be precise about what this does and does not mean. De-identification carried out by JondaX is one input to your own assessment, and it is not a legal conclusion. We do not describe the output of JondaX as anonymised, because whether data meets that standard depends on the full context described in this guide: the purpose, the recipient, the other information available and the controls in place. Those judgements rest with the organisation responsible for the data and its advisers. Our role is to carry out the technical step carefully, to be open about how we work so that you can assess it, and to support the measurement described in check 8 on your own documents.
Jonda Health is ISO 27001 certified, and JondaX is designed to comply with HIPAA, GDPR and PDPA. We expect to be asked every question in check 11, and we are glad to go through them with you.
If you are preparing health data for research, for AI or for work with a partner and would like to talk through your approach, get in touch at hello@jonda.health.
De-identification is a broad term for removing or transforming identifiers. Pseudonymisation replaces identifiers with a code while a separately held key allows records to be linked back to the person. Anonymisation means individuals cannot reasonably be identified by anyone. The legal consequences differ between jurisdictions, so it is important to use the terms precisely.
Under GDPR, yes. Pseudonymised data remains personal data, because it can be linked back to a person using the key, and the law continues to apply. Other jurisdictions take their own positions, so check with a legal adviser.
Usually not. Identifiers also appear inside documents, images, file names and free text, and a combination of indirect details such as exact dates, a small location and a rare condition can identify a person without any name.
HIPAA recognises two routes: removing a defined list of identifiers with no actual knowledge that the remaining information could identify the person, or obtaining a determination from a qualified expert that the risk of re-identification is very small. HIPAA is a United States law, and other jurisdictions apply different tests.
Yes, and it can be effective, particularly for identifiers inside documents and free text. Its performance should be measured on your own documents, for each language and each type of identifier, with continuing human review. It is also important to check where the identified documents are processed and whether they are sent to any third-party model.
Yes. Technical measures reduce risk and do not remove it. An agreement that prohibits re-identification, limits the use of the data and restricts onward sharing is part of what makes a release responsible, and it is often part of what regulators expect.
JondaX from Jonda Health de-identifies clinical documents, including laboratory reports received as PDFs, scans and images, as part of turning them into structured data. Whether the result meets a particular legal standard depends on your context, and remains an assessment for the organisation responsible for the data and its advisers.
Suhina Singh is the founder and CEO of Jonda Health, a Singapore-based health data infrastructure company. A physician by training, she works with health systems across Asia-Pacific to harmonise, de-identify and standardise clinical data so it can be trusted and used. Jonda Health is ISO 27001 certified.
