What DocketHealth does, and how it protects your data

Yes. All PHI (patient names, dates of birth, MRNs, payer member IDs), free-text PA and clinical narratives, and uploaded documents are encrypted at the application layer with AES-256-GCM before they're ever written to disk — so a leaked database credential, a stolen backup, or a disk snapshot exposes ciphertext, not usable PHI. The database connection itself is also TLS-encrypted in transit.

DocketHealth is built with the technical safeguards a HIPAA-regulated practice requires: encryption at rest and in transit, role-based access control, database-enforced tenant isolation, and a tamper-evident audit log. HIPAA compliance itself is a shared responsibility that also depends on your organization's own policies, training, and a signed Business Associate Agreement — please talk to our team before processing real PHI in production.

No. Every organization's data is isolated twice over — once in the application layer, and a second time at the database layer via PostgreSQL Row-Level Security — so even a bug in one query can't leak another org's records.

Every new account must enter a one-time code sent to the email address used at signup before it can log in for the first time, so no one can create an active account with an email address they don't actually own.

Yes — TOTP-based multi-factor authentication with backup codes (which an admin can require org-wide), plus enterprise single sign-on via SAML 2.0 or OIDC.

Yes. Every sensitive action is written to a hash-chained audit log designed to make tampering detectable, and org admins can export it at any time.

On a managed PostgreSQL instance with Row-Level Security enforced at the database level, behind a TLS-terminated web service. See our documentation for the full technical architecture.

Yes, in five specific places: semantic note review, payer-policy extraction, documentation-aware denial-risk scoring, appeal-narrative drafting, and per-field confidence on scanned/faxed intake. In every case the AI is given only the minimum data needed for that task and used strictly for extraction or analysis — text sent to the model is used to generate that one response and isn't used to train the underlying model. AI output is never written to a record or a claim without a human reviewing it first.

No, never. Every AI feature in DocketHealth produces a suggestion, a draft, or a flag for a person to review — not a determination. Denial-risk scoring, for example, is a deterministic, explainable calculation (not an opaque model output) that only adjusts based on facts already in the record, like whether a note has a missing signature.

Nothing stops working. If AI isn't configured or a call fails, the underlying action (saving a note, submitting a request, uploading a document) still completes — the AI step is simply skipped and marked as unavailable. Appeal drafting goes further: a deterministic template narrative is always prepared first, so staff never end up with nothing to review even if the AI-grounded draft can't be generated.

Yes. Every login is scored against that user's own history — a brand-new IP, a rapid change from their last known IP, a new device, or a wildly atypical hour — and a risky sign-in automatically requires a one-time emailed verification code before it's granted, even for accounts without MFA enabled. Separately, a behavioral anomaly detector watches the audit log itself for patterns like an unusually large volume of PHI access or an off-hours bulk export, and surfaces them to your admins on the Security tab.

Every document fed to an AI feature (a faxed referral, a pasted payer bulletin) is scanned for known prompt-injection patterns — text crafted to look like instructions rather than data — before extraction runs. Every AI-generated output (an appeal narrative, an extracted field) is separately scanned for PHI-shaped values that don't actually trace back to the source document, since those are either a hallucination or an over-disclosure. Both checks are advisory and logged; they never replace the human-review requirement every AI feature already has.

Yes, as an advisory compliance signal, not an accusation or an automatic block. DocketHealth screens prior-authorization submission patterns for things like the same patient and procedure code resubmitted repeatedly in a short window, one submitter's volume unusually concentrated on a single procedure code, or a denial rate well above your organization's own baseline — the same kind of patterns a payer's own program-integrity team would eventually notice, surfaced first, internally, with time for your compliance officer to review and correct course.