9 common questions about EMS claims and eligibility checks
Guide
Emergency medical services (EMS) billing doesn't look like other healthcare billing. There's no front-office intake for an ambulance ride (or flight).
Instead, paramedics capture what information they can at the scene, often while delivering emergency care. EMS billers often have to check insurance coverage after transport, not before.
EMS claims carry their own quirks. They have to include ambulance-specific origin and destination procedure modifiers. Use the wrong modifier and the claim gets rejected.
This guide covers nine things to know when building eligibility checks and claim workflows for EMS providers using Stedi.
1. How can I figure out if a patient is covered by multiple insurance plans?
If you don't know whether the patient has coverage or who the payer is, start with an insurance discovery check. You can run one using just demographics, like name and date of birth (DOB), with or without a Social Security Number (SSN).
Once you have a payer, run an eligibility check to confirm the patient's first name, last name, DOB, and member ID match what’s on file with the payer. Follow up with a Coordination of Benefits (COB) check to find any additional payers.
COB scenarios are common for EMS. For example, older patients are often dual eligible, with both Medicare and Medicaid.
2. Should I use batch or real-time eligibility checks for EMS services?
When to use real-time eligibility checks
If your EMS crews run eligibility checks in transit or you need a response in seconds, use real-time eligibility checks. They also work for time-insensitive scenarios, like verifying insurance before submitting a claim.
If your workflow includes a mix of time-sensitive and time-insensitive scenarios, start with real-time checks to keep things simple. Move to batch checks if you're running thousands of time-insensitive checks at once and building custom logic to handle them.
When to use batch eligibility checks
If you only ever verify insurance after care is delivered, use batch eligibility checks. Stedi's batch checks let you submit many requests at once and return the same coverage and benefits data in the same fields as a real-time check.
Batch eligibility checks also include automatic retries and longer retry windows, so a single request is more likely to come back with a complete response.
You can submit batch checks using our API or by uploading CSVs to the Stedi portal.
3. Which STCs should I use for EMS-related eligibility checks?
In an eligibility request, a Service Type Code (STC) tells the payer what kind of benefits you're checking. But not every payer supports the same STCs.
Testing is the best way to find out which STCs work for each payer. Our docs cover general STC testing tips. Here's specific guidance for EMS providers.
Step 1. Start with STC 30 (Health Benefit Plan Coverage)
Begin with STC 30 as your baseline. You’ll use the response to test whether the payer supports more specific STCs.
Many payers fall back to their STC 30 response if you submit an STC they don't support.
Payers aren't obligated to return ambulance benefits under STC 30. Transport STCs also aren't in the CAQH CORE required response set. You'll usually need to send a transport-specific STC to get EMS benefits.
Step 2. Test EMS-specific STCs
Try one or more STCs from the following table.
STC | Description | Use for |
| Licensed Ambulance | Ground or air ambulance services (emergency or non-emergency) |
| Cabulance | Non-emergency transport in a wheelchair van, stretcher van, or taxi |
| Air Transportation | Fixed-wing or rotary-wing air ambulance |
| Medically Related Transportation | Broad fallback for any medically necessary transport |
Example: Active ambulance benefit returned for STC 59
Send one STC per eligibility request. Many payers don't support multiple STCs in a single check. If you use multiple STCs, some payers may reject the request. Others may return a default response or only use the first STC provided.
Step 3. Compare the eligibility responses
Compare the payer's responses for STC 30 and the transport STC you tested.
If an STC returns transport coverage that STC 30 didn't, the payer supports that STC. Use that STC in future eligibility checks for that payer.
Repeat the process for each payer. You can't assume STCs that work for one payer apply to another.
Tip: Use a script to loop and diff
You can script your eligibility requests to speed up the testing process. Specifically, you should loop through candidate STCs and compare the responses against the baseline STC 30 response for the same patient. If you’re using Stedi’s JSON Eligibility API, you can save the benefitsInformation array for each STC and diff them.
For more tips, see our STC testing docs.
4. How do I find ambulance carveouts in eligibility responses?
A carveout is when the primary payer for a plan lets another entity handle certain benefits. Many plans carve out benefits for EMS and ambulance services to a third-party administrator.
For example, some Medicaid managed care organizations (MCOs) carve out ambulance benefits to fee-for-service Medicaid.
Payers aren’t required to return carveout benefits in eligibility checks. Most don't. Many do return the carveout admin’s information.
Look for a related benefit entry with an active-coverage or contact-entity flag, a transport-related Service Type Code (STC), and the carveout admin's contact info. Free-text phrases like AMBULANCE SERVICES MANAGED SEPARATELY may sit in a separate benefit-description entry.
When to look for | JSON Eligibility API field | 271 X12 element |
A benefit code of |
| |
An EMS-related Service Type Code (STC) |
| |
The carveout admin's contact info | Loop | |
The patient's member ID with the carveout admin (if present) |
| |
Free-text descriptions. These are often in a separate entry with a benefit code of |
|
For example, in Stedi’s JSON Eligibility API response:
To learn more, see our carveout benefits docs.
5. Do I use a professional or institutional claim for ambulance services?
Most EMS providers bill electronically using an 837P professional claim. You can submit a professional claim with Stedi using our JSON API, X12 API, or SFTP.
Some hospital-based ambulance services may bill under the hospital's fee structure using an institutional claim, but it’s less common.
6. How do I send the patient care report with an electronic claim?
What’s a patient care report?
A patient care report (PCR) is a document that captures a patient's condition, transport details, and interventions. It’s the primary billing record and clinical documentation for EMS transport.
Many payers require a PCR to reimburse EMS-related claims. Most EMS crews complete the PCR after every transport.
Submit patient care reports as claim attachments
If the payer supports electronic attachments, you can submit the PCR using our JSON API, X12 API, or SFTP. You can check payer support using the Stedi Payer Network or the Payers API.
For example, in the Search Payers API response:
To learn more, see our claim attachment docs.
7. How do I bill base transport and mileage on a claim?
Submit them as two separate service lines, one for base transport and one for mileage.
For example, in the Stedi JSON Professional Claims Submission API request body:
Common HCPCS codes for transport and mileage
The following table outlines common HCPCS procedure codes for EMS transport and mileage.
HCPCS | Service |
| Ground ambulance mileage, per statute mile |
| Advanced life support (ALS) level 1, non-emergency transport |
| Advanced life support (ALS) level 1, emergency transport |
| Basic life support (BLS), non-emergency transport |
| Basic life support (BLS), emergency transport |
| Fixed-wing air ambulance, one way |
| Rotary-wing air ambulance, one way |
| Advanced life support (ALS) level 2, emergency |
| Specialty care transport (SCT) |
| Fixed-wing mileage, per statute mile |
| Rotary-wing mileage, per statute mile |
Loaded miles
For Medicare and most payers, only loaded miles – miles with the patient onboard – are billable on the mileage line. Check with the payer for their specific mileage rules.
8. Which origin and destination modifiers should I use?
In a professional claim, a procedure modifier is a two-character code added to a HCPCS or CPT code that provides additional context about the service.
Procedure modifier in 837P claims
837P X12 element | |
|
For ambulance claims, the modifier captures the trip's origin and destination. The first character is the origin. The second is the destination.
Origin and destination codes
Code | Meaning |
| Diagnostic or therapeutic site |
| Residential or custodial facility |
| Hospital-based end-stage renal disease (ESRD) facility |
| Hospital |
| Site of transfer between facilities |
| Freestanding end-stage renal disease (ESRD) facility |
| Skilled nursing facility |
| Physician's office |
| Residence |
| Scene of accident or acute event |
| Intermediate stop at physician’s office on way to hospital (destination code only) |
For example, SH means scene (S) to hospital (H). RH means residence to hospital. NH means skilled nursing facility to hospital.
If you’re using Stedi's JSON Professional Claims Submission API, you pass the modifier in the procedureModifiers array on the service line.
9. Which ambulance-specific fields should I include on the claim?
Most EMS providers bill using 837P professional claims. These claims include several ambulance-specific fields:
Ambulance-specific claim fields
837P X12 element | |
| |
| |
Loop | |
Loop | |
|
Don’t use the service facility location
For ambulance claims, use the ambulance pickup and drop-off location fields, not the generic service facility location field.
837P X12 element | |
Loop | |
Loop | |
Loop |
When the pickup is a place without a street address – a highway shoulder, a trailhead, a rural intersection – use a description in the first address line instead:
837P X12 element | |
|
Get more tips
If you’re building claims or eligibility workflows for the EMS space, Stedi can help.
Contact us to set up a demo or consultation.
Share
Start free with a sandbox account. Upgrade to production when you're ready. There are no monthly minimums or setup fees. You only pay for the transactions you use. See our pricing.
