Healthcare Data Privacy Lab
Healthcare systems should remove what external tools do not need.
I built a small offline anonymisation prototype for clinical notes because sensitive health data should not move into AI tools, SaaS products, or shared workflows by default. Later, I found OpenMed and started contributing to the larger open source ecosystem.
The dangerous moment happens before the upload
The dangerous moment is not only when a model gives an answer.
The dangerous moment is earlier, when someone copies sensitive health text into an external tool without knowing where it goes, who can access it, whether it is logged, whether it can be deleted, or whether the system needed that data in the first place.
That tool might be an AI product. It might also be a normal SaaS platform, ticketing system, transcription app, analytics dashboard, intake form, or file converter.
Names are obvious. Dates are not. Locations are not. IDs are not. A clinical note can expose a person even after the name is removed.
A small local prototype with a larger question
I first built a local macOS prototype around NLM Scrubber so a user could drag and drop health notes and remove protected health information before using the text elsewhere.
It was not a medical product and not a compliance guarantee. It was a proof of principle: sensitive text should be cleaned locally before it goes anywhere else.
health-data-anonymiser is the first public artifact in this track. The larger idea crosses borders and languages: health forms, identifiers, dates, and legal expectations differ across Europe, the United States, Belgium, Spain, Morocco, and other contexts. The public repo is not a global compliance engine. It is the first local artifact for the data minimisation principle.
The mature move was to contribute
After building the prototype, I found OpenMed: a broader open source healthcare project working on local first clinical text processing, PII detection, deidentification, and medical entity extraction.
The mature move was not to pretend my prototype was the whole answer. The mature move was to contribute to the project already going deeper.
I do not own OpenMed and I did not build it. OpenMed is a larger open source project maintained by its own community. My role is a small contributor to specific privacy and reliability work.
This is not a story about owning the biggest project. It is a story about noticing the right problem early, building a first artifact, then joining the stronger ecosystem when I found it.
Boring edge cases that matter
My OpenMed work is a small part of a larger community effort. I am not listing every contribution here because the point is not a scoreboard. The point is the kind of work privacy systems need:
- Date handling.
- Format preservation.
- Deterministic behavior.
- CI coverage.
- Privacy edge cases.
In healthcare privacy, small date bugs are not small. A date can identify a person, corrupt a timeline, or make deidentified text misleading.
No real patient data
The question is what reaches the system
Healthcare data is entering a phase heavy with new regulation.
The important question is not only which model or SaaS product is used. The important question is what data reaches the system, what is removed first, what stays local, what is logged, and what can be audited later.
This matters because health data can be used for more than care: profiling, insurance risk assessment, employment screening, public sector eligibility, fraud checks, advertising, data brokerage, social engineering, and identity theft all become easier when too much sensitive context moves around without traceability.
My interest is the layer before compliance theater: data minimisation, deidentification, local processing, human review, and evidence.
- The EU AI Act uses a risk based framework, including high risk categories where systems can affect health, safety, or fundamental rights.
- Colorado SB26-189 now frames automated decision making technology around consequential decisions, including health care services, with developer and deployer documentation duties starting January 1, 2027.
- California's DROP system shows the data broker direction: residents can submit deletion requests and data brokers must begin processing them from August 1, 2026.
- The FTC mobile health app tool treats health app privacy and security as a business obligation, not a design afterthought.
From artifact to collaboration
This project track proves 4 things:
- I can identify privacy risks in clinical text workflows.
- I can build small local tools that demonstrate the principle.
- I can contribute to larger open source healthcare infrastructure.
- I can translate technical privacy issues into governance, product, and operational questions.
Where the honesty line sits
- This is not a medical product, a diagnosis tool, or medical advice.
- It is not a compliance guarantee and does not claim HIPAA compliance.
- Deidentification reduces risk. It does not eliminate every reidentification risk.
- OpenMed is not my project. My contribution is small, specific, and part of a larger community effort.
- Real clinical data still needs privacy review, legal review, and human output review before use.
Before an external system sees the text
If your team is experimenting with healthcare AI or any health data SaaS workflow, start with the data boundary.
What is removed?
What stays local?
What reaches the external system?
Who reviews the output?
What evidence proves the system behaved responsibly?