AI systems for hospitals, and the work around the medicine

What AI systems for hospitals actually cover

AI systems for hospitals are the software and automations that run the administrative side of the place: appointment requests, patient records, handoffs between departments, billing and insurance paperwork, rotas and payroll, stock, management reporting and, where a charitable trust sits behind the hospital, donations and donor care. Clinical judgement is not on that list and never joins it.

The word system carries more weight here than the word AI. Some of this needs a model that can read an incoming message and decide what to do with it. Much of it is ordinary automation: a reminder that fires on time, a record that updates itself, a report that assembles without anyone staying late.

One thing about hospitals shapes every build. The same patient is handled by reception, a consultant, a laboratory, a ward and a billing desk, and each keeps its own version of what happened. Most of the waste sits in the gaps between them rather than inside any one department.

• The patient path: enquiry, appointment, record, result and follow up
• The money: patient billing, insurance approvals and claims, supplier payments
• The people: rotas, on call cover, leave, duty allowances, hiring and credential checks
• The building: consumables, pharmacy stock and equipment, with reorder raised before the shelf is empty
• The trust, where there is one: donations, receipts, restricted funds and funder reporting

The week you actually have

No solutions in this section. Read the list and count.

• Appointment requests arrive by phone, by message and at the desk, and only some get written down anywhere
• A patient record exists in a paper file, a spreadsheet and one consultant's memory at the same time
• A test is repeated because nobody could find the result another department already has
• Results are ready and the patient still travels in to collect a printed page
• Reception spends the first hour of the morning telling people their turn has moved
• A follow up happens only if the patient remembers to come back
• A consultant sits through a no show while somebody on the waiting list would have taken the slot
• Insurance approvals and claims are chased by hand, and rejections pile up unworked
• Nobody can tell you today's occupancy without ringing round the wards
• Consumables run out before anyone notices the level was low
• The rota and the on call cover are rebuilt in a spreadsheet every single week
• Finding one specific compliance record takes an afternoon
• Donation receipts and thank you messages are written one at a time by whoever has an hour
• The trustee pack is assembled in the week before the deadline, from numbers nobody trusts

The arithmetic, done on your own numbers

No industry average is worth quoting here, because a borrowed number tells you nothing about your hospital. Do three sums on your own figures instead. They take far longer to gather than to calculate, and the gathering is itself the finding.

• Sum one: what one consultation slot earns you, multiplied by every slot lost last month to a no show or to a cancellation nobody backfilled.
• Sum two: the hours your staff spend each week on records, rotas, billing paperwork and reports, multiplied by what an hour of their time costs you, multiplied by fifty two.
• Sum three, if a trust sits behind the hospital: your average donation, multiplied by the number of donors who gave once last year and have not heard from you since.

If you cannot produce the first number at all, that is its own answer. Slot level data is not being recorded, so the first thing to build is the recording.

What gets built, and what gets built first

A hospital does not buy a whole catalogue of systems. It buys the one that hurts and adds to it later. The first build is almost always the patient's own path, because every department downstream depends on that single line working: enquiry, appointment, record, result, follow up.

Below is what a full build eventually covers, accumulated over a year or two rather than a quarter.

• One inbox for appointment requests however they arrive, by phone, by WhatsApp, by web form or at the desk, with a reply going out in seconds instead of hours
• Routing, so a request reaches the right department or consultant without reception deciding it from memory
• Booking, confirmation, reminders and the preparation instructions a patient needs before a procedure
• Missed call recovery, so a call nobody could answer produces a message back rather than silence
• Cancellation backfill from a waiting list, the part that turns an empty slot into a filled one
• One patient record, visible to the departments you allow and nobody else, with duplicates merged
• A patient portal showing results, appointments, history and invoices, so people stop travelling in for paper
• Billing and claim tracking, with rejected claims separated out so somebody works them
• Rota, on call and leave scheduling, and the overtime calculation that follows from it
• Discharge summaries, referral letters and certificates generated from the record instead of retyped
• A daily briefing, a management dashboard, and donation reporting with restricted funds kept apart

What stays human in a hospital

Clinical judgement stays entirely with your doctors. Nothing clinical is automated, and that is not a line added to the end of a sales page. It is a design rule that changes what the system may say, which conversations it may continue, and where it must stop and fetch a person.

Every workflow is labelled before you approve it. Automated means it runs unattended and escalates when something looks unusual. Augmented means the machine prepares the work and a named person signs it off.

• Anything clinical, without exception: no triage, no diagnosis, no interpretation of a result, no medical advice, however harmless the question looks
• Anything symptomatic, which escalates to a person immediately, including at two in the morning through a booking channel
• A distressed patient or family member, where the system stops talking and hands over
• Anything published in the hospital's name or the trust's name
• Fees, waivers, discounts and anything legally binding
• A serious complaint, which should reach a named person long before it reaches a review site

How this differs by market

A hospital in Karachi, one in Dubai, one in Manchester and one in Toronto have roughly the same week and very different rules about it. These differences change the build rather than decorate it.

• Data law comes first, not last. Where patient records must stay inside your own environment, the build is designed that way from the start, and that rules out some tools before anyone opens them.
• Messaging rules differ. WhatsApp Business API messaging runs on opt in, on templates approved in advance, and on a window that closes after the patient's last reply.
• Payment differs. Where patients pay directly, the money system is billing and receipts. Where an insurer or a public payer sits in the middle, it is approvals, claims and rejection reasons.
• Channel differs. In some markets patients send voice notes and screenshots of payment rather than typed text, and mix two languages in one message. A system that reads only tidy English fails on the first real message.
• The charitable side differs most. Zakat, sadaqah, restricted funds and grant conditions each carry reporting duties, and a donation system that cannot hold a restricted fund apart from general income is not finished.

The parts of a hospital we will not build into

Three limits, stated plainly, because the passages that talk a reader out of a purchase are the ones worth printing.

There is a fourth situation, and it is the least comfortable. If nobody inside the hospital will own this, even for an hour a week, the system gets installed, admired and then abandoned. If you are hoping this reduces clinical or nursing headcount, it does not, and we will not pretend otherwise.

• Write access is not guaranteed. Some hospital and laboratory systems let an outside system read and write records. Some genuinely do not, whatever the sales page says. That is checked during the audit, and where the answer is no, a person commits the record.
• Automating a broken process makes the wrong thing happen faster and more often. Where the honest recommendation is to delete a step rather than build around it, that is the recommendation.
• Volume has to justify the build. A single consultant clinic seeing a handful of patients a day needs a shared calendar and one person who answers messages, not a records platform.

Who is answerable, what moves the cost, and where the system fetches somebody

Wobble is four co-founders rather than a vendor with an account team, and on a hospital that has a practical consequence: the person who decides what gets built is the person you can ask why. Moiz Khan owns automation architecture and sets the boundary between what a system may say and what it must stop and fetch a human for. Haad owns growth and client solutions and runs the diagnosis with your administrators. Ibrahim owns build and workflows and trains your staff on each piece as it lands. Ali owns marketing and sales. All four are named with their backgrounds on who runs Wobble, which is a fairer thing for a procurement committee to check than a capability deck.

No price appears on this page, because the same list of systems costs a forty bed hospital and a multi site trust entirely different amounts, and the things that move it are countable before anybody quotes. How many departments have to see the same patient record. Whether your existing hospital management software will permit an outside system to read or write at all. How many claims a month pass through the billing desk. Who is answerable in month four. A hospital with its own technical staff can build the reminder and the daily briefing in-house and often should, because operating a small one teaches more than reading a proposal does. What is harder to hold internally is merging duplicate patient records across departments that each believe their own version.

The stop is the entire safety argument, so it is specified before the build rather than described afterwards. A symptomatic message hands it to a person on duty at once, including at two in the morning through a booking channel, and the time that takes is measured rather than promised. A distressed patient or relative halts the automation on the first message. Fees, waivers, discounts, anything legally binding and any reply published in the hospital's or the trust's name need human approval before they exist anywhere. A serious complaint reaches a named person long before it reaches a review site, and the number of complaints an automation answered instead should be nil and should be checked each month.

Wobble works from Karachi, bills month to month and is answerable for what it operates, across 25 engagements in six countries, including Bio-Labs and Lazma in healthcare and Center for Sight in New York, where an established practice books appointments largely hands-free. What a hospital holds at the end is not a licence. The automations, the record connections, the message history and the administrative credentials live in the hospital's own accounts, so you own the system and can pass it to an internal team or a different supplier without asking anyone's permission. In a hospital that is a governance requirement rather than a preference, because a retention or deletion obligation you cannot execute across every copy is not an obligation you have actually met.

Common questions

Does any of this make clinical decisions?

No. Nothing built here triages, diagnoses, interprets a result or gives medical advice, and that work is declined when it is asked for. The systems handle admin, records, logistics and money. Anything symptomatic reaching a booking or messaging channel is escalated to a person rather than answered.

We already have hospital software. Does this replace it?

Usually not. Most hospitals have a joining problem rather than a software problem: the system holds the record, but nobody connected it to appointments, billing, the rota or the trust. What your software will allow is checked during the audit, and the build works around it.

Where does patient data sit?

In your accounts, under your logins, wherever the tools allow. Where a system has to hold something, it is documented and listed by name. Access is by role rather than a shared password, every access is logged, and if the engagement ends you keep the accounts, workflows, documentation and data.

How long before something is actually working?

The first build is deliberately small and lands early, so something visible is running before you commit to anything ambitious. The audit comes first and produces a written diagnosis and a build order. Larger hospitals take longer at the audit stage because there are more departments to sit with.

Does this work for a hospital with a charitable trust behind it?

That is one of the more common shapes. The donor side becomes its own system: receipts and certificates issued automatically, restricted funds tracked separately from general income, lapsed donors contacted, and trustee reporting assembled from the same records.

What if our systems will not connect to anything?

Then you are told before you spend money rather than after. Some systems genuinely refuse outside connections. The usual answer is a design where the automation prepares everything and a person commits the final action inside the existing software.