Clinical AI ships when a nurse signs off
A signed BAA proves a vendor. It does not prove the system was built so a human catches its mistakes.
In short
5 things that decide this
- 01Most guides to HIPAA-compliant AI answer which tools will sign a Business Associate Agreement. That is a procurement question, not an engineering one.
- 02The engineering question is who signs off on what the model says, and whether the system makes that sign-off fast enough to survive daily use.
- 03TrialTriage, built by Hashlogics, ranks oncology clinical trials against NCCN guidelines. A nurse reviews and finalizes every match before it reaches a patient.
- 04The platform tracks 23 audit action types, uses TOTP multi-factor login, and de-identifies patient data with age ranges, ZIP prefixes and pseudo-patient IDs.
- 05Compliance here is a design choice made before the first line of code: build the review step into the workflow, not bolt it on after an incident.
The question buyers ask, and the one that matters
Search 'how do you build HIPAA compliant AI' and most answers read like a vendor checklist. Does the model provider sign a Business Associate Agreement? Will it store training data, and does it log access? Useful, but it answers which tool to buy. It does not answer how to build the system around it.
A signed BAA covers the vendor's handling of data. It says nothing about a model that ranks a treatment wrong, misses a contraindication, or surfaces a trial the patient does not qualify for. That failure is not a data breach. It is a clinical error. The software has to be built so a licensed person catches it before it reaches anyone.
Compliance as an accountability design
Treat the model as a ranking engine, not a decision-maker. It proposes. A named, licensed person disposes. That single rule changes what you build. Add a fast review interface and a record of who approved what and when. Keep identifiable patient data away from the model wherever possible.
- 01De-identification before the model sees anything: age ranges instead of birthdates, ZIP prefixes instead of addresses, pseudo-patient IDs instead of names
- 02A review step in the workflow itself, not a disclaimer bolted on after: the nurse adjusts or confirms each match, and nothing ships without that action
- 03An audit trail that records the action itself, beyond the login: what was ranked, what a human changed, and when
- 04Access control by role, so a patient, a nurse, an insurer and an admin see only what their role needs
How this ran in TrialTriage
TrialTriage matches cancer patients to clinical trials. Oncology nurses used to cross-reference patient records against NCCN guidelines and trial databases by hand. That search ate hours and risked missed enrollment windows. Hashlogics built a platform where nurses enter de-identified patient data, and large language models rank eligible trials against NCCN guidelines and drug data.
The ranking is fast. Sign-off is not automatic. A nurse reviews every ranked list, adjusts it if needed, and finalizes the result before it reaches a patient or an insurer. The platform runs on NestJS and PostgreSQL. Fireworks AI generates the matches. Redis handles insurer batch jobs, so a whole file of eligibility checks processes without a nurse waiting on each one alone.
It launched HIPAA-aligned rather than retrofitted. Session-based auth used TOTP multi-factor login. Protected health information carried field-level encryption. An audit trail tracked 23 action types from the first release. That trail turns 'a nurse reviewed it' into something a compliance officer can check.
What to check before you build
Before scoping a clinical AI system, get clear answers on four points. Who is the named, licensed person who signs off on each output, and is that step built into the workflow or left to trust? What identifiable data reaches the model, and can it be stripped first? Does the log capture what a human overrode, or only when someone logged in? And can a compliance review reconstruct, months later, exactly who approved a specific result and why?
A BAA answers a vendor question. These four answer whether the system is safe to run. Build the review step in from the start. The audit trail follows naturally, instead of becoming a separate project once a regulator asks for one.
Questions this raises
01How do you build HIPAA compliant AI?
Start with what data the model sees, beyond which vendor you pick. De-identify patient data before it reaches the model. Keep a licensed human as the final sign-off on every output, and log both the model's suggestion and the human's decision. A signed Business Associate Agreement with your model provider is necessary but covers only the vendor side.
02Why does clinical AI need human review instead of running automatically?
A ranking model can surface a strong candidate and still miss context a chart does not capture, like a prior reaction or a scheduling conflict. Speeding up the search is safe, and it saves hours. Skipping the final decision is not, because it removes the person accountable for a clinical outcome, and regulators and patients will not accept that trade.
03Who builds healthcare AI systems like this?
Teams that treat the compliance requirements as part of the architecture, not a checklist added at the end. Hashlogics built TrialTriage this way: de-identification, role-based access and an audit trail were designed alongside the matching pipeline, not layered on after launch.
