Project · Healthcare
Regional health referral intake
Replacing a paper and email referral process across a distributed clinic network with a secure intake platform that made urgency, completeness and status visible.
The operating problem.
A regional clinic network received referrals from general practices, hospitals and community providers across fourteen sites. The volume was modest — around 1,200 referrals a month — but the process was entirely manual. Faxes arrived in shared inboxes, paper forms were re-keyed into the practice management system, and urgency was assessed from whatever information happened to be included.
The network had a clinical governance obligation to ensure that urgent referrals were identified and actioned consistently. It also had a privacy obligation to protect identifiable health information as it moved between sites, systems and email accounts.
The executive did not want a new clinical system. They wanted the intake process to become reliable, measurable and safe, while keeping the existing practice management system as the patient record.
The challenge.
The visible problem was fragmented technology. The underlying problem was a process that depended on individual compensation.
- Four different referral forms were in use, with different mandatory fields and inconsistent definitions of urgency.
- Intake staff re-keyed information into the practice system, creating duplicate work and transcription errors.
- Referring practices had no reliable confirmation that a referral had been received or accepted.
- There was no structured audit trail of who assessed a referral, when, and on what basis.
What we found
A sample of referrals showed that 37 percent were missing at least one item needed for triage. Staff spent an average of eleven minutes per referral on data entry and follow-up before a clinician could review it.
The variation was not caused by careless referrers. Each clinic had developed its own form and its own workaround because the central process did not accommodate local workflows. The absence of a shared model was the root cause.
The most sensitive risk was urgency. Staff used experience to identify potentially urgent referrals, but that judgement was not consistently recorded. A structured triage model with a safe default was needed before any automation could be introduced.
How the work was structured.
Each stage produced a decision or an artefact that the next stage could rely on.
Shadow the intake process
We observed intake staff across four representative sites, including peak periods and exception handling. The process map included the informal steps that never appeared in policy.
Define the referral model
We worked with clinical and administrative owners to define a single referral record, mandatory information, urgency categories and safe-default rules.
Build the intake platform
A secure portal for referrers, a structured work queue for intake staff and a triage workflow with role-based access and audit history.
Integrate with the patient record
A controlled interface to the practice management system created the patient encounter after acceptance, avoiding duplicate entry while keeping the clinical record authoritative.
Roll out in waves
Two clinics piloted the platform while paper referrals continued in parallel. The model was refined before the remaining sites were onboarded.
Difficult problems and how we resolved them.
The delivery was not a straight line. These are the issues that required a design decision rather than a task.
Urgency rules varied by clinic and clinician.
We did not attempt to automate clinical judgement. Instead, we encoded the agreed minimum rules as a triage framework: red flags forced an urgent review, incomplete information triggered a follow-up task, and clinicians retained the ability to escalate. Every override required a reason and was visible in the audit record. The clinical governance committee signed off the rule set before build.
Patient identity was inconsistent across referrals and the practice system.
We implemented a matching process based on multiple identifiers, with a manual review queue for uncertain matches. The platform never merged records automatically. Intake staff could see the candidate matches and confirm the correct patient, which reduced duplicate creation without creating a new safety risk.
Referring practices resisted another portal.
The portal was designed to take under three minutes for a routine referral, with saved templates and clear status tracking. We ran short onboarding sessions and provided a printed referral checklist for practices that needed it. Adoption improved when referrers could see that their referral had been received and when it was reviewed.
The transition could not stop the existing service.
We ran a parallel period at the pilot sites. Paper and portal referrals were both accepted, and the intake staff used a single work queue that showed source and status. The parallel period was longer than originally planned, but it exposed edge cases before the remaining clinics moved.
The result in operational terms.
Measures were agreed with the client before delivery and compared against a baseline. The figures below are client-reported.
The measured intake time fell from an average of 19 minutes to 6 minutes per referral. The improvement came from removing duplicate entry, standardising mandatory information and giving intake staff a single work queue rather than four inboxes.
The network also gained something it did not have before: a reliable view of demand. Referral volume, source, urgency and time-to-review became visible to service managers, which allowed staffing to be adjusted before backlogs developed.
What we would do differently.
Every engagement produces lessons. A project page that only reports success is not useful to the next client.
- Clinical governance must be involved before the workflow is designed, not after the prototype is shown.
- Data migration and identity matching deserve more time than they usually receive in a healthcare project.
- A parallel run is not a sign of indecision; it is a controlled way to protect a live service.
These lessons have been incorporated into how we scope and run similar engagements. They are part of the reason the approach pages are specific about decision points and exit criteria.
The disciplines behind the result.
Projects rarely use one capability in isolation. The links below show where the work sits.
Design for the exception, not the demonstration.
The referral platform looked straightforward in the happy-path demonstration: a referrer completes a form, intake staff review it, a clinician accepts it. The operational value came from the exception paths: missing information, uncertain patient identity, urgent red flags and a referral that arrived while the practice system was unavailable.
We spent more time on those paths than on the main form, and that is where the reduction in handling time came from. A workflow that only works when the information is complete and the systems are available is not ready for a clinic.
The transferable lesson is to budget for exception design in any healthcare intake project. The main path is necessary; the exception path is what determines whether staff trust the system under pressure.
Have a similar constraint?
Tell us what is not working. We will help you define a first step that produces evidence, not just activity.