Compliance

Health benefits are regulated. This page summarizes the plan structure, data handling boundaries, and go-live gates that affect the integration.

​

Who is what: the plan structure

Use these roles when mapping the plan into regulated surfaces: Use the approved plan display names from GET /plans in customer-facing surfaces. The planType value is backend classification for eligibility, quoting, and regulated workflows; do not expand it into marketing copy.

​

Quotes are indicative

Every quote carries "pricingBasis": "indicative" and ships with its own assumptions strings. The contract:

• Quote numbers are indicative pending underwriting confirmation.
• They become binding only at enrollment plus underwriting sign-off.
• Material census changes re-rate.

Keep that framing attached to any displayed quote amount.

​

Data handling

​

What you send us

Census data (names, dates of birth, ZIP codes, emails, dependent relationships) is enrollment and eligibility data. Before live mode is enabled, Prescience and your company execute:

• a Business Associate Agreement (BAA), and
• a data processing agreement

covering exactly this data. This is why psk_live_ keys return 403 live_mode_disabled until the partnership paperwork is done: the gate is contractual, not technical. Test mode is for development against the full API without that data relationship in place; use realistic-but-fake people in test mode if your policies require it.

​

What we send you

The other direction is restricted by design:

• Aggregate and de-identified only. GET /account returns funding, premium, spend, and savings aggregates: never named claims, never diagnoses, never any individual’s health data.
• k-anonymity suppression. When a spend category could be traced to a small number of members, the API suppresses the categories (spend.suppressed: true) instead of returning them. You don’t implement this; your only job is to render the suppressed state.
• The roster is administrative. GET /members carries enrollment status and a dependent count: no dependent identities, no health information.

The practical consequence: your platform never holds PHI from Prescience, which keeps your own compliance surface where it already is (HR data) rather than expanding it into claims data.

​

Go-live checklist

1. Core flow green in test mode (group → census → quote → enrollment), webhook signatures verified end to end.
2. BAA + data processing agreement executed.
3. Required commercial and operational agreements completed.
4. Prescience enables live mode and issues your psk_live_ key.
5. First real employer group created with the live key.

Items 2–4 can run in parallel with implementation.