Physical Therapy Clinic Software Problems: The 7 That Cause Denials, and How to Fix Them

Why does the scope stop at a shared calendar?

Because the complaint everyone can articulate is that the front desk cannot see the other clinics. So the project gets scoped as one calendar across four locations, which is genuinely useful and is about a third of the work.

What that scope misses is that scheduling in a therapy group is a rules problem rather than a visibility problem. Evaluations need longer than follow ups. Vestibular patients only match to therapists with that training. A returning patient should stay with the therapist who wrote her plan of care unless she asks to move. Pelvic floor slots cannot overlap with an aide supervised session. And a booking must check remaining authorised visits before it is offered at all.

Build a shared calendar without those rules and you have made it easier for four front desks to make the same mistakes faster. The coordinator still calls the other clinic to confirm what the screen appears to show, because she has learned not to trust it.

The fix is to write the rules down before quoting, in the words your clinical director uses, and treat each one as a testable condition rather than a note in a requirements document. The screen is the easy part. The rules engine underneath it is what makes the screen worth looking at, and it is the line most often underpriced.

What goes wrong when you migrate authorisation trackers and waitlists?

Both datasets are wrong on the day you migrate them, and that is the actual project.

Authorisation spreadsheets drift for predictable reasons. A visit was delivered and never decremented. A reauthorisation came through and the new count was typed into a different row. A patient transferred between clinics and both trackers now hold a partial history. Importing those counts as truth means your new system starts by enforcing a wrong number, and the first thing it does is block a legitimate booking or allow an illegitimate one, which destroys front desk trust in week one.

Waitlists are worse because they are stale rather than wrong. Names sit on them for weeks, half those patients have been seen elsewhere or given up, and nobody has curated the list because curating it was nobody's job.

What works: treat the authorisation import as a reconciliation with a human reviewing every case, not a load. Compare the tracker against the visit history in your record system and resolve differences before anything enters the new system. Run a short parallel period where the front desk keeps the spreadsheet updated while the new system takes over, so discrepancies surface while both sources still exist. For waitlists, do not migrate at all. Start clean, invite patients back onto the new list at their next contact, and you will have a list that is short and real rather than long and ignored.

Why does the record system sync break after launch?

Because the integration surface for a documentation first record system is narrower than the surface an open platform offers, and the sync design decides which features are even possible.

WebPT is built around a therapist documenting a visit, not around a central team routing demand across a metro area. Many builds therefore sync through scheduled exports plus whatever endpoints are available, which means some data flows overnight rather than instantly. That is workable, and it has consequences you must design for. If appointment data is a night old, a booking made in the new system and a booking made directly in the record system can collide, and the collision surfaces as two patients arriving for the same slot.

The second failure is drift. Somebody books directly in the record system because it was quicker, the new system does not know, and the availability it shows is wrong. Once a coordinator sees that twice, she stops trusting the screen and goes back to phoning the other clinic.

Three defences. Decide which system is authoritative for the schedule and enforce it operationally as well as technically, so direct booking in the record system becomes an exception with a reason rather than a habit. Read every booking back to confirm it landed before telling the patient. And put a visible freshness indicator on the screen, so a coordinator knows whether she is looking at live data or last night's, which is far better than her guessing.

What happens when authorisation workflow and protected data controls are not covered?

Authorisation is the operational gap that costs money every month. Storing an authorised visit count is not the same as managing it. The count usually exists somewhere in the record system, and nobody is looking at visit eight of twelve when the reauthorisation should be requested. Nothing stops the scheduler booking visit thirteen. The payer specific detail, which plans want progress notes attached and which portals take a week, lives in one biller's head and a colour coded spreadsheet, so when she takes a holiday the denials follow her out of the door.

Make the authorisation a first class object in the booking flow. Booking beyond the authorised count raises a hard warning that requires a manager override rather than a soft note. At a threshold you set, the system opens a reauthorisation task with that payer's checklist, the patient's outcome scores and a due date based on that payer's known turnaround. A single dashboard shows every authorisation expiring in the next fortnight across all locations. It is unglamorous plumbing and it is routinely the feature that pays for the project.

The data control gap is quieter and more serious. A custom layer holding schedule, authorisation and plan of care data is holding protected health information, which means a signed business associate agreement, encryption in transit and at rest, genuinely enforced role based access so a front desk user at one clinic cannot browse another clinic's patients, audit logging of every record access, and a documented breach process. Expect this to add a real percentage to any healthcare build. It is not optional and it is much cheaper designed in than retrofitted.

Should you build custom or configure what you already own?

Stay on what you have if you run one or two locations with fewer than ten therapists, your authorisation write offs are occasional rather than monthly, and your real complaint is documentation speed. Custom software built around WebPT will not make documentation faster, and at that size a strong front office lead who owns the spreadsheets rigorously beats a software project comfortably.

Configure harder before deciding. WebPT Reach and similar reminder tooling reduce no shows meaningfully, appointment types and durations can be set up properly, and per clinic reporting exists whether or not anyone runs it. A fair share of what groups describe as missing turns out to be unconfigured or unused.

Build when the coordination cost has become structural. A central scheduling team exists or clearly should. Authorisation write offs recur every month rather than occasionally. The owner cannot see yesterday's numbers without asking someone. And a fifth or sixth location is on the roadmap, which multiplies every one of these problems rather than adding to them.

One position we hold firmly: do not commission a record system replacement. Documentation and claims belong in the certified system you already have, where the regulatory burden and the therapist habits already live. The money is in the operational layer around it, and that layer is buildable inside a quarter.

How do hidden costs get into the quote?

Real time synchronisation with the record system is the first and largest. Scheduled exports are affordable. Anything approaching live is real engineering against a narrow interface, and it determines which features are possible at all, so it belongs in the first week of design rather than in a later phase.

The number of payers whose authorisation rules you want encoded is the second. Two payers is a pattern. Fifteen is a rules library with an owner and a maintenance cost, because payer rules change.

Patient facing applications are the third. A self scheduling portal on the web is one thing. Native mobile applications carry design work, store review cycles and a support obligation your clinics have never had.

Protected data infrastructure is the fourth, as above, and it is often absorbed into a line called hosting.

The authorisation reconciliation described earlier is the fifth, and it is regularly priced as a data import when it is a clinical and billing review with human decisions in it.

Sixth is the phasing itself. Insist on a first release scoped to ship inside one quarter under a contract that lets you stop after phase one and keep everything built so far, source code included. A developer who only sells the nine month version is optimising for their revenue rather than your clinics.

What separates a therapy clinic build that works from one that fails here?

First, the developer can explain your authorisation workflow back to you. Visit counts, reauthorisation timing, payer variation, and why visit eight of twelve is the moment that matters. A team that cannot describe that will burn your budget learning your industry, and the learning will show up as denials.

Second, backfill is automatic rather than aspirational. The moment a cancellation lands, the system computes which waitlisted patients actually fit that therapist, location and visit type and still have authorised visits remaining, texts the top matches a claim link, and only escalates to the front desk if nobody responds within a short window. That query spans scheduling, authorisation and plan of care data, which is exactly why no single off the shelf tool does it, and it is the feature that most reliably pays for the project because it converts payroll you have already committed into billed visits.

Third, drop off is visible the same week. Any active patient with no future appointment, or a booking cadence that has fallen below plan, appears on a morning list for that clinic with a one tap rebooking link that respects the same rules as the central scheduler. Recovered visits at the tail of a plan of care are the cheapest revenue a group can find, because acquisition already happened.

Fourth, you own it outright, with a work for hire or full assignment clause, code in a repository you control from day one, and third party licences documented. If a developer wants to licence the software back to you, walk.