At first glance, building a digital referral form can look straightforward. Form-building tools are readily available, fields can be added quickly and templates can provide a useful starting point.
But the visible build is only one part of the work.
A referral form has to translate clinical and operational requirements into something that works at the point of care. It should help referrers identify the right service, capture the information that service needs and make the next step clear.
The receiving service, in turn, needs enough information to accept, prioritise and act on the referral safely.
The true cost of form creation therefore goes beyond licence fees and configuration time. It includes the clinical input, operational knowledge, design effort, testing, assurance and ongoing ownership required throughout the life of the referral pathway.
The mechanics of creating a form are increasingly accessible. The more complex work is deciding what the form actually needs to do.
Before a build can begin, someone must establish:
These are not simply configuration questions. They involve clinical, operational, technical and user-experience decisions.
Clinicians, service managers, administrative teams and digital colleagues may all need to contribute, often alongside their existing responsibilities. That internal capacity is part of the overall resource required to create a form, even when it does not appear as a separate line on an invoice.
A form can be technically complete and still perform poorly in practice.
Unclear referral criteria can lead referrers to choose the wrong service. Ambiguous questions can leave receiving teams needing clarification. Missing information can delay referrals or result in rejection.
Adding every possible question is not necessarily the answer either. It can make the form unnecessarily burdensome for users.
Each issue may appear small on its own, but when repeated across practices, services and hundreds or thousands of referrals, the operational burden can become significant.
Clinicians spend longer completing referrals. Administrative teams chase missing information. Providers interpret inconsistent submissions manually. Rejected referrals have to be corrected and resubmitted. Patients wait while avoidable gaps are resolved.
A form that is quick to produce can therefore continue adding time to every referral long after the initial build is complete.
Different services have different criteria, clinical risks and information needs. A musculoskeletal pathway cannot simply reuse the logic of a dermatology or mental health referral.
At the same time, excessive customisation creates its own burden. Forms become inconsistent, users have to relearn familiar tasks and similar services may end up solving the same problems in different ways. Testing, support and future changes can then become harder to manage.
A more balanced approach standardises the elements that benefit from consistency while keeping service-specific elements flexible where they need to be.
Common patterns can be used for patient and referrer information, layout, commonly used question types, navigation and accessibility. Service-specific design can then concentrate on referral criteria, clinical content, pathway logic and the information required for triage.
This avoids repeatedly designing the same basic structure while preserving the flexibility needed for safe and useful referrals.
It can be tempting to save time by asking a small project team to create a form and then inviting clinicians to approve it at the end.
But this often moves effort rather than removes it.
Late review may reveal that a key question is missing, terminology does not reflect clinical practice or the proposed workflow does not match how referrals are actually made and received. Fixing those problems at the end can require rework, further approval and additional testing.
Co-design brings the people who understand the pathway into the process earlier. That might include receiving services, referrers, form specialists and relevant assurance colleagues.
The aim is not to place the burden of design on clinicians. It is to involve them where their knowledge adds the most value.
A well-structured process can move from discovery and requirements gathering, through design and build, into proportionate usability, technical and clinical assurance before approval and launch. Bringing those conversations forward can protect clinical time by reducing repeated clarification, late-stage corrections and avoidable problems after deployment.
Focused investment earlier in the process can prevent a much larger burden from spreading across the pathway later.
A basic electronic form captures information. A SMART Referrals form can support a decision and help users complete a task within a clinical workflow.
Depending on the pathway and available integration, this may include:
The value does not come from the number of features. It comes from removing avoidable effort or reducing risk at meaningful points in the referral.
Specialist design and established capability can support this work through proven methodology, reusable patterns, assurance and experience of designing referral journeys that work in practice.
Health and care teams are being asked to improve access, coordinate services and make better use of limited capacity.
Many of the people needed to design referral processes are also managing operational pressures or delivering care. Their time remains a real resource requirement, even when it is absorbed internally.
Time spent learning a tool, interpreting requirements, rebuilding logic, coordinating feedback or resolving preventable referral problems cannot be used for other priorities.
This is why a build-versus-buy decision is rarely just about the price of a platform or the apparent speed of creating a form internally.
The better question is whether the organisation has the available capacity, specialist expertise, assurance processes and ongoing ownership needed to support the form throughout its life.
That decision will vary according to clinical complexity, referral volume, integration requirements and the consequences of failure. It should also take into account the number of users affected, the level of assurance required, the availability of reusable components and the effort needed to support and maintain the form after launch.
A form should not be treated as a one-off digital asset.
It is part of a living pathway. Services change, criteria are updated, teams reorganise and new evidence or guidance emerges. The form has to continue reflecting those changes without creating confusion or introducing new risk.
The initial build may be the most visible cost, but it is not necessarily the largest.
The wider resource requirement sits across the form’s entire lifecycle: the people who design and create it, the clinicians who use it, the services receiving it and the teams responsible for keeping it accurate over time.
So the more useful question is not simply:
“How much does it cost to create a form?”
It is:
“How much time and friction can we remove from the referral pathway?”
Interested in understanding the true resource required to design, build and maintain effective referral pathways? Get in touch – hello@dxs-systems.co.uk
