Quick answer: Setting up Nextech prior authorization automation involves enabling the ePA module, mapping your payer list to Nextech's payer rules, configuring the procedure and medication catalog that should auto-trigger PA flagging, and routing the resulting queue to a dedicated staff role or AI agent. The work is mostly operational rather than technical — most of the timeline goes into payer enrollment for ePA, building the procedure-to-payer rule map for your specialty mix, and training the auth team on the new workflow. Plan for 4–8 weeks at a mid-to-large specialty practice with payer mix that's mostly ePA-eligible; longer if you're heavy on smaller commercial plans or worker's comp.
The prerequisites — what to have in place before you start
Before the rollout begins, three things need to be in place. The setup itself doesn't take long; getting these prerequisites right is what determines whether the rollout lands in 4 weeks or stretches to 12.
Nextech RCM module access. The ePA functionality lives inside Nextech's RCM module. Practices running Nextech EHR without RCM access will need to add the module before the PA automation can be enabled. The procurement step alone usually adds 1–2 weeks if it isn't already in place; account managers move faster when the request goes through with a clear go-live date attached.
Payer enrollment for electronic prior authorization. ePA isn't automatic on the payer side. Each payer requires the practice to enroll in electronic PA submission through the payer's portal, with the payer issuing credentials and confirming that the practice's NPI and TIN are configured for ePA traffic. For a typical specialty practice with 15–25 active payers, plan for 2–3 staff weeks of enrollment work distributed across 4–6 calendar weeks. Most major commercial payers and Medicare Advantage plans process ePA enrollment in 5–10 business days; the long tail of smaller plans is where the timeline drags.
A clear inventory of your procedure and medication catalog. Setting up the ePA flagging rules requires knowing exactly which procedures and medications your practice orders that require PA at which payers. Pull a 90-day claim history filtered to denied claims with PA-related denial codes, plus a list of high-volume biologics or surgical procedures from your scheduling system. This becomes the input to the rule-mapping step.
With these three pieces in hand, the actual configuration work goes fast.
Step 1 — Enable the ePA module and confirm payer coverage
The first configuration step is to turn the ePA module on inside Nextech and confirm which of your payers are reachable through the ePA channel. This typically runs through Nextech's implementation team rather than as a self-service toggle, with a kickoff call to scope your payer list against Nextech's current ePA payer coverage.
Most major commercial payers and Medicare Advantage plans show up cleanly in Nextech's ePA payer coverage as of 2026. The list to confirm against your payer mix usually includes:
- Each major commercial payer your practice contracts with (UnitedHealthcare, Aetna, Cigna, Humana, BCBS plans relevant to your geography)
- Medicare Advantage plans your patients carry
- State Medicaid managed care organizations relevant to your patient mix
- Smaller regional commercial plans (variable coverage — confirm each one)
- Worker's comp carriers (typically not ePA-eligible)
For each payer in your list, the kickoff call should produce a clear yes-or-no on ePA support, the expected response time, and any payer-specific configuration required. Payers that aren't ePA-eligible go into a separate workflow (manual submission via portal or fax), which is the work the native automation can compile but not fully send.
This step is where the rollout's real coverage gets defined. A practice with 90%+ of PA volume from ePA-eligible payers gets the full benefit of the automation; one with 60% has a meaningfully larger manual workflow still in front of them.
Step 2 — Map your procedure and medication catalog to PA flagging rules
The second step is the configuration work that determines what gets flagged when a provider places an order. The system needs to know which procedures and medications require PA at which payers — and the rule set has to match your specific specialty mix.
The implementation team works from two inputs: Nextech's baseline payer-policy library (which the team maintains across customers) and your practice's specific procedure catalog. The work is to overlay your catalog onto Nextech's library and identify the gaps — procedures your practice does that aren't yet in the library, or payers your practice contracts with whose policies the library doesn't fully reflect.
For specialty practices, the gaps tend to concentrate in a few areas:
- High-cost biologics in dermatology, rheumatology, and gastroenterology. Each major biologic has its own PA criteria at each payer; the rule mapping has to capture the step-therapy and prior-treatment requirements specific to each combination.
- Surgical procedures in ophthalmology, orthopedics, and plastic surgery. Procedure-specific PA requirements vary by payer and frequently by patient diagnosis combination, which the rule mapping needs to handle.
- Visit-frequency-limited services across multiple specialties. PT/OT visit limits, injection frequency caps, and certain imaging studies need rules that account for the patient's recent service history.
Plan for 1–2 weeks of catalog mapping work, including a review pass with your auth team and provider leadership to validate the rules before going live.
Step 3 — Configure the auth team's work queue and role-based routing
The third step is the operational configuration that determines how flagged PA requests reach your auth team. Inside Nextech, PA flags surface in a work queue; the queue configuration determines who sees what, in what priority order, and with what context.
The decisions to make in this step:
- Queue ownership. Some practices route every PA flag to a single central auth team; others split by specialty or by provider. For a multi-provider single-specialty practice, central queue ownership is usually cleanest. For a multi-specialty group, splitting by service line keeps the work focused.
- Priority ordering. Urgent PA requests (surgical procedures scheduled within 7 days, time-sensitive medication starts) should rise to the top of the queue ahead of routine PAs. Configure the urgency rules based on your scheduling cadence.
- Documentation pulls. For each procedure-payer combination, the rule should specify which chart sections to pull into the PA packet (H&P, imaging report, prior treatment history, etc.). The auth team can adjust per submission, but a sensible default reduces friction.
- Exception routing. When the automation can't fully assemble a PA submission (missing documentation, ambiguous payer rules, peer-to-peer requested), the case should route to a specific exception queue rather than getting stuck in the main queue.
This is where the rollout transitions from technical configuration to operational design. The configuration is reversible — your team will tune it during the first 60 days of operation — but starting with a clear ownership and routing model is what keeps the queue from becoming a graveyard.
Step 4 — Pilot on a subset of payers before going full network
The fourth step is to pilot the configuration on a focused subset of payers before turning the automation on for your full payer mix. This is the operational equivalent of shadow mode: the automation runs, the team validates the output, and any rule gaps surface where they can be fixed without putting real PA submissions at risk.
The right pilot scope is usually 2–4 payers representing 30–50% of your PA volume, with a mix of "easy" payers (major commercial, mature ePA support) and "hard" payers (specialty-heavy clinical criteria, payers whose policies recently changed). Run the pilot for 2–3 weeks with these criteria for moving to full rollout:
- The automation correctly flags PA requirements on at least 95% of orders for the pilot payers
- The pre-built submissions require less than 5 minutes of auth team review and editing on average
- Denials on submitted PAs aren't running higher than your pre-automation baseline
- The exception queue isn't growing past what the team can work in real time
When all four criteria are met, expand the live coverage to the rest of your payer mix. The cumulative timeline from kickoff to full network coverage typically lands at 4–8 weeks for a mid-to-large specialty practice with mostly ePA-eligible payers.
Common gotchas to plan for
Four issues surface frequently enough during Nextech prior authorization automation rollouts that operators should plan for them rather than be surprised.
Payer rules that change without notice. Payers update their PA requirements quarterly (or more often), and Nextech's rule library updates on its own cadence. The window between a payer changing a rule and Nextech catching up is where surprise denials happen. Build a monthly review where the auth team checks denied PA claims against the current rule set and flags any rules that need updating.
Peer-to-peer escalations that fall outside the automation. The automation can route the peer-to-peer request, but the actual call is provider-to-physician and stays manual. For practices with high peer-to-peer volume, this work stays on the provider's calendar regardless of how good the automation is.
ePA fallback when a payer doesn't support electronic submission. When a payer in your mix doesn't accept ePA, the automation can compile the submission packet but a staff member has to send it through the payer's preferred channel (portal, fax, occasionally phone). Plan for the auth team to spend meaningful time on the non-ePA payer subset until coverage expands or the payer adds ePA support.
Provider documentation gaps that block PA submission. Some procedures require specific clinical documentation in the chart for the PA to be defensible. If providers aren't documenting consistently, the automation surfaces the gap as a stuck PA. The fix is provider-level coaching, which the automation surfaces as data but doesn't solve on its own.
When to layer in a dedicated AI PA agent
Most practices that adopt Nextech's prior authorization automation eventually evaluate whether to layer a dedicated AI PA agent on top. The signal that it's time is usually one of three things: PA volume that's outgrowing the auth team's capacity even after automation, a payer mix that includes a significant share of non-ePA or unusual commercial plans, or denial-driven AR that's the largest single category of aged receivables.
Honey Health's Prior Authorization agent fits as the layer on top of Nextech's native ePA module. The agent reads orders from Nextech, applies its own payer-rule modeling across hundreds of plans (including the non-ePA long tail), handles submission across ePA, portal, fax, and phone channels, and writes PA status back into the Nextech work queue so the auth team operates in one place. The same architecture extends across eligibility verification, denial management, refill management, fax triage, and payment posting, so practices adopting AI PA automation as the first step can extend automation across the rest of the back office without changing vendors.
The honest framing: Nextech's native ePA module handles the routine workflow well. The AI agent on top is what closes the gap on the long tail. Whether the gap is worth a separate investment depends on your PA volume and payer mix — and on whether back-office automation is something you'll extend across multiple workflows over the next 12–18 months.
Frequently asked questions
How long does setup take if our practice doesn't have Nextech RCM yet?
Add roughly 4–6 weeks for the RCM module procurement and onboarding ahead of the PA configuration steps. The full rollout from initial conversation to live PA automation at full network coverage typically lands at 10–14 weeks if RCM isn't already in place, versus 4–8 weeks for practices already running Nextech RCM.
Do all providers in our practice need to be on the same workflow?
Not strictly, but it's much cleaner. The PA work queue and routing logic configure best when every provider's PA flags surface through the same queue with the same priority rules. If different providers run different PA workflows (one provider has their own auth coordinator, others share a central team), the configuration can support it but the rollout gets more complex and the analytics layer becomes harder to read.
What happens to PAs that are in flight when we go live?
In-flight PAs (already submitted to the payer, awaiting response) continue through the workflow they started in. The automation picks up new PA flags from go-live forward; the auth team continues to handle the in-flight cases manually until they resolve. Most practices reach a steady state where the automation handles the new flow within 2–4 weeks of go-live.
Does the automation integrate with our scheduling workflow?
Yes. When a PA gets approved through the ePA module, the status flows back into Nextech's scheduling workflow so the patient can be booked. When a PA is denied or pending, the case shows up in the scheduling queue with the right flag so the scheduler knows not to book the patient until the PA resolves. This is one of the strongest day-one benefits of the automation — schedulers stop calling patients to book appointments that can't actually happen yet.
Can we configure the automation to handle our specific specialty's clinical criteria?
Largely yes, with limits. Nextech's rule library handles the major commercial payer policies across most specialties. For specialty-specific clinical criteria the library doesn't fully model — particular step-therapy requirements, narrowly-defined diagnostic thresholds, named clinical trial enrollment exclusions — your auth team will need to layer those into the documentation pull rules during setup. A dedicated AI agent on top of Nextech is what closes the long tail where the rule library doesn't reach.
