How claims and eligibility checks work for value-based care

Most healthcare providers get paid the same way a plumber or mechanic does: They deliver a service, send a bill, and collect payment.

In healthcare, that bill is called a claim. The insurer who receives the claim is called the payer.

This model, fee-for-service (FFS), is the most common payment model in US healthcare.

Value-based care (VBC) is an alternative. Instead of paying per service, payers pay based on patient outcomes.

VBC also changes the way standard healthcare transactions, like claims and eligibility checks, fit in. This guide covers how.

What is fee-for-service?

In a fee-for-service (FFS) model, a healthcare provider (like a doctor, dentist, therapist, or hospital) submits a claim to the payer for each service they deliver.

You can think of the claim as an itemized bill. Every service has its own line item, called a service line. The payer pays each service line separately.

If you visit a doctor for a check-up and get a flu shot during the same visit, that's two separate service lines. It could even be two separate claims.

The FFS model creates a direct link between volume and revenue. More patients and more procedures lead to more claims and more revenue for the provider.

What is value-based care?

Value-based care (VBC) is a spectrum of payment models intended to reward providers for keeping patients healthy, not delivering services. Common VBC payment models include:

• Pay-for-performance, which adds quality bonuses on top of standard FFS claims.

• Bundled payments that group all services for a specific episode under a single payment.

• Population-based arrangements, like Accountable Care, that replace FFS entirely.

Risk models for population-based arrangements

In population-based VBC arrangements, payers pay providers based on the quality and cost of care for a specific group of patients, called a patient population.

In most of these arrangements, the payer sets a benchmark, an estimate of what the payer expects to spend on the provider's patient population over the year. The benchmark is based on historical spending and adjusted for factors like patient age, health status, and regional cost trends.

How the provider is paid depends on the VBC arrangement’s risk model. Common VBC risk models include:

• Shared savings (upside only): Providers receive standard fee-for-service payments throughout the year. At year end, if actual spending comes in under the benchmark, the provider earns a bonus. No penalty if it doesn't.

• Risk-based (two-sided): Providers receive standard fee-for-service payments throughout the year. At year end, the provider earns a bonus if spending comes in under the benchmark, and a penalty if it goes over.

• Full capitation: The payer pays the provider a fixed monthly amount for each patient, called a per-member-per-month (PMPM) payment. The payer and provider have to agree in advance on the patient roster. Patients gain and lose coverage over time. Both sides typically go through a formal process to align on who's included before the PMPM is calculated.

Full capitation

You can think of capitation as a retainer: The provider takes responsibility for a defined group of patients, and the payer covers a flat monthly fee – the PMPM – for each one.

The provider earns the same PMPM regardless of how often each patient is seen. The provider absorbs losses if total costs exceed the capitation amount, and keeps any surplus if costs come in under.

In most full capitation contracts, there's a ceiling on how much the provider can lose. If a patient's care gets extremely expensive (say, a catastrophic illness), the payer steps in and covers costs above a certain threshold. Contracts may also carve out exceptions for other scenarios, like care outside the provider's network or when a patient travels out of the area.

Do value-based care providers run eligibility checks?

Yes. Providers run eligibility checks to confirm a patient is covered before delivering care. A patient's insurance coverage can change at any time, even if the payer is using a VBC model. For example, the patient might lose insurance, switch plans, or get Medicare coverage.

If the patient isn't covered, most providers will need to collect payment directly from the patient or submit a claim to their new payer.

An eligibility response may not directly indicate whether a patient is part of a patient population for a VBC arrangement. Providers may need to interpret other eligibility response details, like the group number, to determine whether the patient falls under a VBC arrangement.

Do value-based care providers still submit claims?

Yes. Most VBC arrangements require providers to report every patient encounter to the payer, even when no fee is charged. The payer uses this data to track which patients received what care and to set benchmarks.

Providers report patient encounters with claim submissions. You can submit encounter claims electronically just like a normal FFS claim, with one key difference: Most payers require you to set the claim identifier, also called the encounter identifier or transaction type code, to RP (Reporting).

In some cases, the payer may also require you to set the charge amounts for the claim and its service lines to zero. Other payers expect charges but don’t pay based on them. Check with the payer before submitting encounter claims to confirm.

Claim identifier

Claim charge amount

Service line charge amount

Zero-dollar claims

Some payers expect all charge amounts to be set to $0 on encounter claim submissions. This is common in VBC arrangements for commercial payers. An example zero-dollar claim using the JSON 837P Professional Claims Submission API endpoint:

curl --request POST \
  --url "https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/professionalclaims/v3/submission" \
  --header "Authorization: <api_key>" \
  --header "Content-Type: application/json" \
  --data '{
    "claimIdentifier": "RP",  // Reporting. Typically used for encounter claims.
    ...
    "claimInformation": {
      "claimChargeAmount": "0.00",
      ...
      "serviceLines": [
        {
          ...
          "professionalService": {
            "lineItemChargeAmount": "0.00",
            ...
          }
        }
      ]
    }
  }'

curl --request POST \
  --url "https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/professionalclaims/v3/submission" \
  --header "Authorization: <api_key>" \
  --header "Content-Type: application/json" \
  --data '{
    "claimIdentifier": "RP",  // Reporting. Typically used for encounter claims.
    ...
    "claimInformation": {
      "claimChargeAmount": "0.00",
      ...
      "serviceLines": [
        {
          ...
          "professionalService": {
            "lineItemChargeAmount": "0.00",
            ...
          }
        }
      ]
    }
  }'

curl --request POST \
  --url "https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/professionalclaims/v3/submission" \
  --header "Authorization: <api_key>" \
  --header "Content-Type: application/json" \
  --data '{
    "claimIdentifier": "RP",  // Reporting. Typically used for encounter claims.
    ...
    "claimInformation": {
      "claimChargeAmount": "0.00",
      ...
      "serviceLines": [
        {
          ...
          "professionalService": {
            "lineItemChargeAmount": "0.00",
            ...
          }
        }
      ]
    }
  }'

curl --request POST \
  --url "https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/professionalclaims/v3/submission" \
  --header "Authorization: <api_key>" \
  --header "Content-Type: application/json" \
  --data '{
    "claimIdentifier": "RP",  // Reporting. Typically used for encounter claims.
    ...
    "claimInformation": {
      "claimChargeAmount": "0.00",
      ...
      "serviceLines": [
        {
          ...
          "professionalService": {
            "lineItemChargeAmount": "0.00",
            ...
          }
        }
      ]
    }
  }'

curl --request POST \
  --url "https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/professionalclaims/v3/submission" \
  --header "Authorization: <api_key>" \
  --header "Content-Type: application/json" \
  --data '{
    "claimIdentifier": "RP",  // Reporting. Typically used for encounter claims.
    ...
    "claimInformation": {
      "claimChargeAmount": "0.00",
      ...
      "serviceLines": [
        {
          ...
          "professionalService": {
            "lineItemChargeAmount": "0.00",
            ...
          }
        }
      ]
    }
  }'

Shadow claims

Some payers require the provider's actual submitted charges on encounter claims rather than $0. These are called shadow claims or shadow pricing. The payer uses the charge data for rate-setting and benchmarking. No payment is made against it. An example using the JSON 837P Professional Claims Submission API endpoint:

curl --request POST \
  --url "https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/professionalclaims/v3/submission" \
  --header "Authorization: <api_key>" \
  --header "Content-Type: application/json" \
  --data '{
    "claimIdentifier": "RP",  // Reporting. Typically used for encounter claims.
    ...
    "claimInformation": {
      "claimChargeAmount": "150.00",
      ...
      "serviceLines": [
        {
          ...
          "professionalService": {
            "lineItemChargeAmount": "150.00",
            ...
          }
        }
      ]
    }
  }'

curl --request POST \
  --url "https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/professionalclaims/v3/submission" \
  --header "Authorization: <api_key>" \
  --header "Content-Type: application/json" \
  --data '{
    "claimIdentifier": "RP",  // Reporting. Typically used for encounter claims.
    ...
    "claimInformation": {
      "claimChargeAmount": "150.00",
      ...
      "serviceLines": [
        {
          ...
          "professionalService": {
            "lineItemChargeAmount": "150.00",
            ...
          }
        }
      ]
    }
  }'

curl --request POST \
  --url "https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/professionalclaims/v3/submission" \
  --header "Authorization: <api_key>" \
  --header "Content-Type: application/json" \
  --data '{
    "claimIdentifier": "RP",  // Reporting. Typically used for encounter claims.
    ...
    "claimInformation": {
      "claimChargeAmount": "150.00",
      ...
      "serviceLines": [
        {
          ...
          "professionalService": {
            "lineItemChargeAmount": "150.00",
            ...
          }
        }
      ]
    }
  }'

curl --request POST \
  --url "https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/professionalclaims/v3/submission" \
  --header "Authorization: <api_key>" \
  --header "Content-Type: application/json" \
  --data '{
    "claimIdentifier": "RP",  // Reporting. Typically used for encounter claims.
    ...
    "claimInformation": {
      "claimChargeAmount": "150.00",
      ...
      "serviceLines": [
        {
          ...
          "professionalService": {
            "lineItemChargeAmount": "150.00",
            ...
          }
        }
      ]
    }
  }'

curl --request POST \
  --url "https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/professionalclaims/v3/submission" \
  --header "Authorization: <api_key>" \
  --header "Content-Type: application/json" \
  --data '{
    "claimIdentifier": "RP",  // Reporting. Typically used for encounter claims.
    ...
    "claimInformation": {
      "claimChargeAmount": "150.00",
      ...
      "serviceLines": [
        {
          ...
          "professionalService": {
            "lineItemChargeAmount": "150.00",
            ...
          }
        }
      ]
    }
  }'

Claim acknowledgments and ERAs

Stedi and the payer return 277CA claim acknowledgments for encounter claims as normal. Because there's no claim payment, no related ERA is typically returned.

ERAs for provider adjustments

Under VBC, payers may also send ERAs for provider-level adjustments – credits and debits not tied to a specific claim. Common examples include:

• Capitation payments: PMPM or other payments related to care for a patient population.

• Quality bonuses: Bonus payments sent at the end of a performance period when a provider meets quality benchmarks.

• Recoupments: Adjustments used to claw back previous overpayments.

These appear as provider-level adjustments in the ERA. Each adjustment includes a Provider Adjustment Reason Code that explains why the payer made the adjustment. A negative amount is a credit to the provider. A positive amount is a debit, such as a recoupment.

For example, in the ERA Report API response:

{
  "transactions": [
    {
      ...,
      "providerAdjustments": [
        {
          "adjustments": [
            {
              "adjustmentReasonCode": "CV",           // Capitation Payment
              "providerAdjustmentAmount": "-5000.00", // Credit to provider (negative amt)
            },
            {
              "adjustmentReasonCode": "BN", // Bonus, such as a quality payment
              "providerAdjustmentAmount": "-1200.00",
            },
            {
              "adjustmentReasonCode": "OA", // Other adjustment. In this case, recoupment.
              "providerAdjustmentAmount": "300.00", // Debit to provider (positive amt)
              "providerAdjustmentIdentifier": "RECOUP-94060555" // ID used for reconciliation
            }
          ],
          ...
        }
      ]
    }
  ]
}

{
  "transactions": [
    {
      ...,
      "providerAdjustments": [
        {
          "adjustments": [
            {
              "adjustmentReasonCode": "CV",           // Capitation Payment
              "providerAdjustmentAmount": "-5000.00", // Credit to provider (negative amt)
            },
            {
              "adjustmentReasonCode": "BN", // Bonus, such as a quality payment
              "providerAdjustmentAmount": "-1200.00",
            },
            {
              "adjustmentReasonCode": "OA", // Other adjustment. In this case, recoupment.
              "providerAdjustmentAmount": "300.00", // Debit to provider (positive amt)
              "providerAdjustmentIdentifier": "RECOUP-94060555" // ID used for reconciliation
            }
          ],
          ...
        }
      ]
    }
  ]
}

{
  "transactions": [
    {
      ...,
      "providerAdjustments": [
        {
          "adjustments": [
            {
              "adjustmentReasonCode": "CV",           // Capitation Payment
              "providerAdjustmentAmount": "-5000.00", // Credit to provider (negative amt)
            },
            {
              "adjustmentReasonCode": "BN", // Bonus, such as a quality payment
              "providerAdjustmentAmount": "-1200.00",
            },
            {
              "adjustmentReasonCode": "OA", // Other adjustment. In this case, recoupment.
              "providerAdjustmentAmount": "300.00", // Debit to provider (positive amt)
              "providerAdjustmentIdentifier": "RECOUP-94060555" // ID used for reconciliation
            }
          ],
          ...
        }
      ]
    }
  ]
}

{
  "transactions": [
    {
      ...,
      "providerAdjustments": [
        {
          "adjustments": [
            {
              "adjustmentReasonCode": "CV",           // Capitation Payment
              "providerAdjustmentAmount": "-5000.00", // Credit to provider (negative amt)
            },
            {
              "adjustmentReasonCode": "BN", // Bonus, such as a quality payment
              "providerAdjustmentAmount": "-1200.00",
            },
            {
              "adjustmentReasonCode": "OA", // Other adjustment. In this case, recoupment.
              "providerAdjustmentAmount": "300.00", // Debit to provider (positive amt)
              "providerAdjustmentIdentifier": "RECOUP-94060555" // ID used for reconciliation
            }
          ],
          ...
        }
      ]
    }
  ]
}

{
  "transactions": [
    {
      ...,
      "providerAdjustments": [
        {
          "adjustments": [
            {
              "adjustmentReasonCode": "CV",           // Capitation Payment
              "providerAdjustmentAmount": "-5000.00", // Credit to provider (negative amt)
            },
            {
              "adjustmentReasonCode": "BN", // Bonus, such as a quality payment
              "providerAdjustmentAmount": "-1200.00",
            },
            {
              "adjustmentReasonCode": "OA", // Other adjustment. In this case, recoupment.
              "providerAdjustmentAmount": "300.00", // Debit to provider (positive amt)
              "providerAdjustmentIdentifier": "RECOUP-94060555" // ID used for reconciliation
            }
          ],
          ...
        }
      ]
    }
  ]
}

Can a provider support both fee-for-service and value-based care?

Yes. A provider organization might have a PMPM contract with one payer and bill fee-for-service to others. For example, a practice might have:

• A PMPM contract with one payer for Medicare Advantage patients

• Fee-for-service billing with other payers and plans they're in network with

Some VBC models, like Accountable Care Organizations (ACOs), also layer bonuses or other shared savings on top of a traditional fee-for-service structure.

Get started with Stedi

You can use Stedi to submit claims and run eligibility for providers billing under value-based care or a fee-for-service model.

To get started, sign up for our free Basic plan. It includes 100 free claim submissions and 100 free eligibility checks each month.