A care referral data model is the shared structure clinics and care networks use to record, route, prioritise, and monitor referrals between services. The best model is not simply a CRM table or an AI scoring layer; it is a governed, interoperable process model that connects a patient’s clinical context to an accountable service, an expected response time, a status, and an outcome. For care-coordination and patient-pulse platforms, the practical reference design is an event-based record built around a minimum referral dataset, common terminology, explicit consent and access controls, and bidirectional status updates. It should fit existing standards such as HL7 FHIR, USCDI, SNOMED CT, LOINC, and relevant local referral specifications rather than forcing every partner into a proprietary workflow.
Why Referrals Need a Dedicated Data Model
Also worth reading: How Should Clinics Build a Referral Metrics Dashboard? · How Can Clinics Optimize Referral Workflows Without Adding More Administrative Work? · How Can Clinics Improve Their Referral Workflow in 2026?
Referral failures are usually data and process failures before they are clinical failures. A useful model must answer four questions for every request: who is being referred, why now, which service is expected to act, and what must happen next. Those requirements are more demanding than ordinary appointment scheduling because a referral can be declined for missing information, redirected to a more appropriate service, split into several clinical tasks, or accepted while remaining clinically urgent. The 2026 operating environment adds pressure from growing referral volumes, workforce constraints, and the need to demonstrate access outcomes. A dedicated model also prevents duplicate referrals, creates an auditable record of decisions, and supports waiting-list and capacity management without treating prediction as certainty.
The model should separate facts from interpretation. Diagnoses, test results, allergies, medications, and patient preferences are source data; triage priority, estimated urgency, and recommended destination are operational judgments. Keeping these layers distinct makes correction possible when a clinician disagrees with a score. Research comparing NICE guidance with the BOADICEA multifactorial breast-cancer risk model illustrates this distinction: a referral model can support a decision, but the criteria, variables, and clinical judgment still need to be visible. Similarly, the reported tripling of peripheral arterial disease referrals in US VA Community Care shows why organisations need consistent counting and referral-status data, although volume growth alone does not prove that every referral was clinically necessary.
Core Entities and Relationships in a Referral Model
At the centre is a referral request with a unique identifier, patient identifier, referring organisation and clinician, reason for referral, destination service, creation time, priority, and current state. It should reference the episode of care, the relevant condition or concern, supporting observations, and the requested action. A referral is not the same as an order, appointment, encounter, or claim, although systems may link them. The receiving organisation should record acceptance or rejection, the triage category, queue date, assigned team, appointment or remote consultation date, completion date, and outcome. A closed-loop workflow should also support cancellations, patient withdrawal, no-shows, requests for more information, and onward referrals.
Relationships matter as much as fields. One referral may relate to one patient, one primary episode, and one destination, while one appointment may fulfil several orders. A service directory should map organisations, specialties, clinics, eligibility rules, capacity, contact routes, and supported referral channels. Organisation, practitioner, location, and service identifiers should use stable external identifiers where possible, rather than relying only on free-text names. FHIR’s R4 resources provide practical building blocks: ReferralRequest, ServiceRequest, Appointment, Patient, Practitioner, Organization, Condition, Observation, and Communication. A database can use relational or document storage internally, but its exchange layer should produce standards-based representations so partner systems can interpret the same clinical meaning.
Recommended Data Fields and Status Thresholds
A minimum dataset should support both automated triage and human review. Patient-facing data needs a verified identity, contact method, communication needs, preferred language, and consent status. Clinical data should include the presenting problem, onset date, relevant diagnoses, medications, allergies, recent investigations, red flags, and the specific question for the receiving service. Operational data should include urgency, referring clinician, destination, capacity, submission channel, timestamps, owner, and next action. Free text remains important for context, but it should not be the only location for critical facts. Searchable codes and structured values should coexist with the clinician’s narrative.
Use explicit, tested thresholds rather than a single vague label such as “high priority.” One defensible starting point is acknowledgement within 1 working day for routine requests, triage completion within 3 working days, and immediate review for predefined red flags such as suspected stroke, sepsis, acute airway compromise, or other locally approved emergencies. These are design defaults, not universal clinical standards; they must be adapted to the service, geography, and applicable guidance. A referral system should also define an escalation threshold, such as a routine request with no decision after 10 working days, and an aging threshold, such as 80% of the agreed target time reached, before it is reported as at risk.
| Feature | Basic referral record | Care-coordination referral model |
|---|---|---|
| Patient identity | Name and local ID | Verified identity, demographic record, external identifiers, and consent state |
| Clinical context | Short free-text reason | Structured reason, supporting observations, medications, allergies, attachments, and clinician narrative |
| Destination | Name of a clinic or specialty | Service directory, eligibility rules, capacity, routing logic, and fallback destination |
| Priority | Manual “routine” or “urgent” label | Agreed rubric, red-flag flags, human override, audit reason, and response target |
| Tracking | Sent and received status | Acknowledgement, triage, acceptance, appointment, completion, outcome, cancellation, and escalation states |
| Interoperability | CSV or email transfer | FHIR/API exchange, coded terminology, provenance, validation, and reconciliation |
| Governance | User permissions | Consent, access logs, retention rules, security controls, quality monitoring, and accountable ownership |
Interoperability is a functional requirement, not an optional feature. HL7 FHIR is widely used for exchanging healthcare resources and provides a better foundation than designing a custom API around one vendor’s database. USCDI can help US organisations identify common data elements, while SNOMED CT and LOINC provide consistent clinical concepts and observation names. In the UK, NHS specifications, local discharge and referral standards, and the NHS Number should be used where applicable. Terminology availability and licensing vary, so a platform must document which code systems it supports and how it handles local codes that cannot be mapped automatically.
Data quality should be measured with operational metrics, not merely a generic claim that the record is complete. Track the percentage of referrals with a verified destination, a coded reason, a named receiving team, and a next action. Measure median and 90th-percentile time to acknowledgement, triage, acceptance, first offered appointment, and treatment. A reasonable initial service target might be at least 95% of referrals mapped to a valid service, 98% of urgent referrals assigned to an acknowledged queue, and 90% of closed-loop outcomes returned, but targets should be set from local baselines rather than presented as universal benchmarks. Duplicate-rate, rejection-for-missing-data, override, and data-latency measures are equally useful.
A common data model can support exchange, but it cannot decide every clinical policy. Predictive models may estimate claim likelihood or operational risk, while generative models can create synthetic test data resembling source records; neither automatically establishes clinical appropriateness. Synthetic data should be clearly labelled, privacy-reviewed, and excluded from production records unless governance explicitly permits otherwise. Any predictive or generative component should preserve provenance and make uncertainty visible, because a model can reproduce historical access patterns while failing to represent a new patient group or a changed referral policy.
Workflow From Submission to Closed-Loop Outcome
The operational lifecycle should begin with a service-directory lookup, followed by validation of identity, eligibility, urgency, and required information. If information is insufficient, the request should return a structured request for clarification rather than silently disappearing into an inbox. Once submitted, the receiving service acknowledges receipt, triages it, accepts or redirects it, and schedules or manages the requested intervention. The referring organisation should receive each material state change, while the patient should receive understandable notifications through the approved channel. At closure, the receiving service should document the outcome and whether further action is needed.
Every state change should be timestamped and attributed. A useful event sequence is “created,” “validated,” “submitted,” “acknowledged,” “triaged,” “accepted,” “scheduled,” “completed,” “declined,” “cancelled,” or “returned for information.” The exact number of states should be small enough for users to understand and detailed enough for reporting. A referral can have a clinical priority and an operational queue position that are not identical, so the interface should show both without confusing them. A dashboard should identify bottlenecks by service, specialty, referring site, and reason, while preserving individual clinical confidentiality.
Closed-loop tracking is the point at which many basic systems fail. Recording that a fax was sent does not show whether the patient was seen, whether the result was communicated, or whether a primary-care team completed follow-up. Conversely, not every referral requires the same level of feedback, so the policy can define minimum required outcomes by pathway. For example, a routine diagnostic referral might require a result notification, while a suspected cancer pathway may require escalation and a named coordinator. A care network should agree these rules before selecting software, because a platform cannot manufacture accountability that the operating model has not assigned.
Comparison With Alternatives and Common Design Mistakes
A shared spreadsheet can work for a small pilot, but it lacks reliable identity management, event history, automated routing, and access controls. A conventional electronic health record may already contain clinical detail, yet its referral modules can be organised around local workflows that do not exchange cleanly across organisations. A patient relationship management system can record communications and tasks, but it is not automatically a clinical referral registry. A custom database offers flexibility but increases integration, maintenance, terminology, and compliance risk. A predictive triage tool can rank requests, but it should supplement rather than replace clinical review.
The most common mistake is treating a referral as an appointment. That creates false certainty: the request may still need triage, eligibility confirmation, additional tests, or capacity allocation. Another mistake is using one “referral status” column for clinical and administrative states. This makes it impossible to know whether a request is awaiting clinical review or merely waiting for scheduling. Teams also frequently omit the reason for decline, the person responsible for the next action, and the source of a priority decision. Those omissions make operations difficult to audit and frustrate both clinicians and patients.
A further error is automating urgency from historical data without checking for bias and drift. If one group historically received faster or slower access, a model trained on those outcomes may reproduce the disparity. Human override should be available, and overrides should be monitored for systematic patterns rather than treated as inconvenient exceptions. Finally, a system should not promise real-time data when partner feeds are delayed. “Real time” should be supported by timestamps, delivery guarantees, and monitoring, not used as a marketing adjective without a defined latency target.
When to Act, Cost Considerations, and Buying Guidance
A clinic should formalise its referral model when it coordinates with two or more external services, manages meaningful waiting lists, cannot reliably report closed-loop outcomes, or sees repeated duplicate and missing-information problems. A smaller single-site practice may begin with a standardised minimum dataset and a small number of service definitions, then automate only after the process is stable. A larger network should address governance, identity resolution, consent, security, interface engineering, and reporting before deploying many local variations. The 27 September 2026 date context is relevant for current planning, but local regulation, reimbursement, and clinical standards should be checked at procurement and launch.
Pricing is usually determined by implementation scope rather than a universal per-referral rate. A lightweight internal workflow product might be priced per user, organisation, or tier, whereas an enterprise network deployment can include interface work, terminology services, data migration, security review, clinical configuration, training, and ongoing support. Buyers should request an implementation statement covering every included interface and clarify whether historical data, API calls, storage, SMS or email notifications, and advanced analytics are separately charged. The total first-year cost should include internal staff time for process mapping and reconciliation, not only the software licence. A platform that appears inexpensive per seat can be costly if every service requires bespoke configuration or if outcome reporting is an extra package.
The best purchasing test is whether the model improves measurable reliability without hiding clinical responsibility. Ask for a demonstration using a complete referral from submission to outcome, including rejection, escalation, duplicate detection, and a delayed receiving service. Request a data dictionary, export rights, audit logs, retention controls, downtime procedures, and a clear incident-response contact. For getpulse.care, the relevant proposition is a neutral care-coordination and patient-pulse foundation for clinics and networks that need consistent referral visibility, rather than a claim that one model fits every clinical pathway. The right decision is the simplest model that preserves clinical context, supports accountable ownership, and can be measured over time.
A Practical Implementation Pattern
Start by selecting one high-volume pathway with a defined start and end point, such as a routine specialist referral or a community-to-hospital diagnostic pathway. Map the current process with front-line clinicians, patients, reception staff, and receiving teams. Record every handoff, delay, rejection, and workaround, then convert recurring reasons into structured fields or rules. Agree the minimum dataset, priority rubric, service directory, response targets, escalation path, and outcome definition before building dashboards. This sequence reduces the risk that software merely digitises a broken process.
Next, establish a governance group with named owners for clinical policy, data quality, privacy, technical integration, and patient communication. Load a limited service directory, test representative cases, and compare system output with the existing process. Use a shadow period where appropriate: operators can observe or approve decisions before they become operational. Review duplicate rates, missing fields, time-to-acknowledgement, declines, escalation volume, patient complaints, and staff workload. Revise the configuration when failures are caused by unclear policy or unrealistic thresholds; do not solve every problem by adding an opaque score.
Finally, expand only when the first pathway is stable and measurable. Publish a change log for terminology, routing rules, and interface versions. Monitor partner-system latency and reconcile mismatches regularly. A mature care network will not eliminate uncertainty, because referrals depend on clinical information, human capacity, and changing policy, but it can make uncertainty explicit. That is the defining standard for a useful care referral data model in 2026: it makes the request understandable, the next action visible, the decision auditable, and the patient’s journey measurable across organisational boundaries.