Secure Referral Systems

Secure referral systems enable the transfer of protection case information between organisations while maintaining confidentiality, integrity, and chain of custody. You implement these systems when establishing interagency referral pathways, configuring case management platforms for external data sharing, or enabling field staff to make secure referrals in low-connectivity environments. The outcome is a documented, encrypted referral pathway with verification mechanisms that protect survivor data throughout the transfer process.

Protection referrals carry unique risks. A referral for gender-based violence services, if intercepted, exposes the survivor to retaliation. A child protection referral transmitted insecurely reveals family circumstances to unauthorised parties. The technical controls in this procedure address these risks through encryption, access verification, and acknowledgement protocols that create an auditable chain of custody from referring organisation to receiving organisation.

Prerequisites

Before implementing secure referral systems, confirm these requirements are met:

You need the data sharing agreement in place before any technical implementation. This agreement specifies data elements permitted in referrals, retention periods, purpose limitations, and incident notification requirements. Without this legal foundation, technical controls provide security but not compliance.

Verify encryption capability on your infrastructure:

# Test TLS 1.3 support to partner endpoint
openssl s_client -connect partner-referral.example.org:443 -tls1_3 2>/dev/null | grep -E "Protocol|Cipher"
# Expected output:
# Protocol  : TLSv1.3
# Cipher    : TLS_AES_256_GCM_SHA384

# Verify certificate chain
openssl s_client -connect partner-referral.example.org:443 -showcerts 2>/dev/null | openssl x509 -noout -dates -issuer
# Confirm: notAfter date is future; issuer is trusted CA

For organisations using encrypted email as a fallback channel, verify GPG key infrastructure:

# Import partner organisation's public key
gpg --import partner-org-public.asc

# Verify fingerprint matches out-of-band confirmation
gpg --fingerprint partner@example.org
# Confirm fingerprint matches value received via separate channel (phone, in-person)

# Test encryption to partner
echo "Test message" | gpg --encrypt --armor --recipient partner@example.org > test-encrypted.asc
# File should contain -----BEGIN PGP MESSAGE----- block

Procedure

Referral platform security configuration

This procedure covers the Primero case management system. Adapt parameters for other platforms (CommCare, custom systems) while maintaining equivalent security controls.

1. Configure transport layer security for all referral endpoints. Access the Primero administration console and navigate to System Settings, then Security Configuration. Set the minimum TLS version to 1.3 and disable all cipher suites except AES-256-GCM and ChaCha20-Poly1305. Save the configuration and verify the setting persists after page refresh.

   For self-hosted Primero installations, edit the nginx configuration directly:

   server {
       listen 443 ssl http2;
       server_name primero.example.org;

       ssl_certificate /etc/ssl/certs/primero.crt;
       ssl_certificate_key /etc/ssl/private/primero.key;

       # TLS 1.3 only for referral endpoints
       ssl_protocols TLSv1.3;
       ssl_ciphers TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256;
       ssl_prefer_server_ciphers on;

       # HSTS with 1-year duration
       add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

       # Referral-specific location
       location /api/v2/referrals {
           # Additional headers for referral data
           add_header X-Content-Type-Options nosniff always;
           add_header X-Frame-Options DENY always;

           proxy_pass http://primero-app:3000;
           proxy_set_header X-Forwarded-Proto https;
       }
   }

Test the configuration before reloading:

   sudo nginx -t
   # Expected: syntax is ok, test is successful
   sudo systemctl reload nginx

2. Create the interagency referral user group with restricted permissions. In Primero, navigate to Admin, then User Groups, then New User Group. Name the group “Interagency Referral Partners” and assign these permissions only: Cases (Read, Referral), Referrals (Read, Write, Manage). Do not assign Case Create, Case Update, or any administrative permissions. This group provides the minimum access required for receiving organisations to accept referrals and update referral status.

3. Configure referral-specific data visibility rules. Protection referrals must not expose all case data to receiving organisations. Navigate to Admin, then Roles, and create a new role named “Referral Recipient”. Under Form Visibility, enable only these forms: Referral Details, Service Required, Risk Assessment Summary, Consent Documentation. Disable visibility for: Full Case History, Family Composition Details, Previous Service Providers, Location History. Assign this role to all users in the Interagency Referral Partners group.

   The visibility configuration follows data minimisation principles. Receiving organisations need sufficient information to provide services but not the complete case history, which remains with the referring organisation.

4. Enable referral encryption at the application layer. Primero encrypts data at rest by default, but referral payloads transmitted via API require explicit configuration. Edit the Primero application configuration:

   referral:
     encryption:
       enabled: true
       algorithm: aes-256-gcm
       key_derivation: pbkdf2
       iterations: 310000
     payload:
       # Fields encrypted beyond transport layer
       encrypt_fields:
         - survivor_code
         - risk_level
         - service_details
         - consent_documentation
     audit:
       log_referral_access: true
       log_field_access: true
       retention_days: 2555  # 7 years for protection data

Restart the Primero application service after configuration changes:

   sudo systemctl restart primero
   # Verify service started successfully
   sudo systemctl status primero | grep -E "Active|Main PID"
   # Expected: Active: active (running)

5. Configure partner organisation endpoints. Each receiving organisation requires registration in the referral system. Navigate to Admin, then Agencies, then Add Agency. Enter the partner organisation’s details including their API endpoint URL, public key for encrypted communications, and designated referral coordinator contact. The API endpoint URL follows the pattern https://partner-primero.example.org/api/v2/referrals/incoming.

   For each partner, upload their public certificate:

   # Convert partner certificate to PEM format if needed
   openssl x509 -in partner-cert.crt -out partner-cert.pem -outform PEM

   # Verify certificate validity
   openssl x509 -in partner-cert.pem -noout -dates -subject
   # Confirm: subject matches partner organisation; dates are valid

   # Copy to Primero certificates directory
   sudo cp partner-cert.pem /opt/primero/certs/partners/
   sudo chown primero:primero /opt/primero/certs/partners/partner-cert.pem
   sudo chmod 644 /opt/primero/certs/partners/partner-cert.pem

Interagency referral workflow configuration

The referral workflow defines how case workers initiate referrals and how receiving organisations acknowledge and accept them.

+-------------------------------------------------------------------+
|                     REFERRING ORGANISATION                        |
+-------------------------------------------------------------------+
|                                                                   |
|  +------------------+                                             |
|  | Case Worker      |                                             |
|  | initiates        |                                             |
|  | referral         |                                             |
|  +--------+---------+                                             |
|           |                                                       |
|           v                                                       |
|  +--------+---------+     +------------------+                    |
|  | Referral         |     | Supervisor       |                    |
|  | created with     +---->| approval         |                    |
|  | consent attached |     | (if required)    |                    |
|  +------------------+     +--------+---------+                    |
|                                    |                              |
+-------------------------------------------------------------------+
                                     |
                                     | Encrypted API call
                                     | (TLS 1.3 + payload encryption)
                                     v
+-------------------------------------------------------------------+
|                     RECEIVING ORGANISATION                        |
+-------------------------------------------------------------------+
|                                    |                              |
|                           +--------v---------+                    |
|                           | Incoming         |                    |
|                           | referral queue   |                    |
|                           +--------+---------+                    |
|                                    |                              |
|           +---------------------+--+-------------------+          |
|           |                     |                      |          |
|           v                     v                      v          |
|   +-------+-------+    +--------+--------+    +--------+-------+  |
|   | Accept        |    | Request         |    | Decline        |  |
|   | referral      |    | more info       |    | with reason    |  |
|   +-------+-------+    +-----------------+    +----------------+  |
|           |                                                       |
|           v                                                       |
|  +--------+---------+                                             |
|  | Acknowledgement  |                                             |
|  | sent to          |                                             |
|  | referring org    |                                             |
|  +------------------+                                             |
|                                                                   |
+-------------------------------------------------------------------+

Figure 1: Secure referral workflow between organisations

6. Define referral approval thresholds. Not all referrals require supervisor approval, but high-risk cases and inter-country referrals must include an approval step. In Primero, navigate to Admin, then Workflow Configuration, then Referrals. Configure approval requirements:

   # Referral approval configuration
   approval_required:
     conditions:
       - field: risk_level
         operator: equals
         value: high
       - field: destination_country
         operator: not_equals
         value: current_country
       - field: case_type
         operator: in
         values:
           - child_protection
           - trafficking
     approvers:
       - role: supervisor
       - role: protection_coordinator
     timeout_hours: 48
     escalation:
       enabled: true
       escalate_to: protection_manager
       after_hours: 24

These thresholds ensure that referrals involving elevated risk receive human review before transmission while allowing routine service referrals to proceed with appropriate urgency.

7. Configure acknowledgement requirements. Every referral must receive explicit acknowledgement from the receiving organisation. Unacknowledged referrals represent a safeguarding gap: the referring organisation believes services are being arranged while the receiving organisation has not confirmed acceptance. Set acknowledgement timeframes based on referral urgency:

   Urgency level	Acknowledgement deadline	Escalation trigger
   Emergency	4 hours	2 hours without response
   Urgent	24 hours	12 hours without response
   Standard	72 hours	48 hours without response

   Configure these timeframes in the workflow settings. When a deadline passes without acknowledgement, the system alerts the referring case worker and their supervisor to follow up through alternative channels.

8. Implement the verification handshake. Before transmitting referral data, the system must verify the receiving endpoint is authorised and operational. Configure the pre-referral verification check:

   # Verification script run before each referral transmission
   #!/bin/bash
   PARTNER_ENDPOINT="$1"
   EXPECTED_FINGERPRINT="$2"

   # Verify TLS certificate fingerprint
   ACTUAL_FINGERPRINT=$(echo | openssl s_client -connect "${PARTNER_ENDPOINT}:443" 2>/dev/null | \
     openssl x509 -noout -fingerprint -sha256 | cut -d= -f2)

   if [ "$ACTUAL_FINGERPRINT" != "$EXPECTED_FINGERPRINT" ]; then
     echo "ERROR: Certificate fingerprint mismatch"
     echo "Expected: $EXPECTED_FINGERPRINT"
     echo "Actual: $ACTUAL_FINGERPRINT"
     exit 1
   fi

   # Verify endpoint responds to health check
   HTTP_STATUS=$(curl -s -o /dev/null -w "%{http_code}" \
     "https://${PARTNER_ENDPOINT}/api/v2/health")

   if [ "$HTTP_STATUS" != "200" ]; then
     echo "ERROR: Partner endpoint not responding (HTTP $HTTP_STATUS)"
     exit 1
   fi

   echo "Partner verification successful"
   exit 0

This script prevents referral transmission to compromised or unavailable endpoints.

Offline referral handling

Field locations with intermittent connectivity require offline-capable referral mechanisms. This section configures secure referral handling when network access is unavailable.

+------------------------------------------------------------------+
|                      FIELD LOCATION (OFFLINE)                    |
+------------------------------------------------------------------+
|                                                                  |
|  +------------------+     +------------------+                   |
|  | Case worker      |     | Local device     |                   |
|  | creates referral +---->| encrypted        |                   |
|  | offline          |     | queue            |                   |
|  +------------------+     +--------+---------+                   |
|                                    |                             |
|                                    | (Stored encrypted at rest)  |
|                                    |                             |
|                           +--------v---------+                   |
|                           | Connectivity     |                   |
|                           | restored         |                   |
|                           +--------+---------+                   |
|                                    |                             |
+------------------------------------------------------------------+
                                     |
                                     | Automatic sync
                                     | (TLS 1.3)
                                     v
+------------------------------------------------------------------+
|                      CENTRAL SERVER                              |
+------------------------------------------------------------------+
|                                                                  |
|  +------------------+     +------------------+                   |
|  | Queued referrals |     | Validation and   |                   |
|  | decrypted        +---->| duplicate        |                   |
|  |                  |     | detection        |                   |
|  +------------------+     +--------+---------+                   |
|                                    |                             |
|                           +--------v---------+                   |
|                           | Normal referral  |                   |
|                           | workflow         |                   |
|                           +------------------+                   |
|                                                                  |
+------------------------------------------------------------------+

Figure 2: Offline referral queue and synchronisation

9. Configure the offline referral queue on field devices. Primero’s mobile application stores referrals locally when connectivity is unavailable. Verify offline encryption is enabled:

   // Mobile app configuration (config/offline.js)
   module.exports = {
     offline: {
       enabled: true,
       encryption: {
         algorithm: 'aes-256-gcm',
         keyStorage: 'secure-enclave',  // iOS Keychain / Android Keystore
         keyRotationDays: 30
       },
       queue: {
         maxSize: 100,  // Maximum pending referrals
         retryInterval: 300,  // Seconds between sync attempts
         maxRetries: 288  // 24 hours of retries at 5-minute intervals
       },
       referrals: {
         allowOffline: true,
         requireLocalApproval: true,  // Supervisor on-site must approve
         expiryHours: 168  // Referrals expire after 7 days if unsent
       }
     }
   };

10. Establish the offline approval workflow. When network connectivity is unavailable, referrals still require approval for high-risk cases. Configure local approval authority:

    In field settings, a designated supervisor with local approval authority can approve referrals that would normally require remote supervisor approval. The system records this approval with the supervisor’s device-local signature and synchronises the approval chain when connectivity returns.

    Configure local approval authority in the mobile application settings. Navigate to Settings, then Offline Mode, then Approval Authority. Add staff members authorised to approve referrals offline. Each authorised approver must have completed protection data handling training within the past 12 months.

11. Configure synchronisation conflict resolution. When connectivity returns, the offline queue synchronises with the central server. Conflicts arise when the same case has been modified both offline and online. Set the conflict resolution policy:

    # Sync conflict configuration
    sync:
      conflict_resolution:
        referrals:
          strategy: server_wins_with_merge
          merge_fields:
            - notes
            - status_updates
          preserve_local:
            - offline_approval
            - local_timestamp
        priority: online_first
      validation:
        check_consent_expiry: true
        check_case_closed: true
        reject_if_closed: true

The “server wins with merge” strategy preserves the server state as authoritative while appending local notes and status updates. This prevents data loss while maintaining consistency.

Encrypted email fallback configuration

When platform-to-platform referral is unavailable, encrypted email provides a secure fallback channel. This is common when referring to organisations that lack API-enabled case management systems.

12. Configure the organisation’s GPG key infrastructure for referral communications. Generate a dedicated keypair for referral communications separate from individual staff keys:

    # Generate organisation referral key
    gpg --full-generate-key
    # Select: (1) RSA and RSA
    # Keysize: 4096
    # Validity: 2y (keys should be rotated)
    # Real name: Example Organisation Referrals
    # Email: referrals@example.org
    # Comment: Protection referral communications only

    # Export public key for distribution to partners
    gpg --armor --export referrals@example.org > example-org-referrals-public.asc

    # Verify key details
    gpg --list-keys referrals@example.org

Distribute the public key to partner organisations through a verified channel. Do not send keys via unencrypted email. Use secure file transfer, in-person exchange, or verification via phone call.

13. Create the encrypted referral email template. Staff sending referrals via encrypted email must use a standardised format that includes required fields while minimising exposure:

    Subject: [ENCRYPTED] Referral - [Case Code] - [Urgency Level]

    -----BEGIN PGP MESSAGE-----
    [Encrypted content containing:]

    REFERRAL DETAILS
    ================
    Case Code: [Anonymised identifier]
    Referring Organisation: [Name]
    Referring Case Worker: [Name, Contact]
    Date of Referral: [YYYY-MM-DD]
    Urgency: [Emergency/Urgent/Standard]

    SERVICE REQUESTED
    =================
    Service Type: [Category]
    Specific Needs: [Description]

    CONSENT STATUS
    ==============
    Consent Obtained: [Yes/No]
    Consent Date: [YYYY-MM-DD]
    Consent Limitations: [Any restrictions]

    RISK INFORMATION
    ================
    Risk Level: [High/Medium/Low]
    Safety Concerns: [Relevant information only]

    CONTACT INSTRUCTIONS
    ====================
    Preferred Contact Method: [Specify]
    Safe Contact Times: [Specify]
    Contact Restrictions: [Specify]

    -----END PGP MESSAGE-----

14. Train staff on encrypted email procedures. Encrypted email requires specific handling to maintain security:

    Case workers must verify recipient key fingerprints before first use. The fingerprint verification happens through a separate channel: phone call to a known number, video call with visual confirmation, or in-person verification. Document the verification in the case file.

    Configure email clients to require encryption for all messages to partner referral addresses. In Thunderbird with Enigmail, right-click the partner contact and select “Require Encryption”. In Outlook with gpg4o, add the partner to the “Always Encrypt” list.

Verification

After completing the configuration, verify secure referral functionality through these tests:

Test transport layer security to all partner endpoints:

# For each partner endpoint
./verify-partner.sh partner-referral.example.org "AA:BB:CC:DD:EE:FF:..."
# Expected: Partner verification successful

# Verify no fallback to older TLS versions
openssl s_client -connect partner-referral.example.org:443 -tls1_2 2>&1 | grep -i "handshake"
# Expected: handshake failure (TLS 1.2 should be rejected)

Test the referral workflow with a non-sensitive test case:

1. Create a test case in Primero using clearly fictional data (name: “TEST CASE - DO NOT ACTION”, all fields marked as test data)
2. Initiate a referral to a partner organisation’s test environment
3. Confirm the referral appears in the partner’s incoming queue
4. Have the partner accept the referral
5. Verify acknowledgement is received by referring system within expected timeframe
6. Delete test data from both systems

Test offline referral capability:

1. Enable airplane mode on a field device running the Primero mobile application
2. Create a test referral offline
3. Verify the referral is stored in the encrypted local queue (Settings > Sync Status should show “1 pending referral”)
4. Restore connectivity
5. Verify automatic synchronisation occurs within the configured retry interval
6. Confirm the referral appears in the central system with offline approval chain intact

Test encrypted email fallback:

# Send test encrypted message to partner
echo "TEST REFERRAL - Please confirm receipt and delete" | \
  gpg --encrypt --armor --recipient partner-referrals@example.org | \
  mail -s "[ENCRYPTED] Test Referral" partner-referrals@example.org

# Partner should confirm:
# - Message received
# - Decryption successful
# - Content readable

Verify audit logging captures referral events:

# Query Primero audit log for referral events
sudo -u primero psql primero_production -c "
  SELECT created_at, user_name, action, record_type, record_id
  FROM audit_logs
  WHERE record_type = 'Referral'
  AND created_at > NOW() - INTERVAL '24 hours'
  ORDER BY created_at DESC
  LIMIT 20;"

# Expected: entries for referral creation, transmission, acknowledgement

Troubleshooting

For issues not resolved by this table, collect diagnostic information before escalating:

# Collect Primero logs for the past hour
sudo journalctl -u primero --since "1 hour ago" > primero-logs.txt

# Export referral-specific errors
sudo -u primero psql primero_production -c "
  SELECT * FROM sync_errors
  WHERE error_type LIKE '%referral%'
  AND created_at > NOW() - INTERVAL '24 hours';" > referral-errors.csv

# Test network path to partner
traceroute partner-referral.example.org > network-path.txt

Provide these files to your IT support team or Primero support channel.

See also

• Protection Data Principles
• Safeguarding Case Management Security
• Consent in Humanitarian Contexts
• Encryption Standards
• Data Classification