Third Party Administrator (TPA) — Claims Player
Audience: Claims outsourcing firms, managed service providers, benefit administrators. Role: Claims handling agent, adjudication coordinator, vendor manager. Substrate: truth_node:organization, APF roles, PoCE sessions, integration_entity (client mirror).
1. Role in Claims Processing
A TPA handles claims on behalf of an insurer or self-funded employer. The TPA does not bear risk — it administers the claims process: intake, adjudication, vendor management, and settlement coordination. The TPA configures the Sovereign OS claims engine with its client's CNS types, lookup values, and panel roles.
| Function | Canonical Primitive | Example |
|---|---|---|
| Client relationship | truth_node:organization | Self-funded employer or insurer client |
| Claims administration | claim (adjudication lifecycle) | Intake → validate → approve/reject → settle |
| Vendor management | integration_entity (provider mirror) | Garage, clinic, contractor networks |
| Settlement coordination | fn::escrow::hold / fn::escrow::disburse | Payment released against verified proof |
2. Capabilities & Attestations
| Capability | Required For | Attestation Source |
|---|---|---|
claims_adjudication | TPA adjuster role | Claims adjuster certification |
vendor_management | TPA vendor coordinator | Vendor credentialing |
intake_processing | TPA intake specialist | HIPAA/privacy training (healthcare) |
evidence_review | TPA reviewer | Claims audit certification |
All capabilities require: approved affiliation + active status + attestation. Lease TTLs: one hour for operational roles.
3. Panel Eligibility — TPA
TPAs operate as a panel organisation role for their client's claim types. The declarative panel values define which TPAs are eligible for which claim types and amounts:
| Client Vertical | TPA Roles | Quorum Pattern |
|---|---|---|
| Insurance (motor/home) | Adjuster + reviewer | Two-person for amounts > $500 |
| Healthcare (medical/pharmacy) | Clinical reviewer + utilization reviewer | Two-person for prior auth |
| Government (benefit/compensation) | Agency officer + cross-agency reviewer | Cross-agency quorum |
| Commerce (order/refund) | CS agent + finance | Two-person for amounts > $1,000 |
The resolver returns eligible versus ineligible-with-reasons. A TPA missing capability or attestation for a claim type is ineligible.
4. Guard Boundaries — TPA
| Boundary | Enforcement |
|---|---|
| No risk-bearing | TPA never approves settlement above its authority band; escalates to insurer/client |
| No auto-approval | Creator cannot approve own claim; SOD enforced |
| No synthetic evidence | Missing evidence refused with clear error; never invented |
| No fake metrics | TPA dashboard renders live data or honest empty states |
| Client data isolation | s184_record_federation boundaries between TPA clients |
5. Worked Example — TPA Medical Claims Administration
- Client (self-funded employer) configures claim types:
cns://claim/type/healthcare/medical_claim. - Employee submits claim via TPA portal (intake map: patient, service codes, provider NPI).
- TPA adjuster assigned via panel eligibility (clinical reviewer for medical claims).
- Clinical review — service codes validated against diagnosis, medical necessity checked.
- Prior authorization — medical director approves (quorum: adjuster + medical director).
- Claim settled — payment authorized against EOB, escrow released to provider.
- Reconciliation report — TPA provides client with claims summary (live data only, no invented metrics).
Guard check: Clinical reviewer ≠ Provider. PHI never in match facets. No settlement without PoCE proof receipt.
6. What We Do Not Build
- No TPA-specific tables. All TPA claim data maps to canonical primitives.
- No risk underwriting. The TPA does not bear risk; the insurer or self-funded employer does.
- No synthetic adjudication. AI help is advice only; never advances governance.