Skip to content

Built for HIPAA compliance. Plain about how.

A referral carries a patient's name, history and films. Here is exactly what protects it, written so a front desk can read it and an IT lead can check it.

Referral ER-2481
Tooth 19 · retreatment
AES-256
Patient
v1:9fK2xQe7Lm0aVt3z:Wq3T+e0P
Date of birth
v1:Qw81nZpE:k7Rb2s
Medical alerts
v1:Hc0r5Ty1uN8w:aZ+41v
Clinical notes
v1:pL7dE2kq9Xw0R3m:Uf8sN1yq
Imaging
3 files · encrypted blobs
Each identifier is its own ciphertext; a copied database file reads like this.
Illustrative record and sample values. Real ciphertext is longer and never shown in the app.

Six safeguards, one record.

Each safeguard covers a different way patient information could leak, from a stolen password to a copied file.

Signing inTOTP

With two-factor sign-in enabled, a password alone is not enough.

  • Two-factor sign-in with an authenticator app (TOTP). Each user turns it on in their security settings, and changing it requires their password.
  • Repeated failed sign-ins are throttled per network address and per account.
  • Sessions are stored hashed and end after 8 hours at most.
The record at restAES-256

What is saved on disk is unreadable without the key.

  • Every patient identifier is encrypted field by field with AES-256: name, date of birth, contact details, insurance details, medical alerts, medications, clinical notes and the completion report.
  • Uploaded files are encrypted too: radiographs, CBCT, photos, PDFs and DICOM.
Who can open whatRole-based

Each person sees their practice's cases, and only those.

  • Access is role-based: referring office, specialist practice and administrator accounts see different things.
  • Data is scoped to the practice. One practice cannot read another practice's cases or reports.
  • Privacy mode blurs patient names for screens in shared spaces like a front desk.
A record of every accessHash-chained

Who opened a case, and when, is written down and cannot be quietly changed.

  • Sign-ins, failed sign-ins, case views and uploads are written to an audit log.
  • Each entry carries the hash of the one before it, so a deleted or edited entry breaks the chain and shows.
The web layerCSP

The site itself refuses requests and content it does not expect.

  • Changes to data must come from eReferral's own origin (cross-site request checks).
  • Strict security headers and a content security policy: no third-party scripts, fonts or trackers load on any page.
What the patient seesNo PHI

The tracking page shows progress, never the patient.

  • Patients follow a referral with a 128-bit tracking code; no account is needed.
  • The tracking page shows status and the appointment date. No name, date of birth or clinical details.

What we do not claim.

Security pages are easy to inflate. These are the lines we hold, so you can trust the rest of the page.

Claims this page will not makeHeld until they are trueNot claimed
HIPAA certified
There is no official HIPAA certification for software. eReferral is built for HIPAA compliance; how a practice uses it is part of its own compliance.
Uptime
eReferral is in pilot, and we do not publish availability figures until we can stand behind them.
Integrations
No practice management integration yet. eReferral works on its own today; nothing is synced to or from your practice software.
Customers
No customer logos or numbers. The product is in pilot, so this site shows the product itself rather than claims about who uses it.