Published for transparency while formal governance documents are prepared with counsel. There is no binding effective date until this banner is removed.
This Data Processing Addendum describes how the parties' roles map across the data-protection regimes that apply. Under HIPAA, shteg.ai is a covered entity in its own clearinghouse capacity and a business associate when it processes PHI for a covered-entity customer. Under general data-protection terminology, the customer is typically the controller of the personal data it entrusts to us, and shteg.ai processes that data on the customer's documented instructions. The finalized DPA will state precisely which role attaches to each processing activity, since the same entity can hold different roles for different flows.
Processing is limited to what is necessary to deliver the platform, product, and clearinghouse and settlement services: receiving and routing clinical and claims transactions, performing eligibility, remittance, and settlement functions, and the operational support around them. Data is processed on the customer's instructions and to meet legal obligations, and to the minimum necessary. Processing that would require PHI without a Business Associate Agreement fails closed.
The DPA references the technical and organizational measures the system is built on: encryption in transit and at rest through the underlying Google Cloud infrastructure and Cloud Healthcare data stores, per-tenant isolation, minimum-necessary access controls, a hash-chained WORM audit ledger providing tamper-evident logging, and the fail-closed doctrine that converts a missing control into a refusal. Certifications such as SOC 2 and HITRUST are gated objectives, not achieved certifications, and the DPA will describe them as such.
shteg.ai uses subprocessors to deliver the service; the current, real list and each vendor's status are published at /legal/subprocessors, and we require a BAA or equivalent flow-down before a subprocessor handles PHI. The platform is operated on United States-based Google Cloud regions, and the infrastructure and vendor set are US-centric; the finalized DPA will address any cross-border transfer mechanisms if and when they apply. The binding version will also set out the notification and objection process for subprocessor changes.
The DPA will describe how we assist the controller in responding to individual rights requests — access, correction, deletion, and the HIPAA individual rights described in our Notice of Privacy Practices — and how data is returned or deleted at the end of the engagement, subject to legal retention obligations and the immutability of the append-only audit ledger, which retains a tamper-evident record of events rather than the underlying clinical payloads. Specifics are reserved for the counsel-reviewed binding version.
Because this is a draft, the most reliable answer is a direct one. For questions about how data would be processed under a DPA, or to request a Business Associate Agreement, email us and a human will respond. When the counsel-reviewed version is finalized, this draft banner will come down and an effective date will appear.
Data processing roles, subprocessors, or a Business Associate Agreement — send a note and a person will respond. No form that posts into a void.