Automating patient administration without data leaving the hospital

Ask a hospital director where automation would free up time fastest, and the patient administration office is a likely answer. Ask where they hesitate longest, and you often get the same answer. Every request that lands there carries a name, a date of birth and a hospital stay. So anyone who wants to automate patient administration has to settle one question before anything else: where does the model run? For this workflow our answer is a server in your own data centre. No request leaves the building, and everything after that is craft.

The example below is constructed. We have no client references cleared for publication yet, so this describes how we would build such an agent, not a client case.

Automating patient administration, starting with one shared inbox

Picture a general hospital whose patient administration team works from a shared inbox. Emails arrive there, so do submissions from the website's contact form, and so do faxes, which the fax machine forwards as PDFs. Three staff members work through the inbox alongside admissions and billing. On a Monday morning it holds, among other things:

• a patient who needs confirmation of her August stay for her employer,
• a GP practice that never received the discharge letter for a shared patient,
• a health insurer requesting documents on a case, with a deadline,
• a son asking when his father will be discharged,
• a self-paying patient with a question about the bill for a private room,
• two out-of-office replies and a newsletter.

Each of these takes the same moves today. Read it, look up the case in the hospital information system, check whether the sender is entitled to the information, gather documents, reply. Only the third move involves a real decision. An agent can prepare everything else.

Six steps from request to reply

1. Sorting

The agent reads each message and assigns it a type: confirmation of stay, request for a report or letter, insurer request, family enquiry, billing question, other. Out-of-office replies and newsletters go into a separate folder. Nothing gets deleted. On the insurer's fax it also reads the deadline from the letter and attaches it to the case as a date. The list the team opens in the morning is sorted by those deadlines, not by arrival time.

2. Finding the case

Using name, date of birth and period, the agent searches the hospital information system. For the patient who needs the confirmation, exactly one stay matches. The GP practice only gives a name and "discharged last week", and the hospital has two patients with that name. The agent picks neither. It flags the request and notes what is missing: the date of birth. Mixing up two patients would be the most expensive mistake in the whole workflow, so one rule has no exceptions here. A request is matched to a case only when the match is unambiguous.

3. Checking who is asking

This is where the decision sits, and it stays with the staff member. The agent prepares it by looking at what the system already knows. Is the practice recorded on the case as the referring or follow-up practice? Is the insurer that is asking the payer for this case? Is there a power of attorney or a confidentiality waiver on file for the son? The answer goes onto the request as a short line, such as "insurer matches payer" or "no authorisation on file".

For the son there is none. So the agent drafts a polite reply that says nothing about the stay and explains what the hospital needs from his father before it can share anything.

4. Gathering documents

For the confirmation of stay, the agent fills in the hospital's template with admission and discharge dates from the case. For the practice, it pulls the discharge letter from the archive once the case is clear. For the insurer, it collects the requested documents and adds a short list of what exists and what doesn't. It does not fill a gap with something that looks similar. It records the gap.

5. The reply as a draft

Every reply sits on the request as a draft, attachments included, with a note on each detail saying where it came from: the case, the template or the archive. Medical reports go out only through the communication channel the hospital has approved for medical documents, and never to patients as an unprotected email attachment. We agree that channel with you before building, and the agent sticks to it.

6. Sign-off

The staff member sees two lists. The first holds requests where case, sender and documents are all certain, like the confirmation of stay. One look and it's approved. The second holds the flagged ones, here the practice without a date of birth and the son without authorisation. Nothing is sent until someone signs off. The self-payer's billing question the agent doesn't answer itself. It passes it to billing together with the case and the invoice.

Where the model runs

For this workflow the language model runs on a server in your data centre, behind your firewall. Inbox, hospital information system, archive and model all sit on the same network, and no request or report leaves the hospital. Other hospital workflows need far less, an implant order for instance, which contains no patient name at all. Which workflows those are, and what each place to run a model costs, we cover in our articles on running agents in a hospital under GDPR and on the cost of each option. We bring the data processing agreement with us.

What gets settled first, and how fast the agent is running

Before we build, we go through the request types with your patient administration team and write down the house rules: who gets which information, which templates apply, which channel is used for which documents. Add read access to the information system and archive, involvement of the staff council, and the data protection impact assessment, for which we supply the workflow description. We sort all of that out together in the Automation Check beforehand. It is groundwork, not build time.

The agent itself takes one to two days to set up, and testing with real requests happens the same week. On your own hardware, setting up the model comes on top.

Every automation we deliver comes with a maintenance agent. It monitors operation and checks the input and output of every interface for changes. If an update makes the hospital information system return dates in a different format, it reports that before a wrong confirmation goes out. It is included in the fixed price.

Sophera Consulting builds this agent for each hospital individually, at a fixed price with no subscription, and the result belongs to you. Which requests your patient administration should start with is what we work out in the free Automation Check.

Our recommendation

Start with confirmations of stay and requests for letters. The case is usually unambiguous, the template already exists, and the sender can be checked against the system. Add insurer requests next, since the deadline list alone saves a lot of searching and chasing. During the test, count how many drafts are approved unchanged and how often a case couldn't be matched. The second number tells you which requests arrive with too little information, and a better contact form often brings it down faster than any agent will.