🔵 PoC #1: Flexpa — Insurance Data Aggregator
Replace 6 manual OAuth integrations with 1 unified API call
1 What It Does
Flexpa is "Plaid for health insurance." Instead of maintaining 6 separate OAuth flows (Aetna, Anthem, Cigna, etc.), you call one API. Flexpa handles the insurer connections and returns FHIR-formatted claims data.
2 How It Fits in Architecture
→User selects insurer in app (existing screen)
→Flexpa Link SDK — replaces manual OAuth redirect. Patient consents once.
→Flexpa API — GET /ExplanationOfBenefits, /Patient, /Coverage
→Your backend — stores EOBs in existing DynamoDB (same schema)
→Existing app flow — no changes needed downstream
3 Integration Points
const response = await axios.get(
`https://api.flexpa.com/fhir/v1/ExplanationOfBenefits`,
{ headers: { Authorization: `Bearer ${flexpaAccessToken}` } }
);
✅ Pros
- Replaces all 6 manual OAuth integrations
- One API call instead of per-insurer flows
- Sandbox available, free during PoC
- FHIR R4 — compatible with existing data model
- Covers 100+ insurers in their network
⚠️ Cons
- Third-party dependency (Flexpa goes down, you go down)
- Cost at scale (Flexpa pricing TBD)
- Different data schema may need mapping
- Requires patient consent flow change
4 PoC Test Plan
- Get Flexpa sandbox API keys (free at flexpa.com/developers)
- Build minimal Flexpa Link consent screen in test environment
- Connect 1 test insurer (Aetna) via Flexpa
- Compare returned EOBs against existing Aetna handler output
- Verify data maps correctly to existing DynamoDB schema
- Test with real patient account (1 user, 1 insurer)
🟢 PoC #2: Plaid — HSA/FSA Bank Aggregation
Connect HSA/FSA bank accounts to see real-time balances and match transactions
1 What It Does
Pull HSA/FSA bank account balances and 24 months of transaction history. Then cross-reference transactions against Rekencile claims to show "HSA eligible" badges and remaining balances.
2 How It Fits in Architecture
→User links HSA account via Plaid Link SDK (new screen)
→Plaid /accounts/get — detect account type = "hsa"
→Plaid /transactions/get — pull 24mo of HSA transactions
→New Lambda — match HSA transactions against Rekencile EOBs
→App shows: HSA balance, eligible claims, reimbursed amounts
3 Integration Points
const accounts = await plaidClient.accountsBalanceGet({ access_token });
const hsaAccount = accounts.data.accounts
.find(a => a.type === 'investment' && a.subtype === 'hsa');
const txns = await plaidClient.transactionsGet({
access_token, start_date: '2024-01-01', end_date: today
});
✅ Pros
- Covers ALL HSA custodians via Plaid network
- Balance + transactions + investment holdings
- Plaid Link is battle-tested (used by 8000+ apps)
- Free sandbox environment
- Completes the financial picture with insurance claims
⚠️ Cons
- Additional permission request for patients (bank access)
- Plaid pricing at scale (per-linked-item)
- New screen flow needed in app
- FSA accounts harder (typically employer-managed cards)
4 PoC Test Plan
- Get Plaid sandbox credentials (free at dashboard.plaid.com)
- Add Plaid Link SDK to test environment
- Link a test HSA account (Fidelity, Lively, Optum sandbox)
- Pull balance and transactions
- Manually match 3-5 transactions against existing EOB data
- Verify "HSA eligible" classification matches IRS Pub 502 rules
🟡 PoC #3: Cost Estimation — Patient Responsibility
Show patients estimated costs before and after insurance claims
1 What It Does
Take the EOB data you already pull from insurers and enrich it with contracted rate data to show patients their estimated responsibility before claims process, and track what they've actually paid vs. owed.
2 How It Fits in Architecture
→EOB arrives from insurance (existing flow)
→New cost-estimation Lambda — cross-references procedure codes (CPT/HCPCS)
→Price transparency API — get contracted rate for provider+procedure
→Patient dashboard — shows: billed, allowed, patient responsibility, paid
3 Data Sources for Cost Estimates
Option A — DIY with existing EOB data (simplest):
Your EOBs already have: billed amount, insurance payment, patient responsibility. Add an "estimated vs actual" tracker per claim. No external API needed for PoC.
Option B — Change Healthcare Care Cost Estimator API:
Provider-focused. Requires provider NPI lookup. Good for in-network estimates. Has free sandbox.
Option C — CMS Hospital Price Transparency data:
Public data. Large machine-readable files (MRF) from hospitals. Complex to parse but free.
✅ Pros
- Strong patient value — "what do I owe?"
- Option A (DIY) needs no external APIs
- Leverages existing EOB data you already have
- Differentiator — most apps don't show cost estimates
⚠️ Cons
- True estimates need contracted rate data (not free)
- Accuracy depends on data completeness
- Option B/C require provider-level data
- Higher complexity than PoC 1 & 2
4 PoC Test Plan
- Take 5 existing EOBs from DynamoDB (with real amounts)
- Build simple "claim summary" view: billed vs. patient responsibility
- Add "payment tracker" — mark claims as paid/pending
- Test with 3 patient accounts
- If accurate enough → explore contracted rate API for refinement