Capital S Consulting
Patient Services and Hub Integration That Fits Your Model
The hub, the specialty pharmacies, and your team each own part of the patient journey. We help you decide who holds what, then build the feeds and visibility that keep everyone current
Three Parties, One Patient Journey
In one common model, three parties touch every patient. The hub is the system of record: it takes the enrollment form, captures consent, holds the patient's identity, and routes each prescription to the right specialty pharmacy based on payer and business rules. The specialty pharmacies run benefits investigation, prior authorization, appeals, dispensing, and refill outreach, and push every status change back to the hub as it happens. You hold the third seat: your field teams work providers and accounts in your CRM, your leadership works from dashboards, and both run on de-identified data flowing from the hub into your commercial data warehouse. A 3PL moves product underneath all of it. Capital S builds your side of that triangle, and works through the design with your team so the triangle holds. It is one piece of the wider launch platform we stand up for firms bringing a first therapy to market
Who Does What in a Modern Hub Model
Four groups touch a patient between a signed prescription and a first dose. The platform has to reflect how that work is split, and where the patient's identity is allowed to live
The Hub: Master Patient Record
The hub receives enrollment forms, stores patient identity and consent, creates the tokenized patient identifier, and holds the single master patient record. It routes each prescription to the right specialty pharmacy and tracks the journey end to end. In this model, the hub is the single source of truth for the patient
Specialty Pharmacies: Execution
Benefits investigation, prior authorization, appeals, claims adjudication, dispensing, and refill outreach. Each pharmacy sends shipment, refill, and adherence updates back to the hub in near real time, so the hub always holds the complete journey
Your Systems: De-Identified Visibility
Your CRM holds providers, accounts, field and FRM activity, and patient case status. Your data warehouse receives the hub's reporting feed for analytics and KPIs. Many programs keep both systems free of patient identity by design, with everything keyed to the tokenized patient identifier
Your People, in the Right Systems
Who works where is your decision, made during the operating model design. Some programs put care coordinators in the hub platform where the identified case sits. Others keep case work in your CRM. Field reimbursement managers typically work escalations in your CRM, and leadership works from warehouse-fed dashboards. Nobody re-keys a status between systems
The Hub Has the Data. Your Team Does Not
Nothing here is a vendor failure. The hub is doing its job, the specialty pharmacies are doing theirs, and the information still ends up stranded on the wrong side of a contract boundary. That is a design problem, and it gets solved in the feeds and the data model
Your Team Works From Yesterday
The hub knows benefits verification came back yesterday afternoon and the prior authorization was denied this morning. Without a reporting feed, your field team and your leadership find out on the next status call, or from a spreadsheet somebody exported Friday. The data is there. The lag is what costs you
No Agreed Source of Truth
The hub owns the master patient record. The pharmacies own the dispensing detail. Your warehouse owns the de-identified journey. That split works when it is written down per data domain: created where, mastered where, copied where. Left unwritten, records drift and reconciliation turns into a standing meeting
Consent and Identity Stay Fuzzy
Everyone agrees patient identity needs a boundary. Far fewer teams can say exactly which system may hold what, from the enrollment form arriving to your dashboard counting the patient. That boundary belongs in the data design, where nobody has to remember it
What We Build on Your Side
We build your side of the model on Salesforce and an AWS commercial data warehouse. We do not stand up the patient services operation end to end. What we recommend is using the partners' own feeds and sending de-identified information back into your systems, then doing the design work that keeps all three parties aligned. If your program runs without a hub and the pharmacies report straight to you, start with our specialty pharmacy integration page instead
The Consolidated Hub Reporting Feed
One scheduled, de-identified feed from the hub into your commercial data warehouse, covering the full patient journey: enrollment and consent status, benefits verification and prior authorization outcomes, program determinations, specialty pharmacy assignment, and the shipment, refill, and adherence updates the pharmacies push to the hub. We write the specification with the vendor, validate every load, and make failures visible instead of silent
Tokenized Patient Identifier Architecture
The hub creates the tokenized patient identifier, and it becomes the one identifier shared across the hub, the pharmacies, and your systems. We design your warehouse and CRM around it, so enrollment, dispense, adherence, and persistence link into one journey without your systems ever holding a name. Funding-source transitions keep the same ID, so persistence reporting does not misread a coverage change as a lost patient
De-Identified Case Visibility in Salesforce
Journey status surfaced in your CRM against the provider and account records your field team already works: where each case sits, what is blocking it, and how long it has been there. Program status from copay and patient assistance vendors appears the same way. When your model keeps identity at the hub, that visibility carries no PII at all
FRM and Access Escalation Workflows
Payer and access escalations routed inside your CRM by reason for the stall, so a prior authorization denial reaches the field reimbursement manager who works that prescriber's office, with the de-identified case reference and the payer context they need before the visit
Process Flow and System-of-Record Design
We map the patient, prescription, product, and data journeys across the hub, specialty pharmacies, 3PL, and your own systems, then work through the source of truth for every data domain with your team: created where, mastered where, copied where. Each handoff gets a warm-handoff definition: who calls whom, what moves with the patient, and what the receiving team sees on arrival
Vendor Selection Support
We shape hub and specialty pharmacy RFPs, evaluate what each vendor's system already provides against what belongs in Salesforce, and sit in the demos with you. After the award we design the final workflows with the partners you selected, against their real file formats rather than an assumed spec
Why Launch Teams Bring Us In Early
Your Operating Model, Not Ours
Hub-led, hybrid, or direct to pharmacy: the right design depends on your program, your team, and your vendors. We map the options, walk you through the tradeoffs, and build to the model you choose rather than forcing a reference architecture onto your launch
Built for Launch Teams
We build for a first commercial launch: a handful of coordinators, one therapy, a hub selection still in flight. The system stays small enough to stand up before approval and structured enough to grow after. The same principle drives our rare disease CRM work
Identity Lives Where You Decide
Some programs keep patient identity entirely at the hub. Others keep identified cases in Service Cloud with consent capture and field-level security around them. Either way, the rule is enforced in the data model rather than a training deck, and you can show an auditor exactly why every record exists and what it is allowed to hold
Frequently Asked Questions
What are hub services?
Hub services are the coordination programs a pharmaceutical firm sets up to move a patient from a signed prescription to a first dose. A hub vendor centralizes the transactional work in between: intake of the enrollment form, capture and confirmation of patient consent, benefits verification, prior authorization support, coordination of copay and patient assistance programs, and assignment of the prescription to the specialty pharmacy that will dispense it. Most hubs also report status back to the prescriber's office.
Firms use a hub so a small internal team is not processing paperwork. A launch team of fifteen people cannot chase payer forms across fifty states. The hub absorbs that volume, and the firm's care coordinators and field reimbursement managers spend their time on the cases that stall.
Hub vendors are also called patient support programs or patient services hubs. The names differ, the function is the same.
Should our care coordinators work in our CRM or the hub's system?
Both models are common, and the right one follows your operating model. In the hub-led version, the hub vendor handles intake and case processing, so putting your coordinators into a second platform creates duplicate entry and two versions of every case status. There your Salesforce environment receives de-identified case visibility, program status, and reporting, while the hub platform stays the coordinator's daily workspace.
The CRM-led version fits when your firm employs the coordinators and the hub does narrower transactional work. Service Cloud holds the case, the hub feeds status into it, and your team owns the patient conversation directly. The tradeoff is that you are staffing and running that work yourselves, and every hub status has to arrive cleanly enough to trust.
The decision is yours, and it is worth making deliberately before a vendor contract settles it by default. We design to whichever model you choose.
How does consent gating work?
Consent is captured and stored at the hub, alongside the patient's identity. Until it is confirmed, nothing about the patient flows downstream: the hub can hold pre-consent staging information tied to the prescription, and your systems see nothing at all, or at most that an anonymous case exists.
Once consent is confirmed, the hub's reporting feed begins sending that patient's journey, de-identified and keyed to the tokenized patient identifier. Consent withdrawal runs the same path in reverse: the feed stops sending it, and the record trail shows why.
We build that rule into the feed and the warehouse itself, so nothing depends on someone remembering the policy.
What data comes back from the hub each day?
In the consolidated model, one daily reporting feed brings back the complete de-identified journey: enrollment status, consent events, benefits verification results with payer and plan detail, prior authorization submissions and outcomes including denials and appeal stage, program determinations such as copay or patient assistance eligibility, specialty pharmacy assignment, and the shipment, refill, and adherence updates the pharmacies have pushed to the hub.
That single-feed answer depends on the pharmacies reporting to the hub in near real time. Where they do not, or where a program runs without a hub, dispense data arrives on direct pharmacy feeds instead; that work is covered on our specialty pharmacy integration page.
A daily batch file is the common baseline. Many hub platforms support more frequent drops or an API for status lookups, and we design for the cadence your vendor supports today.
Can you help us choose a hub vendor?
Yes. We help write the RFP, build the evaluation criteria, and sit in the vendor demos with your team. The step firms most often skip is checking what each vendor's own platform already does. Some hubs include a case management front end your coordinators could work in directly. Others expect you to bring one. That difference changes what you build in Salesforce and what you end up paying for twice.
We also press on integration specifics during evaluation: file formats, feed frequency, consent handling, API availability, and what changes cost after signature. The award stays your decision. We give you the technical read behind it, then design the final workflows with the partner you pick.
The question we press hardest: will the pharmacies report to the hub in near real time, and will the hub give you one consolidated daily reporting feed? That answer moves the integration cost more than any other line in the RFP.
Building out patient services for a launch?
The data design decides what your team sees. Get it right early