OptimizeRx cut its daily data refresh 85% and halved drug price forecast error

The workflow before#

OptimizeRx works with pharmaceutical manufacturers, and those clients wanted price forecasts across therapeutic categories they could plan around. The methods in place missed by 25 to 30%, which is too wide to set strategy on. The data behind them refreshed in a nightly batch that took 6 to 8 hours, so the insights client teams saw were 24 to 48 hours old. Bringing on a new client meant 4 to 6 weeks of integration work before their data was usable, and getting a new model version live took 2 to 3 weeks. The data team spent much of its time keeping the pipeline running instead of improving the forecasts.

What we built#

We built OptimizeRx a price forecasting service and a faster data pipeline under it. The service runs several forecasting methods side by side, tests each against history and uses whichever does best for each drug and category. The pipeline gets fresh data to it in under an hour. Client teams get forecasts they can plan with, with a range around each one.

Forecasts that pick their own method

Prophet, Amazon Forecast and custom gradient-boosted models all run against the same history, and a backtesting step picks or blends the best one for each series. We chose competition over a single favorite model because drug prices behave differently by category; what works for a generic rarely works for a specialty biologic.

A range around every number

Each forecast covers 30, 60, 90 and 180 days and comes with a confidence range. Client teams can see when a forecast is firm and when it isn't, which is what they need to decide how hard to lean on it.

A refresh measured in minutes

We rebuilt the pipeline on Azure with raw, cleaned and business-ready layers, so each refresh processes what changed instead of reloading everything. The daily refresh dropped from 6 to 8 hours to 45 to 60 minutes, and new client data now fits a standard pattern that takes 1 to 2 weeks to onboard.

New models live in days

Every model is tracked from experiment to production, and retraining kicks in when accuracy drifts. A data scientist can promote a better version in 2 to 3 days instead of waiting weeks for a release.

How we delivered it

We moved the pipeline first, since every other improvement depended on fresh data, then ran the forecasting service in parallel with the old methods until its error was consistently lower. The data team took over the model registry and retraining workflow as part of the handover.

Before and after#

What's next#

Forecasts and clean data in one place set up the next step: putting forecasts and their drivers in front of client teams through an assistant that answers pricing questions directly, such as why a category's forecast moved this week and how confident the model is.