Medical Claims — HIPAA/FHIR — Playbook
Audience: Healthcare providers, payers, TPAs, clearinghouses. Playbook Type: Match + Plan + Optimize loop Status: Soft (practice) — not yet LIVE Source: D-09 — Optimization Capability (developer) §1.2 (procurement.multi_source_fill@1), Claims Plane — Processing Claims, Guarded Transitions, and Declarative Packs §4 (medical claims pack)
1. Use & Purpose
Medical claims processing with HIPAA/FHIR boundaries — claims are adjudicated without declaring raw sensitive health fields. The playbook takes a medical claim from intake to settlement, using solver-assisted provider selection and multi-source fill, with PHI scrubbed from match facets and encrypted storage for clinical data.
Optimizers propose, claim gates authorize, never settle or pay.
2. Who Uses It
| Player | Role |
|---|---|
| Patient | Receives care, submits claim via provider |
| Provider (clinic/pharmacy) | Renders service, submits claim, provides evidence |
| Payer | Risk bearer, settlement payer |
| TPA | Claims administration (optional) |
| Adjuster | Loss assessment, approval |
| Reinsurer | Notice for high-value claims |
3. Flow
| Step | Actor | Action | Gate |
|---|---|---|---|
| 1 | Provider | Service rendered, clinical documentation created | PHI stored in MinIO (encrypted), hash reference only |
| 2 | Provider | Claim submitted via clearinghouse (EDI 837) through Camel gateway | SOAP/XML translation; PHI scrubbed from match facets |
| 3 | System | Claim created: cns://claim/type/healthcare/medical_claim, PoCE session started | Required fields validated; 400 if missing |
| 4 | Adjuster | Assigned via panel eligibility (two-person quorum for amounts > $500) | SOD: adjuster ≠ provider |
| 5 | Solver | procurement.multi_source_fill@1 recommends provider network fill branch_and_bound 1.4.0 | Fail closed: solver down → 503 |
| 6 | Human adjuster | Approves clinical review + payment amount | Named human confirms; clinical necessity checked |
| 7 | Payer | Settlement authorized against EOB | Evidence: service codes + clinical report |
| 8 | System | Claim finalized with PoCE receipt | All transitions recorded; receipt sealed |
| 9 | Provider | EOB transmitted via EDI 835 through Camel gateway | PHI-safe transmission |
4. Guard Rails
- PHI never in match facets. Sensitive clinical data stored in MinIO (encrypted), hash reference in claim metadata.
- Two-person quorum for claim amounts above $500.
- Medical lines demand service codes and clinical reports as evidence.
- Solver verdicts are gates, not approvals. Never settles or pays.
- External verdicts honoured. A negative verdict blocks settlement.
- HIPAA/FHIR boundaries. BBS+ selective disclosure; no raw PHI in public notices.
5. Evidence & Rollout
| Element | Detail |
|---|---|
| Version | 1.0.0 (Soft) |
| Source pack | Medical claims (Kenya) — cns://claim/type/healthcare/medical_claim |
| CNS types | cns://claim/type/healthcare/medical_claim, cns://resource/patient |
| Lookup values | Guard policies, quorum bands, SLA windows, panel roles, intake maps (NATS KV) |
| PoCE integration | fn::lifecycle::start_poce_session → record_poce_step → finalize_poce_session |
| Solver capability | procurement.multi_source_fill@1, engine branch_and_bound 1.4.0 |
| Camel routes | EDI 837 (inbound), EDI 835 (outbound), SOAP/XML translation |
| Rollout path | Soft → pilot with single provider network → LIVE gate |
| Low-resource behavior | Intake via provider portal/fax/API; verification via EHR sync or SMS code |
Soft ≠ LIVE honesty: Nothing sets live_gate_met without REAL probe results. Env flags alone never count.
6. What We Do Not Build
- No synthetic settlement. The solver never settles or pays; a named human approver confirms via PoCE.
- No PHI exposure. Clinical data encrypted at rest, accessed via BBS+ selective disclosure.
- No fake provider matches. Unqualified providers are never shortlisted.
- No synthetic "OPTIMAL" verdict. Solver down → 503 fail closed.
- No fake metrics (e.g., "99% auto-adjudication rate"). Live data or honest empty states.