Kestrel check
Updated August 5, 2026 · written for the person who has to approve this
Summary for a compliance review. Kestrel Check never receives protected health information. Billing files are parsed in the user's browser; only de-identified billing fields and per-run one-way keys are transmitted, and no claim line is stored. Kestrel does not submit claims, is not a clearinghouse, and is not in the transmission path to any payer. Because no PHI is received, Kestrel is not a business associate for this workflow and no BAA is required — the architecture, not a promise, is what makes that true.
Under the Privacy Rule's Safe Harbor method, information is de-identified when the eighteen listed identifier types are removed and the discloser has no actual knowledge that what remains could identify an individual. The identifier list includes names, dates directly related to an individual, account and record numbers, contact details, and any other unique identifying number, characteristic, or code (45 CFR 164.514(b)(2); see the HHS de-identification guidance).
Kestrel Check is built so that none of those identifiers is transmitted:
Consequence: Kestrel does not create, receive, maintain, or transmit PHI on behalf of a covered entity in this workflow, which is the statutory trigger for business associate status. A BAA is therefore not required and none is offered for Kestrel Check. Users are contractually asked not to submit PHI (Terms §5).
Section 3060 of the 21st Century Cures Act amended section 520(o) of the Federal Food, Drug, and Cosmetic Act to exclude certain software functions from the device definition, including software intended for administrative support of a health care facility — expressly including the processing and maintenance of claims or billing information (see FDA's guidance on section 3060). Kestrel Check performs billing and administrative analysis only. It makes no diagnostic, treatment, or clinical recommendation, and is not a medical device or clinical decision support software within FDA's meaning.
Claims travel from a practice management system, as an 837 file, through a clearinghouse, to the payer. Kestrel sits beside that chain, before submission, and never inside it. Kestrel holds no payer connections, no clearinghouse relationships, no trading partner agreements, and no ability to submit, alter, or withhold a claim. If Kestrel is unavailable, customers bill exactly as they always have. This is deliberate: it keeps Kestrel out of the critical path and out of the chain of custody for claim data.
| Role | Can see | Cannot see |
|---|---|---|
| Member | Their own results and check history; their organization's payer roster and schedule | Anyone else's results, the invite link, team totals |
| Organization admin | Aggregate team usage: checks, lines, findings caught, last check time per member; org settings and invite link | The contents of any member's file — which no one can see, because contents are never transmitted |
| Kestrel staff | Service-wide aggregate metrics; the payer rule set and its provenance | Customer files, claim lines, or any patient information |
Roles are enforced server-side on every request; the interface never decides access. Privileged actions (role changes, member removal, settings changes, invite rotation) are recorded with the acting user's identity. An organization cannot be left without an administrator.
Rules are extracted by AI from payer documents that the payers themselves publish, and every rule stores a verbatim quote from its source document — a rule cannot exist in the system without one. Before a rule is allowed to block a claim line, it passes a two-model adversarial review: one model evaluates it against the wider source text and the engine's enforcement semantics, and a second tries to construct a legitimate claim the rule would wrongly block. Rules that fail that review remain advisory. Every rule records who or what approved it and why. Users always see the payer's own sentence and a link to the document, and are asked to verify against it.
| Provider | Purpose | Data |
|---|---|---|
| Render | Hosting | Requests, hashed IPs |
| Supabase | Database, authentication | Email, account records, check counts |
| Anthropic | Column mapping, pattern review, rule extraction | Header names, payer company names, de-identified code lines with relative day numbers. No training on API data. |
| Apple | iOS subscriptions, Sign in with Apple | Handled by Apple |
Send them to kestrelaba@gmail.com. If your organization requires a security questionnaire or a written data flow description, this page is the summary and we will answer specifics directly.