Patient Support Hub Software Problems: The 7 That Stall Time to First Dose, and How to Fix Them

Why does hub scope stop at the case record?

Most hub software requirements describe a case: create it, assign it, move it through statuses, close it. That is the part everyone can picture, and it is the part packaged platforms already do well. What gets left out is everything that determines how long a case takes, which is the only measure the brand team actually cares about.

The omissions are consistent. Intake is scoped as a data entry screen rather than as document handling. Benefit verification is scoped as a note field rather than as structured payer policy. Pharmacy triage is scoped as a handoff rather than as a reconciliation problem. And the stall detector, the thing that notices a case has not moved, is nobody's requirement because it is nobody's screen.

The fix is to scope by elapsed time rather than by workflow step. Draw the path from fax received to first dose, put a target duration on every hop, and then ask for each hop what evidence proves it completed and what raises an alarm when it does not. In our delivery experience that exercise surfaces two or three transitions nobody owned, and those transitions are almost always where the days are going. It also produces the event model the analytics depend on, because a system that records only current status can never tell you where time was lost.

What goes wrong when you migrate open cases and consent records?

Vendor exports flatter themselves. Demographics and current status come across cleanly, which is why the export looks fine in a sample. The parts that matter come across badly or not at all.

Case history is the first casualty. Note threads written by coordinators over months carry the reasoning behind every decision, and they usually arrive as one concatenated text blob with no author, no timestamp and no link to the event they describe. Once flattened, that history cannot be reconstructed, and the first time somebody needs it is during an audit or an appeal.

Consent is the one you cannot improvise. If the incumbent recorded consent as a flag, the export tells you the patient consented but not to what, under which form version, from which date, or whether any part was later revoked. You cannot lawfully assume scope, and you cannot ask several thousand patients to re-sign because a software migration lost the detail.

Pharmacy linkage is the third. The mapping between your case and the pharmacy's patient record often exists only inside the incumbent's matching layer, so it does not appear in an export at all.

The pattern that works is parallel running rather than a cold cutover. Open every new case in the new platform, let the existing caseload burn down in the old one, and migrate only what you can prove. Never cut over during a plan year change, when eligibility is shifting under everybody at once.

Why do specialty pharmacy and payer integrations break after launch?

Because none of the counterparties are integrating with you. They are sending you a file they already produced for their own purposes.

Pharmacy dispense files break in three ways. Column names change without notice because the pharmacy upgraded its own system. Status vocabularies differ between pharmacies and drift within one, so Shipped, Fulfilled and Complete mean subtly different things across your network. And some pharmacies report only completed fills, which means a patient who abandoned at the counter over cost looks identical in your data to a patient the prescription never reached. That is the difference between an outreach opportunity and a lost patient, and the file cannot tell you which.

Payer connections break differently. Electronic eligibility exchange confirms coverage exists. It does not tell you the specialty tier, the step therapy requirement, the site of care restriction or whether the plan mandates a pharmacy outside your network, so the coordinator still calls, and whatever she is told still needs somewhere structured to live.

Three defences. Validate every inbound file on arrival against an expected shape and quarantine rather than silently ingest when it fails. Normalise every pharmacy status into your own vocabulary with an explicit mapping per pharmacy that a human owns. And match on a composite of identifiers with a confidence score, routing ambiguous matches to a review queue instead of discarding them. Above all, build the stall detector: a triaged case with no dispense event past a threshold becomes a work item with a reason hypothesis, not a row in a monthly report.

What happens when consent scope and copay eligibility are not modelled properly?

These are the two failures that turn a software problem into a compliance problem, and both are usually discovered by someone other than you.

Consent is not a flag. A patient may have authorised the hub to contact her and to coordinate with her pharmacy, but not authorised patient identifiable data to reach the brand team. A different program or a different state form may carry a different scope. Authorisations expire. Patients revoke. A system that stores a single boolean cannot represent any of that, so the rule ends up living in an analyst's memory, and the failure surfaces when a scheduled extract runs after a revocation and includes a patient it should not.

Copay support carries a harder line. It cannot be offered to patients with federal healthcare coverage, which is a legal constraint under the Anti-Kickback Statute rather than a program preference somebody can toggle when a quarter looks tight. Leaving that to a coordinator's judgement under production pressure is how programs generate findings.

Build both as enforced structure. Consent becomes a versioned object with scope, effective date, expiry and revocation events, checked at query time on every read path, so a brand report is filtered by the system rather than by a person remembering. Copay eligibility reads the coverage type captured during benefit verification and refuses federal beneficiaries in code, with a test suite and an audit log behind it. When compliance asks how you know an extract contained no unauthorised patients, you show a query log rather than an assurance.

Should you build custom or configure what you already own?

If you have one specialty product, a few hundred enrollments a year and no second brand in the pipeline, keep the vendor. AssistRx, ConnectiveRx, Mercalis and Careform run real hubs at real scale, and what you are buying is trained coordinators, an existing pharmacy network and a compliance posture you do not have to construct. That is worth paying for rather than learning case management on your own launch.

Push the configuration further before concluding it cannot flex. A fair share of what manufacturers describe as platform limitations turns out to be a program rule that was never written into the vendor's configuration because the original implementation team has rotated.

Build when three things are true together. You carry two or more specialty products, so program logic is a portfolio problem and every change request multiplies across brands. Your rules change more than twice a year, which becomes normal the moment payers start actively managing your product. And patient level event history is strategic to how you negotiate access, which means the data has to sit in your environment rather than in a quarterly extract.

There is a middle path almost nobody proposes: keep the vendor's people, own the platform. Contract case management labour from a service provider while running your own system, so staffing and call centre compliance stay outsourced and the program logic and the data do not.

How do hidden costs get into the quote?

The count of specialty pharmacies in your network is the first, and it is rarely priced honestly. Each pharmacy is a separate file format, a separate status vocabulary and its own reconciliation rule. Three pharmacies is a modest integration. Eight is a workstream.

Multi product scope is second. Every brand carries its own eligibility criteria and its own authorisation form, and forms are not cosmetic, they define what the system is legally permitted to do with the data.

Nurse and injection training services are third, and they drag scheduling, field staff mobile use and visit documentation into scope. Leaving these with the incumbent through the first year is the single easiest way to keep a first release contained.

Telephony integration for screen pop and call recording is fourth, and it is more work than it sounds because the matching between an inbound number and a case is imperfect.

Migration of open cases is fifth, as described above, and it is always harder than the vendor's export suggests.

Ask for each of these as a named line. A single figure labelled integrations means nobody has looked at your pharmacy network yet.

What separates a hub build that works from one that fails here?

Four things.

First, the system chases the same morning. Document extraction reads the inbound fax on arrival, scores completeness before a human opens it, and triggers an outbound naming the exact missing field within minutes. The gain is not fewer coordinators. It is that a missing prescriber signature is chased on day zero rather than day four.

Second, payer knowledge accumulates. Every verification writes structured fields for benefit type, tier, authorisation requirement, step therapy drug, mandated pharmacy and appeal path, so the next coordinator opening a case for that plan starts with everything the previous twenty cases learned. A hub that stores this as free text throws away its own best asset every day.

Third, stalls raise work items. Nothing sits in a queue unexamined because a triaged case with no dispense past a threshold becomes somebody's task this afternoon, with a hypothesis attached.

Fourth, ownership is settled in writing before kickoff: the repository, the cloud accounts and the data are yours, and the infrastructure runs in your own accounts. In a category where the entire reason to build is escaping vendor dependency, accepting a new dependency defeats the exercise. At Digital Heroes the client owns the code from the first commit.