Security
PIN in, payload out.
The whole design follows from one decision: the person who enters the code and the person on the phone must be proven to be the same person, before anything is shown.
Entering a PIN never releases a packet. Only a verified read-back does.
How the binding works
When the staff member types the one-time code, the page does not show the packet. It shows a short confirmation number and nothing else. They read that number aloud over the phone, and the assistant checks it against what the server issued.
That single extra step is what ties the browser session to the specific call. Only someone who can hear this call can know the number on this screen.
What it defeats
A page that impersonates ours and captures codes gets nothing useful. If it forwards a captured code to us, the confirmation number is issued to its session, not to the staff member’s screen — so the number they read back does not match, the session is destroyed with zero information displayed, and the failed attempt itself tells us a look-alike exists. Codes are single-use, expire in minutes, and are burned on failure.
What it narrows, but does not eliminate
An attacker able to relay the real confirmation number to the staff member in real time, during the call, is a harder case. We evaluate network and device signals at verification time and escalate to an additional challenge when something looks wrong — but we will not tell you this is solved, because it is not. It is a known, documented residual risk that we are closing with machine-verifiable channel binding over the audio path in a later phase.
We would rather write that down than let you discover it later.
The two-surface wall
The page a clinic uses and the console a patient uses are not the same application. They are separate sites, on separate domains, deployed separately. The receive page has no login, no accounts, and no authentication code in its bundle at all — a build check fails the deploy if any appears.
The receive page never asks for anything
It accepts a code and displays a packet. It will never ask a staff member for a username, password, clinic account, or any detail about the practice. That gives front desk staff one simple rule to remember, and gives an attacker impersonating us nothing worth harvesting.
Encryption and access
- Packets are stored as AES-256-GCM ciphertext. The plaintext is never written to disk.
- Each packet has its own data key, held wrapped in a managed key vault. It is unwrapped only for a session that has passed the read-back, under a lease measured in minutes.
- Access expires on its own and can be revoked while a session is still open. A misdirected session is a link that dies — unlike a misdirected fax, which is unrecoverable the moment it prints.
- Every disclosure, view, and download is written to an append-only, hash-chained audit log with device and network metadata, anchored nightly so tampering is detectable.
Calling the wrong number
Misdirected disclosure is the risk we take most seriously, because directories go stale and numbers get reassigned. Three things structurally prevent it.
The assistant confirms the practice before naming the patient. A patient’s name paired with a clinic’s specialty is itself a disclosure. A wrong number therefore costs nothing: the answerer hears a generic greeting, the call ends, and that directory entry is quarantined.
What can be sent depends on how well we know the destination. Every entry carries a confidence score built from independent sources and a last-verified date that decays. Weakly verified destinations are limited to the appointment conversation only.
Delivery is revocable and logged. If something does go wrong, we can prove exactly what was and was not seen — the difference between a contained incident and a reportable breach.
What we do not do
- Write to, or read from, a clinic’s records system. There is no integration.
- Sell, share, or broker patient data.
- Run advertising or cross-site tracking, on any of our sites.
- Load third-party JavaScript on the receive page. It has none.
- Call a practice that has told us not to. That flag is permanent, with no override in the system.
Compliance posture
Services that touch patient data run under business associate agreements, and the patient-directed flows are designed to meet the FTC Health Breach Notification Rule as well as HIPAA where it applies. Consent is captured, signed, and timestamped in the app before anything moves, which produces a cleaner disclosure record than a phone call or a fax ever has.
If you are a practice manager who needs specifics for a vendor review, write to clinics@receivepin.com and we will send the detail rather than a brochure.
Reporting a vulnerability
Send it to security@receivepin.com. We do not pursue researchers who investigate in good faith, avoid privacy violations, and give us reasonable time to fix things before going public. Please do not use real patient data in a test.
Reviewing us for your practice?
We would rather answer a hard question now than have it surface during a call.