Specialty Pharmacy Data Aggregator: How to Choose One, and When You Do Not Need One

What a specialty pharmacy data aggregator does, in short

A specialty pharmacy data aggregator collects the status, dispense and inventory files that each specialty pharmacy, hub and distributor in your network sends, standardises them into one format, checks their quality and delivers a single feed or reporting platform to the manufacturer. Choose one on five things: how many of your pharmacies and data types it already connects to, how it handles late and restated files, how it links patients across sources without identities, what you can do with the data once delivered, and what happens to your history if you leave.

Most manufacturers with a limited distribution network end up using an aggregator, an in-house pipeline, or a mix of both. The right answer depends on how many pharmacies you have, how fast your network will change, and whether your team wants a vendor platform or the raw data in its own warehouse. This guide covers what aggregators should handle, how to compare them, a scorecard you can paste into an RFP, a worked example of what bad aggregation does to time to therapy reporting, the contract terms that matter, and the cases where you do not need an aggregator at all.

It is written for patient services, trade and channel, market access and commercial analytics leads at emerging and mid-sized pharma and biotech companies, particularly those preparing a specialty launch or renewing an aggregation contract.

Why specialty pharmacy data aggregation exists

Specialty products rarely move through the retail channel that prescription audits see well. They go through a small network of specialty pharmacies, often supported by a hub that handles enrolment, benefits investigation and copay programmes. Each pharmacy reports to the manufacturer under its own contract, in its own layout, with its own status codes and on its own schedule. With three pharmacies that is manageable in a spreadsheet. With eight pharmacies, a hub, a copay vendor, a specialty distributor and a third-party logistics provider, it is not.

The stakes have grown with the channel. Datavant, citing industry figures in its guide to linking specialty pharmacy data, puts specialty drugs at 50 percent of total US drug spending in 2021, up from 24 percent in 2007. For a single brand the money is concentrated in few patients: IQVIA's John Giannouris wrote in a June 2021 IQVIA blog that "a single adherent patient can equate to multimillion-dollar revenue" for specialty therapies. When each patient matters that much, a referral that sits unnoticed for a week is a commercial problem, not a reporting nuisance.

An aggregator exists to make that network readable. In a 2018 Pharmacy Times interview, Giannouris (then at ValueCentric) described aggregators as working on behalf of manufacturers while serving pharmacies too, and gave the example of shared visibility that lets a pharmacy ask "why is this patient hung up for 8 and a half days" before the manufacturer has to chase it.

Which data sources and file types should an aggregator cover?

IQVIA's 2021 article on specialty product data lists seven groups of sources a specialty brand can draw on. Use it as a coverage checklist when you compare aggregators. The table adds the file types you will hear about, using the definitions in Veeva's Nitro documentation for the EDI transactions.

The connectors in Veeva Nitro show how unevenly vendors cover these. Its documentation lists three aggregator connectors for 3PL data: IntegriChain (852 and 867), ProMetrics (852) and ValueCentric (844, 849, 852 and 867). That is not a ranking of the vendors, only proof that "we aggregate channel data" can mean different things. Ask every bidder for the exact list of sources and transactions they already receive for brands like yours.

Status and dispense data is where most of the value and most of the mess sits. If your team has not yet agreed one status vocabulary, read our guide to specialty pharmacy status codes and a patient status model before the RFP, because the aggregator will map to whatever model you give it.

Aggregator, in-house pipeline or hybrid?

Full aggregator

The vendor signs onto your pharmacy data agreements as your agent, receives every file, maps it to a standard model, runs quality checks, and delivers dashboards plus an extract. Best when you are launching, have no data engineering team, and want pharmacy onboarding, file chasing and data quality follow-up handled by people who already know each pharmacy.

In-house

Pharmacies and the hub send files directly to you, and your team or a partner builds ingestion, validation and reporting in Snowflake, Databricks, Azure or BigQuery. Best when you have few pharmacies, a stable network, existing data engineering capacity, and a need to join SP data tightly with CRM, claims and finance data.

Hybrid

The aggregator handles pharmacy onboarding, file collection, standard layouts and first-line quality, then delivers clean, patient-level, tokenised data into your warehouse. Your own models compute time to therapy, abandonment and persistence on your definitions and join SP data to everything else. It suits teams that have outgrown the aggregator's standard dashboards but do not want to chase pharmacies themselves.

The RFP scorecard: nine questions to ask every aggregator

• 1. Coverage of your network

  Which of your named specialty pharmacies, hub, copay vendor, distributors and 3PL do they already receive data from today, for which data types, and for how many brands?

  • Name your network in the RFP
  • Ask for live connections, not plans

• 2. Timeliness

  How many days pass between a status change at the pharmacy and the record appearing in your feed? What is the delivery cadence, and how are weekends and holidays handled?

  • Ask for measured lag on a recent month
  • Daily vs weekly delivery

• 3. Late, missing and restated files

  How do they detect a file that did not arrive, a volume drop, a format change or a resent file? Are restatements flagged so history can be rebuilt without double counting?

  • Ask to see the exception report
  • Written restatement rules

• 4. Standardisation

  What is their standard status and dispense model, and can it map to yours? Who decides how a new or ambiguous pharmacy code is mapped, and is that mapping visible to you?

  • Mapping table delivered to you
  • Change log for code mappings

• 5. Patient linking and privacy

  How are patients linked across pharmacy transfers, hub and claims without identities? Which tokenisation provider is used, and will the same tokens work with data you license elsewhere?

  • Token compatibility with your claims data
  • Expert determination for de-identification

• 6. Raw data delivery

  Will you receive record-level, tokenised data in your own warehouse, not only dashboards? At what frequency, in what schema, and including full history and restatements?

  • Snowflake share, S3 or SFTP
  • Documented schema and dictionary

• 7. Pharmacy management support

  Do they help draft data agreement exhibits, follow up with pharmacies on quality, and benchmark pharmacy performance on data quality and time to fill?

  • Who chases the pharmacy
  • Benchmarks you may share internally

• 8. Exit and ownership terms

  If you leave, or the vendor is acquired, what history do you receive, in what format, and how fast? Can the pharmacies redirect files to a new agent without re-papering every contract?

  • History export at no extra charge
  • Change-of-control clause

• 9. How price scales

  Vendors do not publish list prices. Ask how fees change as you add pharmacies, products, data types or users, and what is included versus charged as custom work.

  • Price a second launch now
  • Separate set-up and run fees

How to choose a specialty pharmacy data aggregator, step by step

A worked example: what one late file does to your numbers

The figures here are illustrative, chosen to show the pattern rather than taken from any client. Picture a specialty brand with five specialty pharmacies in a limited network. In a normal week the network reports 120 new referrals: 30 from Pharmacy C and 90 from the other four.

• The late file. Pharmacy C's weekly file arrives four days late. Without a missing-file check, Monday's report shows 90 referrals, a 25 percent drop. Field and access teams start asking which payer changed its policy. Nothing changed; one file was late.
• The resent file. Pharmacy C then resends the previous week's file with corrections, including the same 30 referrals. If the pipeline appends rather than replaces, the next report shows 150 referrals for that week, a 25 percent jump in the other direction.
• The transfer. Six of Pharmacy C's patients are transferred to Pharmacy A because of a payer network restriction. Without patient linking across pharmacies, those six appear as abandoned at C and as new referrals at A, so abandonment is overstated and time to therapy restarts the clock for six patients who were already waiting.

A good aggregator, or a good in-house pipeline, catches all three: it flags the missing file before reporting runs, treats the resent file as a restatement that replaces earlier records, and stitches the transfer into one patient journey using de-identified tokens. The difference shows up most in exactly the metrics leadership watches. We explain why the transfer case matters so much in prescription abandonment vs reversal, and how tokens make the link possible in patient tokenization for specialty pharma.

When you test finalists, give them this scenario. Ask each to show, on their platform, what happens to the weekly referral count and to time to therapy when a file is late, resent and when a patient moves between pharmacies.

Contract and data agreement terms that matter

Aggregators often help write the data exhibits in your specialty pharmacy agreements. In his April 2018 Pharmacy Times interview on launches, Giannouris described this as part of the job: helping manufacturers decide "what are the right data elements to ask for" and what language to include in data agreements. That help is useful, but the agreements are yours. Make sure they cover:

• Data elements and layout: the status, dispense and inventory fields each pharmacy must send, with your status model attached, not left to each pharmacy's defaults.
• Timeliness and completeness: how quickly after an event the record must be sent, and what counts as a complete file.
• Recipient and agent: who receives the data, so the pharmacy can send it to your aggregator now and to a new agent or your own warehouse later without renegotiating.
• De-identification and linking: which tokenisation provider is used and that tokens are generated consistently across pharmacies and the hub.
• Quality remedies: what happens when files are repeatedly late or wrong, tied to any data or service fees you pay the pharmacy.

On the aggregator contract itself, three clauses are worth insisting on before price: raw data delivery to your own environment, full history in a documented format on exit, and visibility of every code mapping the vendor applies. If the aggregator also provides channel or gross-to-net inputs, align its definitions with finance first, as described in our gross to net guide for specialty pharma.

Common mistakes when buying specialty data aggregation

• Buying dashboards instead of data

  Standard dashboards are useful at launch, but if you cannot get record-level data into your own warehouse you cannot join it with CRM, claims or finance, and every custom question becomes a change request.

• Letting the vendor define your KPIs

  If time to therapy is defined in the vendor's platform, it changes when the vendor changes it. Keep KPI logic where you can read and version it.

• Scoring on a headline connector count

  A large number of connections means little if your own pharmacies and hub are not live. Score only on the sources in your network.

• Ignoring restatements

  Pharmacies correct and resend files. Without explicit restatement handling, history drifts and nobody can reproduce last quarter's numbers.

• Signing late in launch planning

  Pharmacy data agreements are negotiated alongside the network. Bring the aggregator decision forward so the data exhibits are right from the first contract.

• No exit plan

  Switching aggregators is mainly a data-history and pharmacy re-routing problem. Agree both before you sign, while you still have leverage.

When you do not need a specialty pharmacy data aggregator

An aggregator is not always the right buy. You may not need one if:

• Your network is one or two pharmacies with a stable hub, and the pharmacies can send files in a layout you specify. A direct pipeline into your warehouse with automated validation is often simpler.
• You already run a commercial data warehouse with data engineering support, and the main value you want is joining SP data to CRM, claims and finance, not someone else's dashboards. See our guide to the pharma commercial data warehouse.
• Your product is sold mostly through retail or open distribution, where licensed prescription data and distributor 867 data cover most of what you need.

You almost certainly do need one, or at least the hybrid model, if you are launching into a limited network of several pharmacies, have no in-house data engineering, or expect your network to change often. For launch-specific reporting needs, our pharma launch analytics guide sets out what to have ready before first shipment.

How Greenwolf helps with specialty pharmacy data

We are not an aggregator and we do not resell one, so we have no stake in which vendor you choose. Our founder came up through pharma commercial operations consulting at ZS, and our specialty pharmacy data analytics work sits on either side of the aggregator decision.

Before you buy, we help write the definitions, network inventory and scorecard, and test finalists against your real files. After you buy, or if you decide to build in-house, we take the aggregated feed and any direct pharmacy and hub files into your own warehouse, validate every load, link patients through the tokens you already receive, and build time to therapy, abandonment and persistence reporting on definitions your teams agree. For a specialty therapy provider whose identifiers did not line up across sources, clean identifiers and automated pipelines cut manual reporting work by 60 to 80 percent.

We sign an NDA before any data is shared, build inside your environment, work on de-identified data wherever possible, and handle protected health information only under your Business Associate Agreement. This is part of our wider specialty pharmacy analytics practice, and the KPIs we usually build first are listed in patient access KPIs.

Questions about specialty pharmacy data aggregators