How an organization connects, exactly where PHI is seen and not seen, the FHIR exports and imports, and everything a client needs to get started — explained at the tech, practical, and business levels.
Pick the altitude for your audience.
Members engage in Reality Health Games; engagement (points, badges, microcredentials, drops, events)
is written to Supabase (Postgres) with row-level security and an organization_id
on every row. A nightly edge function serialises engagement into HL7 FHIR R4 resources
(Observation, DiagnosticReport,
Provenance). Member identifiers are replaced with a one-way
HMAC-SHA256 token (privacy-preserving record linkage) and the 18 HIPAA
Safe-Harbor identifiers are stripped. The de-identified, tokenized bundle is delivered to a neutral
linkage service, which joins it to the partner's tokenized claims and returns cohort aggregates.
Integration is via SMART-on-FHIR OAuth2 APIs, FHIR Bulk Data $export (NDJSON),
or SFTP flat files for partners without a FHIR endpoint.
Your organization gets its own branded space in the Academy. Your members play and learn; the system records what they do automatically. Each night, a de-identified summary of that activity leaves FFH. If you (or your payer) want to know whether it moved the needle on ER visits, missed appointments, or screenings, we match our engagement data to your claims data through a neutral middle party — using scrambled ID codes, not names — and you get back a report. You don't install anything. If your system can send a data file, that's all the technical lift there is.
PHIt Insights turns engagement into proof of outcomes, in the health system's own data language, so it plugs into an HIE, a payer, or an EHR without custom work. It comes in three tiers: a free Community view (aggregate only) that surfaces gaps and resources; a paid Payer module that links to your claims to prove whether a program worked and what it saved; and a Grant engine the Foundation uses to measure and report outcomes to funders. Build once on a federal standard, reuse for every partner.
| Path | Best for | What it is |
|---|---|---|
| FHIR API (SMART on FHIR) | Health systems, HIEs, EHR-connected orgs | OAuth2 secured FHIR R4 read/write endpoints |
FHIR Bulk $export | Population-level programs | NDJSON export/import of the whole cohort |
| Flat file / SFTP | Orgs without a FHIR endpoint | CSV extract keyed to the privacy token |
Every path carries the same de-identified, tokenized payload. No path ever moves names or claims into FFH.
Four zones. Identity never crosses a boundary; only scrambled tokens do.
You (FFH) see only your own members' engagement — the same data you already hold because they're your users. You never see the payer's claims or anyone's diagnoses.
The payer sees only its own members' claims — never your engagement identities.
The matched, cross-linked dataset is de-identified, and the person who analyzes it — an FFH analyst or an external researcher — works on de-identified, aggregated data under an expert-determination methodology (or a Limited Data Set under a Data Use Agreement if dates/geography are needed). No single party ever holds both identities together. That is the whole design.
FHIR R4, the standard mandated by the 21st Century Cures Act. Base:
https://api.theforceforhealth.com/fhir/r4
| Data | FHIR resource | Endpoint |
|---|---|---|
| Engagement index / points / streak | Observation | GET /Observation?category=engagement |
| Badges & microcredentials | Observation | GET /Observation?category=credential |
| Certified Patient score | DiagnosticReport | GET /DiagnosticReport?code=certified-patient |
| Ledger / audit trail | Provenance | GET /Provenance |
| Whole population | Bulk NDJSON | GET /Group/[id]/$export |
| Data | FHIR resource |
|---|---|
| ER / hospital visits | Encounter |
| Cost / claims | ExplanationOfBenefit / Claim |
| Screenings (e.g., colonoscopy) | Procedure |
| Missed appointments | Appointment (status=noshow) |
// GET /Observation?category=engagement&_since=2026-07-01 { "resourceType": "Observation", "status": "final", "code": "engagement-index", "valueQuantity": { "value": 72, "unit": "index" }, "subject": { "identifier": { "system": ".../token", "value": "tok_9f3a1c…" } } }
SMART-on-FHIR OAuth2 client-credentials (POST /oauth2/token). Partners without a
FHIR stack use a REST/JSON + CSV-over-SFTP path and webhooks — same tokenized, de-identified payload.
The questions a client's IT, legal, and finance teams actually ask.
No. FFH only ever holds engagement data for its own users. Your claims stay on your side; the two are linked through a neutral service on scrambled tokens, and the analysis is de-identified.
Yes, by design. The reporting layer uses Safe-Harbor de-identified aggregates (not PHI). Any identified feed runs under a Business Associate Agreement with member consent. Nothing is pooled that would put both identities in one place.
At minimum, nothing technical — your members just engage. To measure outcomes, your team (or your payer) provides a claims/utilization extract, either via FHIR or a flat file keyed to the privacy token.
No. FHIR is the preferred path if you have it, but a CSV over secure SFTP works just as well. No installation on your side.
A branded instance is provisioned in under 30 minutes. A first de-identified engagement export follows the first cycle; an outcomes readout follows once a claims extract and the data agreement are in place.
Student data is governed by FERPA and COPPA and does not enter the claims-linkage product. The household and outcomes linkage runs first on the consented adult population.
You own your organization's data and your reports. FFH owns the platform and the aggregated, anonymized Network-level metrics used for benchmarking.
The Community view is free. The Payer analytics module is a paid subscription (per-member-per-month plus an analytics license), with an optional outcome-based component. Grant-funded delivery is scoped per program.
Seven steps. Most of the effort is paperwork, not engineering.
Fill this out on a discovery call to scope and provision a partner. In production it posts to
/api/onboard (Supabase); here it assembles the onboarding record you can copy.