Can we store the record number instead of the name? A billing architecture decision
A clinic asked whether swapping the patient name for a medical record number keeps a billing system out of HIPAA. It does not. Here is the design question that was actually worth asking.
- build log
- architecture
- healthcare
- hipaa
- system design
A clinic asked me a good question this month. If the billing system stores the medical record number instead of the patient’s name, does that keep it out of HIPAA?
No. And the reason is more useful than the answer.
I am not a lawyer and none of this is legal advice. It is an engineering read of the regulation text and the published vendor terms, written up so the reasoning can be checked.
Why the swap does not work
A medical record number is itself one of the eighteen identifiers listed in the Safe Harbor method at 45 CFR 164.514(b)(2). It sits in the same list as the name. Swapping one for the other trades a listed identifier for a listed identifier.
It is arguably worse. Names repeat and change. A record number is a clean permanent key for re-identifying somebody.
There is a second reason that is harder to design around. What a specific person owes for their care is payment information for the provision of health care. That is protected health information on its own, whatever the identifier column is called. A patient balance system cannot be designed out of HIPAA.
The question worth asking instead
Not how to avoid the rule. How little the system needs to know to do its job.
Every identifier a system holds costs money, widens a breach, and pulls another vendor inside the compliance boundary. So the design question is how much can be left with the clinic, who already has it.
Three designs came out of that.
Hold the full record. Name, date of birth, provider, address, phone, email, balance. Works end to end. Four vendors inside the boundary. Largest breach surface. This is what already existed.
Hold the same record with a record number instead of the name. Legally identical to the first. Same cost. Buys nothing. This is the one that was asked for, and the one I argued against.
Hold an opaque code, the balance, days past due, and one way to reach the person. The key from code to person stays with the clinic. Three vendors instead of four. A breach exposes a code and an amount.
The third is not free. Staff work from codes instead of names. Printed letters have to be merged at the clinic. It is a rebuild of the import, the screens and the letter flow rather than a setting you toggle. That is the honest trade, and the clinic gets to decide it with the numbers in front of them.
Taking money without an agreement in place
The card processor does not sign business associate agreements. That is its published position, not an oversight, because transaction data is combined with personal data for fraud detection and shared with downstream providers.
So the design makes sure nothing it receives is protected health information. The charge carries an opaque identifier and an amount. Names are stripped from the payment description, the metadata, the customer record and the product record. The payment link resolves the code on our side; the processor sees the result, never the input.
Worth saying plainly: the first version of that leaked names into the payment description and the customer object. It was rebuilt. That is exactly the kind of thing that never announces itself.
The assumption I got wrong
An earlier version of this analysis assumed the hosting vendor would only sign an agreement on an enterprise contract. That single assumption was the biggest recurring cost in the engagement, and a large part of the argument for the minimal design.
I re-checked it before publishing. It is no longer true. That vendor now signs on its Pro plan as a self serve paid add on.
The recommendation did not change, because the minimal design still removes a vendor and shrinks the breach. But the price of the alternative fell a long way, and a decision record that quietly carries a stale cost is worse than no decision record. So the old number is corrected in the write up rather than dropped.
The whole thing is public
No client named, no client data, none of their systems. What is public is the reasoning: the three designs, the boundary drawn as diagrams, how a website, a phone agent and a billing system connect without any of them knowing more than they should, and a vendor table with the date each fact was checked.