Zero retention architecture, running clinical AI without storing patient data

What zero retention actually requires

It is a property of how a system is built, not a policy layered on top, and it is what RA 10173↗ is actually asking for when it talks about proportionality. Our own architecture is published in full. Three things have to be true simultaneously.

• No database write containing personal health information, at any point in the request lifecycle
• No logging of payload contents, including inside error handlers, which is where most leaks actually happen
• No caching layer that outlives the request, and no queue that persists the payload while waiting

Why anonymization alone is not enough

Hashing an identifier is necessary but not sufficient. A record stripped of a name but retaining admission date, discharge date, age, facility and diagnosis is often re-identifiable, particularly in a small facility or an uncommon condition.

The stronger position is not to keep the record at all. If the only artifact that survives a request is a hash and a counter, re-identification has nothing to work with.

What a hospital DPO should ask any AI vendor

These five questions separate architectural commitments from marketing language.

Related Every PhilHealth claim denial reason, and how to prevent each one

1. 01Where exactly is patient data written to disk, and can you show me that it is not
2. 02What appears in your logs when a request fails partway through
3. 03If I search your storage for a known test patient, what comes back
4. 04Which of your subprocessors receive payload data, and under what agreement
5. 05Can the system submit or transmit anything without a recorded human decision

The questions a DPO should actually ask

• Where is patient data written, and can you show me the code path that writes it. A vendor that answers with a policy rather than an architecture has told you the answer
• What appears in your logs when a request fails. Error handlers are where most leaks live, because they are written to help a developer and nobody audits them
• What is in your error responses. A validation failure that quotes the submitted payload back has sent patient data to every proxy and monitoring system between us
• What persists after the request, and what is it for. If the answer is a hash, ask what it is a hash of and whether the salt is held separately
• Who can read the audit log, what is in it, and can it be deleted. An append-only log is a compliance asset and also a category of personal data about your own staff
• Which subprocessors exist and what can each one reach. If the named list is not shared with you in writing, ask why not

Why hashing alone is not anonymization

A record stripped of a name but retaining admission date, discharge date, age, facility and diagnosis is frequently re-identifiable, particularly for an unusual diagnosis in a facility of known size. The hash protects the identifier. It does nothing about the quasi-identifiers around it.

This is the failure mode behind a large share of anonymization incidents. The organization did remove the direct identifier, in good faith, and considered the job done.

There is no gap between a chart and a claim here, because nothing is kept on either side of it. The stronger position is not keeping the record at all. If the only artifact surviving a request is a non-reversible hash and a counter, there is no combination of fields left for anyone to work with, and the question stops being a matter of how well the anonymization was done.

Hashing protects the identifier. It does nothing about the five fields sitting next to it.

Why this is a competitive position, not a constraint

Retention creates obligation. Every stored record is a breach notification risk, a subpoena target, an access request to service and a line item in a compliance audit.

A system that retains nothing removes most of that surface. It also shortens procurement, because the hardest questions in a hospital privacy review are about storage, and there is nothing to review.