I did not start with a healthcare AI strategy.
I started with a discomfort.
People are going to paste clinical notes, lab results, doctor summaries, patient stories, form exports, insurance letters, and screenshots into tools because the tools are useful.
Some of those tools use AI.
Some are ordinary SaaS.
Some are dashboards, ticketing systems, analytics products, transcription apps, note apps, CRMs, intake forms, or file converters.
That part is already decided.
The question is what happens before the upload.
What gets removed?
What stays local?
What reaches the service?
Who stores it?
Who can resell it?
Who can match it with something else later?
Who can prove what happened?
The first version was small
The public repo was small.
A local tool. A clinical note. A basic question: can I remove sensitive health information before the text leaves the machine?
It was not a company.
It was not a medical product.
It was not a compliance guarantee.
It was a refusal to accept the default behavior: copy the raw text, paste it into a cloud system, and hope the privacy policy is enough.
I do not like reducing it to a technical shell around another tool.
Technically, it used NLM Scrubber.
But the point was not the software plumbing.
The point was the question behind it.
Could a normal person clean a health note locally before sending the useful part somewhere else?
Could the system start with less data, not more?
The bigger idea behind the repo
The repo was the first public artifact of a larger idea.
Health data does not look the same everywhere.
The forms are different.
The identifiers are different.
The dates are different.
The languages are different.
The legal context is different.
I was born in Belgium. I have Moroccan roots. I have lived in Spain for years. I communicate a lot with people and projects connected to the United States.
So the question did not feel abstract.
Belgium, Morocco, Spain, the European Union, the United States.
Different forms.
Different assumptions.
Different privacy language.
Different legal pressure.
The impossible version would be a global anonymiser for 200 countries.
That is not what I built.
The useful version was smaller: start with the most relevant contexts, learn from existing tools, adapt the thinking to real identifiers and real workflows, and keep the processing local where possible.
That is the story behind the prototype.
Not a finished global compliance engine.
A first artifact for a harder question.
Why this is not paranoia
The problem is not that every company is secretly selling your hospital note.
That is too easy to say and too weak to defend.
The problem is that data moves.
It is logged.
It is retained.
It is copied into backups.
It is used for product improvement.
It is shared with processors.
It is combined with browsing, location, purchase, device, and account data.
It is sometimes sold.
It is sometimes breached.
It is sometimes inferred from data that did not look medical at first.
The FTC has warned that health information is broader than treatments and diagnoses: location, browsing, and purchase data can also reveal health information.
That matters because a person is not only exposed by the thing they typed into a medical form.
A person is exposed by the connections.
A pharmacy purchase.
A clinic visit.
A pregnancy search.
An allergy.
A medication.
A workplace absence.
A support ticket.
A photo.
A video.
A calendar event.
One data point may look harmless.
The pattern is not harmless.
What can be used against you
Health data can become leverage.
Not always.
Not automatically.
But enough that the default should be restraint.
An allergy is not just a medical fact.
In the wrong hands, it is a vulnerability.
A medication can reveal a condition.
A condition can affect how someone judges your reliability, your risk, your ability to work, your insurance profile, or your credibility.
A location trail can reveal which clinic someone visited.
A pregnancy-related purchase can reveal something before the person has told anyone.
A mental health note can become a stigma point.
A genetic or chronic condition can become a profiling signal.
A dataset that reaches a criminal market can help with impersonation, phishing, loan fraud, account takeover, or social engineering.
This is not a movie plot.
It is the practical consequence of giving away too much context because a service was convenient.
The service may be useful.
The convenience may be real.
The report may be good.
The workflow may save time.
That still does not mean the raw data needed to leave.
The insurance, work, and public sector angles
The future risk is not only advertising.
It is scoring.
Insurance scoring.
Employment screening.
Public sector eligibility.
Fraud checks.
Background checks.
Credit and lending decisions.
Border and immigration questions.
Dispute evidence.
Legal credibility.
When enough data is available, systems can cross-check the story you tell against the story your data tells.
That can be useful when it catches fraud.
It can also be unfair when the data is incomplete, old, inferred, biased, bought from a broker, or taken out of context.
The person being judged may never see the full profile.
They may never know which data point mattered.
They may never know which company held it.
That is why health data minimisation is not just a technical preference.
It is a power question.
What the prototype exposed
Anonymisation is not just removing a name.
A clinical note can identify a person through dates, rare events, locations, timelines, family details, phone numbers, IDs, or combinations of details that look harmless on their own.
Remove the name and leave the admission date, the discharge date, the hospital, and the phone number, and the note may still point back to a person.
Remove too much, and the note may stop being useful.
Change a date badly, and the clinical timeline can become misleading.
That is where the work gets serious.
Not dramatic.
Serious.
The boring edge cases are the privacy system.
Why dates matter
Dates look small until you treat them as evidence.
A birth date can identify someone.
A surgery date can identify someone.
An admission and discharge interval can matter clinically.
If a system shifts dates by 0 days, privacy has not improved.
If it changes `03/15/22` into a different format without warning, the text shape has changed.
If it preserves the year in one place and shifts the month in another, an interval can become nonsense across a year boundary.
These are not glamorous problems.
They are exactly the kind of problems that decide whether a privacy layer can be trusted.
Finding OpenMed
After building the prototype, I found OpenMed.
OpenMed is a larger open source healthcare project working on local first clinical text processing, PII detection, de-identification, and medical entity extraction.
It was working on the same privacy problem at a deeper scale.
The immature move would have been to pretend my small prototype was the whole answer.
The mature move was to contribute to the project already going deeper.
So I did.
I did not build OpenMed.
I do not own OpenMed.
I contributed a small part to privacy and reliability around de-identification.
Other contributors have done more.
That matters.
This is not a bragging story.
It is a collaboration story.
I built a small standalone prototype first. Then I found a larger open source project working on the same problem and started contributing where the work could matter more.
Why I am not listing every contribution here
The public trail exists.
GitHub can show it.
But the lesson is not "look at my pull requests."
The lesson is that healthcare privacy work becomes real in boring details: dates, formats, reproducibility, tests, defaults, and review.
That is the part I care about.
Not owning the biggest project.
Not pretending the first prototype solved everything.
Joining the stronger ecosystem when I found it.
Regulation is moving toward the same question
The legal direction is not identical across regions, but the pressure is easy to see.
In Europe, GDPR Article 9 treats data concerning health as special category data.
The EU AI Act uses a risk based framework, including high risk categories where systems can affect health, safety, or fundamental rights.
The United States does not have one federal GDPR equivalent for all health-adjacent data.
That is part of the problem.
Some protections exist in specific contexts.
Some pressure is coming through state laws, enforcement, and sector rules.
Colorado SB26-189 frames automated decision-making technology around consequential decisions, including health-care services, with developer and deployer 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 and FTC health information guidance both point to the same practical question: what health information is collected, how it is used, who receives it, how long it is kept, and whether the consent was meaningful.
None of this means a demo is compliant because it removes a few identifiers.
That is exactly the trap.
Compliance is not a sticker you put on a prototype.
The useful layer is before compliance theater: collect less, remove more, keep processing local where possible, review outputs manually, and preserve evidence of what happened.
The missing layer
There is a missing layer in most data sharing.
Traceability.
Not just a privacy policy.
Not just a checkbox.
A way to know where sensitive data traveled, who touched it, what was removed, what was retained, and what downstream use was allowed.
Call it a ledger, a receipt, an audit trail, a contract, or something smarter.
The name matters less than the function.
Right now, most people do not have that.
They upload.
They trust.
They forget.
The data does not forget.
That is a separate article.
But it is the reason this small prototype mattered to me.
What teams should do next
The practical next steps are not dramatic.
They are boring.
That is why they matter.
Do not paste raw clinical text into tools by default.
Do not upload health forms, lab results, or screenshots into SaaS tools unless the data flow is understood.
Remove identifiers first.
Treat dates as sensitive.
Treat allergies, medications, pregnancy status, mental health notes, genetic data, and rare conditions as high-risk context.
Keep local processing where possible.
Use synthetic examples for testing.
Review outputs manually.
Keep logs of what was removed and what was sent.
Ask where the data is stored.
Ask who the processors are.
Ask whether the data can be deleted.
Ask whether it is used for training, analytics, profiling, or product improvement.
Do not claim compliance without legal and privacy review.
If the system cannot answer those questions, the problem is not the prompt.
The problem is the workflow.
What I learned
What I learned is simple: healthcare privacy is not a button you press at the end. It is a boundary you design before sensitive data ever reaches a system that does not need it.
The practical next steps are boring, which is why they matter.
Do not paste raw clinical text by default.
Remove identifiers first.
Treat dates as sensitive.
Use synthetic examples for testing.
Keep processing local when possible.
Review outputs manually.
Log what was removed and what was sent.
Do not claim compliance because a demo worked once.
Better healthcare technology does not start with a better prompt.
It starts with less unnecessary data crossing the boundary.