Auth57 security & compliance —
no PHI accepted.

Most healthcare vendor-risk reviews start with one question: does this vendor touch PHI?For Auth57, the answer is structurally no — and that's not marketing copy, it's an architectural constraint.

The PA Lookup API accepts four parameters: state, program, and either drug or service. None identify a patient. The API returns PA rule data — verdict, source URL, next steps — against those categorical inputs, never against a specific person.

Because we don't accept PHI, the obvious consequences apply:

• No HIPAA BAA required. HIPAA's Business Associate framework governs entities that create, receive, maintain, or transmit PHI on a covered entity's behalf. Auth57 does none of those things. Happy to sign a BAA as belt-and-suspenders if your procurement team requires it — email hello@auth57labs.com.
• Incident severity is bounded. A worst-case breach of Auth57 exposes rule lookups and API-key metadata, not patient records. No HHS breach notification. No member-facing disclosure.
• Vendor questionnaires shrink. Roughly 60% of typical VRM questions are PHI-scoped. Those questions are either N/A or answered by the architectural posture alone.

Defense in depth: the API also rejects requests at the edge when query params or free-text fields match unambiguous PHI shapes — SSN, formatted phone, email, or MM/DD/YYYY dates. A misconfigured client gets a 400 with code: phi_rejected instead of silently logging PHI into our request logs.