Opexia builds insurance eligibility verification automation for practices, care-management organizations and billing companies. We send X12 270 inquiries through your clearinghouse or payer APIs, in batch before appointments and in real time at booking or check-in, and use payer-portal automation only where no electronic response exists. Coverage, copay, deductible and coinsurance details are written back to your PM or EHR, and anything unclear goes to a staff exceptions queue.
If several of these sound familiar, verification is happening too late or costing too much staff time:
Coverage is confirmed when the patient arrives, leaving no time to fix a problem before the visit.
Staff read copays and deductibles off a payer screen and retype them into the patient record.
Claims come back denied because a plan ended or changed after the patient's last visit.
Deductible and coinsurance aren't known before the visit, so cost conversations happen after the bill.
The team keeps a list of portal passwords and works through it patient by patient.
Eligibility verification answers three questions before a visit: is this patient covered on the date of service, by which plan, and what will they owe? HIPAA's standard for asking electronically is the X12 270 inquiry and 271 response, and federal operating rules require health plans to answer in real time with deductibles, copays, coinsurance and coverage for specific service types. So the data usually exists. The work is in asking for every scheduled patient, reading responses whose detail varies by payer, and getting the answer into the system your staff actually use. That is the layer we build. Inquiries go through your clearinghouse or directly to payer APIs: in batch for the coming days' appointments, and in real time when a visit is booked or a patient checks in. For a payer with no usable electronic response, the check can run by browser automation on its portal, within the portal's terms of use and with credentials your practice controls; if a portal uses CAPTCHA or bot detection, we leave that payer to your staff rather than work around it. Responses are normalized into one format and written back to your PM or EHR where it accepts them, and inactive coverage, unmatched members and plan changes go to an exceptions queue. The software is built to HIPAA requirements (encryption, audit logging, role-based access).
This is one specific service within RPA Billing Automation.
| Approach | What staff still do | Payer coverage | When checks run | How coverage problems surface | Makes sense when |
|---|---|---|---|---|---|
| Check by hand | Log in to portals or call payers for each patient, then type benefits into the PM system. | Every payer, one patient at a time. | Whenever the front desk finds time, often the day of the visit. | At check-in, or later as a denied claim. | The schedule is small and the payer list is short. |
| Your clearinghouse or PM vendor's built-in eligibility feature | Turn on batch or real-time checks and read results in the vendor's screens. | Payers connected to that clearinghouse. | On the schedules the vendor offers. | Through the vendor's standard flags. | Results already land on the appointment for your payers. Start here. |
| Off-the-shelf RPA or RCM product | Configure the product and manage the vendor relationship. | The payers, portals and PM systems the product supports. | On the product's scheduling options. | Through the product's rules and queue. | Your payers and PM or EHR are all on the product's supported list. |
| Custom automation | Work the exceptions queue and talk to patients about what they owe. | Clearinghouse and payer APIs first; portal automation for the rest where terms allow. | On your rules: at booking, days before the visit, the morning of, or all three. | Your own flags, such as a plan change since the last check, routed to the right person. | Payers or systems that no single product covers, or results that need to reach a system your vendor can't write to. Slowest to start. |
If your clearinghouse or PM system already checks every scheduled patient and puts the answer where staff work, keep it. Custom automation is for the payers, timing rules or write-backs those tools don't cover.
HIPAA names the X12 270/271 (version 5010) as the standard for eligibility and benefit inquiries and responses, required since January 1, 2012, with federally mandated operating rules since January 1, 2013. Those rules are why an eligibility check can usually be automated without a portal bot. Source: CMS, Adopted Standards and Operating Rules.
In effect
Health plans must respond to providers' eligibility questions in real time, including patient financial responsibility (deductibles, copays, coinsurance and in- and out-of-network variances) and coverage for specific service types, and must provide secure access to eligibility information over the internet.
Current CORE version
CORE's Eligibility & Benefits Infrastructure Rule sets a 20-second maximum for a real-time 271 response, and requires a batch of 270s submitted by 9:00 pm Eastern on a business day to be answered by 7:00 am Eastern the next business day. Plans may schedule weekly downtime but must publish it. The April 2022 update changed the availability terms, not these response times.
Engineering context, not legal or billing advice. A 271 response confirms coverage as the payer reports it on the date asked; it is not a guarantee of payment. CAQH, which authors the CORE operating rules, now operates under the name DataSpring. Last reviewed 2026-09-28.
Useful groundwork before a first call:
270 generation, 271 parsing and normalization of payer-specific responses
Real-time check endpoint for booking and check-in, with role-based access at the API layer
Inquiry history, benefit summaries, change detection and the exceptions queue
Primary route for 270/271 exchange, in batch and real time
Portal fallback for payers without a usable electronic response, where terms allow
Batch runs ahead of each clinic day
Common questions about automated insurance eligibility checks before every visit
Yes, but only for payers with no usable electronic route. We use logins your practice owns, ideally a separate account for the automation that your portal administrator can disable at any time. Credentials sit encrypted in a secrets manager, never in code or email, and we review each portal's terms of use before automating it.
A changed portal stops that payer's checks, not the whole run. The bot confirms it reached the expected page and fields; when it doesn't, it halts, alerts us and moves those patients to the exceptions queue so staff can check them by hand. Clearinghouse and API checks carry on. Fixes after launch fall under a monthly support agreement.
Usually both, for different moments. Batch inquiries for the coming days' schedule run overnight; under CORE rules, a batch submitted by 9:00 pm Eastern on a business day is due back by 7:00 am Eastern the next business day. Real-time checks, due within 20 seconds under the same rules, cover same-day bookings and check-in.
A 271 says whether coverage is active on the date asked and, depending on the payer, the plan, copay, deductible and coinsurance, and sometimes whether authorization or a referral is needed. Detail varies by payer and service type, and it is not a guarantee of payment, so we keep the full response alongside our summary.
It may be enough. If it checks every scheduled patient and writes the result to the appointment, keep it. Custom work helps when checks still need someone to click, results stay in the clearinghouse's screens, some payers are missing, or you need your own rules, such as flagging a plan change since the last visit.
No. It removes the lookups and re-keying: portal logins, member-ID searches and copying benefits into the PM system. Your front-desk and billing staff still handle the exceptions, such as inactive coverage, a patient with a new plan or a response that needs a call to the payer, and they talk to patients about what they owe.
Yes. We sign a Business Associate Agreement (BAA) before any PHI access: no one on our team sees protected health information until it is executed. Eligibility inquiries carry member IDs and dates of birth, so the agreement is in place before any connection is set up. We can sign your BAA or provide ours.
Cost depends on scope, so we don't quote a generic range. Book a free 30-minute consultation: we review your requirements and workflow, then send a written scope and quote tied to what you actually need. Here the main variables are how many payers lack an electronic response and how results reach your PM or EHR.
Deep-dive technical guides related to automated insurance eligibility checks before every visit
Calculate how much you're spending on manual processes and how fast custom software pays for itself.
Calculate SavingsDownload a practical checklist of HIPAA Security Rule safeguards to review before you launch.
Get ChecklistRead the published CCM/PCM engagement: Excel to a multi-tenant platform serving 8,000+ patients.
Read the Case StudySchedule a technical consultation to discuss your specific requirements, timeline, and budget. No sales pitch—just engineering.
Or explore the engineering glossary to learn more about healthcare software terminology.
'/%3e%3cpath%20d='M534.104%20592.554C517.522%20607.15%20492.036%20605.65%20479.37%20587.55C432.827%20521.038%20409.925%20440.343%20415.135%20358.545C420.344%20276.748%20453.298%20199.61%20507.904%20139.54C522.764%20123.194%20548.234%20124.939%20562.83%20141.521L608.023%20192.862C622.619%20209.444%20620.638%20234.536%20607.101%20251.994C581.387%20285.156%20565.941%20325.498%20563.237%20367.978C560.53%20410.458%20570.733%20452.433%20592.032%20488.59C603.245%20507.624%20602.027%20532.765%20585.445%20547.361L534.104%20592.554Z'%20fill='url(%23paint1_linear_154_257)'/%3e%3cpath%20d='M404.368%20499.661L455.381%20493.203L438.013%20356L387%20362.458L404.368%20499.661Z'%20fill='white'/%3e%3cpath%20d='M349%20408.709L355.956%20459.657L492.983%20440.947L486.026%20390L349%20408.709Z'%20fill='white'/%3e%3cdefs%3e%3clinearGradient%20id='paint0_linear_154_257'%20x1='170'%20y1='492.5'%20x2='449'%20y2='508.5'%20gradientUnits='userSpaceOnUse'%3e%3cstop%20stop-color='%236648E0'/%3e%3cstop%20offset='1'%20stop-color='%23413AC9'/%3e%3c/linearGradient%3e%3clinearGradient%20id='paint1_linear_154_257'%20x1='429'%20y1='384'%20x2='549.5'%20y2='380.5'%20gradientUnits='userSpaceOnUse'%3e%3cstop%20stop-color='%235B51FF'/%3e%3cstop%20offset='1'%20stop-color='%233428E6'/%3e%3c/linearGradient%3e%3c/defs%3e%3c/svg%3e)