When a Patient Asks You to Erase It

Here is a question I would want every clinic to put to us, and to every other company that touches its patients' information: when a patient asks you to erase what you hold about them, what actually happens? Not what the policy says. What the system does: which records go, which copies, how long it takes, and how anyone would know afterwards that it happened.

Last week I put that question to our own system, one store at a time, and the honest answer was: not enough. Call transcripts and text messages had no way to be deleted. A message a caller left for the team could be marked resolved but never erased. Deleting a document removed the original, left its other copies behind, and reported success even when the storage step failed. A clinic leaving us would have been taken apart by hand, with no record that it was done. No clinic is live on ARAGS yet. That is exactly when this has to be fixed, so we fixed it.

The clinic decides how long

Under Alberta's Health Information Act, the clinic is the custodian of its patients' information. A company that stores and processes that information for the clinic is, in the Act's words, an information manager, and the Act requires a written agreement between the two. That split shapes everything below: the clinic decides, we carry it out, and we record that we did.

So retention is now the clinic's election, not ours. The owner chooses how long the day-to-day records are kept (the calls, the texts, the reminders): 30 days, 90 days, a year, or until the clinic says otherwise. If nobody chooses, the default is 90 days, and after the period the records are removed automatically. Documents the clinic uploads are kept until the clinic directs that they be erased. A changed election applies to the records already written, not just the new ones.

A message a caller leaves for the team is never swept away while it is still open; its clock starts only once a person has dealt with it. And if the system cannot read the clinic's choice when it writes a record, it keeps the record rather than guess. A record is never deleted earlier than the clinic chose.

To be plain about “removed automatically”: the cloud database enforces the expiry, and it deletes an expired record typically within 24 hours of its time, not to the second. So every night, as part of the check that runs the platform while we sleep, we confirm that no call record or team message has outlived its date by more than 72 hours. A setting the check cannot read is a failure, never a pass.

Every erasure leaves a receipt, and the receipt holds nothing

Calls, texts, messages left for the team, documents, conversations with the assistant, what the assistant remembers, the team's own records: each can now be erased on the clinic's instruction, from the dashboard or by asking the assistant, which reads back what will go and asks before it acts. Erase a conversation and every memory the assistant learned from it goes in the same step.

The record goes everywhere it lives. A document goes with its text, the pieces it was split into for search, its review and quarantine copies, and any dictation filed into it. A call record goes with the phone carrier's own copies of the call and its texts, deleted first. If a copy cannot be destroyed, the erasure stops and touches nothing, so it can be tried again rather than left half done.

Each erasure files a receipt on the clinic's audit trail: what kind of record, how much of it went, the outcome, and whether it came from the dashboard or the assistant. What the receipt does not hold is the record. Not its words, and not even its ID, because an ID can contain a phone number. It holds a keyed fingerprint instead, so nobody can match a receipt to a patient by trying every phone number there is. And if the system cannot write that receipt, it refuses to erase.

Leaving is a procedure, with a certificate at the end

The same rule applies when a clinic leaves. Until last week that would have been a hand teardown. It is now one script that runs in a fixed order and can resume where it stopped. First it returns the clinic's information in a commonly readable form, kept in the clinic's own region. Then it destroys every store: the database, the files, the backups, the phone number, the users' access, and the carrier's records of past calls and texts. Then it checks that nothing remains, and it will not report success while anything does.

Then comes the part that is easiest to round off. On our platform a deleted file stays recoverable for seven days, and a deleted database record can be read back for seven days. We keep those recovery windows while a clinic is with us, and the agreement we offer clinics says so plainly. The certificate of destruction is issued in writing only after the windows have ended. What we keep afterwards is the record of the erasure and the certificate, and neither contains a name, a number, or a word of the clinic's content.

That agreement, the information manager agreement, was rewritten last week to say all of this: the election and its default, the recovery windows, erasure on instruction, and the phone carrier named as a sub-processor. Our own terms of service had said more than the system did on this; they now say what it does.

Two findings that were not on the list

Following every path the data takes turned up two problems that had nothing to do with erasure and mattered more. One would have let a signed-in user change a record that decides which clinic they belong to. The other, when a clinic's own database was slow to open, would have answered from a shared system database instead of refusing. Both failed open, and in a system that holds health information that is the wrong way to fail. Both were closed the day they were found, and after the first fix went out I tried it from my own account against the live system: that record can now be read by its owner and written by no one but the server.

The check was right, the code was wrong

A receipt is only worth something if the trail it sits on is in order. Every night our check runs the platform end to end on synthetic clinics, and one thing it reads is the trail of a document upload: the card that says the upload started has to come before the security scan's verdict on it. Two nights running this week, it didn't. The verdict sat ahead of the start, by less than half a second.

The cause was ours. The code asked the scanner to begin and only then wrote the “started” card, in the background. The two had been racing since the trail shipped a month ago; the card had been winning, sometimes by less than a tenth of a second, and after last week's changes it lost. Our own design says the start comes first, so the check was right and the code was wrong. We fixed the code: the start card is now written and confirmed before the scan is asked to begin, and if that write ever takes longer than five seconds the upload goes ahead anyway, because the trail must never hold up a clinic's work. The check was not touched. We have not pinned which change tipped the race, and the scanner's own verdict card is written the same background way, so that is on the list too.

What is still open

One piece is not built yet, and it is the one the opening question is really about: the patient's own record in the clinic's list. The calls, texts and notes tied to a patient's number can be erased today. The record itself cannot yet be corrected or erased on its own, and that surface is required before any clinic goes live. The offboarding script has its tests but has not yet been rehearsed end to end on a test clinic. And the rewritten agreement goes to counsel before any clinic signs it.

So, when a patient asks a clinic on ARAGS to erase what we hold? The clinic decides. We erase it everywhere it lives, the carrier's copies first, and write a receipt that holds nothing of it. For the patient record itself, the honest answer this week is not yet, and it is the next thing we build.

---