Fiduciary Ledger: The Three-Sided Settlement Orchestration

Traditional healthcare claims processing is a two-sided system: payer adjudicates, provider waits for payment, patient deals with balance bills. Turquoise TEP introduces a third dimension: the Fiduciary Ledger, a real-time orchestration layer that connects clinical intent (what was promised in the AEOB), contractual reality (what the Direct Contract allows), and financial settlement (what Stripe executes). This creates a triangular, deterministic payment flow with complete audit trails.

The Triangular Ledger Model

The Fiduciary Ledger sits at the intersection of three systems:

Clinical Intent (Top): The AEOB promises a patient a Maximum Cost Share. This is a binding forecast based on the expected scope of service. The clinical intent is "what we told the patient they would owe."

Contractual Reality (Left): The Direct Contract defines bundled rates, SSPs, provider shares, and pricing rules. The contractual reality is "what the contract actually allows us to pay."

Financial Settlement (Right): Stripe Connect executes payments atomically, splitting bundled rates among multiple providers, recording opaque trace_ids, and completing settlement in seconds. The financial settlement is "what actually moved out of the payer's account."

The Fiduciary Ledger at the center reconciles these three perspectives. If they don't align (e.g., actual claim cost exceeds AEOB forecast), the ledger captures the discrepancy (True-Up), the reconciliation, and the settlement.

Turquoise as a Deterministic Pricing & Orchestration Engine

This is critical: Turquoise TEP is not a bank, not a credit card processor, and not a financial institution. It is a deterministic pricing and orchestration engine. Turquoise never holds patient funds, never holds provider funds, and never settles its own transactions. Instead:

1. Payer authorizes payment via the Direct Contract and ClaimResponse.
2. Turquoise calculates pricing, validates bundling, and generates payment instructions.
3. Stripe executes the actual transfer from payer's account to provider account(s).

Turquoise's role is to ensure that every instruction to Stripe is deterministic, auditable, and reconcilable. Every dollar moved is tied to a clinical encounter, a contractual rate, and a patient.

The PaymentAdvice Flow

The PaymentAdvice is the Fiduciary Ledger's core workflow. It orchestrates the three-way handshake:

Step 1: Claim Submission & Approval

The provider submits one or more claims (professional and institutional). The payer (via a Trading Partner or in-house system) approves the claim and authorizes payment. Approval is communicated via a ClaimResponse with status = "active" and outcome = "complete".

Step 2: Validation & Pricing

TEP validates the claim against the applicable Direct Contract:

• Does the CPT code match an SSP in the contract?
• Is the facility type eligible (outpatient vs. inpatient)?
• Are all required providers present (surgeon, facility, anesthesia, etc.)?
• Is the claim cost within expected ranges?

If validation passes, TEP applies bundled pricing. If the SSP rate is $2,500 and the provider submitted a professional claim for $1,500, TEP recognizes this as a component of the $2,500 bundle and applies the contract rate instead of the submitted amount.

Step 3: Fiduciary Ledger Entry

TEP creates a Fiduciary Ledger entry with:

• EncounterID: Unique encounter identifier.
• ClaimID: Submitted claim identifier(s).
• SSP Applied: Which Standard Service Package was used.
• Bundled Rate: Total rate (e.g., $2,500).
• Provider Shares: Breakdown by provider (facility 40%, surgeon 35%, anesthesia 15%, pathology 10%).
• AEOB Reference: Links to the patient's Maximum Cost Share promise.
• Calculated Amounts: Exact dollar amounts to transfer to each provider.
• Timestamp: When the ledger entry was created.

Step 4: PaymentAdvice Generation

TEP generates a PaymentAdvice—a detailed, human-readable summary of:

• What will be paid, to whom, and how much.
• Which encounter and Direct Contract govern the payment.
• The audit trail (claim ID → encounter ID → contract ID).
• Any discrepancies (True-Up needed? AEOB overage? Fiduciary Adjustment?).

The PaymentAdvice is sent to the payer for secondary confirmation (optional but recommended for high-value or complex cases).

Step 5: Stripe Authorization & Transfer

Once approved, TEP sends a batch instruction to Stripe:

{
  "authorizedBy": "payer-user-id",
  "transfers": [
    {
      "amount": 1000,
      "currency": "USD",
      "destination": "acct_sharp_pavilion",
      "traceID": "tfer_OPAQ0002A1B2C3D4E5F6G7H8I9J0K1L",
      "metadata": {
        "encounterID": "ENC-2024-0001",
        "providerRole": "facility"
      }
    },
    {
      "amount": 875,
      "currency": "USD",
      "destination": "acct_surgeon_789",
      "traceID": "tfer_OPAQ0002A1B2C3D4E5F6G7H8I9J0K2M",
      "metadata": {
        "encounterID": "ENC-2024-0001",
        "providerRole": "surgeon"
      }
    },
    {
      "amount": 375,
      "currency": "USD",
      "destination": "acct_anesthesia_456",
      "traceID": "tfer_OPAQ0002A1B2C3D4E5F6G7H8I9J0K3N",
      "metadata": {
        "encounterID": "ENC-2024-0001",
        "providerRole": "anesthesia"
      }
    },
    {
      "amount": 250,
      "currency": "USD",
      "destination": "acct_pathology_lab",
      "traceID": "tfer_OPAQ0002A1B2C3D4E5F6G7H8I9J0K4O",
      "metadata": {
        "encounterID": "ENC-2024-0001",
        "providerRole": "pathology"
      }
    }
  ]
}

Each transfer has:

• Amount: The provider's share of the bundled rate.
• Destination: The provider's Stripe Connect account.
• TraceID: An opaque, randomly generated identifier (no PHI, no patient data).
• Metadata: Minimal fields (encounterID, providerRole) for reconciliation.

warning

CRITICAL: No PHI in Stripe

The metadata object in the Stripe transfer contains only the encounterID and providerRole. It does NOT contain:

• Patient name, DOB, or MRN
• Procedure details or diagnosis codes
• Claim IDs or billing information
• Any other protected health information (PHI)

The traceID is a one-way, opaque identifier. If someone gains access to Stripe data, they cannot identify which patient or which clinical service the payment corresponds to. PHI remains secure in TEP's encrypted ledger.

Step 6: Settlement & Confirmation

Stripe executes all transfers within seconds (typically < 2 seconds). Each transfer is atomic—either all succeed or none do. Stripe returns confirmation receipts with timestamps and final balance information.

TEP records the settlement in the Fiduciary Ledger:

{
  "ledgerEntryID": "LEDGER-2024-0001",
  "status": "settled",
  "settlementDate": "2024-03-11T09:35:00Z",
  "encounterID": "ENC-2024-0001",
  "transfers": [
    {
      "traceID": "tfer_OPAQ0002A1B2C3D4E5F6G7H8I9J0K1L",
      "provider": "Sharp Outpatient Pavilion",
      "amount": 1000,
      "status": "completed",
      "completedAt": "2024-03-11T09:35:02Z"
    },
    ...
  ],
  "totalSettled": 2500,
  "trueUpStatus": "pending"
}

TEP then sends the ClaimResponse (with the Stripe trace_ids embedded in extension fields) back to the provider and payer. The provider can now invoice the patient for their cost-share (if any) and reconcile their accounting. The payer records the settlement in their financial ledger.

The Paper Trail: Encounter → Payment

One of TEP's key features is auditability. A complete, traceable chain exists from clinical encounter to payment settlement:

1. Encounter Start: Patient arrives, service is rendered (2024-03-10).
2. AEOB Issued: Payer promises Maximum Cost Share of $300 (2024-03-08).
3. Claims Submitted: Provider submits professional + institutional claims (2024-03-11).
4. Claim Validated: TEP matches claims to SSP and Direct Contract (2024-03-11 09:00).
5. Pricing Applied: Bundled rate of $2,500 calculated and allocated by provider share (2024-03-11 09:15).
6. Payment Authorized: Payer approves fund flow via ClaimResponse (2024-03-11 09:20).
7. Stripe Transfer: Four transfers initiated to provider accounts (2024-03-11 09:25).
8. Settlement Confirmed: Stripe confirms all transfers complete (2024-03-11 09:35).
9. Ledger Recorded: Fiduciary Ledger entry created with all trace_ids (2024-03-11 09:40).
10. True-Up Check: If AEOB ≠ actual cost, reconciliation scheduled (2024-03-11 10:00).

At any point, an auditor can ask: "What happened to the $375 transfer to the anesthesiologist?" The answer:

• Trace ID: tfer_OPAQ0002A1B2C3D4E5F6G7H8I9J0K3N
• Linked to: EncounterID ENC-2024-0001
• Linked to: ClaimResponse claimresponse-enc-2024-0001
• Linked to: Direct Contract SHARP-GI-2024
• Linked to: AEOB AEOB-2024-0001
• Linked to: Patient encounter (2024-03-10, Sharp Outpatient Pavilion, CPT 00810)

The paper trail is complete and cryptographically signed.

True-Up Reconciliation in the Ledger

True-Up is handled within the Fiduciary Ledger. After settlement, TEP compares the AEOB's Maximum Cost Share forecast to the actual claim cost:

True-Up Example 1: Overpayment (AEOB > Actual)

• AEOB forecast: $2,500 (patient cost-share: $300)
• Actual claim: $2,200 (patient cost-share should be: $264)
• Delta: $36 patient overpayment

Ledger entry:

{
  "trueUpStatus": "refund_pending",
  "trueUpType": "overpayment",
  "aeobForecast": 2500,
  "actualClaim": 2200,
  "delta": 300,
  "patientRefundAmount": 36,
  "payer_providerAdjustment": 264
}

TEP initiates a refund to the patient within 24 hours via Stripe (to the payment method on file). The provider's payment is adjusted accordingly (provider receives $1,936 instead of $2,200, the difference of $264 goes back to the payer).

True-Up Example 2: Underpayment (Actual > AEOB)

• AEOB forecast: $2,500 (patient cost-share cap: $300)
• Actual claim: $2,800
• Patient liability should be: $420 (at 15% cost-share), but capped at $300 (AEOB).
• Delta: $120 Fiduciary Adjustment (payer-to-provider)

Ledger entry:

{
  "trueUpStatus": "fiduciary_adjustment_pending",
  "trueUpType": "underpayment",
  "aeobForecast": 2500,
  "actualClaim": 2800,
  "delta": 300,
  "patientCap": 300,
  "fiduciaryAdjustmentAmount": 120,
  "fiduciaryAdjustmentReason": "Actual claim exceeded AEOB forecast; patient protected by price lock"
}

The patient is not billed more than $300 (AEOB price lock). The provider is not paid the full $2,800 (contract rate applies). The $120 difference is a Fiduciary Adjustment settled between payer and provider. This is tracked in the ledger and reconciled monthly.

info

Fiduciary Adjustment Definition (Revisited):

A Fiduciary Adjustment is a payment made between payer and provider (or provider and payer) when actual claim costs exceed the contractual bundled rate. The patient is never exposed to this delta—they are protected by the AEOB's Maximum Cost Share cap. The Fiduciary Adjustment is a contractual obligation between payer and provider, not a patient liability.

Stripe Connect Integration

Stripe Connect is a managed payments platform that allows sub-accounts (in this case, provider accounts) to receive payments from a master account (the payer). TEP uses Stripe Connect to:

1. Atomic Transfers: Multiple providers are paid from a single encounter-level instruction. If any transfer fails, the entire batch is rejected (no partial payments).
2. Opaque Trace IDs: Each transfer gets a unique, non-guessable trace_id that cannot be reverse-engineered to reveal PHI.
3. Account Segregation: Each provider has a separate Stripe Connect sub-account. Payment splits are enforced at the platform level, not in TEP application logic.
4. Audit Trails: Stripe maintains its own audit logs (separate from TEP). Both sets of logs can be cross-referenced for reconciliation.

TEP's Stripe integration is characterized by:

• Transfer Groups: Multiple transfers from a single encounter are tagged with the same Transfer Group ID, making batch reconciliation easy.
• Idempotency: If TEP re-submits the same payment instruction (due to network failure), Stripe uses the idempotency key to detect duplicates and prevent double-payment.
• Metadata: Only opaque identifiers and minimal metadata are stored in Stripe. Clinical and financial details stay in TEP.

Ledger Queries and Reconciliation

The Fiduciary Ledger supports several query patterns:

Query	Purpose	Result
ledger.search(encounterID)	Find all payments for an encounter	List of settlement records, True-Up status, trace_ids
ledger.search(traceID)	Reverse-lookup: which encounter is this payment for?	Encounter ID, claimID, provider role, amount
ledger.search(directContractID, dateRange)	Find all payments under a contract in a time period	Aggregate settlement amounts, count of encounters, True-Up summary
ledger.search(status="pending_trueup")	Find unresolved True-Up entries	List of encounters awaiting reconciliation, delta amounts
ledger.audit(encounterID)	Full audit trail for one encounter	Timeline of all events (GFE → AEOB → claim → settlement → true-up)

Key Design Principles

The Fiduciary Ledger embodies three design principles:

1. Determinism: Pricing is never ambiguous. Given a claim, a Direct Contract, and an SSP, the price is determined by formula. No adjudication surprises, no manual overrides.

2. Auditability: Every transaction is recorded and traceable. A dollar can be traced from encounter to settlement to ledger entry to Stripe transfer.

3. Patient Protection: The AEOB Maximum Cost Share is a binding promise. The patient cannot be billed more, regardless of claim complexity or cost overruns. Provider-payer disputes are settled as Fiduciary Adjustments, not patient balance bills.

Next Steps

Refer back to Encounter Lifecycle for context on when True-Up occurs. See Fast FHIR R4 Mapping for the ClaimResponse structure that triggers Fiduciary Ledger entries. For API details on submitting claims and querying the ledger, see the Submit Claim and Ledger Entries endpoints.