PHI masking, from the socket to the audit log

If your floor handles calls for clinics, payers, or pharmacies, protected health information moves through your systems whether you planned for it or not. A patient reads out a member ID. An agent updates a record mid-call. A recording is stored for quality review. Each of those moments is a place where the data can leak, and each is a place a HIPAA review will ask you about. This piece explains what PHI is in plain terms, then walks through how TelVox protects it from the live socket all the way to the audit log.

What counts as PHI

PHI stands for protected health information. Under HIPAA, it is health information that can be tied to a specific person. That is broader than a diagnosis. A name, a phone number, an email address, a member or account number, an appointment date, or a recording of a patient's voice can all be PHI once they sit next to anything about that person's care or coverage. The rule you have to internalise is simple: it is not only the medical detail that is sensitive, it is anything that identifies the person the detail belongs to.

That definition is why a dialer is squarely in scope. A call platform is full of identifiers by design. It stores phone numbers, it captures dispositions, it records audio, and it streams live events to agent screens. Protecting PHI on that kind of system means protecting it in motion, at rest, and in the trail you keep of who did what.

Masking, with a digit count you control

The first line of defense is not showing more than an agent needs to see. TelVox annotates PHI fields and masks them, and the number of digits left visible is configurable. An agent can confirm the last few digits of a phone number or a member ID to verify identity without the full value ever sitting on the screen in plain text. You decide how much shows, so you can match the setting to what your own compliance team is comfortable with.

Encrypted where it rests

Data that is stored is data that has to be encrypted. TelVox uses AES-256-GCM envelope encryption at rest. That protects call recordings and stored secrets such as SIP passwords, TOTP secrets, and integration credentials. S3 storage adds SSE-KMS on top, and traffic is protected with TLS in transit. The intent is that a copy of the data at rest is not a copy of the data in the clear.

PHI is not safe because one screen hides it. It is safe when every place the data can rest, move, or be logged treats it as sensitive by default.

An audit trail that redacts

HIPAA expects you to keep a record of access to PHI. The catch is that a naive audit log becomes a second copy of the very data you are trying to protect. TelVox handles that by redacting the sensitive fields as it writes. The audit trail is append-only, and it automatically redacts phone numbers, emails, names, and secrets. You get the accountability of a full record of who did what, without turning the log itself into a PHI exposure.

One tenant cannot see another

None of the above matters if one customer's data can surface in another customer's account. TelVox enforces org-scoped isolation at the data layer. Every query is scoped to the organisation making it, and a request for another organisation's record returns a not-found response rather than leaking that the record exists. Isolation is the default behaviour of the data layer, not a filter someone has to remember to add.

What a HIPAA review actually checks, and the BAA

A HIPAA security review is not a single yes-or-no question. Reviewers walk the data through its whole life and ask, at each stage, what protects it. The controls above map directly onto that walk:

• In motion: PHI blocked from real-time socket payloads, TLS in transit.
• On the screen: masking with a configurable visible-digit count.
• At rest: AES-256-GCM envelope encryption, plus SSE-KMS on S3 storage.
• In the record: an append-only audit trail that redacts phone, email, name, and secrets.
• Between customers: org-scoped isolation, where a cross-org request returns not-found.
• On paper: a signed Business Associate Agreement and available security documentation.

That last line is the legal spine of the whole arrangement. A BAA, or Business Associate Agreement, is the contract HIPAA requires between a covered entity and any vendor that handles PHI on its behalf. It puts your obligations in writing: how the data is protected, what happens if something goes wrong, and who is responsible for what. TelVox will sign a BAA, and is built for HIPAA workloads. On the broader certifications, we are direct about status: SOC 2 Type II and ISO 27001 certification are in progress, and we share those reports as they are completed. We would rather tell you exactly where we stand than overstate it.