A Prior-Authorization Workflow That Survives Multi-State Coverage

I spent three years running PA operations for a telehealth cardiology group that started in four states and ended up in fourteen. The thing nobody tells you when you sign the fifth state's contracts is that each new state builds a fifth process, wearing the first one's clothes. Prior authorization rules sit at the payer level, but payers adjust criteria state by state to comply with insurance codes, Medicaid managed care contracts, and network adequacy rules that shift at every border. I've seen a single commercial payer run eleven different medical policy documents for the same CPT code across twelve states, because state mandates on telehealth parity, step therapy limits, and referral requirements force local variation whether the payer wants that complexity or not. Medicaid makes it worse. CMS sets broad guardrails, but each state runs its own program underneath them, so billing Medicaid in Ohio and Medicaid in Texas for the same endocrinology consult means two fee schedules, two sets of PA criteria, and two definitions of what "remote" even means for coverage. Nobody hands you a memo explaining this, and you find out only when the denial comes back with a reason code that doesn't match anything you've seen before. Telehealth parity laws make this worse before they make it better, which surprised me the first time I ran into it. A state can require payment parity for virtual visits, reimbursing telehealth at the same rate as in-person, without requiring utilization parity. So the payer pays the same rate but still demands stricter PA documentation for the video visit than the office visit, and we assumed, wrongly, in our second year, that if an in-person echo didn't need PA, the telehealth version wouldn't either. Wisconsin taught us otherwise, and that one denial cost us about eleven days of care delay for a patient who needed a cardiology follow-up sooner than that. ## Documentation packets: build by payer-state pair, not by specialty The obvious move is building one packet per specialty. A rheumatology PA and a psychiatry PA clearly need different clinical content, and most practices get that far on instinct alone. What they miss is that the packet also has to flex by payer and by state, because identical CPT codes trigger different documentation thresholds depending on where the patient happens to be sitting when the claim gets filed. What worked for us was a base template plus overlays. The base covered what every payer wants regardless of geography: history and physical findings, relevant labs or imaging, prior treatment attempts, a clear medical necessity statement tied to the CPT or HCPCS code in question. The overlay layer stacked on whatever a specific payer in a specific state demanded beyond that. A Wisconsin Medicaid managed care plan wanted a signed telehealth consent form as its own standalone attachment, while the private payer down the street, same state, didn't ask for it at all. California's telehealth documentation rules looked nothing like New York's for the exact same clinical scenario, down to the wording of the attestation line. Skip the overlay step and submit the same packet everywhere, and the denial rate climbs steadily with each new state, because some form or attestation a specific payer requires never made it into the packet, even when the clinical case itself is strong. We tried the opposite fix too: pad every packet with every possible attachment, just in case. That slowed submission down and buried reviewers in paper nobody asked for, and our approval rate didn't move. What actually worked was a maintained matrix, kept inside our PA software, mapping payer, state, and specialty to the exact attachment list, updated every single time a payer revised its medical policy. That last part is the one people skip, because payers don't send a press release when they change a policy, and someone has to go looking. ## Denial coding: reading the reason behind the reason Denial codes look standardized on paper. CMS and most commercial payers use some version of the X12 278 response codes, layered on HIPAA-adopted reason and remark code sets, so in theory a "medical necessity" denial should mean the same thing everywhere. It doesn't, and the same underlying reason gets coded inconsistently payer to payer. Treating the raw code as the whole story gets you nowhere fast. A denial marked "not medically necessary" from one payer might genuinely reflect a documentation gap in the chart. The identical code from a different payer might really mean the packet lacked the specific telehealth attestation language buried three pages deep in that payer's medical policy, an administrative failure wearing a clinical costume. We learned this the hard way after resubmitting three straight denials with more clinical detail, more labs, a longer necessity statement, only to get bounced again for the same reason. The chart was never the problem. So we built our own tag alongside the payer's official code: clinical-insufficiency, administrative-technical, eligibility-mismatch, out-of-network-technicality. Four tags, just enough to tell staff what the appeal actually needs to contain before they start writing it. Administrative-technical denials hit remote practices disproportionately, and this is the part that's specific to telehealth: missing originating-site information, a GT or 95 modifier the payer's system expected and didn't get, a place-of-service code that doesn't match what their claims engine wants for a virtual encounter. Catch these early and they're a one-shot fix, but catch them late, after someone's already drafted a clinical appeal for what was really a coding error, and you've burned a turnaround cycle on the wrong problem. ## Appeal turnaround: the clock is different everywhere There's no national clock for appeals. Deadlines come from a mix of state insurance regulation, individual health plan terms, and, for Medicaid, whatever language sits in that state's managed care contract. I've worked appeals with a thirty-day standard window in one state and something closer to half that in another, for the same payer, same plan type, different zip code on the patient's address. Expedited appeals exist for exactly the situations where the standard clock creates a health risk, which matters enormously in specialty care, where a delay can leave a patient waiting past the point it's safe to wait. But the criteria for what even counts as expedited shift by state and by payer, so staff need to know, plan by plan, when they can invoke that pathway and what justifies it on paper. We missed an expedited designation once, early on, because the case came in on a Friday afternoon and nobody flagged it before the weekend. What should have been a 72-hour turnaround turned into a three-week delay, because the standard track was never built to handle urgency it didn't know existed. A shared spreadsheet with due dates doesn't hold up at volume; ours didn't survive past state number six. What did work was a tracking system built around payer and state pairs, storing the standard window, the expedited window, the required submission format (fax, portal, or direct API for the payers that support electronic prior authorization under the newer interoperability rules), and an internal deadline set several days ahead of the real one, so a bounced resubmission still has room to get fixed before the actual clock runs out. ## What holds the system together None of these three pieces, the documentation matrix, the denial taxonomy, the appeal tracker, does much on its own. A denial correctly flagged as administrative-technical is only useful if someone updates the documentation matrix with the missing requirement, and an appeal tracker is only useful if a person actually acts inside the window it's tracking. We learned that the hard way more than once, usually on a Friday. The practices that manage this well stop treating PA as a task you hand to one biller and forget about. It's a small research function that never really stops, because payer medical policy changes, state regulations shift, and CMS updates its interoperability rules, and none of these things announce themselves. Someone has to be the person who reads the update email nobody else opens. That's overhead, plainly. But an ad hoc process that assumes every state behaves like the first one costs more, in denied claims, delayed care, and staff hours spent relearning the same lesson state by state, than building the matrix right the first time. Remote specialty care doesn't scale past a handful of states on good clinical work alone. It scales when someone, somewhere, builds the boring parts to handle the variation instead of hoping it will go away.