Data is building up in your FHIR server. What’s next?
The business weighs in: “We have all this rich patient data. What can we use it for?”
Analytical dashboards, AI ingestion, academic and business research.
To use healthcare data for these purposes in a compliant and legal way often involves de-identifying or anonymizing FHIR resources so that the patient or person referenced cannot be identified.
There are two common approaches taken to this. The easy way and the right way.
The easy way is to blacklist and exclude specific elements that are known to contain data that can be used to identify a patient. Obvious examples are:
- Patient name
- Address
- Date of birth
- Identifiers
- Text narratives
In a perfectly controlled system, where all data is as expected and comes from 100% controlled sources, this might work.
The problem is you leave yourself exposed when unexpected data arrives in unexpected elements.
- Extensions that can contain anything
- String fields with free text
- Resource reference display strings
A new data source or a UI change after the project goes live can introduce data that identifies the patient.
Blacklisting elements is unsafe and cannot be relied on.
You need to stop thinking about what to remove and start thinking about what to keep.
The right way is whitelisting – where you select the elements and attributes that will form part of your de-identified resource.
You explicitly say what you want to keep. Examples might be:
- Observation.value (excluding attachments)
- Condition.severity (system + code)
- MedicationRequest.medication
You take only the elements that provide value, with no way to connect them back to an individual patient. Everything else is left behind.
Define what’s allowed instead of what’s not allowed.
Otherwise you run the risk of exposing your organization to legal issues down the road.
---
Download my “FHIR Architecture Decisions” book
FHIR Weekly
Join 1,100+ business and technical leaders.