# Security, privacy, and legal boundaries

This architecture minimizes exposure; it is not a legal opinion. Launch requires written approval from counsel familiar with healthcare advertising, consumer-health-data laws, privacy, referral/fee restrictions, corporate-practice rules, telehealth/pharmacy rules, recurring billing, and every state where a publication may appear.

## The boundary in one table

| The partner may | The partner must not | Chia owns |
|---|---|---|
| Display an exact approved paid catalog publication | Rewrite clinical/eligibility claims or omit terms/disclosures | Catalog approval, seller/provider/pharmacy identities, final terms |
| Use fresh partner-owned account service-state evidence locally | Send state evidence, identity, contact data, device data, answers, or arbitrary metadata to Chia | Verified care location and clinical eligibility after handoff |
| Offer an equal-access share/no-share choice | Preselect sharing, degrade no-share, prefetch either URL, or use a consent wall | Receiving the minimal shared program/referral context after affirmative choice |
| After affirmative JIT choice, request one opaque 15-minute environment-matching handoff without identity and open it in the OS browser | Add user/account/device/contact/state metadata; use a WebView, redirector, callback, tracking wrapper, or status lookup | Identity, intake, clinical consent, checkout, payment, care, and fulfillment |
| Receive catalog cache-validation signals and explicitly requested synthetic webhook tests | Receive or infer individual lifecycle/outcome events | Patient/order support and every individual status |
| Read immutable Finance-released statement revisions and privacy-thresholded aggregates | Request individual reconciliation, line items, treatment/program/geography cuts, or sum superseded revisions | Authoring, approving, correcting, paying, and releasing the fixed-fee statement |

If activated under a signed agreement, the partner acts only as a
publisher/marketplace surface. It is never the merchant of record, seller,
healthcare provider, pharmacy, checkout, order/fulfillment agent, or Chia
patient-support system.

## Structural marketplace requirements

- Chia or the expressly named entity is seller and merchant of record, controls final terms, obtains payment authorization, and handles refunds/cancellation and support.
- Clinical and pharmacy parties act independently in their named roles. The partner does not evaluate eligibility, recommend or guarantee a drug, control a prescription, or answer clinical questions.
- Catalog copy is Chia-controlled, versioned, effective/expiring, state-gated, complete, and non-truncatable. A clinician may recommend something different or no treatment.
- The partner's service fee is fixed, prospective, documented at fair market value, and independent of views, taps, leads, purchases, patients, prescriptions, products, revenue, shipments, or outcomes. That structure reduces risk but is not itself a federal or state safe harbor: counsel must separately confirm intent, every applicable safe-harbor element, state fee-splitting/referral rules, and whether marketplace, broker, advertising, telehealth, pharmacy, or other registration requirements apply.
- Production 2.1 exposes only a separate append-only Finance release projection. Amounts and paid/due state come from the approved immutable statement record, never live activity. Any count additionally requires an immutable group threshold of at least 10 plus composition release approval, remains nullable, and is separate from the fee formula and individual reconciliation. Partner-specific approval may raise but never lower that floor.

Contract language alone is insufficient. Actual UI, support behavior, money flow, marketing, analytics, and operations must match these facts.

## Consumer-health data and the JIT choice

A user's care-program selection can be consumer health data even if the partner never receives HIPAA PHI. The partner must maintain its own applicable consumer-health notice and rights path, approved access/retention/deletion controls, and counsel-approved consent/legal basis.

Where context sharing is permitted, the transfer occurs only after an unbundled affirmative choice naming:

- the recipient;
- exactly `selected care program` and the credential-bound partner referral origin;
- the purpose;
- the partner's fixed compensation relationship;
- both parties' applicable privacy/rights links.

Refusal remains a fully usable neutral route. No dark pattern, preselected choice, consent wall, or degraded no-share experience is permitted. `affirmed:true` attests the user's action; it does not replace the approved UI, consent record/retention analysis, or counsel review.

The partner's own observation of catalog interactions stays inside the approved partner boundary. Never put service state, a selection, a handoff URL, app-focus/return timing, or treatment-interest telemetry into advertising systems, crash/session replay, broad analytics, or an unapproved AI model.

The partner's current public privacy policy is a review input, not counsel approval and not the production consumer-health/rights configuration. If that policy or the partner's SDK configuration describes advertising or analytics collection of purchases or product interactions, the partner must technically suppress advertising pixels, ad attribution, behavioral analytics, session replay, profiling, and equivalent SDK events on every Chia catalog, selection, JIT-consent, and handoff surface. Production may launch only when counsel has separately approved the exact consumer-health notice and rights URLs configured by Chia; render only the exact `partner_consumer_health_policy_url` and `partner_privacy_rights_url` returned in the live catalog. Never substitute a general policy URL in app code.

## No reverse disclosure

Chia never tells the partner whether a person:

- created an account or completed intake;
- was eligible, approved, denied, or prescribed;
- authorized or failed payment;
- purchased, canceled, refunded, or contacted support;
- had an order filled, shipped, delivered, or interrupted.

There is no callback, user/order reference, status API, lifecycle webhook, or treatment-level settlement dimension. The partner must not infer those facts from browser return, app focus, aggregate timing, catalog composition, support contact, or any side channel.

## Security baseline

- Server-only, environment-bound, least-privilege credentials; no secrets or SDK in mobile/browser bundles.
- Exact HTTPS origins, no redirects, closed request/response schemas, request IDs, bounded timeouts/retries, and fail-closed decoding.
- Authenticated assets streamed to temporary storage and committed only after complete header/length/digest verification.
- Exact-raw-body webhook HMAC, five-minute replay window, environment checks, `test:true` enforcement, and durable no-side-effect deduplication receipts; V2 has no live webhook job.
- Production launch redemption revalidates the current activation without caching, and the resulting internal care context, browser cookie, and catalog session cannot outlive the approval or publication that authorized them. The activation digest is retained only inside Chia's signed care/payment boundary for audit and is never returned to the partner.
- No secret, raw payload, business-resource identifier, authenticated asset URL, or short-lived handoff URL in logs, tickets, tracing, analytics, or ordinary support. A validated `Chia-Request-Id` may be recorded only for operational correlation as documented in [Errors](https://partners.chia.health/docs/errors/).
- Separate sandbox/production deployments, credentials, endpoints, storage, alerts, and certification.

Public contracts, docs, SDK source, and synthetic fixtures are safe inputs for coding agents. Secrets, production payloads, raw runtime webhooks, state evidence, handoff URLs, user telemetry, and consumer-health/patient data are not. See [AI-agent instructions](https://partners.chia.health/docs/ai-agents/).

## Required approvals before production

- signed commercial agreement and data-flow schedule;
- exact seller/MoR/provider/pharmacy/platform/partner role matrix;
- fixed-fee FMV, federal and state fraud-and-abuse/fee-splitting analysis, and a written determination of every relied-on safe-harbor element or other legal basis;
- marketplace, broker, advertising, telehealth, pharmacy, discount-plan, tax, and other state registration/licensing analysis;
- approved catalog, paid-ad label, party/price/terms/disclosure/JIT copy;
- state display, sharing, clinical, pharmacy, and offering matrices;
- consumer-health privacy/consent/rights/retention assessment;
- security, incident, credential/webhook rotation, and deletion/hold plans;
- named owners, evidence hashes, effective dates, and expiry/re-review dates;
- certification of the exact release, origins, partner endpoint, renderer, and mobile build.

Production uses separate runtime, finance, and webhook credentials. Before written activation, the runtime key authenticates but catalog and handoff fail closed. After written activation, it serves only the approved live catalog and creates identity-free co-branded handoffs. The finance key reads only immutable tenant- and environment-bound records explicitly released by Finance; all webhook tests remain synthetic. The release projection contains no patient, order, payment-level, shipment, program, geography, event, treatment, or date-row data. Chia alone collects payment as merchant of record and owns the patient, clinical, order, shipment, refund, and support lifecycle.

Stop launch if operations contradict the boundary—for example, compensation depends on conversion, partner support answers clinical/order questions, a callback reveals status, analytics records selection URLs, required terms are omitted, or an approval/configuration expires. No API wording cures contrary conduct.

## Primary guidance behind these gates

The following official sources are review inputs, not a legal safe harbor or an approval to launch:

- [HHS HIPAA de-identification guidance](https://www.hhs.gov/hipaa/for-professionals/special-topics/de-identification/index.html) describes Safe Harbor and Expert Determination. Aggregation by itself does not establish either method.
- [HHS OIG's Anti-Kickback Statute FAQ](https://oig.hhs.gov/faqs/general-questions-regarding-certain-fraud-and-abuse-authorities/) explains that fair market value alone is not a dispositive defense; intent, facts, and every applicable safe-harbor condition still matter.
- [FTC Health Breach Notification Rule guidance](https://www.ftc.gov/business-guidance/resources/complying-ftcs-health-breach-notification-rule-0) covers certain non-HIPAA health apps and connected services handling individually identifiable health information.
- [Washington Attorney General My Health My Data guidance](https://www.atg.wa.gov/protecting-washingtonians-personal-health-data-and-privacy) addresses consumer-health-data collection and sharing consent, including for businesses outside Washington that target Washington consumers.
- [Colorado Attorney General CPA guidance](https://coag.gov/resources/colorado-privacy-act/) identifies health conditions and diagnoses as sensitive data and requires consent for sensitive-data processing.

Chia and the partner must obtain written advice from qualified healthcare and privacy counsel on the exact facts, states, entities, compensation, UI, data uses, agreements, and release configuration. These links and technical controls do not replace that advice.