Opexia builds prior authorization automation for practices, specialty groups, billing companies and MSOs whose staff spend their days in payer portals and fax queues. Our software checks whether a service needs authorization, assembles the documentation the payer asks for, submits through the payer's API, the X12 278 or its portal, tracks each decision, and routes denials and requests for more information to your team, with every step recorded in an audit trail.
If several of these sound familiar, the workflow is ready for automation:
Coordinators log into several portals a day to submit requests and re-check the ones still pending.
Whether a service needs authorization is checked against payer lists, PDFs or a phone call, every time.
Nobody can see at a glance which requests are due, stalled or waiting on more information.
Denials and requests for more information sit in a portal inbox or fax queue until someone happens to check.
When a payer disputes a request, rebuilding what was submitted, when and by whom means digging through email, faxes and screenshots.
Prior authorization is a chain of small manual steps: look up whether this payer requires authorization for this service, find the right form, pull the chart notes, submit through one of several portals, then keep checking until a decision arrives. CMS-0057-F now requires Medicare Advantage, Medicaid, CHIP and federal-exchange plans to decide within set timeframes, give a specific reason for every denial and, generally from January 1, 2027, offer a FHIR Prior Authorization API. It covers only those payers and excludes drugs, so we build a hybrid layer rather than wait for every payer to catch up. One internal model of a prior authorization request sits above a connector per payer: a FHIR connector following the HL7 Da Vinci CRD, DTR and PAS implementation guides where the payer supports them, an X12 278 connector through your clearinghouse, a browser connector for portals whose terms allow automated access, and a manual connector for phone and fax. Staff work from one queue sorted by due date, payer and status. Documentation packets are assembled from your EHR data or uploads, and a clinician or authorized staff member reviews every clinical packet before it is submitted. Every lookup, submission, status change and edit is written to an audit log. The software is built to HIPAA requirements (encryption, audit logging, role-based access), and you own the source code on final payment.
This is one specific service within RPA Billing Automation.
| Option | What it handles | Payer coverage | Where requests are tracked | Audit trail | Trade-off |
|---|---|---|---|---|---|
| Manual staff work | Everything, one request at a time: rule lookups, forms, portal submissions and follow-up calls. | Any payer, through whatever channel it offers. | Spreadsheets, notes and portal inboxes. | Whatever staff remember to save. | Nothing to build, but the work grows with volume and depends on who is in that day. |
| Clearinghouse or practice management vendor feature | Electronic X12 278 submission and responses for payers connected to that vendor. | The vendor's payer connections; portal-only payers stay manual. | Inside the vendor's screens. | The vendor's transaction log. | Often already in place; rarely covers payer-specific rules or documentation assembly. |
| Off-the-shelf prior authorization product | Rule lookups, submission and tracking in a packaged workflow. | The product's payer network and rule library. | The product's own work queue. | The product's log, on the vendor's terms. | Quick to start when your workflow matches the product; harder to fit unusual payers, services or several client practices. |
| Custom automation | The lookups, packets, submissions and status checks your team does today, payer by payer. | A FHIR API, X12 278, portal or manual connector, chosen for each payer. | One queue in your own system, next to your scheduling and EHR data. | You decide what is logged, and you hold the log. | Slowest to start, and connectors need maintenance as payers change. |
Custom automation only makes sense when the other options leave gaps, for example when your payer mix is split across APIs, the 278 and portals, or you run authorizations for several practices with different rules.
CMS-0057-F applies to Medicare Advantage organizations, state Medicaid and CHIP fee-for-service programs, Medicaid managed care plans, CHIP managed care entities and QHP issuers on the Federally-facilitated Exchanges. It does not apply to drugs, and plans outside those programs are not covered, so most providers will keep working with a mix of payer APIs, the X12 278 and portals. Source: CMS fact sheet, CMS-0057-F (January 17, 2024).
Final rule
CMS released the Interoperability and Prior Authorization final rule. Impacted payers must change how they handle prior authorization, generally from January 1, 2026, and implement FHIR APIs, generally from January 1, 2027. Exact compliance dates vary by payer type.
Enforcement discretion
CMS's National Standards Group said it will not take HIPAA Administrative Simplification enforcement action against covered entities that implement an all-FHIR Prior Authorization API without the X12 278. Payers may still offer the 278 alone or combined with FHIR, so a submission layer needs to handle both.
In effect
Impacted payers, except QHP issuers on the Federally-facilitated Exchanges, must send decisions within 72 hours for expedited requests and seven calendar days for standard requests. Impacted payers must give a specific reason for every denial, however the request was sent, and the first public prior authorization metrics were due by March 31, 2026.
Proposed
CMS proposed extending electronic prior authorization and decision timeframes to drugs, and HHS proposed adopting FHIR and Da Vinci implementation guides as the HIPAA standard for prior authorization transactions, with compliance 24 months after a final rule (36 months for small health plans). Comments closed June 15, 2026. It is a proposal, not a final rule.
Upcoming
The Prior Authorization API must list covered items and services, identify documentation requirements, support request and response, and return an approval with its end date, a denial with a specific reason, or a request for more information. CMS recommends the Da Vinci CRD, DTR and PAS guides. The other three APIs are due on the same general date.
Engineering and operations context, not legal or billing advice. Last reviewed 2026-09-28.
Useful before a first call:
Request model, payer connectors and role-based access enforced at the API layer
Requests, status history, documentation references and the audit log
Coverage checks, documentation templates and submission where payers support them
Electronic request and response for payers on the HIPAA transaction
Portal connector for payers without an API, within each portal's terms of use
Encrypted payer credentials, scoped to one connector and kept out of logs
Common questions about prior authorization automation that checks, submits and tracks requests
Rarely all of them the same way. Each payer gets the best route it offers: a FHIR API where it has one, the X12 278 through your clearinghouse, portal automation where its terms allow, or a manual step in the same queue. The written scope lists the route for each payer before anything is built.
Credentials sit in an encrypted secrets store, scoped to one connector and never written to logs. We review each portal's terms before automating it and use only accounts the payer permits. We do not bypass CAPTCHAs or bot detection; where a portal forbids automation, that payer goes through an API, the 278 or staff.
Connectors are monitored. A failed login, missing field or unexpected response stops that connector, alerts us and moves its open requests to the staff queue rather than guessing. We then update the connector. API changes are usually versioned and announced; portal changes often are not, which is why portal connectors need ongoing maintenance.
No. It gathers the documentation a payer asks for and flags gaps, but a clinician or authorized staff member reviews every clinical packet before submission. Denials, peer-to-peer requests and appeals go to your team. The automation removes lookups, form filling and status checks; clinical judgement stays with people.
No. It removes the rule lookups, re-keying and repeated status checks that fill their day. Staff still handle the exceptions: missing documentation, requests for more information, peer-to-peer reviews, denials and anything that needs clinical judgement. The difference is that they work from one queue instead of a dozen portals.
No. CMS-0057-F requires impacted payers to offer a Prior Authorization API, generally by January 1, 2027, but it covers only Medicare Advantage, Medicaid, CHIP and federal-exchange plans, and excludes drugs. We build the API connector alongside 278 and portal connectors, so each payer can move to its API when it is ready.
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. We can sign your organization's BAA or provide ours. The software is built to HIPAA requirements (encryption, audit logging, role-based access), and it still belongs in your own HIPAA risk analysis.
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. Scope depends mostly on how many payers are included, which route each supports, and how much documentation assembly is involved.
Deep-dive technical guides related to prior authorization automation that checks, submits and tracks requests
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)