Referral

Referrals

Pre-read

Organization scope Practitioner scope

Idea in brief

This feature allows Practitioners to refer patients to other facilities — i.e. from one Primary Healthcare Center (PHC) to another. It enables patients to access facilities that are better equipped to treat them.

Agni is designed for PHCs. We plan to support two types of referrals:

1. Within-system: Entities that exist within the ambit of Agni, i.e. another PHC.

2. Outside-system: Entities that exist outside the ambit of Agni — both public and private healthcare organizations.

Convention used: source and destination of referral

• Source: Where the referral originates from

• Destination: The one who receives the referral

Anatomy of a referral

What are the preconditions for a referral?

A referral requires an Encounter to take place. An Encounter is an interaction between a Practitioner and a Patient, with clinical intent. In Agni, the triggering Encounter can be a risk assessment, a consultation, or a procedure.

Hence, a patient cannot simply be diverted from the queue of one PHC to another. There must be a clinically meaningful interaction that drives the referral process.

What information should a referral contain?

A referral should carry the following information:

• Patient name and identifier

• Source practitioner name and identifier, and the organizational unit (i.e. PHC) with which the practitioner is affiliated at the time of generating the referral

• Destination name and identifier

• Date and time of the referral

• Content of the referral: why it is being made

• Context for the referral: relevant medical records

The following table shows how these information fields map to the two types of referral we introduced earlier.

Information field	within-system	outside-system
Patient	✅	✅
Source	✅	✅
Destination	✅	❌
Date-time	✅	✅
Content	✅	✅
Context	✅	❌

An outside-system referral is like an email without a recipient or attachments. Patients take the note to whomever they wish to consult, and they carry copies of their medical records with them.

The destination - practitioner or facility?

For within-system referrals, the destination is another facility, i.e. an org unit, not a practitioner. In government-run primary healthcare systems, physicians and nurses are transferred across facilities. Hence, targeting individual practitioners is not useful. Also, proximity is an important consideration for patients — and Location is a property of Organization, not Practitioner.

Referral workflow via FHIR

The remainder of this note shall focus on FHIR implementation for within-system referrals.

The FHIR homepage mentions "Referrals" within R4 > Workflow. However, this points to the ServiceRequest resource, which is designed for requests such as "a referral for a diagnostic test". The Task resource was also evaluated, but it is a state machine to handle workflow; it does not have the necessary data fields that referrals require.

Appointment resource: excellent fit for referrals

Finally, the Appointment 🔗 resource was examined, and found to be well-suited to our use case. The FHIR documentation states that:

Appointment resources are used to provide information about a planned meeting that may be in the future or past. Examples include... a follow-up for a clinical visit ...

Using the Appointment resource, a Practitioner can create a request for a future healthcare event in any Location. For referrals, the destination shall be a different facility (Location) — though we can easily grasp that the same method can be used to book a follow-up visit in the same facility.

Notable elements of the Appointment resource

Mandatory elements are marked with an asterisk (*).

• .status *: When a referral is created, this parameter shall be set to proposed. When the patient visit the destination facility and checks-in, this status is updated to arrived

• .description: the "subject line" of the referral

• .note: the "body" of the referral

• .participant*: Each referral must have at least one participant, and either the type or the actor shall be further specified. This is a FHIR constraint. In our implementation, we shall use this element to specify both the source and the destination, by providing two objects with both type and actor, as explained in the section below.

Participant element

1. Source object:

   • .participant.actor *: The source Practitioner. This element also accepts a Location or HealthcareService resource.

   • .participant.type: REF, for the person initiating the referral (i.e. the source). .type uses this valueset 🔗.

2. Destination object

   • .participant.actor *: The destination Location. This element also accepts a Practitioner or HealthcareService resource.

   • .participant.type: ATND, for the overseer at the destination. Participant types are defined with Practitioners in mind, but we shall use them even when .actor references a Location.

Data access

When a patient is referred to a different Location, users mapped to that Location shall have access to the patient's records. The data payload for the patient can be queued after the referral information.

Inputs for techdocs

• Section 12.14.5 🔗 describes status transitions in the appointment workflow. The techdoc for referral workflow implementation should utilize this section.

• The constraints that apply to the Appointment resource need to be kept in mind. For instance, when the Appointment.status element is proposed, it does not require a start or end time. However, once the status is updated to arrived, a start or end time is mandatory.

Limitation

A broader definition of referrals includes requests for follow-up from a PHC nurse or physician to a community health worker (CHW), or vice versa. However, CHW-PHC interactions are being kept out of the immediate scope of the system. It shall be introduced in consultation with Lattice's clients.