Make vs Zapier for Outpatient Physical Therapy Networks

Before the first visit, note whether the payer requires prior authorization at all, and if so, whether it's been obtained. A straightforward Zapier connection that checks authorization status against the payer and flags a missing one before the first visit is scheduled catches the most damaging version of this gap: treatment starting, and racking up visits, before authorization exists at all.

Most authorizations cover a specific number of visits, not an open-ended course of care, and treatment continuing past that count without a renewed authorization is a real payment risk, not a paperwork technicality. This needs conditional logic: count visits against the specific authorization on file for that patient and that payer, and flag it with enough lead time, several visits before the count runs out, to actually request a renewal before treatment has to pause. That counting-and-flagging logic, tied to each patient's individual authorization rather than a flat visit-number rule for every case, is where Make's branching fits better than a simple Zapier trigger.

Some payers require specific documentation, a progress note at a set visit interval, functional outcome measures at intake and discharge, tied to the authorization itself, not just to the general chart. Missing that specific documentation can mean a denied claim even when the visit itself was entirely appropriate and covered. Flagging the documentation requirement at the same time as the visit-count check, rather than as a separate workflow someone has to remember to run, keeps both checks from drifting out of sync with each other.

At discharge, outcome measures need to close out the episode of care both clinically and administratively, feeding back into the record in a way that supports the next authorization request if the patient returns for a related issue later. A clean discharge record makes a future reauthorization request faster and more likely to succeed the first time, rather than starting from scratch on documentation that already existed but wasn't organized to be reused when the patient came back six months later with a related complaint.

Walk five recent patients through these four columns and mark where each one actually stalled or nearly stalled: a late authorization, a visit count that ran out before anyone noticed, a missing progress note, or clean sailing throughout. If the same column keeps showing up as the problem across most of the five patients, that's your first automation project, not a general platform decision made in the abstract. Most PT networks find visit-count tracking against individual authorizations is the recurring problem across nearly every patient they check, which points toward Make over a simple Zapier trigger from the start.

Use this sequence to run the exercise:

1. Pick five recent patients and walk each one through the four columns: authorization at intake, visits remaining, documentation, and discharge tracking.
2. Mark where each patient actually stalled or nearly stalled, such as a late authorization, a visit count that ran out unnoticed, or a missing progress note.
3. Note which patients had clean sailing, so you can see what the process looks like when it works before you change anything.
4. Count how often each column shows up as the problem across the patients you reviewed.
5. Automate the column that recurs most, and only then compare Zapier, Make and Workato against that specific gap.

It's tempting to build a single authorization-tracking workflow and assume it covers every payer, but different payers genuinely have different authorization rules, some require it upfront, some allow a grace period, some cover a visit count and others cover a date range instead of a count. A single flat workflow built around one payer's rules will misfire constantly against the others, either flagging false alarms on payers that don't actually require the same thing or, worse, missing real gaps on payers whose rules the workflow was never built to check. Map your actual payer mix before building anything, and expect the real workflow to branch by payer type from the start rather than treating that branching as an edge case to bolt on later once the simple version turns out not to fit most of your caseload.

A useful discipline is naming the payer explicitly in every rule you write down, rather than writing a rule that silently assumes one payer's behavior applies to everyone. That habit alone catches most of this mistake before it ever reaches a live workflow.