Security & PHI
We do not store a patient identifier, anywhere
The free scrubber runs entirely in your browser and transmits nothing. A saved claim on a paid plan holds procedure codes, modifiers, units and a payer, and nothing else. Here is exactly what we hold, how it is scoped, and what we do not yet offer.
Principles
How DenialPath treats claim data
The free scrubber never transmits a claim
Scrubbing one claim in the free tier runs the same engine code as the paid product, entirely in your browser tab. The payer, date of service, codes, modifiers and units you type never leave the page: there is no request to intercept, because none is made. This is why the engine has no dependency on anything server-side.
No patient identifier ever touches our database
There is no name, date of birth, member ID, or account number column anywhere in our schema. A claim you choose to save on a paid plan stores only the procedure codes, modifiers, units and the payer you billed against, the fields the engine actually needs to reproduce its verdict. There is nothing to store beyond that, because the engine never asks for anything more.
Every user record is owner-scoped
Postgres Row Level Security scopes each row to the account that owns it across profiles, API keys, the request log, saved claims, scrub runs and appeal letters. Another account's rows are not reachable through the app, the API, or a shared key.
API keys are hashed, shown once, revocable
We store a sha-256 hash of a key plus a short prefix so you can tell one from another. The key value itself is never written down. It is displayed once, at creation, and you can revoke it instantly from your account if it is ever exposed.
No file storage, because there is nothing to upload
Supabase Storage is disabled in our configuration. A claim is a small set of typed fields (codes, modifiers, units, payer), never a document, an EOB scan, or any other file, so there is no upload path and nothing sitting in a bucket to secure or to leak.
No model provider in the request path
Every verdict is a deterministic lookup against the cited CMS and X12 datasets in lib/engine, run in code. Nothing you enter, saved or not, is sent to a model or AI provider, and nothing is used to train one. Our MCP server lets an agent you control call the same deterministic engine; it does not send your account data anywhere else.
Not medical advice, not a coverage determination
DenialPath provides billing and administrative guidance based on published CMS and X12 sources. It is not medical advice, not a coverage determination, and not a guarantee of payment. NCCI and MUE edits are republished quarterly and payer policies vary by contract. Always confirm against the payer's own current policy before submitting or appealing.
What we don't yet offer
- No HIPAA certification. We minimise what we store (no patient identifiers, ever) as an architecture decision, not a compliance program, and we will not claim a certification we have not earned.
- No SOC 2 report, or any other third-party security certification.
- No third-party penetration test yet.
- No bug bounty programme. Report anything you find to us by email and we will act on it.
- No team seats and no SSO. An account is one person today.
We'd rather say this plainly than let silence imply a compliance status we haven't earned.
FAQ
Security questions
Is the free scrubber HIPAA compliant?
We do not use that phrase, because we have not sought a certification and would rather describe the actual mechanism: a single free scrub runs entirely in your browser and makes no network request at all, so there is nothing to secure in transit and nothing at rest on our servers for that scrub. Whether that satisfies your organisation's specific compliance requirement is a judgment only you can make; ask your compliance officer, do not take our word for it.
What does a saved claim on a paid plan actually store?
The procedure codes, modifiers, units and payer you billed, plus the verdict and the CMS edit quarter it was checked against. That is the complete list. There is no name, date of birth, member ID or account number field in the schema to fill in even if you tried.
Do you store any files?
No. There is no file storage on this service, Supabase Storage is switched off, and there is nothing to upload beyond the typed claim fields above.
Can other accounts see my saved claims?
No. Row Level Security scopes every saved claim, scrub run, appeal letter, API key and log row to the account that owns it, and there is no world-readable user data.
Is my data sent to an AI model?
No. No model or AI provider sits in the request path for a scrub or a denial lookup. Every verdict is a deterministic lookup against cited CMS and X12 data, run in code. Our MCP server lets an AI agent you control call that same deterministic engine.
Do you offer a SOC 2 report or a penetration test?
Neither, and no bug bounty either. We say so plainly rather than implying a compliance status we have not earned. If one of those is a hard requirement for you, contact us before you build on the service.
Read the full privacy policy
Details on what we collect, why, and how to delete it.