Nirmitee.io

Real-time eligibility verification · United States

Real-Time Eligibility Verification for Your EHR or Product

We build real-time eligibility verification and claim status into your EHR, practice management system or health tech product. We use X12 270/271 and payer APIs wherever a payer offers them, and use a payer portal only where no permitted electronic route exists, its terms allow it and your customer authorizes it. Every answer lands on the right patient and appointment, in words your front desk can act on.

Book a scoping call ↗See the routes by payer →
  • 270/271
  • 276/277
  • Availity APIs
  • Optum
  • UnitedHealthcare
  • CAQH CORE
  • Payer portals

Coverage confirmed before the patient walks in.
  1. 01Ask

    A 270 or an eligibility API call at scheduling, check-in or the night before, for the right payer and plan.

  2. 02Read

    The 271 or API response parsed into active coverage, copay, deductible, coinsurance and the reasons a check failed.

  3. 03Act

    Results written to the patient and appointment, gaps sent to a work queue, and claim status checked the same way after billing.

Evidence you can check

The problem

Sound Familiar?

These are the four problems we hear first from practice groups, billing teams and the health tech companies that serve them.

Three portals for one patient

Staff sign in to Availity, a payer portal and a vision portal to answer one question: is this patient covered, and what do they owe today?

A 271 nobody can read

The eligibility response comes back with dozens of benefit lines. The front desk needs one copay and one deductible for this visit type.

Checks that fail with no reason

A check says rejected. Nobody knows whether the member ID is wrong, the date of birth is off or the payer simply timed out.

Payers with no electronic route

Some payers, vision plans in particular, cannot be reached over a standard eligibility request through your clearinghouse, so someone still checks a portal by hand every morning.

Use cases

What It Looks Like When It Works

Four use cases, each shown as the screen your team works in. The patients are fictional; the payer rules behind each screen are real.

Coverage on the Schedule Before the Patient Arrives

Today

The front desk checks coverage while the patient waits at the counter.

With the integration

Every visit shows active or inactive and what the patient owes today, checked overnight and again at check-in. Only the visits that need a call stand out.

What we build
  • Batch 270 checks for tomorrow's schedule and a real-time check at check-in
  • Benefits for the visit type turned into copay, deductible left and coinsurance
  • Results written back to the appointment in your EHR or practice management system
Front desk schedule showing coverage status and what each patient owes today, with one plan that ended flagged for a call
Illustrative screen with fictional patients: front desk schedule showing coverage status and what each patient owes today, with one plan that ended flagged for a call. Tap to open full size.

Failed Checks That Say What Went Wrong

Today

A check says rejected and staff start guessing, or call the payer.

With the integration

Each failed check names the cause in plain words, such as a member ID the payer cannot find or a date of birth that does not match, and the fix. Payer timeouts retry on their own.

What we build
  • AAA rejection codes and inactive plans mapped to plain reasons and next steps
  • Automatic retries for payer timeouts, with an alert if the payer stays down
  • A work queue so each exception has one owner
Eligibility exceptions queue where each failed check shows the reason, the payer code and the fix
Illustrative screen with fictional patients: eligibility exceptions queue where each failed check shows the reason, the payer code and the fix. Tap to open full size.

Payers With No Electronic Route

Today

Someone signs in to a vision or specialty payer portal every morning and copies benefits by hand.

With the integration

A governed portal check reads the benefits, compares every value before saving and logs every step. Staff only approve the two-step sign-in.

What we build
  • Portal automation only where the portal's terms and your customer's authorization allow it
  • One login per bot, staff-approved two-step sign-in, values read back before saving
  • A full audit log and screenshots kept inside your environment
Audit log of a governed EyeMed portal check, from sign-in to saving the benefits on the appointment
Illustrative screen with fictional patients: audit log of a governed EyeMed portal check, from sign-in to saving the benefits on the appointment. Tap to open full size.

Claim Status Without Phone Calls

Today

Billers call payers or open portals to find out why a claim has not paid.

With the integration

Claim status is checked every morning by claim age. Paid claims post, pended claims get a date to check again, and denials land in a named biller's queue with the payer's reason.

What we build
  • 276/277 claim status and payer claim APIs on a schedule by claim age
  • Status and denial reasons in plain words, with the payer's code kept
  • Routing rules that send each status to the right queue
Claim status work queue showing paid, pending and denied claims with the next step for each
Illustrative screen with fictional patients: claim status work queue showing paid, pending and denied claims with the next step for each. Tap to open full size.

First call

Questions We Will Ask You on the First Call

The answers decide the route, the timeline and where these projects usually go wrong. You do not need them all before we talk.

Which clearinghouse do you use today, and do you have API access on your contract?

Availity, Waystar, Change Healthcare and Stedi each expose eligibility differently, and API entitlement is often a separate line item.

Which 20 payers make up most of your visits?

Payer mix decides how much works over standard 270/271 and how many payers need an API or a portal.

Which visit types need which benefits?

A physical, a specialist follow-up and an eye exam use different service type codes. Asking for the wrong one returns the wrong copay.

When should the check run?

At booking, the night before, at check-in, or all three. Each has a different load and a different failure plan.

What should staff do when coverage is inactive?

Call the patient, reschedule, or see them as self-pay. The answer shapes the work queue.

Where should results land?

On the appointment, in a patient banner, or in your own product. Write-back rules differ by EHR.

Which payers have no electronic route for you?

For those, we confirm the portal's terms and your customer's written authorization before any automation.

Who owns exceptions and claim follow-up?

Every queue needs a named owner, or failed checks quietly pile up.

The short answer

Real-Time Eligibility Verification, in Short

Real-time eligibility verification is the electronic form of insurance verification. Real-time insurance eligibility verification asks a payer whether a patient's coverage is active and which benefits apply, and returns coverage details in seconds instead of a phone call, one of the main ways practices and health systems work to reduce denials caused by inactive coverage. Most payers answer an X12 270 inquiry with a 271 response through a clearinghouse, and CAQH CORE rules expect that round trip within 20 seconds. Some clearinghouses and payers add REST APIs, such as Availity's Coverages API and Optum's eligibility API. For some payers, often vision and dental plans, your clearinghouse may have no electronic route; then the options are manual eligibility checks or authorized portal access. We build these routes behind one interface in your product.

Who it is for
EHR, practice management and digital health companies adding eligibility and claim status, and provider groups whose staff still check coverage by portal and phone.
What we build
Eligibility at scheduling and check-in, benefit parsing for the front desk, claim status polling into work queues, payer API connections and governed portal automation.
The outcome we design for
Coverage answers in the workflow where staff need them, inactive plans caught before the visit, and a record of every check. These are intended outcomes, confirmed in your pilot.

Routes by payer

Eligibility, Claim Status and Portal Routes by Payer

Each payer exposes a different mix of EDI, API and portal access. These are the routes we build against and the detail that decides how reliable each one is.

RouteWhat it gives youLimits to plan forWhat we design for
X12 270/271 through a clearinghouseCoverage status, plan, copay, coinsurance, deductible and limits by service type for most US payersCAQH CORE expects a 271 or 999 within 20 seconds; payer coverage of benefit detail variesService type codes per visit, AAA rejection handling and payer-specific quirks; full EDI detail lives on our X12 EDI page
Availity APIs (Coverages, Claim Statuses, Service Reviews)REST and JSON on top of 270/271, 276/277 and 278, plus a Payer List and payer-specific ConfigurationsOAuth 2.0 token valid 5 minutes; the demo plan returns canned responses only; standard access goes through an Availity contract with higher rate limitsToken refresh, payer configuration lookups before each call and add-ons such as IsAuthRequired and Member ID Card where your contract includes them
Optum eligibility APIMedical network eligibility through Optum's developer platformAccess, versions and payer list set by your Optum agreementOne internal eligibility model so Optum and other sources return the same fields to your app
UnitedHealthcare provider APIsClaim status with proprietary codes, cost share and payment detail beyond a 277; eligibility with prior authorization and referral requirementsFeature sets differ between UnitedHealthcare's own guides, so we confirm them for your accountMapping proprietary claim codes to your work queue reasons
Claim status 276/277 and claim status APIsWhere a claim is, why it is pending and what was paidPolling limits and payer response depth varyScheduled checks by claim age, results routed to the right biller with the payer's reason attached
Payers without an electronic route on your network (for example EyeMed on Stedi)Coverage and allowances from the payer's provider portalStedi lists EyeMed eligibility and real-time claim status as unsupported on its network; check other permitted connections before choosing portal access. Portals need a login, often with MFAGoverned portal automation: one login per bot, staff handle MFA, every read verified and logged
Prior authorization status and attachmentsWhether a service needs authorization, request status and document uploadUsually a separate API product or portal flowLinking PA status to the appointment; full PA workflows live on our prior authorization pages

Availity facts are from Availity's own API guide (published March 2025, updated October 2025). UnitedHealthcare facts are from its Digital Solutions Comparison Guide. Confirm the APIs your contract includes before scoping.

What we build

What Our Eligibility and Payer Portal Automation Builds

Pick the workstreams you need. Each one ships with a specification, test runs and an owner.

01

Eligibility at Scheduling and Check-in

Real-time checks when an appointment is booked and again at check-in, plus a batch run for tomorrow's schedule, so problems surface while there is still time to call the patient.

270/271 005010X279A1 · CAQH CORE · batch and real time

Automating 270/271 eligibility verification →
02

Benefits Your Front Desk Can Read

The 271 or API response turned into active or inactive, copay, deductible remaining and coinsurance for the visit type, with the reason a check failed in plain words.

EB segments · service type codes · AAA rejections

X12 EDI integration services →
03

Claim Status Into Work Queues

Claim status checked on a schedule by claim age, with pended and denied claims routed to the right biller and the payer's own reason attached.

276/277 · Availity Claim Statuses · payer claim APIs

Claim status automation with 276/277 →
04

Payer API Connections

Availity, Optum and payer-specific APIs behind one internal model, with token handling, payer configuration lookups and rate limits built in, so your app calls one interface.

OAuth 2.0 · REST and JSON · Payer List · Configurations

Payer and clearinghouse integration →
05

Governed Payer Portal Automation

For payers with no electronic route, a bot reads the portal under its own login, staff approve MFA, every value is checked and every step is logged. We only automate a portal its terms and your customer allow.

One login per bot · MFA handoff · audit log · read-back checks

EHR automation without API access: FHIR vs RPA vs computer-use agents →
06

Monitoring and Support

Response times tracked against the 20-second CORE target, alerts when a payer or portal starts failing, and a runbook your support team can follow.

Response times · alerts · runbook

Integration monitoring and support →

Buyer decisions

Eligibility Verification Options Compared

Most products end up using more than one source. The right mix depends on your payer list and how much detail your staff need.

OptionBest fitStrengthsWhat to plan for
Clearinghouse EDI 270/271Products serving many payersBroad payer reach, an adopted HIPAA standardParsing benefit detail, enrollment and a clearinghouse contract
Clearinghouse or payer REST APITeams that want JSON and faster buildsEasier to code against, extras such as member ID cardsAPI entitlements and rate limits in your contract
Eligibility API vendorTeams that want one vendor for payer coverageQuick start and a single contractCoverage gaps, per-check pricing and less control over the data
Payer portal automationPayers with no electronic eligibilityReaches data no API returnsPortal terms, customer authorization, MFA and screen changes
Staff calls and manual portal checksLow volume or unusual plansNo build neededStaff time, missed checks and records spread across portals unless staff log them

We start every project with your top payers by volume and pick the route per payer, so the portal is the exception and not the plan.

Integration boundaries

Eligibility and Portal Automation Boundaries: Who Owns What

Payer data crosses contracts, terms of use and patient privacy. We write the split down before the build starts.

The payer

Owns its APIs, EDI companion guides and portal terms. We build to the published interfaces and the terms you have agreed.

The clearinghouse

Owns enrollment, payer routing and transaction pricing. We prepare enrollment details and test against its rules.

Your customer

Authorizes any portal login used on its behalf and keeps the credentials it owns. We never share a login between practices.

Your product team

Decides where eligibility appears in the workflow and what staff do with a failed check. We supply the states and wording for each result.

The integration layer (ours)

Connections, parsing, retries, portal bots, audit logging and alerts. Defects in this layer are ours to fix.

Security and PHI

Eligibility responses are PHI. We sign a BAA, encrypt in transit and at rest, and work inside our ISO 27001:2022 certified management system.

Deliverables

Eligibility and Payer Automation Deliverables

Everything lands in your repository and your runbook.

01

Payer route map

Your top payers by volume, with the route chosen for each: EDI, API or portal, and why.

02

Integration code in your repository

Eligibility, claim status and portal modules behind one interface, with payer configuration kept out of the code.

03

Benefit display rules

How each response becomes active, copay, deductible and coinsurance on screen, with the failed-check wording.

04

Test evidence

Recorded runs covering active, inactive, unknown member, payer timeout, AAA rejection and portal change cases.

05

Portal automation controls

Login ownership, MFA handoff, read-back checks and the audit log, documented for your customer's security review.

06

Monitoring and runbook

Response time and failure dashboards, alerts and a support runbook per payer.

Delivery phases

Real-Time Eligibility Verification Timeline

Initial planning estimate: 6 to 10 weeks for an agreed first payer set, subject to enrollment, API access, EHR write permissions and validation. We confirm a release plan after discovery.

  1. 01

    Discovery and access

    Weeks 1 to 2

    Payer list ranked by volume, route chosen per payer, clearinghouse and API access requested

  2. 02

    Build

    Weeks 2 to 5

    Eligibility, benefit parsing and claim status built and tested against the simulator and sandboxes

  3. 03

    Payer validation

    Weeks 4 to 8

    Live checks with real payers, portal flows approved, failure wording confirmed with staff

  4. 04

    Go-live and hypercare

    Weeks 6 to 10

    First practices live, monitoring on, runbook handed over, next payers scheduled

Cost drivers

What Drives Eligibility Integration Cost

Use the scoping call to pin down the workflow, the access you need and what goes into a scoped proposal. These are the factors that move cost.

Number of payers and routes

Each API and each portal adds its own build and tests; EDI payers through one clearinghouse share most of the work.

Benefit detail needed

Active or inactive is quick; service-type benefits with accumulators take more parsing and review.

Claim status scope

Adding 276/277 or claim APIs adds scheduling, routing and work queue rules.

Portal automation

Each portal needs login handling, change detection and its own tests.

Where results appear

Writing results into an EHR you do not own needs that EHR's API work as well.

Support level

Monitoring and on-call support are priced per connection.

Book a call ↗

Proof

Payer and Eligibility Work You Can Check

Client names are withheld. The first two items are delivered client work, described without identifying the client; the simulator is open-source and shows how we test, not access to your payers.

Live in production

Behavioral Health Revenue Cycle Platform

Built and run for a US behavioral health group: eligibility is checked before every visit, the signed session note becomes the 837P claim, and denials land in a work queue with the payer's reason attached.

See RCM integration →

Live in production

Wound Care Claims and Eligibility Workflow

Built for a US wound care provider group: coverage checked through the clearinghouse before the visit and the dense 271 benefit response read into plain terms for the front desk.

See X12 EDI integration →

Public GitHub repository

Open-source X12 Clearinghouse Simulator

A stand-in for a real clearinghouse connection with 120 scenarios across 270/271, 278, 837, 999, 277CA, 835 and 276/277, so eligibility and claim status code is tested before payer enrollment finishes. It exercises integration behavior with synthetic cases and does not prove a live connection to your payers.

View the simulator on GitHub →

Security

ISO 27001:2022 Certified, BAAs Signed

We are ISO 27001:2022 certified and sign Business Associate Agreements for work that touches patient data.

FAQ

Real-Time Eligibility Verification: Questions Buyers Ask

What is real-time eligibility verification?

It is an electronic check of a patient's insurance coverage that returns an answer in seconds. Your system sends an X12 270 inquiry or an API call, and the payer returns a 271 response with coverage status, plan and benefits such as copay, deductible and coinsurance for the type of visit.

How fast is a real-time eligibility check?

CAQH CORE operating rules expect a real-time 270 to get a 271 or an error response within 20 seconds, measured on 90 percent of responses each month. The rule covers the response time, including error responses; it does not guarantee that benefits come back. Payer and clearinghouse outages are the main cause of slow answers, so we monitor response times.

Does eligibility verification guarantee payment?

No. An eligibility response reports coverage and benefit information at the time of the check. Payment still depends on the service, authorization, coding, the payer contract and claim adjudication, which is why claim status and remittance are tracked separately.

How do you handle an eligibility timeout?

A timeout is not treated as inactive coverage. The check goes to a retry queue with a time limit, and if the payer stays down the visit is flagged for staff review with the last known result and its timestamp shown, so nobody acts on a stale answer.

Which insurance eligibility verification API should we use?

It depends on your payer list. A clearinghouse 270/271 connection reaches most payers. REST APIs such as Availity's Coverages API or Optum's eligibility API are easier to build against for the payers they cover. Eligibility API vendors offer one contract. We map your top payers first and pick the route per payer.

How do I connect an insurance eligibility API to an EMR?

Trigger the check from the EMR's scheduling or check-in event, send the patient's member ID, date of birth and payer, and write the parsed result back to the patient and appointment. If you do not own the EMR, the write-back needs that EMR's API, such as FHIR Coverage or a vendor endpoint. Whether the payer returns a benefit and whether the EMR lets an outside system write it are separate questions, so we confirm the write method and the screen staff will see for each EHR.

Does Availity have an API for eligibility and claim status?

Yes. Availity's API guide lists Coverages for eligibility, Claim Statuses for 276/277 and Service Reviews for prior authorization and referrals, all REST and JSON. Access starts with a demo plan that returns sample responses, and live use needs a standard plan under an Availity contract.

What if a payer has no electronic eligibility route?

Some payers, often vision and dental plans, are not reachable over 270/271 through a given clearinghouse. For those, the options are a phone call, a staff portal check or governed portal automation. We automate a portal only where its terms and your customer allow it, with a separate login per bot and every step logged.

Is payer portal automation allowed?

It depends on the portal's terms of use and your customer's authorization. Many portals allow access only by the provider's own users, so the customer must own and authorize each login. We review the terms with you first and use an API or EDI route wherever one exists.

Can you automate claim status checks across payer portals?

Yes. We use 276/277 claim status and payer claim APIs first, on a schedule based on claim age. For payers that only show status in their portal, a governed bot reads it under the customer's login. Results go to a work queue with the payer's reason attached.

How long does eligibility integration take?

Our initial planning estimate is 6 to 10 weeks to a first live set of payers. Clearinghouse enrollment and API access usually set the date. Payers added later on the same route go faster because the parsing and tests already exist.

How much does real-time eligibility integration cost?

Cost depends on how many payers and routes you need, the benefit detail you want, whether claim status is included, how many portals need automation and where results must appear. After a scoping call we send a scoped proposal with the access dependencies listed.

Next step

Get Coverage Answers Inside Your Workflow

Tell us your top payers, where staff check coverage today and what your product needs to show. An engineer replies with the route for each payer and a fixed scope.

Book a call ↗Send your payer list →

Start with your workflow

Tell Us About Your Eligibility Needs

Share your top payers, your EHR or product and your target date. Use de-identified examples only. Read by an engineer, answered within one business day.

Please exclude patient data and credentials. We use these details to respond to your enquiry. Privacy policy

Thank you. Your enquiry has been received. Our team will review your requirements.

Standards and Primary Sources