Published for transparency while formal governance documents are prepared with counsel. There is no binding effective date until this banner is removed.
A Business Associate Agreement (BAA) is the HIPAA-required contract that permits protected health information to move between a covered entity and a business associate, binding the associate to defined safeguards, permitted uses, breach obligations, and audit rights. On this platform the BAA is not paperwork after the fact — it is a hard gate. No real PHI flows until a BAA is executed, and the code enforces this: an unconfigured or un-BAA'd PHI integration fails closed with a typed refusal and zero network calls. This page describes what our BAA is intended to cover; it is a draft pending counsel review and is not itself a BAA or an offer to contract.
shteg.ai occupies two HIPAA positions at once. As a registered clearinghouse operating under its own NPI, it is a covered entity. In the transactions it performs for practices — receiving, translating, and routing claims, eligibility, remittance, and settlement data — it acts as a business associate to those covered-entity customers. The finalized BAA will make this dual posture explicit, so that obligations flow in the correct direction for each function and are not blurred by the fact that one entity plays both parts.
The BAA will reference the administrative, physical, and technical safeguards the system is built around: encryption in transit and at rest via the underlying Google Cloud infrastructure and Cloud Healthcare data stores; per-tenant isolation; minimum-necessary access; a hash-chained WORM audit ledger that makes PHI access tamper-evident; and the fail-closed doctrine that turns a missing safeguard into a refusal rather than a silent success. It will also commit to breach notification timelines and to making our records available for the compliance reviews HIPAA contemplates.
Where a subprocessor may handle PHI on our behalf — for example a bank rail, a clearinghouse transport, an EMR integration partner, or a messaging vendor — we require a BAA or equivalent flow-down obligation with that subprocessor before any PHI reaches it. The current, real list of subprocessors and their status is published at /legal/subprocessors. Vendors that are gated or sandbox-only cannot receive real PHI until both their integration and their BAA are in place.
Executing a BAA is a required step before any real PHI or production traffic moves for a customer, and it is a human, counsel-reviewed process — not a click-through. To begin, email us and a person will respond with the current draft and next steps. When the finalized BAA template is published, this draft banner will come down.
A BAA is required before any real PHI or production traffic moves. Email us and a human will respond with the current draft and next steps — no click-through, no form into a void.