Automating hospital processes: where the model computes, and when your own hardware pays for itself

When you automate hospital processes, one technical detail matters more than anything the language model can do: the place where it computes. There are three of them. They differ in cost far more sharply than most boards expect, because one of them only bills when somebody uses it and the other two bill whether anybody does or not. Which one fits a given workflow follows from volume and from the kind of data involved. The arithmetic is further down. First, the workflows themselves.

The hospital processes we automate for clients

Projects we have been allowed to deliver for clients, and are delivering right now:

• Occupancy and bed management
• Reporting for ward managers
• Scheduling of staff appraisal meetings
• Automated ordering of medication
• Automated ordering of implants and endoprostheses
• Early detection of unusual pharmacy movements
• Dictated nursing reports, including documentation of the measures taken

Sorted by the data they touch, these sit very far apart. An implant order needs no patient name at all. A dictated nursing report is almost nothing but patient data. That difference decides where the model should compute.

Ordering endoprostheses, walked through

The example below is constructed. We have no released client references yet, so what follows is a worked example rather than a case study. It shows how we set such a workflow up.

Picture a hospital that runs joint replacement surgery four days a week. Some of the material sits in the supplier's consignment stock inside the building, the rest is ordered for the individual procedure. Today someone in theatre coordination reads through the coming days of the surgical schedule, compares it against what is actually on the shelf, and emails two suppliers.

1. The surgical schedule triggers everything

The agent reads the schedule and maps each procedure to the material group planned for it. A revision case has different requirements than a primary implantation. Anything the agent cannot map with confidence goes onto a list for theatre coordination rather than being guessed.

2. Comparing against what is in the building

Consignment stock is recorded in the materials management system, but it is only as current as the last consumption posting. The agent pulls the stock figure, nets off the procedures documented since then, and flags positions where stock and consumption have drifted apart. That gap usually surfaces on the morning of surgery, when a size is missing. Which size a patient receives is not the agent's call and is often settled during the procedure anyway; its job is to make sure the range agreed with the surgeon is complete and in the building on the day.

3. Draft order, then release

The gap becomes a purchase order in the materials system, created as a draft. Supplier, article numbers, quantity and a delivery date ahead of the surgery are filled in, and every line carries a note on where the value came from: the surgical schedule, the stock figure, or a local rule. Purchasing or theatre coordination reviews the drafts in one list and releases them. Only then does the order reach the supplier, because an order is a commitment, and commitments are made by people.

4. Chasing, and closing the loop

If the dispatch note or the goods receipt has not arrived by the agreed date, the agent says so. It keeps one morning list showing what is still outstanding for which procedure and how much time is left, instead of emailing everyone involved. After surgery, theatre records which implant was used and under which batch number. The agent picks up that posting and writes the consumption against stock. Skip this step and the stock figure is wrong again after a handful of procedures, which is exactly why so much of this is counted by hand today.

Three places the model can compute

A provider's API

The model runs at the provider. The agent sends text and gets an answer back, billed per call. No hardware, no base fee, and a day with no traffic costs nothing. Which providers qualify comes down to European infrastructure and a data processing agreement, and that part is our job during selection.

The implant order above is a good fit. What the agent handles is schedule lines, article numbers and stock figures. It needs no patient name, and where one does appear in the schedule, it is replaced before anything is sent.

A rented server in a European data centre

You rent dedicated hardware with its own GPU. Your model runs on it and nothing else does. The price is a monthly rent, flat regardless of throughput. Against the API you gain control: you know where the machine stands and who can reach it, and the model changes only when you change it. Against owning hardware, you save the purchase and the babysitting of the box.

Reporting for ward managers together with bed management fits here. Case numbers, lengths of stay and occupancy flow through both, sometimes tied to individual patients, but without free text out of the record.

Your own hardware in the building

The server sits in the hospital's own data centre, behind your firewall. Nothing leaves the network, and for some data that is the only answer your data protection officer will accept. You pay the purchase once, then power, rack space and your IT team's time.

The dictated nursing report belongs here. A nurse speaks what she did and observed at the end of her round, the entry appears in the structure the hospital already uses, and the measures performed land in the documentation. The nurse reads it and releases it. A recording like that carries names, diagnoses, observations and often a third person in the background. Your own machine is the simplest answer to that.

What the three cost, worked through

The numbers below are assumptions for a worked example, not a price list. Your own volumes will produce a different result, and those are the ones we put into the automation check.

Say the dictated nursing report runs on twelve wards. Across three shifts that produces roughly 400 dictations a day, 300 spoken words on average, each turning into one structured entry.

Through an API you pay per dictation. Assume two cents for transcription and report together: 400 dictations come to eight euros a day, about 2,900 euros a year. Double the volume and you double the bill.

The rented server costs the same whatever the volume. Assume 900 euros of monthly rent for a machine that serves this model fast enough, so 10,800 euros a year. At 400 dictations a day you are paying roughly three and a half times the API. At 4,000 you are paying exactly the same as before.

Your own hardware costs a lot up front. Assume 25,000 euros for server and GPU, written down over three years, plus power, rack space and support. Call it about 12,000 euros a year for as long as the machine runs.

In this example the crossover sits at roughly 1,500 calls a day for the rented server and roughly 1,650 for the owned machine. Below that the API wins on price. Above it, the fixed machine does.

A single workflow rarely reaches those numbers. Several workflows on the same machine reach them quickly, because dictations, reporting, ordering and pharmacy monitoring together are a different volume than one process on its own. So we run this calculation for the whole hospital instead of one process at a time.

Then there is the case where the arithmetic does not decide anything. If the hospital has settled that voice recordings from the bedside stay inside the network, the machine goes into your own data centre even when the API would be cheaper. That is a legitimate decision. It should just be taken with the number next to it, so everyone knows what the peace of mind costs.

How fast it is up and running

An agent for a workflow like this is built in one to two days, and it is tested against real cases the same week. Anything larger is cut into sections, and each section runs on a scale of days. The choice of location changes little: against an API the agent is ready immediately, while rented or owned hardware adds the setup of the model itself.

What does need lead time is on your side: access to the systems, sign-off on an interface, the data protection impact assessment, bringing in the works council. None of that is build time. It is preparation, and we go through it with you before anyone builds anything.

Sophera Consulting builds these agents individually for each hospital, at a fixed price and with no subscription, and works out beforehand which of the three routes is cheapest at your volumes. Every automation comes with a maintenance agent that watches operations and checks the input and output of each interface for changes; it is included in the fixed price. The only running cost is the model usage itself. Which workflow to start with, and where its model should compute, is what the free automation check is for.

Where to start

Pick the workflow with the clearest trigger and the least sensitive data. The implant order has both. Occupancy planning has neither. Run that first agent against an API, so you start without buying anything and see real figures quickly. Then count two things: how many drafts get released unchanged, and how many calls a day actually accumulate. The first number tells you whether the agent is any good. The second tells you whether your own machine would pay for itself, and it tells you before you buy one.