AI in Healthcare: Data Audit and Stock Forecasting

The model does not predict who will fall ill. It predicts where demand may rise.

That distinction defines the entire project. Clinical prediction identifies people more likely to develop a condition. Operational forecasting looks at aggregate trends and asks one question: which products and consumables are we likely to need over the next few weeks?

A healthcare organisation held the relevant information in its accounting software and its invoicing system. The data existed — separate, and used mostly for administrative record-keeping. BigLearn turned those files into an integrated view relating purchases, sales, stock movements, materials consumption, times of year, historical demand patterns, the calendar and weather conditions.

Buying after demand arrives is already buying late

In clinics and pharmacies demand is not flat. Some products have fairly predictable use; others rise in particular seasons, with temperature changes, wet spells or heatwaves.

Without an integrated view, purchasing decisions lean on individual experience, manual file comparison, the stock visible today, memory of last year — or a reaction to a stockout that has already happened. The problem was not a shortage of data. It was the difficulty of connecting it in time to decide.

Forecasting on incoherent data just produces better-presented errors

So the project started with an audit, not a model. Differences between purchases, invoicing, consumption and stock were examined for products named differently across systems, movements that were hard to reconcile, consumption with no clear match in purchasing, items bought regularly but turning over slowly, sudden changes needing validation, and periods with incomplete information.

None of these was automatically treated as an error. They were presented as points for the responsible team to review. The AI helps find the needle; what it means stays a human decision. The most important early work was not choosing technology — it was making the data comparable. No system had to be replaced: accounting exported a purchases CSV, invoicing exported a sales CSV, and the history was rebuilt from there.

The seasonality was in the data, it just was not visible

Arranged chronologically, the data showed patterns: categories peaking in particular seasons, others tracking the number and type of procedures performed, some with short spikes and others climbing gradually over weeks.

It became possible to compare months and seasons, days of the week, holiday periods, different years, and the length and intensity of peaks — and to compare forecast demand with the demand that actually happened, which is the only way to know whether a forecast is any good. Rather than assuming next year repeats last year, the system looks for recurring patterns and also weighs what happened recently.

Weather is a demand signal, not a clinical explanation

Internal history explains what happened; external data helps sense what is coming. Temperature, sharp swings, rainfall, humidity and heat or cold waves entered as one more signal for the demand model — never as a cause-and-effect relationship with illness.

Where history shows that certain categories usually rise after particular weather patterns, the system flags a possible increase in the following weeks. The output is not a purchase order. It is an early warning for whoever manages stock. One more signal the financial view alone could not show: some materials are not sold, they are consumed during procedures. Considering aggregate procedure volumes explained why certain items left stock without appearing as a sale — by period, unit and category, never by practitioner.

An alert without context helps nobody decide

The system flags stockout risk ahead of a high-demand period, excess stock with slow turnover, abnormal consumption increases, purchases that do not follow the recent trend, approaching seasonality, products with too little history for a safe forecast, and gaps between recorded movements and expected stock.

But «there is an anomaly» is not useful information. Every alert shows the product or category, the period analysed, the usual behaviour, what changed, the data behind the warning and the confidence available — because an unusual combination can be a recording error, a process change, an exceptional situation or a perfectly justified decision.

You do not need to know who the patient is to forecast the stock

Data minimisation here is not compliance bolted on at the end — it follows from the objective. Forecasting demand needs product, category, quantity, date, unit, aggregate activity type, purchase, sale or consumption, stock and seasonal factors. The identity of patients or customers adds nothing to the forecast.

Wherever possible the data is aggregated and reduced to the minimum the objective requires, which lowers both risk and exposure at no cost at all to the quality of the result.

What changes compared with a dashboard

A business intelligence tool shows what happened. Here both perspectives were joined: history → what happened · audit → is the data coherent? · analysis → what patterns exist · forecast → what might happen · alert → what needs attention now · human decision → what we will do.

The AI did not replace the existing reports; it added anticipation. And the value was not in creating more information — it was in making better use of what the organisation already produced every day.

The same architecture serves pharmacies and other clinics

A pharmacy already holds supplier purchases, sales, stock, turnover, categories, dates, returns, stockouts and promotional periods. Combining that with seasonality and external signals makes it possible to anticipate demand by category — preparing for winter, cutting slow-moving excess, comparing branches or regions, matching orders to lead times, tracking products nearing the end of their sale window — without analysing any individual's health.

In medical, dental or veterinary clinics the same logic supports consumables planning, seasonal preparation, per-unit forecasting and comparing expected against recorded stock. And there is no need to start with a complex integration: a first project can use periodic exports and aggregate data, proving the value before anything is connected. The question stops being «how much do we have today?» and becomes «how much are we likely to need, when, and why?»