How to get virtual visit eligibility checks right

Virtual healthcare visits are now common, but verifying patient eligibility for them isn't always straightforward.

Telehealth benefits vary by payer and plan, and it can be a challenge to accurately retrieve coverage details. Without accurate eligibility checks, providers risk billing issues, denied claims, and upset patients.

Stedi’s Real-Time Eligibility Check API gives you reliable, programmatic access to eligibility data as JSON. But access isn’t enough. To get the right eligibility information, it’s just as important to use the right service type code (STC) for the payer.

Why the STC matters

A service type code (STC) tells the payer exactly what benefit information you want. For example, STC 98 indicates a "Professional (Physician) Visit – Office."

The problem is that individual payers may return coverage details for virtual visits differently. Some payers treat virtual visits as office visits, some as separate telemedicine benefits, and others as general medical services.

As a result, different payers require different STCs for eligibility checks. For example, UnitedHealthcare (UHC) maps “VIRTUAL VISITS/TELEMEDICINE” to STC 9. Other payers use STC 98 or STC 30. Payers may use other STCs, such as MH or CF, for virtual mental health visits.

If you use the wrong STC in an eligibility check, the response may omit benefits or return only partial coverage information. This can lead to denied claims or billing surprises for the patient after care is delivered.

Find the virtual visit STC for each payer

To find the right STC for a payer, you’ll need to try multiple STCs, one at a time.

To check virtual visit STCs using the Real-Time Eligibility Check API:

1. Send an eligibility check request.
   In the request, use one of the following STCs at a time, in order, for each payer. Inspect each response before moving to the next STC.
   
   • 98 – Professional (Physician) Visit – Office

   • 9 – Other Medical

   • 30 – Health Benefit Plan Coverage
   
   An example Real-Time Eligibility Check request using STC 98:
   
   

   curl --request POST \
     --url https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3 \
     --header 'Authorization: <api-key>' \
     --header 'Content-Type: application/json' \
     --data '{
     "controlNumber": "123456789",
     "tradingPartnerServiceId": "AHS",
     "externalPatientId": "UAA111222333",
     "encounter": {
       "serviceTypeCodes": [
         "98"
       ]
     },
     "provider": {
       "organizationName": "ACME Health Services",
       "npi": "1999999984"
     },
     "subscriber": {
       "dateOfBirth": "19000101",
       "firstName": "Jane",
       "lastName": "Doe",
       "memberId": "123456789"
     }
   }'

   
   

2. Check the response for a matching code or phrase.
   Check the response’s benefitsInformation objects for the following eligibilityAdditionalInformationList.industryCode value:
   
   

   • 02 (Telehealth Provided Other than in Patient’s Home)

   • 10 (Telehealth Provided in Patient’s Home)
   
   The eligibilityAdditionalInformationList.industryCode is a CMS Place of Service code, which indicates the location where healthcare was provided. The 02 and 10 values are used for telehealth services.
   
   If the eligibilityAdditionalInformationList.industryCode isn’t present, check the benefitsInformation objects for an additionalInformation.description property that contains a phrase like:
   
   • "VIRTUAL VISITS"

   • "TELEMEDICINE"

   • "E-VISIT"

   
   

3. Stop at the first matching STC.
   Use the first matching STC for any future virtual visit eligibility checks with the payer.

   If you don’t find a match after checking all three STCs, fall back to interpreting the response based on STC 98.

Repeat the process for each required payer.

Interpret the eligibility response

After finding the right STC, use the Real-Time Eligibility Check API’s response to extract any needed eligibility information, such as:

• Whether the patient is eligible for a virtual visit

• Whether the patient will owe anything for the visit

• Whether the patient has a limited number of virtual visits

Most eligibility details are in the response’s benefitsInformation object array. Look for benefitsInformation objects containing the STC used by the payer for virtual visits. Then use the following guidelines to interpret the API response.

Patient eligibility

If benefitsInformation.name contains "Active Coverage", the patient is eligible for a virtual visit.

{
  ...
  "benefitsInformation": [
    {
      "code": "1",
      "name": "Active Coverage",
      ...
    }
  ],
  ...
}

Patient responsibility

Some plans require patients to pay a portion of the cost of care, such as a co-pay or deductible. This amount is called the patient responsibility.

You can use the benefitsInformation objects with benefitsInformation.code values A, B, C, F, G, and Y to determine the patient’s financial responsibility for a given STC. For a detailed guide on determining patient responsibility, see Patient costs in the Stedi docs.

Visit limits

Some payers and plans limit the number of covered visits, including virtual visits, per year. In many cases, these limits aren’t hard caps. Patients may be able to get additional benefits with approval, called prior authorization, from their payer.

If the benefitsInformation object’s code is F, the benefitsInformation object includes details about limitations like a numeric visit cap, time period, or other restrictions. However, not all payers return limitations consistently or in the same way.

{
  ...
  "benefitsInformation": [
    {
      "code": "F",
      "name": "Limitations",
      "additionalInformation": {
        "description": "20 visits per calendar year"
      },
      ...
    }
  ],
  ...
}

Most common pattern

The most common pattern is to return values in the following benefitsInformation object properties. For example:

• benefitsInformation.timeQualifierCode: "23" (Calendar year)

• benefitsInformation.quantityQualifierCode: "VS" (Visits)

• benefitsInformation.benefitQuantity: “<number>” (Number of allowed visits)

{
  ...
  "timeQualifierCode": "23",
  "timeQualifier": "Calendar Year",
  "quantityQualifierCode": "VS",
  "quantityQualifier": "Visits",
  "benefitQuantity": "20"
  ...
}

Benefits service delivery

Some payers may include visit limits in the benefitsInformation object’s benefitsServiceDelivery object array instead. For example:

• benefitsInformation.benefitsServiceDelivery.timePeriodQualifierCode: "23" (Calendar year)

• benefitsInformation.benefitsServiceDelivery.quantityQualifierCode: "VS" (Visits)

• benefitsInformation.benefitsServiceDelivery.quantity: "<number>" (Number of allowed visits)

{
  ...
  "benefitsServiceDelivery": [
    {
      "timePeriodQualifierCode": "23",
      "timePeriodQualifier": "Calendar Year",
      "quantityQualifierCode": "VS",
      "quantityQualifier": "Visits",
      "quantity": "20"
    },
    ...
  ],
  ...
}

Process eligibility checks with Stedi today

Eligibility checks don’t just confirm coverage. They remove uncertainty for patients and providers. With the Stedi Real-Time Eligibility Check and Batch Eligibility Check APIs, you can automate eligibility checks within minutes.

To start testing eligibility checks today, create a free sandbox. Or contact us to speak with our team and book a demo.