9 Questions for Pseudonymising Health Data and Keeping It in Country Across Multi-Country Medical Programmes
Registries, patient support programmes and real-world evidence projects often span several countries, each with its own expectations about where health data may go. Pseudonymising at the right point and processing in country where required lets programmes move forward without putting patients or partners at risk.
Suhina Singh
Founder & CEO, Jonda Health
October 15, 2026
·
11 min read
The guide at a glance
Three steps, nine questions. Step 1 shows you the data, step 2 reduces what is identifiable, and step 3 decides what stays where.
How to use this guide
Use it at the design stage of a new multi-country programme, or to review one that is already running.
Work through it with your privacy lead, the programme owner, and someone who knows how data is captured in each country.
Answer each question per country where the answer differs; the tips and pitfalls will show you where differences usually hide.
Use the table at the end to check the whole design before data starts to flow.
This guide is practical, not legal advice. Requirements for health data, cross-border transfer and in-country processing vary by country and change over time, so confirm the current position with legal and privacy colleagues in each market.
Few medical programmes in Asia stay within one country. A registry recruits across several markets, a patient support programme runs in five affiliates, a real-world evidence study combines data from hospitals in different health systems. Each country has its own data protection law, its own expectations about health data, and sometimes its own requirement that certain data be stored or processed locally. Institutions often add conditions of their own.
Two practices do most of the work in making such programmes possible. Pseudonymisation reduces how identifiable the data is before it moves or is analysed. In-country processing keeps identifiable data, and the work done on it, where local rules and partners expect it to be. Designed well from the start, together they let a regional programme produce combined insight without identifiable patient data crossing borders it should not cross.
Most multi-country programmes work with pseudonymised data. Knowing where you sit on this spectrum shapes every other decision.
Step 1
Map the data
Who to involveProgramme owner, privacy lead, country programme teams
What you will have at the endA minimum data list and a data flow per country
1. What personal data does each part of the programme actually need?
Different parts of a programme need very different data. A nurse calling a patient needs contact details; an analyst studying outcomes does not. A regional dashboard needs aggregated figures, not individual records. Listing the minimum data each role and step genuinely needs is the foundation for everything else, because data that is never collected or never shared needs no protection downstream.
TipFor every data field, ask "who needs this, and for what decision?" Fields without a clear answer are candidates to drop or keep local.
Common pitfallCollecting everything available "in case it is useful later", which multiplies privacy risk across every country.
Ask your teamFor each role and step in the programme, what is the minimum personal data needed, and why?
2. Where is data created, stored, processed and accessed, in each country?
Trace the full journey of the data for each country: where it is first captured (a clinic, a call centre, an app, a laboratory), where it is stored, which systems and vendors process it, and who can see it, including regional and global teams. Many programmes discover that data already crosses borders in ways nobody designed, for example through a cloud service hosted elsewhere or a support team in another country.
TipDraw the flow as a simple map, one lane per country. Arrows that cross a border are where your attention belongs.
Common pitfallOverlooking remote access: a record viewed by a team in another country can count as a transfer, even if the data is stored locally.
Ask your teamFor each country, where is data captured, stored, processed and viewed, and which of those steps cross a border?
You are ready for step 2 when you have a minimum data list for each role and a data flow map for each country.
Step 2
Pseudonymise at the right point
Who to involvePrivacy, data and IT teams, clinical reviewers, local data custodians
What you will have at the endA pseudonymisation design and a documented risk assessment
3. Are we pseudonymising as close to the source as possible?
The earlier identifiers are replaced, the fewer people, systems and vendors ever handle identifiable data. Ideally, pseudonymisation happens at or near the point of capture, within the country and under the control of the organisation that holds the original records. Everything downstream, from analysis to regional reporting, then works with pseudonymised data by default.
TipMark the point of pseudonymisation on your data flow map. Everything to its right should never need identifiable data.
Common pitfallSending identifiable data to a central team or vendor "to be pseudonymised there", which moves the most sensitive data the furthest.
Ask your teamWhere exactly does pseudonymisation happen in each country, and who handles identifiable data before that point?
4. Who holds the key, and where?
Pseudonymised data can be linked back to a person by whoever holds the key that connects codes to identities. That key is what keeps pseudonymised data useful, for example to update records or follow patients over time, and also what keeps it sensitive. It should be held separately from the data, by a clearly named custodian, usually in the country where the data originated, with strict rules on who may use it and when.
TipKeep the key with the local data custodian, such as the site or the in-country programme partner, rather than with the team analysing the data.
Common pitfallStoring the key in the same system as the pseudonymised data, which makes the separation meaningless.
Ask your teamWho holds the key in each country, is it stored separately from the data, and who is allowed to use it?
5. Have we covered free text and documents, not only structured fields?
Removing names and identity numbers from structured fields is the easy part. Identifiers also hide in clinical notes, referral letters, discharge summaries, scanned documents, report headers, file names and image metadata. In multi-language programmes they appear in several scripts and naming conventions. A pseudonymisation approach that ignores unstructured content leaves identifiable information in the dataset without anyone intending it.
Direct identifiers hide in unstructured content. Indirect identifiers can identify people in combination.
TipTest your approach on real documents from each country and language, including scans and handwritten content, and have a person review a sample of the output.
Common pitfallPseudonymising the database but attaching the original documents, with names and identity numbers intact, to the same record.
Ask your teamHow are identifiers removed from notes, documents, images and metadata, in every language the programme uses?
6. Have we tested re-identification risk, including when data is combined?
Even without names, a record can sometimes point to one person: a rare condition in a small town, an exact date of birth with a specific procedure, or a very small group in a report. Risk also changes when datasets from different countries or sources are combined. Assess re-identification risk before data is shared or combined, and apply measures such as generalising dates and ages, grouping small locations, and suppressing very small counts in outputs.
TipAgree a minimum group size for any reported figure across the programme, so small cells are handled consistently in every country.
Common pitfallAssessing risk for each country's data separately, then combining the datasets without assessing the risk again.
Ask your teamWho assessed re-identification risk, and does that assessment cover combined data and every output we publish or share?
You are ready for step 3 when the point of pseudonymisation, key custody, handling of unstructured content and re-identification risk are all documented.
Step 3
Keep processing in country where required
Who to involveLegal and privacy per country, IT, vendors, local partners
What you will have at the endA processing design that respects each country's requirements
7. What must stay in country, and what can move?
For each country, agree what must remain local and what may be shared across borders, and on what basis. A common pattern is that identifiable data and the key stay in country, pseudonymised record-level data moves only where the law and agreements allow it, and aggregated results are shared regionally. The answer can differ by country, by institution and by type of data, so it is worth recording explicitly.
Identifiable data stays local. What moves is less identifiable, and only where the rules allow.
TipAsk whether the regional question can be answered with aggregated results alone. If it can, record-level data may not need to move at all.
Common pitfallDesigning around the least restrictive country, then finding that a stricter market cannot join the programme without a rebuild.
Ask your teamFor each country, what must stay local, what may move, and on what legal basis and agreement?
8. Can processing actually run in each country?
Deciding that data should stay in country is only useful if the work can be done there. Check whether your systems and vendors can be deployed in each country or an approved local environment, whether any clinical review or quality checking can be carried out by people based locally, and whether support teams elsewhere would need access to identifiable data. In-country processing often depends on vendor flexibility more than on technology.
TipAsk vendors to describe, in writing, exactly where their processing, storage, support and human review take place for each country.
Common pitfallA vendor stores data locally but sends it elsewhere for processing, review or support, which undoes the in-country design.
Ask your teamCan every step that touches identifiable data, including human review and support, run within each country where required?
9. Is the design documented, agreed and kept up to date?
A sound design needs to be written down and agreed: the data flows, the point of pseudonymisation, key custody, risk assessments, what stays in country, and the legal basis for any transfer. These records support approvals from ethics committees and institutions, help answer questions from partners and regulators, and make it easier to add a country later. Because laws and programmes change, the design should be reviewed regularly.
TipKeep one living document per programme, with a section for each country, and review it whenever a country, vendor or data type is added.
Common pitfallDocumentation written for the initial approval and never updated as the programme grows.
Ask your teamIs our data design documented per country, agreed with partners, and reviewed when the programme or the rules change?
Your design is ready when each country's requirements are met, processing can run where it needs to, and the whole approach is documented and agreed.
Check your design
Use this table before data starts to flow, and again whenever you add a country or a vendor.
Question
In good shape
Needs attention
1. Minimum data
Each field justified by role and purpose
Everything collected in case it is useful
2. Data flows
Mapped per country, including remote access
Border crossings unknown
3. Point of pseudonymisation
At or near source, in country
Identifiable data sent centrally first
4. Key custody
Held separately by a local custodian
Key stored with the data
5. Unstructured content
Notes, scans and metadata covered in all languages
Only structured fields handled
6. Re-identification risk
Assessed, including combined data and outputs
Names removed and nothing more
7. What stays where
Agreed per country with a legal basis
Designed around the least strict country
8. In-country processing
Every step, including review, can run locally
Vendor processes or reviews elsewhere
9. Documentation
Living, per country, reviewed on change
Written once for approval
How Jonda Health can help
Handling health data across countries, formats and languages is central to what our team does every day. You do not need to have every answer before talking to us. There are two ways we can support your programme.
Jonda Health Services
Design the data flow before data flows
Through our Health Data Foundations and Data Sourcing work, we help medical affairs and evidence teams map minimum data and data flows by country, decide where pseudonymisation should happen and who holds the key, and design programmes that respect in-country requirements from the start.
JondaX
Pseudonymise and structure data in country
JondaX turns clinical records in PDFs, scans, images and mixed formats across more than 10 languages into structured, standardised information through a single API, with de-identification available. It can be deployed and processed fully within a client's country, and we can support in-country clinical review where required. JondaX is ISO 27001 certified and designed to comply with HIPAA, GDPR and PDPA.
Book a free 30-minute data readiness conversation
Bring the countries in your programme and the data you need, and we will talk through where pseudonymisation should happen and what needs to stay in country.
