What a case engine is (and isn't)
A case engine takes routine work from arrival to done, using your rules. Cases that need judgement reach the right person with the evidence ready.
Mitch Flindell · 25 September 2026 · 5 min read · Journal
A referral lands in the inbox. Someone reads it, finds the matching form, checks what is missing and works out who needs to act. The same thing happens with the next referral. Capable people spend time moving routine work along, case after case.
A case engine takes responsibility for that whole piece of work. It reads each case as it arrives, checks it against your rules, finishes what is routine and brings the exceptions to the right qualified person. Every step is logged. The unit of work is a finished case.
Start with the case, not the inbox
A case might be a referral, claim, booking or bill. It can arrive by fax, email, portal or form. The channel tells us where to collect it. Your business tells us what it means, what needs checking and what counts as done.
Today
- ✕Someone matches the faxed referral to the admission form.
- ✕They check fund cover, consent and medication details by hand.
- ✕They gather the records for the nurse when the warfarin stop date is missing.
With the engine
- ✓ADM-4822 opens from the 09:14 fax.
- ✓Fund cover and consent pass; the missing warfarin stop date is flagged.
- ✓The nurse receives the evidence and the hospital’s rule together.
For a routine case, the engine carries the work through those checks to the agreed endpoint. That might mean a booking recorded or a claim lodged. We define the endpoint together, because reading a document is only part of the job. A useful result has to reach the systems your team relies on.
The rules belong to you. We learn which information matters, which records need to agree and which conditions require a person. Where a missing detail can be requested under an agreed rule, the engine can do the chasing. If the answer remains unclear, the case needs attention.
That boundary matters as much as the automation. Your team should be able to see why a case finished on its own and why another stopped. The record includes what was checked, what happened and who made a decision, with the time attached.
One admission, from fax to a nurse
Here is that day-hospital pre-admission for a knee arthroscopy. It shows a case that correctly needs a person. The useful work is in preparing that decision and making the reason visible.
ADM-4822 reaches the nurse with the completed checks, the medication exception and its source in one record. The nurse’s decision is recorded at 09:40.
The engine does not choose a medication stop date. It identifies the missing information against the hospital’s agreed rule and routes the case to a nurse. The handoff includes the reason, evidence, rule and suggested next step, alongside the checks already completed.
The nurse can begin with the issue that needs judgement. There is no need to reconstruct the case from an inbox and a separate stack of forms. The decision becomes part of the same record, so the team can follow what happened from arrival onwards.
ADM-4822 is a touched case: a person made a decision. That is the right result for this example. A clean admission that meets every agreed condition can take the routine path through to completion.
☛ ADM-4822
09:14
Fax received: referral and admission form become one case.
09:16
Cover and consent checked; warfarin has no stop date, so the evidence is prepared for review.
09:40
The nurse’s decision is recorded against the case.
What a case engine is not
It is not a chatbot waiting for someone to ask the next question. A chatbot can help someone find information or draft a response. A case engine follows the case through to its agreed outcome, including the checks, actions and record of what happened.
It is not a new software package for your team to move into. There is software behind it, but the engagement starts with your operation. The engine works with what your existing systems produce, such as emails, forms, exports and PDFs, and returns its work through agreed channels. There is nothing to install.
It is not RPA screen-scraping, where a bot repeats a sequence of clicks on a screen. The work is organised around the meaning and status of a case. We agree how it connects to your systems during design, with a clear way to recognise completion or a failed handoff.
And it does not take over professional judgement. Clinical decisions, disputed facts and other exceptions stay with qualified people. Access is limited by team and role, and we work through access and privacy requirements with you before using real cases.
Build around work your team recognises
- 01Learn your business: mapping takes days or weeks, depending on your business. We sit with your team, watch the work and map every case type, step, workaround and exception.
- 02Start with small wins: we deliver small, contained improvements found along the way without waiting for the whole map. Each is measured before and after. We prove each improvement on real cases before going further.
- 03Transform the company: when the small wins show it is applicable and the results say it is worth it, we go further, with the case engine running across the business’s workflows. If it is not applicable, we say so honestly.
The key measure is touchless rate: cases nobody touched divided by all cases. It tells us how much work reaches done without asking your team to move it along. We also examine the exceptions, because a well-prepared handoff matters to the person receiving it.
If there is a case your team keeps checking and chasing, we can start there. You are welcome to a free conversation about how it runs today.