Hub Services Vendor Selection: A Scorecard, the Data Terms and an RFP Timeline for Pharma

How to approach hub services vendor selection

Hub services vendor selection is best run as a launch-critical infrastructure decision: agree the access problem the hub must solve, score bidders against weighted criteria, make each finalist run scripted patient cases on its live systems, and write data rights, service levels and exit terms into the contract before award. Start in Phase 3, so the hub is configured, tested and sending data before the first prescription. Most manufacturers that regret a hub choice did not pick a bad vendor; they picked a vendor whose strengths did not match their product, or they signed a contract that left them without the data to tell.

The guides on page one cover the patient-facing questions well: breadth of services, nurse and navigator support, provider experience. What they mostly skip is the part that decides whether you can manage the hub after go-live: what data you receive, at what grain and how often, how case statuses are defined, how performance is measured and what happens to your data and patients if you leave. This guide covers both sides, with a scorecard you can adapt, the data terms to insist on, a timeline anchored to launch and the red flags to watch for.

We build specialty pharmacy and hub data pipelines and the dashboards that sit on them. We do not sell hub services, which is why the data side of the decision gets the attention here that vendor-written guides tend to leave out.

What buyers and analysts say about hub selection

Two decisions to make before you write the hub services RFP

Before drafting questions, settle two structural choices, because they change who you invite.

Integrated hub or best-of-breed stack. An integrated hub runs benefits verification, prior authorisation support, copay and patient assistance, nurse support and specialty pharmacy triage under one contract. A best-of-breed stack splits these across specialists, for example a copay vendor, a benefits verification platform and a separate nurse educator team, with your company or a lead vendor coordinating. Integrated is simpler to manage and easier to measure end to end. Best-of-breed can be stronger where one function is the binding constraint, but you take on the integration and the data reconciliation.

Technology-led or services-heavy. Some vendors lead with electronic benefits verification and e-prescribing-connected workflows that move high volumes with few touches. Others lead with case managers who handle complex, low-volume patients by phone. rxalmanac.com's hub buyer's guide makes the point that mismatching scale to vendor capability is one of the most costly errors: a rare disease therapy with a few hundred patients and a primary care specialty product with tens of thousands of starts need different hubs.

Write down the binding access problem for your product in one sentence, such as medical benefit verification for a buy-and-bill infusion, or copay integrity for a commercially insured self-injectable. Every weight in the scorecard should follow from it. Our guide to the patient journey in specialty pharma is a useful way to locate where your patients are most likely to drop out.

A weighted hub vendor scorecard to start from

• Fit to the binding access problem (25%)

  Evidence the vendor runs your benefit type, payer mix and therapy area at your expected volume, shown in scripted cases rather than slides.

  • Pharmacy vs medical benefit experience
  • Comparable programmes still live
  • Escalation paths for complex cases

• Patient and provider experience (20%)

  How quickly offices get answers, how patients are contacted, and how the hub handles patients who stall between steps.

  • Provider portal and e-enrollment
  • Outreach cadence for stalled cases
  • Nurse or navigator model

• Data delivery and transparency (20%)

  Record-level data at daily frequency, a documented status model, tokenised patient identifiers and raw access, not only a vendor dashboard.

  • Data dictionary in the RFP response
  • Sample file from a live programme
  • Token provider named

• Compliance and privacy controls (15%)

  How patient authorisations are captured, how PHI is separated from commercial use, and how the vendor keeps field teams away from patient-level data.

  • Authorisation language and storage
  • Firewalls between hub and field
  • Audit and incident history

• Operational capacity and continuity (10%)

  Dedicated or pooled staff, launch surge plans, turnover, backup sites and how quickly new payer policies are loaded.

  • Named team for your programme
  • Surge staffing plan
  • Disaster recovery tested

• Commercial terms and exit (10%)

  Fee model, change order rules, service credits and a priced transition plan if you leave.

  • Per-case vs fixed fees
  • Service credits tied to SLAs
  • Transition assistance priced up front

Hub data rights: the terms most contracts get wrong

A hub sees more of the patient journey than any other source you will license: every referral, every benefits verification outcome, every denial and appeal, every hand-off to the specialty pharmacy. If the contract only promises a monthly report or access to the vendor's portal, you will be managing your most important launch vendor by screenshot. Put these terms in the RFP so bidders price them, then in the contract.

• Record-level, daily data. One row per case status change, with dates and reason codes, delivered daily to your own environment. Aggregated reports are useful, but they cannot be reconciled with specialty pharmacy dispense data or claims.
• A documented status model. A data dictionary listing every status and sub-status, what triggers it and how it maps to stages such as benefits verification, prior authorisation, appeal, financial assistance, shipped and discontinued. Our article on specialty pharmacy status codes shows why this matters once several sources are combined.
• Tokenised patient identifiers. De-identified tokens from a named tokenisation provider, so the same patient can be linked across the hub, specialty pharmacies and claims without your company holding identities. See patient tokenization in specialty pharma for how this works.
• Ownership and continuity. The manufacturer owns the programme data, can receive full history in a defined format at any time, and receives it within a set period if the contract ends.
• Change control. Any change to file layout, codes or definitions needs notice and a test file before it goes live, so your dashboards do not break silently.

This is the work our specialty pharmacy and hub data integration service does after award: ingest and validate the hub feed, link it to dispense data and build the reporting market access and patient services teams share. It is much easier when the contract asked for the right data in the first place.

Scripted cases every finalist should run

Clean start

Watch the whole path from e-enrollment to specialty pharmacy hand-off on the vendor's production system, and time each step. This shows the baseline experience a busy office will have.

Denial and appeal

Ask the vendor to show how the denial is captured, who drafts the appeal support, how the prescriber is kept informed and how the case is coded while it waits.

Affordability

Walk through copay programme enrollment, the screening for patient assistance and the hand-off to an independent charity where relevant, including how the vendor keeps those steps compliant.

Drop-off

This is where programmes lose patients quietly. Ask how many attempts are made, on which channels, when the case is closed and what reason is recorded.

A hub selection timeline anchored to launch

Service levels and KPIs to write into the contract

Vague promises such as industry-leading turnaround cannot be enforced. Define each metric precisely, agree how it is calculated from the record-level data, and tie a share of fees to the ones that matter most for your product.

• Time to benefits verification: from a complete enrollment to a verification result communicated to the office, measured in business hours.
• Time to therapy: from enrollment to first shipment or first infusion, split by stage so delays can be located. Our guide to KPIs for patient support hub programs covers the definitions in detail.
• Abandonment and drop-off: the share of approved patients who never start, with reason codes, measured the same way as your specialty pharmacy data.
• Contact centre performance: answer time and abandonment rate for office and patient calls.
• Data quality: files on time, completeness of required fields and the share of records that pass validation.

Agree that disputes over a metric are settled from the raw data you receive, not from the vendor's own dashboard. That single clause changes the quality of every quarterly business review.

Red flags during hub vendor evaluation

When not to run a full hub services RFP

A full selection process takes months and real effort from busy teams, so it is not always the right move.

• The incumbent's problem is data, not service. If offices and patients are well served but you cannot see performance, renegotiate the data terms and fix the reporting before switching. A switch mid-lifecycle carries real risk of patients falling through the gap.
• Volume is too small to support a full hub. Some products with very few patients are better served by a specialty pharmacy's own services plus a focused nurse or case manager model.
• Launch is too close. If you are within a few months of approval with no hub, a shorter process with fewer bidders and a firm scripted test beats a long RFP that leaves no time to build and test.

Whichever path you take, plan the reporting at the same time as the contract. A hub that cannot be measured cannot be managed, and the cost of fixing the data after go-live is always higher than asking for it in the RFP. For how hub data fits with specialty pharmacy feeds and claims, see our overview of specialty pharmacy analytics.

Questions about hub services vendor selection