NudgeWell is an AI-powered benefits nudge engine for small and mid-sized HR teams. It reminds employees to use benefits they already have — FSA balances, HSA deadlines, preventive care, EAP, telehealth — so they don't lose them to the calendar.
NudgeWell does not rely on claims data or diagnosis codes to decide when to nudge. Instead, it matches general eligibility rules to calendar timelines, using only plan structure and member-supplied profile fields. The rest of this page is a plain-language audit of what we store, what we don't, and how the system is wired.
The nudge engine runs in two stages: plan-shape detection and calendar-triggered reminders. Neither stage reads claims.
Plan-shape detection. When you onboard, you tell us your plan structure: does the company offer an FSA? What's the contribution limit and run-out deadline? Does it include HSA matching? Is there a telehealth benefit? Are there preventive-care eligibility windows before a year mark? These are written by the HR admin during onboarding — we do not pull them from a carrier feed.
Calendar-triggered reminders. For each member, the engine reads non-clinical profile fields: plan_type, age_band, as_of_date, ZIP code (for provider lookup), and any optional self-reported data the member chose to enter. It then compares against plan-shape rules and fires a reminder when a calendar date approaches (e.g. “FSA run-out in 21 days”, “preventive visit available since January 1”, “open enrollment opens Oct 15”). No diagnosis, no procedure, no claim.
When a reminder is generated, copy is drafted via our AI proxy. PHI prompts are avoided by construction: the AI is given only calendar context, plan-shape context, and the member's typed commitment text from a previous Coach session (if any). We pass the “what this nudge is about” plain-language label, never the underlying clinical detail.
Every row below maps to a real table in our database. The “Why” column explains the purpose. The “Retention” column states what controls how long the row stays.
| What | Where | Source | Purpose | Retention |
|---|---|---|---|---|
| Self-reported health conditions | members.encrypted_conditions (AES-256-GCM ciphertext) |
Member-typed entry during Coach onboarding or in the employee portal | Tailor AI Coach prompts to the member's stated context. Never returned in API responses. | Until the member deletes their account, or 18 months of inactivity. |
| Self-reported health goals & risk factors | members.health_goals, members.risk_factors (TEXT[]) |
Member-typed entry during onboarding or in the employee portal | Score nudge relevance (e.g., a goal of “lose 10 lbs” matches activity-gap nudges). | Until the member deletes their account. |
| Uploaded Explanation of Benefits (EOB) & denials | claims table — fields: date_of_service, provider_name, provider_npi, cpt_codes, cpt_descriptions, billed_amount, denial_code, denial_reason_text, raw_eob_text, r2_url |
Member-uploaded PDF or manual entry into BillCheck / claim-appeal flows | Generate dispute letters and appeal reminders. Stripe-gated; free preview shows first 2 findings only. | Until the member deletes the claim, or 7 years, whichever is shorter. |
| BillCheck audit submissions | bill_check_audits — fields: visit_description, cpt_codes, cpt_descriptions, findings (JSONB) |
Member-typed visit description + billed CPT codes in BillCheck | Generate the dispute-letter pack. Paywalled ($14.99 one-time). | Until the member deletes the audit. |
| Prescription refill events | rx_refills — fields: drug_name, brand_name, dispensed_at |
Member-typed entry in the prescription-switch nudge flow | Flag generic-equivalent switches the next time a refill is logged. | 365 days rolling. |
| Coach session memory | coach_sessions — fields: commitment_text, biometric_type, biometric_reason, biometric_zip, created_at |
Member-typed free text in the AI Coach chat, plus biometric context only when the member opens a CTA | Carry the member's stated commitment across sessions so the Coach can lapse-check honestly. | 18 months rolling. |
Two notes on the schema above:
members.conditions is preserved for backward compatibility, but new writes go to members.encrypted_conditions only (null in the plaintext column).members.claims_history JSONB column exists from an early synthetic-data scaffold (migration 003_extend_members_synthetic.js). It is not populated from any external system. We do not rely on it for nudge logic.We are explicit here because being vague is what trips up compliance review. The list below is matched to the data we can prove we don't ingest, given the code and the migration history.
headache, fatigue) and an urgency tier — no symptom text, no clinical code, no PHI (see symptom_history and symptom_checker_events).members.external_id are synthetic dedupe keys generated at onboarding, not SSNs.rx_refills table holds only what the member types into the form.All traffic to and from NudgeWell is encrypted in transit using TLS 1.2 or higher. Member-supplied conditions are encrypted at rest using AES-256-GCM, with the key held in a managed secret store and excluded from backups. The ciphertext column members.encrypted_conditions is decrypted only in two narrow paths: the AI Coach prompt builder and the nudge-context join — the plaintext is never persisted and never returned in any API response.
There are exactly two roles that can read a member row: the member themselves (employee self-service) and the HR admin of the account the member belongs to. Cross-account access is denied at the query layer. Cross-tenant queries are audited.
Routes that touch PHI fields go through a db/phi-access.js helper that records who accessed what and when, with field names only — never field values. PHI writes are logged the same way. Both logPhiRead and logPhiWrite are wired into the coach, the employee portal coverage endpoint, the member fetch endpoints, and the chat-session routes.
Every PHI read reaches hr_activity_logs with the actor identity, timestamp, session ID, and the names of fields touched. Field values are not stored in the audit log — only field names. This audit log is queryable from the HR admin dashboard and is the basis for the access reports enterprise customers can request during procurement review.
NudgeWell is built on top of these vendors. Each acts on our behalf to deliver the product. We do not independently audit these vendors and do not display their certifications on your behalf.
| Vendor | Role | What they see |
|---|---|---|
| Render | Application hosting | Application code, environment config, runtime traffic. |
| Neon (serverless Postgres) | Database hosting | Encrypted database storage. At-rest encryption is Neon's. |
| Polsia OpenAI proxy | AI text generation (nudge copy + AI Coach) | Calendar context, plan-shape context, member's typed commitment text. Never PHI prompts by construction — see Section 2. |
| Polsia email proxy | Transactional email delivery | Member's email address and the rendered nudge copy. |
| Polsia R2 (Cloudflare) | Object storage for .ics calendar files |
Rendered calendar subscription files only. Member-uploaded EOBs sit here too (see claims.r2_url), encrypted at the application layer before upload. |
| NPI Registry (CMS) | Public provider lookup | Member-entered ZIP and provider specialty. Returns NPI listings. |
| Meta Pixel | Conversion tracking on marketing pages | Page-view and conversion events. No member identifiers. |
| Google Calendar OAuth | Optional calendar push of nudge events | A nudge event payload (a date and a one-line title) — only if the member linked their Google Calendar. |
NudgeWell is not a HIPAA covered entity. We do not market ourselves as “HIPAA-Compliant.” We have not completed an independent SOC 2 Type II audit, a HITRUST certification, or a formal HIPAA compliance attestation. We do not display third-party compliance badges anywhere on this site because we do not hold any.
For enterprise customers whose procurement process requires an executed Business Associate Agreement, we offer one. Contact enterprise@nudgewell.com. The technical posture that supports that BAA is exactly what is documented above: encryption in transit and at rest, access logging at the field-name level, account-scoped read authorization, and a clear “no carrier feed, no diagnosis, no clinical feed” data minimisation posture.
If a downstream compliance badge becomes necessary for a specific deal, we will earn it in writing before displaying it, not the other way around.
See also: Privacy Policy · HIPAA Compliance Disclosure · Terms of Service