Automated medicine and supplies reordering

The Automated Medicine and Supplies Reordering process is triggered whenever a team member notices that a stock item has fallen below its minimum threshold. From that point, the practice must check current stock and recent consumption data, identify the right supplier, factor in any seasonal demand variation, build a purchase order, get it reviewed and approved, and send it out, typically by email or via a spreadsheet. The process runs daily and happens multiple times each day, with around 1,200 runs per year averaging 18 minutes each. At that volume, the manual approach consumes roughly 360 hours of clinical and administrative time annually.

The process sits inside a regulated healthcare environment. The practice management software holds consumption and stock data and already publishes an API, though that API has never been connected to anything. Orders are currently assembled by hand, which means accuracy depends heavily on whoever is doing the work at the time. Two or three people hold the tribal knowledge about which suppliers to use, what seasonal adjustments to apply, and how to handle the edge cases that fall outside the standard reorder logic. When those people are unavailable, delays and errors follow.

Around 85 to 90 percent of reorder events follow a clear, repeatable pattern where the right decision is essentially deterministic. The remaining 10 to 15 percent involve non-standard demand, inconsistent consumption data, or items that sit outside the standard reorder rules, and those cases require genuine human judgement. Given that medicines are involved and errors carry patient-safety implications, the process cannot simply be handed over to automation in full. Any automated solution has to preserve a meaningful human decision point for the cases that warrant it.

The recommended path is a Hybrid approach, combining an automated end-to-end workflow for routine reorders with a human-in-the-loop review gate for exceptions. The case for this rests on three converging factors: the process is high-volume and mostly rule-based, making the routine majority ideal for automation; the exception rate is meaningful enough and the stakes high enough that removing humans entirely would be irresponsible; and the practice management software already exposes an API, which means integration does not require writing code from scratch.

The practice has no in-house developer, which is an important constraint. A fully coded integration built by a contractor would work, but it would leave the team dependent on external help for every change, bug fix, or seasonal rule update. A low-code AI workflow platform, such as Make, Microsoft Power Automate, or a comparable tool, can connect to the practice system's API and orchestrate the full reorder flow without custom code. That is the most realistic build path given the team's technical capacity, and it is what the assessment's tech stack note points toward. The client has no stated platform preference, which gives room to choose the tool that best fits the API's authentication model and the team's day-to-day comfort level.

The Hybrid path scores higher than a fully automated AI Workflow precisely because of the exception gate. An AI Workflow without a human gate is technically viable, but in this context it is also the path where a misconfigured rule or dirty consumption data produces incorrect orders that nobody catches before they reach the supplier. When the products being ordered are medicines, that is not an acceptable risk profile. The human review gate is not bureaucratic overhead; it is the mechanism that keeps a clinician's judgement in the loop for the cases that genuinely need it, while still automating the 85 to 90 percent of orders that do not.

Traditional Code scores lower not because it is technically wrong but because it is the wrong fit for this organisation right now. The logic for standard cases is deterministic enough to code, and the API is there to connect to, but with no developer on staff the build cost is higher, the maintenance burden falls on contractors, and any change to reorder rules requires a development engagement rather than a configuration update. RPA scores lower still because the API makes UI-level scraping unnecessary and adds fragility without adding intelligence. An autonomous AI Agent is over-engineered here: the process does not require open-ended reasoning, the rules are clear enough to express as workflow logic, and an agent operating without structured human gates is difficult to audit in a GDPR-regulated environment where every decision touching patient data needs a traceable record.

Staying manual is not a realistic option. The current process is costing the practice around 9,000 euros per year in direct labour, generates chronic stock imbalances, and is fragile because it depends on a small number of people who hold knowledge that lives nowhere else. The Hybrid path is projected to recover roughly 75 percent of that cost, with a payback period of around ten months. The more important gain is reliability: orders go out consistently, seasonal adjustments are applied by the system rather than remembered by an individual, and the practice manager has a dashboard showing what was ordered, why, and who approved it.

The top two paths worth comparing seriously are Hybrid and AI Workflow, and the difference between them is less about technical capability than about risk tolerance. An AI Workflow could handle the routine reorders well. The practice management API is available, the standard reorder logic is deterministic, and a fully automated flow would technically function for the 85 to 90 percent of cases that follow predictable patterns. The problem is what happens in the remaining 10 to 15 percent. Errors in a medicine reordering process are not just operationally inconvenient; they carry patient-safety implications and sit under GDPR special-category data obligations. A fully automated path that sends incorrect orders without a human review gate is a compliance and safety liability, not just an IT problem. The moment you add exception routing to an AI Workflow, you have built a Hybrid anyway, so the choice is really between a Hybrid done deliberately and a Hybrid done accidentally with worse governance.

Traditional Code is worth acknowledging because the API exists and the logic for standard cases is entirely deterministic. A coded integration would work. The constraint is purely practical: the practice has no in-house developer, which means every build, bug fix, and rule update requires an external contractor. That raises the ongoing cost and introduces fragility whenever the vendor updates their API or seasonal demand patterns shift. A low-code platform like Make or Microsoft Power Automate can connect to the same API, apply the same logic, and be maintained by the practice manager without writing a line of code. Traditional Code is not wrong; it is just the harder path for this team to own long-term.

RPA and an autonomous AI Agent are both straightforwardly the wrong tools here. RPA would scrape screens that have a perfectly good API behind them, adding fragility for no benefit, and it contributes nothing to the demand forecasting the client wants. An autonomous AI Agent operating without structured human gates is inappropriate anywhere errors carry patient-safety consequences; the process does not require open-ended reasoning, and an agent would be harder to audit and explain to a regulator than a workflow with clearly defined rules. Staying Manual is the status quo problem the client is trying to solve, consuming 360 hours of staff time per year and depending on tribal knowledge held by a small number of people.

The first thing to do before any automation is built is a data audit. Consumption data in the practice management system needs to be assessed for completeness and consistency, because if the underlying data is dirty the automated reorder quantities will be wrong, and wrong quantities in a clinical setting are a worse outcome than slow manual ones. During the same two-to-three week phase, a working connection to the practice software API should be established using a no-code platform, with Make and Microsoft Power Automate being the most realistic candidates given the team has no in-house developer. Make offers flexible HTTP-based API connectors that can call the practice system's endpoints directly, while Power Automate benefits from tight Microsoft 365 integration if the practice already uses Outlook and SharePoint for email and file storage. Either platform can be configured and maintained by a non-technical practice manager once the initial setup is done. This phase also surfaces any supplier-side requirements, such as EDI formats or supplier portal APIs, so they do not become a surprise later.

Once the data is clean enough to trust and the API connection is proven, the core automated workflow can be built. The flow starts with a scheduled trigger, run multiple times per day, that calls the practice management API to retrieve current stock levels for all tracked items. Where a stock level falls below the defined minimum threshold, the workflow calculates the reorder quantity, applying seasonal adjustment factors that are stored as a simple lookup table in the platform, and then generates a structured purchase order. For items with clean data and a clearly matched supplier, the order is formatted and dispatched automatically, either via a supplier API if one is available or via a structured email template, and a confirmation record is written back to the practice system. This end-to-end automated path should be run in parallel with the existing manual process for two to four weeks before the manual process is retired, so the team can validate order accuracy against what they would have done themselves.

The exception routing logic is what separates a well-governed Hybrid from an unsupervised AI Workflow, and it deserves careful design. Any order that fails a data quality check, involves an item not covered by standard reorder rules, matches a non-standard demand pattern, or exceeds a configurable order value threshold is routed to an exception queue rather than dispatched automatically. The practice manager receives a notification, through either Microsoft Teams or email depending on what the team uses daily, with all relevant context pre-populated: current stock level, recent consumption trend, suggested order quantity, and the specific reason the order was flagged. A single-click approval sends the order; an edit option lets the manager adjust quantity or switch supplier before dispatch. Every action, whether automated or human-approved, is logged with a timestamp and user identity in a structured audit log, which is a hard requirement for GDPR records retention and regulated records obligations.

The final phase focuses on calibration and handover rather than new build work. After the first full seasonal cycle of automated orders, actual consumption is compared against the quantities the system ordered to identify where the demand adjustment factors need tuning. This is also when the reorder rules and exception criteria should be formally documented, moving institutional knowledge out of the heads of two or three people and into a reference document the whole team can use. The practice manager takes over ongoing monitoring through a simple dashboard, built in the same low-code platform, showing daily order volumes, exception rates, and any supplier errors or failed dispatches. At this point the process is genuinely owned by the practice rather than dependent on whoever originally built it.