Referral response tracker for access teams

Nothing here is clinical advice, and nothing here should touch identifiable patient information.

Build one reviewed tracker from each incoming referral batch. This gives referral coordinators and patient access managers a consistent queue for chasing missing details, assigning work and meeting local response targets. It is administrative work only, not clinical advice or a way to determine care priority.

Keep identifiable patient information out of the material sent to the model. Use an internal referral ID, and keep the link between that ID and the patient record inside your approved clinical or administrative system.

1. Set the tracker fields before processing referrals

Create one shared tracker in the approved system your access team already uses. Do this before you paste any referral content into a prompt. A fixed structure prevents each coordinator from recording a different version of the same issue.

Use these columns:

Tracker field	What to record	Rule
Referral ID	Internal non-identifying reference	Never use name, date of birth, address or contact details in the prompt.
Received	Date and time received	Copy from the source item.
Referral source	Source type or organisation category	Use a local category list where possible.
Service requested	Service or pathway named in the referral	Copy the stated request. Do not interpret it.
Missing information	Each missing administrative item	Name the missing item precisely.
Priority flag	Priority wording stated by the sender	Record the wording and source. Do not assign a priority.
Next contact	The party to contact and the requested item	For example, referring office: signed order.
Owner	Named team member or role	Assign one owner only.
Response deadline	Date and time for the next action	Apply your local service rule.
Review status	needs review, ready to send, or complete	Only a staff member changes this after checking.

Write down the local rules for owners and deadlines beside the tracker. For example, decide which role owns missing authorisation details, incomplete demographic fields, unclear contact routes and duplicate referrals. Do not ask the model to invent these rules.

2. Prepare a safe referral batch

Work in small batches that your team can review in one sitting. For each referral, make a short administrative extract. Replace patient identifiers with the referral ID before using the model.

Include only what is needed to route work:

• referral ID
• received timestamp
• stated service request
• referral source category
• list of documents or fields present
• list of documents or fields mentioned but absent
• sender's stated priority wording, if any
• existing contact route category, such as referring office portal
• any local deadline category already assigned

Do not include free-text clinical histories, attachment contents, names, phone numbers, email addresses, dates of birth, addresses, account numbers or record numbers. If a call note combines operational and clinical detail, create a short operational extract yourself rather than pasting the note.

3. Ask for rows, not a narrative

Use one reusable prompt. It should force the model to distinguish what is stated from what is missing. Paste only the prepared batch after the instructions.

Use this prompt:

Convert the administrative referral extracts below into a review queue.

For each referral ID, return one row with these fields:
Referral ID | received | referral source | service requested | missing information | priority flag and exact source wording | next contact | owner role | deadline category | review status

Rules:
- Use only facts in the extract.
- Do not infer diagnoses, urgency, eligibility, insurance status or patient preference.
- If a required item is not stated as present, write "confirm whether present" rather than saying it is missing.
- Preserve sender priority wording exactly and label it "sender-stated".
- Suggest an owner role only from this list: intake coordinator, referral coordinator, authorisation team, scheduling team, access manager.
- Use the supplied local deadline category. If none is supplied, write "deadline needs local rule".
- Set every row to "needs review".
- Return a Markdown table only.

Local completeness requirements:
[paste your approved list of required administrative items]

Administrative referral extracts:
[paste de-identified extracts]

Replace the completeness list with the requirements for that specific service. Keep the list operational. Examples include a signed referral document, a required order, a valid return contact route or an authorisation reference where your process requires one.

The model you are using may format tables or accept input differently across approved setups. If behaviour differs, check the xAI documentation overview for current, version-dependent guidance.

4. Review the queue against the source material

Do not import the output straight into the tracker. First, compare each row with its original referral in your approved system. Review all referrals with a sender-stated priority label, all rows marked incomplete and any row where the model wrote confirm whether present.

Then sample the remaining rows. A practical check is to have a second coordinator review a rotating portion of the batch, especially after changing the prompt or completeness list.

Check these points:

• The referral ID matches the correct source item.
• Every listed missing item is actually absent or unconfirmed.
• The priority wording is copied, not rewritten as a clinical judgement.
• The next contact names the right party and asks for a specific item.
• The owner matches the local role rules.
• The deadline follows the local rule and has not been invented.

5. Publish the reviewed work queue

After review, copy confirmed rows into the shared tracker. Set the status to ready to send only when the next contact, owner and deadline are complete. Keep needs review for ambiguous referrals rather than forcing a decision.

At the start of each shift, filter the tracker by:

1. response deadline, earliest first
2. sender-stated priority flags requiring the established escalation route
3. owner
4. missing information type

At the end of the shift, update only the fields that changed: contact attempted, information received, owner reassigned, deadline revised under local rules, or referral completed. This leaves a usable handover queue rather than a one-off summary.

When the queue does not work

If rows contain invented details, shorten the extract and strengthen the prompt rule that facts must be stated. If different coordinators assign different owners, fix the owner-role rules beside the tracker, not the prompt alone. If the queue is too large to review, reduce the batch size and process the oldest deadline group first.

If you cannot safely create a non-identifying administrative extract, do not send that referral to the model. Process it within your approved internal workflow instead. When the output is unclear, leave the row as needs review, assign it to the access manager and resolve it from the source record.