Referral Pathway Systems
Referral pathway systems are technology platforms that coordinate the transfer of individuals between service providers across organisational boundaries. These systems maintain directories of available services, manage the consent and data sharing required for referrals, track referral outcomes, and provide visibility into service availability and bottlenecks. Unlike internal case management systems that track an individual’s journey within a single organisation, referral pathway systems operate in the space between organisations where coordination failures most commonly occur.
The coordination challenge these systems address is substantial. A person fleeing domestic violence requires shelter, legal assistance, health services, livelihood support, and possibly child protection services. Each service exists within a different organisation, each with its own intake process, eligibility criteria, and data system. Without a referral pathway system, the burden of navigating this fragmented landscape falls on the person seeking help or on individual caseworkers making phone calls and sending emails with no visibility into whether referrals are received, accepted, or acted upon.
- Referral
- The formal transfer of responsibility for providing a specific service from one provider to another, accompanied by relevant information and with informed consent from the person being referred.
- Service directory
- A structured database of available services including provider details, eligibility criteria, contact information, operating hours, and current capacity.
- Referral pathway
- A defined route between service types specifying which providers can refer to which services, what information transfers with the referral, and what protocols govern the handover.
- Focal point
- The designated person within an organisation responsible for receiving and processing incoming referrals for a specific service type.
- Closed-loop referral
- A referral where the referring organisation receives confirmation of outcomes including acceptance, service delivery, and case closure, enabling end-to-end accountability.
- Service mapping
- The systematic process of identifying, documenting, and maintaining information about available services within a geographic area or thematic domain.
Referral Architecture
A referral pathway system connects three distinct participant types: referring organisations that identify needs and initiate referrals, receiving organisations that accept referrals and provide services, and individuals who move through the system with their consent governing what information travels with them. The system itself provides the infrastructure for these interactions while maintaining audit trails and enabling coordination oversight.
+-------------------------------------------------------------------+| REFERRAL PATHWAY SYSTEM |+-------------------------------------------------------------------+| || +-------------------+ +-------------------+ || | REFERRING | | RECEIVING | || | ORGANISATION | | ORGANISATION | || | | | | || | +-------------+ | | +-------------+ | || | | Case Worker | | | | Focal Point | | || | +------+------+ | | +------+------+ | || | | | | | | || +--------|----------+ +----------|--------+ || | | || v v || +--------+-------------------------------------------+--------+ || | REFERRAL PLATFORM | || | | || | +--------------+ +--------------+ +--------------+ | || | | Service | | Referral | | Consent | | || | | Directory | | Tracking | | Management | | || | +--------------+ +--------------+ +--------------+ | || | | || | +--------------+ +--------------+ +--------------+ | || | | Pathway | | Analytics | | Notification | | || | | Rules | | Dashboard | | Engine | | || | +--------------+ +--------------+ +--------------+ | || | | || +-------------------------------------------------------------+ || | || v || +---------+---------+ || | COORDINATION BODY | || | (oversight, | || | reporting) | || +-------------------+ |+-------------------------------------------------------------------+Figure 1: Referral pathway system architecture showing participant relationships
The service directory forms the foundation of any referral system. Without accurate, current information about what services exist, where they operate, who they serve, and whether they have capacity, referrals cannot be appropriately targeted. Directory maintenance requires ongoing effort since services open and close, eligibility criteria change, staff rotate, and capacity fluctuates. A directory that was accurate six months ago will contain substantial errors today unless actively maintained.
Referral tracking provides visibility into the status of each referral from initiation through outcome. This tracking enables the referring organisation to know whether their referral was received, whether it was accepted or rejected and why, whether services were actually delivered, and whether the case has been closed. Without this tracking, referrals disappear into organisational inboxes with no accountability for follow-through.
Consent management enforces data protection requirements by ensuring that information only travels with appropriate authorisation. The system must capture consent at referral initiation, limit information sharing to what consent permits, enable consent withdrawal, and maintain records demonstrating that data sharing complied with the individual’s expressed wishes.
Service Directory Design
A service directory must balance comprehensiveness against maintainability. Capturing every possible attribute of every service creates a directory that cannot be kept current. Capturing too little makes the directory useless for matching needs to services. Effective directories focus on the information that actually drives referral decisions.
The core attributes every service entry requires include the service type using a standardised taxonomy, the provider organisation, geographic coverage area, contact information for referral focal points, eligibility criteria, and current operational status. These attributes change infrequently enough to maintain while providing enough information to determine referral appropriateness.
+-------------------------------------------------------------------+| SERVICE DIRECTORY ENTRY |+-------------------------------------------------------------------+| || Service ID: SVC-2024-0847 || Service Type: Mental Health > Individual Counselling || || +------------------------+ +-------------------------------+ || | PROVIDER | | COVERAGE | || | | | | || | Organisation: MHPSS | | Districts: Kampala, Wakiso, | || | Partners Uganda | | Mukono | || | Site: Nsambya Clinic | | Catchment: 25km radius from | || | | | clinic | || +------------------------+ +-------------------------------+ || || +------------------------+ +-------------------------------+ || | CONTACT | | ELIGIBILITY | || | | | | || | Focal Point: J. Nakato | | Age: 12+ years | || | Email: referrals@ | | Gender: All | || | mhpss-ug.org | | Status: Refugees, host | || | Phone: +256-XXX-XXX | | community | || | Hours: Mon-Fri 0800- | | Exclusions: Active psychosis | || | 1700 EAT | | (refer to psychiatric) | || +------------------------+ +-------------------------------+ || || +-------------------------------------------------------------+ || | CAPACITY | || | | || | Status: ACCEPTING REFERRALS | || | Current wait time: 2-3 weeks | || | Monthly slots: 40 new clients | || | Last updated: 2024-11-12 | || +-------------------------------------------------------------+ || |+-------------------------------------------------------------------+Figure 2: Service directory entry structure showing core attributes
Service taxonomies provide the classification scheme that groups services into searchable categories. The taxonomy must be specific enough to distinguish meaningfully different services while remaining simple enough for caseworkers to navigate quickly during a referral. A taxonomy with 500 service types creates analysis paralysis; a taxonomy with 10 types fails to differentiate services that require very different referrals.
Humanitarian contexts commonly use taxonomies aligned with cluster or sector structures. Protection services subdivide into child protection, gender-based violence response, legal assistance, and civil documentation. Health services subdivide into primary care, reproductive health, mental health, and specialised treatment. Livelihoods services subdivide into vocational training, job placement, cash-for-work, and business development. Each subdivision contains further specificity as needed.
Capacity information presents the greatest maintenance challenge. Service availability changes daily based on staffing, funding, caseloads, and supply availability. Static capacity information misleads referrers into sending people to services that cannot serve them. Dynamic capacity requires providers to update their status regularly, which creates burden that reduces compliance over time.
Three approaches address this challenge. The first approach accepts staleness by requiring updates monthly and displaying the last update date prominently so referrers know how recent the information is. A directory entry last updated three months ago signals uncertainty about current capacity. The second approach integrates with provider systems so capacity information flows automatically from case management or appointment systems without manual updates. This approach requires technical integration that smaller providers cannot support. The third approach focuses capacity tracking on high-volume services where accuracy matters most while accepting that low-volume services will have less current information.
Referral Workflow Mechanics
A referral moves through distinct states from initiation to closure, with each transition requiring action from either the referring or receiving organisation. Understanding this workflow clarifies what the technology must support and where coordination commonly fails.
+------------------+ | INITIATED | | | | Referral created | | Consent obtained | +--------+---------+ | v +--------+---------+ | SUBMITTED | | | | Sent to provider | | Awaiting receipt | +--------+---------+ | +-------------+-------------+ | | v v +--------+---------+ +---------+--------+ | RECEIVED | | UNDELIVERED | | | | | | Provider | | Contact failed | | acknowledged | | Provider offline | +--------+---------+ +------------------+ | +------------+------------+ | | | v v v+------+-----+ +----+------+ +---+--------+| ACCEPTED | | PENDING | | DECLINED || | | | | || Will serve | | Under | | Cannot || | | review | | serve |+------+-----+ +-----+-----+ +---+--------+ | | | v | v+------+-----+ | +------+------+| IN SERVICE |<------+ | REDIRECTED || | | || Active | | Alternative || provision | | suggested |+------+-----+ +-------------+ | v+------+-----+| COMPLETED || || Service || delivered |+------+-----+ | v+------+-----+| CLOSED || || Outcome || recorded |+------------+Figure 3: Referral state transitions showing possible paths
Initiation requires the caseworker to identify an unmet need, locate an appropriate service in the directory, obtain informed consent for the referral and associated information sharing, and create the referral record with necessary details. The information included in the referral depends on what the receiving organisation requires to assess the referral and what consent permits sharing.
A referral to mental health services typically includes demographic information, presenting concerns, risk indicators, relevant history, and referring caseworker contact information. A referral to legal services for civil documentation requires identity information, documentation status, and specific legal need. Each service type has standard information requirements that referral pathway systems can enforce through structured forms.
Submission delivers the referral to the receiving organisation’s designated focal point. Delivery mechanisms range from email notifications linking to the referral platform, to direct API integration with the provider’s case management system, to fallback options like SMS alerts where connectivity is limited. The system must handle delivery failures gracefully by retrying, alerting the referrer, or escalating to alternative contacts.
Receipt acknowledgment confirms the receiving organisation has seen the referral. This acknowledgment should occur within a defined timeframe, commonly 24-48 hours, with automatic escalation if no acknowledgment occurs. An unacknowledged referral may indicate an inactive focal point, delivery failure, or simply a referral lost in a busy inbox.
Acceptance or decline represents the receiving organisation’s determination of whether they can serve the referred individual. Acceptance means the provider has capacity and the person meets eligibility criteria. Decline must include a reason: the person does not meet eligibility criteria, the service has no capacity, the person is already receiving this service from another provider, or the referral contains insufficient information to assess. Decline reasons enable the referring organisation to redirect the referral appropriately and provide aggregate data on service gaps.
Service delivery occurs within the receiving organisation’s own systems and processes. The referral platform does not manage service delivery itself but maintains a link to track progress. Receiving organisations update referral status as service delivery progresses, enabling the referring organisation to know whether the person they referred is actually receiving services.
Closure records the outcome of the referral. Did the person receive the intended services? Were services partially delivered? Did the person disengage before service completion? Outcome data enables quality monitoring, identifies providers with high incomplete rates, and provides evidence of referral pathway effectiveness.
Consent and Information Sharing
Referrals inherently involve sharing personal information between organisations, creating data protection obligations that the referral system must enforce. The consent model determines what information can travel with a referral and under what conditions.
Informed consent for referral requires explaining to the individual what information will be shared, with whom, for what purpose, and how long it will be retained. This explanation must occur in language the person understands, which in multilingual contexts requires translated consent materials and interpretation during the consent conversation.
+-------------------------------------------------------------------+| CONSENT AND DATA FLOW |+-------------------------------------------------------------------+| || +------------------+ || | INDIVIDUAL | || +--------+---------+ || | || | Grants consent || v || +---------------------------+---------------------------+ || | CONSENT RECORD | || | | || | Purpose: Referral to mental health services | || | Scope: Demographic, presenting concern, risk level | || | Recipients: MHPSS Partners Uganda | || | Duration: Until case closure + 2 years | || | Granted: 2024-11-14 | || | Method: Verbal with witness | || | | || +--------------------------+----------------------------+ || | || +--------------------+--------------------+ || | | || v v || +-----+------+ +------+-----+ || | REFERRING | | RECEIVING | || | ORG | | ORG | || | | | | || | Full case | Consent-limited data | Referral | || | record +-------------------------->| data only | || | | | | || +------------+ +------------+ || || +-------------------------------------------------------------+ || | DATA NOT SHARED (outside consent scope) | || | | || | - Detailed case history | || | - Other referrals made | || | - Financial information | || | - Information about family members | || +-------------------------------------------------------------+ || |+-------------------------------------------------------------------+Figure 4: Consent-governed data flow between organisations
Consent scope defines the boundaries of information sharing. Blanket consent authorises sharing all relevant information with any service provider for any service. This approach simplifies referral workflows but may share more information than necessary and does not meet data minimisation requirements under frameworks like GDPR. Service-specific consent authorises sharing defined information with a named provider for a specific referral. This approach requires obtaining new consent for each referral but ensures the individual controls each disclosure. Tiered consent defines categories of information with separate consent for each tier, allowing the individual to share basic demographic information broadly while limiting disclosure of sensitive details to specific providers.
Most referral pathway systems implement service-specific consent with the option to grant broader authorisation. The consent record captures who granted consent, when, for what purpose, to which recipients, and what information scope the consent covers. This record must be accessible to demonstrate compliance during data protection audits.
Consent withdrawal requires clear mechanisms. The individual may withdraw consent at any time, and the system must stop further sharing while preserving audit records of sharing that occurred before withdrawal. Practical implementation notifies relevant organisations of consent withdrawal so they can restrict further use of already-shared data where possible.
Protection-sensitive referrals require heightened consent protections. Referrals involving gender-based violence, child protection, or other protection concerns must prevent information from reaching anyone who could use it to harm the individual. A GBV referral must not be visible to staff members who might share information with a perpetrator. Access controls for sensitive referrals restrict visibility to designated protection staff within each organisation, with audit logging of all access.
Emergency referrals present an exception to standard consent requirements. When an individual faces immediate risk to life or safety, referral to emergency services may proceed without explicit consent, documenting the emergency justification. Post-emergency, the individual should be informed of what information was shared and given the opportunity to consent to or withdraw from continued care coordination.
Inter-Agency Data Sharing Agreements
Technology enables referrals, but governance enables the technology. Before organisations can exchange referral data, they must establish data sharing agreements that define responsibilities, permitted uses, security requirements, and liability allocation.
A referral pathway data sharing agreement establishes the terms under which participating organisations share information through the referral system. These agreements operate at two levels: a framework agreement among all pathway participants establishing baseline rules, and bilateral or multilateral service agreements governing specific referral relationships.
The framework agreement establishes the coordination body responsible for pathway governance, data controller and processor relationships, baseline security requirements, breach notification procedures, dispute resolution mechanisms, and conditions for joining and leaving the pathway. Framework agreements typically align with existing coordination structures such as protection working groups, health cluster coordination, or interagency referral networks.
Service agreements between specific providers define what data elements transfer for referrals between those providers, what legitimate bases support the processing, how long referral data is retained, what happens to data when organisations exit the pathway, and any special handling requirements for sensitive cases.
Legal complexity
Data sharing agreements involve legal considerations that vary by jurisdiction and organisational legal structure. Organisations should involve legal counsel in agreement development, particularly regarding data controller responsibilities and liability allocation.
Inter-operability agreements address technical integration where organisations connect their case management systems to the referral platform. These agreements specify API authentication requirements, data format standards, system availability expectations, and incident response coordination when integrations fail.
Platform Options
Referral pathway systems range from shared spreadsheets to purpose-built platforms with sophisticated workflow automation. Selection depends on the scale of coordination required, technical capacity available, existing systems in the participating organisations, and resource constraints.
Spreadsheet-based coordination uses shared documents (Google Sheets, Excel Online) to track referrals and maintain service directories. This approach requires no software procurement, no technical implementation, and minimal training. Limitations emerge as volume grows: manual data entry creates errors, version control becomes difficult with many editors, access control options are limited, and analysis requires manual effort. Spreadsheets suit coordination involving fewer than 10 organisations and fewer than 100 referrals monthly.
Primero and CPIMS+ (Child Protection Information Management System Plus) provide case management with referral capabilities designed for child protection and GBV programmes. Primero supports inter-agency referrals through its referral module, integrating referral tracking with case management. The system is open source, developed specifically for protection contexts, and deployed across UN agencies and NGOs globally. Implementation requires technical capacity for deployment and configuration.
RIMS (Referral Information Management System) platforms exist in various forms as custom-developed systems by coordination bodies for specific contexts. UNHCR’s RIMS, for example, manages referrals within refugee response operations. These systems integrate with broader UN information management ecosystems but may have limited availability to non-UN partners.
Commercial case management platforms with referral functionality include Salesforce (with nonprofit or NGO configurations), Microsoft Dynamics 365, and Apricot by Social Solutions. These platforms provide robust workflow automation, analytics, and integration capabilities but involve licensing costs and may raise data sovereignty concerns. Nonprofit pricing programmes reduce cost barriers, though total cost of ownership including implementation and customisation remains significant.
Purpose-built referral platforms designed specifically for inter-agency coordination include platforms developed by humanitarian innovation initiatives. These platforms focus on the specific challenges of multi-organisation coordination rather than adapting single-organisation case management tools. Availability varies by context and coordination body support.
| Platform Type | Strengths | Limitations | Suited For |
|---|---|---|---|
| Spreadsheet | No cost, immediate deployment, familiar interface | Scale limits, manual processes, weak access control | Small coordination groups, temporary arrangements |
| Primero/CPIMS+ | Purpose-built for protection, open source, established user base | Requires technical capacity, protection-focused | Protection coordination, child protection networks |
| Commercial CRM | Robust functionality, integration ecosystem, vendor support | Cost, data residency concerns, complexity | Well-resourced coordination with existing platform |
| Purpose-built referral | Designed for inter-agency use, coordination-focused | Limited availability, dependency on development organisation | Established coordination bodies with platform access |
Evaluation criteria for platform selection include deployment model (cloud, self-hosted, hybrid), offline capability for field use, mobile accessibility, integration options with existing systems, data residency and jurisdictional considerations, total cost over 3-5 years including implementation and maintenance, and exit strategy if the platform becomes unavailable.
Pathway Maintenance Operations
A referral pathway degrades without ongoing maintenance. Service directories become outdated, focal points change roles, organisations join and leave, and pathway rules require adjustment as coordination evolves. Maintenance operations preserve pathway integrity over time.
Directory maintenance requires regular verification that service entries remain accurate. Monthly verification contacts each provider to confirm contact information, eligibility criteria, and operational status. Automated monitoring can detect when focal point email addresses bounce or phone numbers disconnect, triggering immediate follow-up. Provider self-service interfaces allow organisations to update their own entries with coordination body review, reducing maintenance burden on the pathway administrator.
Pathway rule updates reflect changes in coordination agreements, service availability, or protection protocols. When a new GBV service provider joins the pathway, referral routes must update to include them. When an organisation withdraws from the pathway, pending referrals require redirection and historical referrals require notation. Rule changes should flow through defined governance processes with documentation of what changed, when, and why.
User management addresses staff turnover within participating organisations. When a focal point leaves, their replacement needs access provisioned and training provided before the transition. Departure procedures revoke access for staff who leave, preventing former employees from viewing referrals. Regular access reviews verify that all users with pathway access still require it.
Performance monitoring tracks pathway health through metrics including referral volume by pathway, acceptance rates by provider, time from submission to acknowledgment, time from acceptance to service initiation, completion rates by service type, and redirect volumes. Declining acceptance rates may indicate capacity problems, eligibility mismatches, or pathway configuration issues. Increasing redirect volumes suggest the service directory needs updating. Monitoring dashboards surface these patterns for coordination body attention.
+------------------------------------------------------------------+| PATHWAY HEALTH DASHBOARD |+------------------------------------------------------------------+| || REFERRAL VOLUME (Last 30 days) || +------------------------------------------------------------+ || | Protection to Health: ################ 187 | || | Health to MHPSS: ########## 98 | || | Protection to Legal: ######## 76 | || | Livelihoods to Education: ##### 52 | || +------------------------------------------------------------+ || || ACCEPTANCE RATES BY PROVIDER || +------------------------------------------------------------+ || | MHPSS Partners Uganda: [============= ] 89% | || | Legal Aid Foundation: [=========== ] 78% | || | Health Centre IV Nsambya: [=============== ] 94% | || | Youth Skills Initiative: [======== ] 61% <--Alert | || +------------------------------------------------------------+ || || RESPONSE TIME (Median hours to acknowledgment) || +------------------------------------------------------------+ || | Target: 24 hours | || | Current: 18 hours | || | Outliers: Legal Aid (52h), Youth Skills (67h) | || +------------------------------------------------------------+ || |+------------------------------------------------------------------+Figure 5: Pathway monitoring dashboard showing health indicators
Implementation Considerations
For organisations with limited coordination infrastructure
Where no established coordination body exists, referral pathway implementation must begin with relationship building rather than technology deployment. Identify the organisations that make and receive referrals in practice, document current informal processes, and establish agreement on the value of systematising coordination before introducing tools.
Start with the simplest viable approach. A shared spreadsheet with agreed columns, update responsibilities, and regular review meetings establishes coordination discipline without technology complexity. As volume grows and coordination matures, migrate to more capable platforms with the relationships and processes already established.
Focus initial pathway scope on high-volume referral routes where coordination failures cause the most harm. A pathway connecting protection screening to three core services (health, legal, shelter) delivers more value than a comprehensive pathway attempting to connect all possible services before relationships and processes are ready.
For established coordination mechanisms
Where coordination bodies already exist with defined membership and governance, referral pathway systems can build on established relationships. Technical implementation becomes the primary challenge rather than coordination development.
Assess existing systems within participating organisations. If multiple organisations already use Primero, extending Primero’s referral functionality leverages existing investment and training. If organisations use diverse systems, platform selection favours solutions with strong integration capabilities to connect heterogeneous environments.
Governance structures should map referral pathway roles to existing coordination positions. Protection working group chairs naturally oversee protection referral pathways. Health cluster coordinators oversee health service coordination. Avoid creating parallel governance structures that compete with established coordination.
Data sharing agreement development can accelerate by building on existing memoranda of understanding between participating organisations. Where protection information sharing protocols already exist, referral pathway agreements extend rather than replace these frameworks.
For protection-sensitive contexts
Referral pathways handling protection cases require heightened controls throughout. Access restrictions must limit visibility of sensitive referrals to designated protection staff with audit logging of all access. Anonymisation options allow tracking referral patterns without exposing individual details where aggregate analysis suffices.
Platform selection for protection pathways must address data residency concerns. Protection data about survivors of violence or persecution must not be stored in jurisdictions where government access could endanger individuals. Self-hosted deployment or regional cloud infrastructure with appropriate data sovereignty controls addresses these requirements.
Training for protection referral pathways goes beyond system operation to include ethical obligations, consent processes for trauma-affected individuals, and recognising signs that information sharing may create risk. Technical training without protection training creates systems that function technically while causing harm.
Incident response procedures specific to protection data breaches must define escalation paths, survivor notification protocols, and immediate protective actions when sensitive data may have been compromised. These procedures involve protection specialists, not only IT and data protection personnel.
For multi-country or networked operations
Organisations operating referral pathways across multiple countries face the tension between standardisation and local adaptation. Common platform and data standards enable cross-country visibility and comparison while local configuration accommodates different legal frameworks, coordination structures, and service landscapes.
Federated deployment models maintain local control over sensitive data while enabling aggregate reporting to regional or global levels. Each country instance contains full referral data for that context, with anonymised or aggregate data flowing to higher levels for programmatic oversight without exposing individual records across jurisdictions.
Multi-language support becomes essential when pathways span linguistic contexts. Service directories, referral forms, consent materials, and user interfaces require translation with ongoing maintenance as content evolves. Translation quality directly affects usability; machine translation without review creates confusion that undermines coordination.
Time zone handling affects service level agreements for referral response. A 24-hour acknowledgment commitment means different things when referring and receiving organisations operate in different time zones. Pathway rules should specify whether response times reference the sender’s time zone, receiver’s time zone, or a defined coordination time zone.