Patient Support Hub Software: Why Time to First Dose Stalls Between Enrollment and the Pharmacy

Why hub services software decides whether a specialty launch works

A fax lands in the hub queue at 8:41 on a Tuesday. It is a four page enrollment form for a specialty biologic. Page one has the patient demographics. Page three is missing the prescriber signature. The authorization checkbox on page four is blank, which means legally you cannot do most of what the form was sent to you to do. A case coordinator opens it, creates a case, calls the office, gets voicemail, and drops the case into a queue called Pending Missing Information alongside four hundred others.

Across town the field reimbursement manager for that territory is standing in the prescriber's office being asked one question: where is my patient. She does not know. She has read access to a vendor portal showing a status of In Process, last updated three days ago, with no way to tell whether the delay is the missing signature, a payer that has not answered the prior authorization, or a specialty pharmacy sitting on the prescription waiting for a copay card. Every day in that queue is a day the patient is not on therapy, and on a specialty product the finance impact of a day is not subtle.

The vendors here, AssistRx, ConnectiveRx, Mercalis and Careform, all run real hubs at real scale. What you buy is a service wrapped around a platform, and that platform was designed around their case model, not your program design. When your eligibility rules change, and they will change at every plan year and every payer policy shift, you file a change request and wait. For a manufacturer whose launch curve is a function of time to therapy, waiting a quarter to change one eligibility rule is the problem, not the price.

Problem 1: the enrollment form is a fax, and half arrive incomplete

Prescriber offices send what they send. Some use your portal. Many print the PDF, complete it by hand and fax it, because the medical assistant doing it has fifteen other manufacturer forms that day and the fax is the only channel that works for all of them. You will not change that with a training deck, and you should stop planning as though you will.

Packaged hub platforms solve the fax by putting a person in front of it. Someone reads the image, keys the fields and flags what is missing. That model scales by hiring. It matters because intake is where days are lost: an incomplete form caught in the first hour and chased the same morning is a different program from one caught on day four when the queue finally gets worked.

What a custom build does: document extraction reads the fax on arrival, pulls patient, prescriber, NPI, diagnosis, insurance and the signature and authorization boxes, and scores completeness before a human opens it. Incomplete cases trigger an outbound within minutes naming the exact missing field rather than a generic please call us. Complete cases route straight into benefit verification. The value is not headcount reduction. It is that the missing signature gets chased on the morning it arrives.

Problem 2: benefit verification and prior authorization are two queues pretending to be one

Benefit verification for a specialty product is not one lookup. You have to establish whether the drug falls under the pharmacy benefit or the medical benefit, and for many products the answer differs by plan. An electronic eligibility exchange confirms the patient has coverage. It does not tell you the specialty tier, the step therapy requirement, the site of care restriction, or whether the plan mandates an exclusive specialty pharmacy that is not in your limited distribution network. So the coordinator calls the plan, waits on hold, and types what she hears into a free text note.

That note is where the program's knowledge dies. Nobody can query it. When the same plan denies for the same criterion for the twentieth time, no system notices, and market access finds out from an anecdote at a national sales meeting.

What a custom build does: treat payer policy as data, not narrative. Every verification writes structured fields: benefit type, tier, authorization required, step therapy drug, mandated pharmacy, appeal path and turnaround. Those fields accumulate into a payer policy library that improves every week the program runs, so the next coordinator opening a case for that plan starts with everything the previous twenty cases learned. That single change turns a hub from a call centre into an asset the brand team can use in a contract negotiation.

Problem 3: pharmacy status arrives as a flat file on Thursdays

Once the prescription is triaged to a specialty pharmacy in your network, you lose the patient. What comes back is a dispense status file, usually delimited text over SFTP, often weekly, with each pharmacy using its own column names and its own status vocabulary. One says Shipped. Another says Fulfilled. A third reports only completed fills, so a patient who abandoned at copay looks identical to a patient the prescription never reached.

Hub platforms will ingest and map those files for you, per pharmacy, as a configuration project you pay for. The gap is reconciliation. The pharmacy record carries a different patient identifier and no case number, so matching it back to your case is guesswork, and the silent failure mode is a case showing Triaged forever with no dispense ever appearing against it.

What a custom build does: a matching layer that reconciles on a composite of identifiers with a confidence score and a human review queue for the ambiguous ones, plus an explicit stall detector. A case triaged beyond a threshold with no dispense event becomes a work item with a reason hypothesis, not a row in a monthly report. Time to first dose stops being a number you calculate in arrears and becomes a queue somebody works this afternoon.

Problem 4: consent scope is the part that gets a manufacturer in trouble

A manufacturer may receive patient identifiable data only inside the scope of the authorization the patient signed. Different programs, forms and states carry different scopes, and the same patient may have signed one authorization for the hub and a narrower one for a nursing service. Copay support cannot be offered to patients with federal healthcare coverage, which is a hard line under the Anti-Kickback Statute and not a configuration preference someone can toggle for a good quarter.

Packaged systems carry a consent flag. A flag is not a scope. It cannot express that this patient authorized adherence outreach but not brand team data sharing, that the authorization expires on a date, or that a revocation must retroactively suppress the patient from a report already scheduled to run.

What a custom build does: consent becomes a versioned object with scope, effective date, expiry and revocation events, and every read path checks it at query time. Reports to brand teams pass through that filter rather than trusting an analyst to remember. The copay eligibility rule reads coverage type first and refuses federal beneficiaries in code, with a test suite behind it. When compliance asks how you know a given extract contained no unauthorized patients, you show a query log rather than an assurance.

Problem 5: brand and market access ask questions the vendor platform cannot answer

The questions never change. Days from enrollment to first dose, by payer, by territory, this quarter against last. Which payers drive denials and on which criteria. Which practices enroll and then stall. What proportion of free goods starts convert to a paid fill, and how long that takes. Standard hub reporting returns volume counts and status buckets, which answer none of those.

What a custom build does: an event model underneath the case. Every transition is a timestamped event with an actor and a reason code, so time between any two states is a query rather than a report request with a two week lead time. That is what lets market access argue with a plan using the plan's own denial pattern, and lets the field team be pointed at the practices where cases actually die.

What a patient support hub build costs and how long it takes

A first release covering intake with document extraction, case management, structured benefit verification, prior authorization support, copay and free goods eligibility, and pharmacy triage with status reconciliation runs $90,000 to $180,000 and ships in 14 to 20 weeks in our delivery experience. A full platform adding nurse educator scheduling and call scripting, adherence programs, appeals workflow, a prescriber portal, a patient portal, field reimbursement views with consent enforcement and brand analytics runs $250,000 to $600,000 phased over 9 to 15 months.

What pushes the number up in this category specifically: the count of specialty pharmacies in your network, because each one is a separate file format and its own reconciliation rule. Multi product programs where every brand carries its own eligibility criteria and its own authorization form. Nurse and injection training services, which drag scheduling and field staff mobile use into scope. Telephony integration for screen pop and call recording. And migration of open cases from an incumbent vendor, which is always harder than the vendor's export suggests, because case history and consent records rarely come out clean.

What keeps it down: one product, one authorization form, your top three pharmacies by volume, and leaving nurse services with the existing vendor through the first year.

Build versus buy, and when the hub vendor is the right call

Buy the service if you have a single product, a few hundred enrollments a year and no second brand in the pipeline. A full service hub gives you trained coordinators, an existing pharmacy network and a compliance posture you do not have to construct from scratch. That is worth real money and you should pay it rather than learning case management on your own launch.

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

There is a middle path that works well and almost nobody proposes it: 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 to choose a developer for patient support and hub software

Ask them to model consent on a whiteboard before you sign anything. If they draw a boolean, they are about to build a compliance problem into your foundation. You want scope, version, effective dates, revocation and an enforcement point at query time.

Ask what they have integrated on the pharmacy side. Reconciling weekly dispense files from five specialty pharmacies with mismatched identifiers is the unglamorous core of this system, and a developer who has done it will start talking about match confidence and exception queues without being prompted.

Ask how they will enforce the copay eligibility rule for federally insured patients. The right answer is in code, with tests and an audit log, never left to a coordinator's judgement under production pressure.

Ask who owns the code, the cloud accounts and the data, and put it in the contract before kickoff. At Digital Heroes the client owns the repository from the first commit and the infrastructure runs in the client's own accounts. In a category where the entire reason to build is escaping vendor dependency, accepting a new dependency defeats the exercise.