Pharmacy Demand Forecasting Service with Drift Monitoring and Automated Retraining

The problem

Small pharmacy chains, with a handful of branches and a few thousand products, reorder mostly by habit and by what ran out last week. The cost shows up in both directions: stockouts of fast-moving and essential medicines send patients to a competitor, while overstock of slow items ties up cash and, for medicines, ends in expired stock that must be written off. Demand also shifts with seasons, outbreaks such as dengue season, Ramadan and price changes, so a model trained once goes stale quickly.

This project builds a demand forecasting service for such a chain and, more importantly, runs it properly: every forecast traceable to its data and model, every retrain gated against the live model, drift detected and rollback rehearsed.

What exists and the gap

Pharmacy management and point-of-sale systems record sales and stock well but rarely forecast. Cloud forecasting services exist, but they target larger companies with data teams: AWS, for example, closed its Amazon Forecast service to new customers in July 2024 and points customers to SageMaker Canvas instead. Open source libraries such as Nixtla's StatsForecast make good models easy to train. What small businesses lack is not a model but the operational loop around it, and that loop is exactly what employers hiring ML engineers want to see.

Inspiration

• The NeurIPS paper Hidden Technical Debt in Machine Learning Systems (Sculley and colleagues at Google, 2015) argues that the model is a small part of a real ML system. This project builds the rest.
• The M5 forecasting competition on Kaggle, based on Walmart sales, is a public dataset you can use to develop and backtest before, or instead of, a partner pharmacy's data.

Scope for a final year project

Use a public retail dataset such as M5, or anonymised sales from a local pharmacy if one agrees (remove anything identifying patients). Forecast weekly demand per item and branch, four weeks ahead. Keep the model modest: seasonal baselines and one gradient-boosted model are enough. Spend the effort on the loop:

1. Package the code, lock dependencies and containerise training and serving.
2. Version data with DVC and validate it on arrival.
3. Track every run and register models in MLflow, using a champion alias.
4. Orchestrate a weekly pipeline in Prefect that retrains and promotes only through a quality gate on a fixed backtest window.
5. Serve batch forecasts and a small API, log predictions and join them with actual sales.
6. Monitor drift with Evidently and service health with Prometheus and Grafana, and write a runbook.

What to measure

Forecast error (for example weighted absolute percentage error) against the baselines, error by product group, simulated stockouts and overstock in a backtest, pipeline success rate, time to roll back, and monthly running cost.

Path to a product

A working loop can become a subscription add-on for pharmacy or grocery point-of-sale vendors, who already hold the sales data. Start with one chain as a design partner, show fewer stockouts and less expired stock over a season, then package the pipeline so each new customer is a configuration, not a new project. Distributors that supply many small shops are a second market.

Discuss it and get help

Want to shape this idea for your team? Discuss it at /account/fyp-ideas/demand-forecasting-service-with-drift-monitoring-and-automated-retraining/, ask a question at /account/ask/, or book time with Tauseef at /account/book/. New to Sefism? Create a free account.

Learn what you need on Sefism

• MLOps and LLMOps roadmap: every stage of this project, in order
• MLOps cheat sheet and MLflow cheat sheet
• MLOps Zoomcamp for tracking, orchestration, deployment and monitoring with homework
• DVC documentation, MLflow documentation and Prefect documentation
• Evidently documentation for drift reports and tests
• Designing Machine Learning Systems for distribution shift and continual learning