DNA follow-up list for service recovery

You are checking a de-identified missed-appointment extract for administrative data quality. Do not provide clinical advice, infer health needs, or request names, addresses, dates of birth, contact details, or any other identifiable patient information.

Review the records below. Each record should contain: case ID, appointment ID, service, appointment date, appointment type, attendance outcome, cancellation timestamp, DNA recorded timestamp, previous DNA count within the local policy period, contact attempt count, latest contact outcome, rebooking status, interpreter or communication flag where recorded, safeguarding or vulnerability flag where recorded, and policy reference.

Identify only administrative data issues. Do not fill gaps by assumption. Treat blank, unclear, conflicting, or invalid values as `Needs verification`.

Return two Markdown tables:

1. `Record issues`
Columns: case ID, appointment ID, field with issue, issue found, effect on follow-up decision, required source to check.

2. `Extract summary`
Columns: check, count, affected case IDs, action before classification.
Include checks for duplicate appointment IDs, missing outcome, inconsistent cancellation and DNA status, missing previous-DNA count, missing policy reference, and missing rebooking status.

End with a short section titled `Safe to classify` listing only the appointment IDs with no decision-blocking issue. Do not classify records into contact, rebook, or escalation lists yet.

[Paste de-identified missed-appointment records here]

You are creating an administrative follow-up decision list from de-identified missed-appointment records. Apply only the local non-attendance policy supplied below. Do not provide clinical advice, judge urgency, infer risk, or make a decision that is not explicitly supported by the policy or the record. Do not request or include identifiable patient information.

For every appointment record, assign exactly one primary route:
- `Contact`: the policy requires or permits an administrative contact attempt before further action.
- `Rebook`: the policy permits rebooking or placing the appointment in a rebooking workflow.
- `Escalate`: the policy requires review by the named local role, team, or pathway.
- `Needs verification`: a required field, policy condition, or policy reference is missing, unclear, or contradictory.

A record may have a secondary action, but never use a secondary action to replace the primary route. If the policy allows more than one route and gives no order, choose `Needs verification` and explain the conflict. Quote the relevant policy section or rule reference exactly as supplied. Do not invent a policy rule.

Return one Markdown table titled `DNA follow-up decision list`.
Columns: case ID, appointment ID, service, appointment date, primary route, secondary action, policy rule or section, evidence from record, owner role, target timescale stated in policy, decision confidence, verification needed.

After the table, return a `Totals` bullet list with the number of records in each primary route. Then return `Unresolved policy questions` as a numbered list. Include only questions that block a decision.

Local non-attendance policy:
[Paste the relevant current policy text, decision tree, and local owner roles here]

De-identified missed-appointment records:
[Paste checked records here]

Create an administrative contact worklist from the de-identified records below. This is not clinical advice. Do not write a clinical assessment, infer why an appointment was missed, recommend a care action, or include identifiable patient information.

Include only records where `primary route` is `Contact`. Follow the supplied local non-attendance policy exactly. If a permitted contact method, contact-attempt limit, wording requirement, or target timescale is absent or unclear, write `Needs verification` rather than guessing.

Return one Markdown table titled `Contact worklist`.
Columns: priority order, case ID, appointment ID, service, policy rule or section, required administrative action, approved contact channel if specified, contact attempt number, target completion date or policy timescale, owner role, standard outcome to record, status, blocker.

Use `Do not contact until verified` in the status column where the record or policy does not clearly authorise the planned action. Sort first by policy timescale, then by appointment date, then by case ID. Do not create message text unless the policy text explicitly requires it.

End with a section titled `Before sending work` containing:
- records with missing contact authorisation or method
- records at or beyond the policy contact-attempt limit
- records whose policy route conflicts with the supplied decision list

Local non-attendance policy:
[Paste relevant policy text here]

De-identified Contact records from the decision list:
[Paste records here]

Prepare a de-identified administrative rebooking queue from the records below. Apply only the supplied local non-attendance policy. This is not clinical advice: do not select a clinical priority, change a pathway, or infer whether an appointment is needed. Do not include or request identifiable patient information.

Include only records where `primary route` is `Rebook`. Preserve the service, appointment type, and any policy-approved rebooking condition exactly as recorded. If the policy does not state whether rebooking is permitted, what appointment type to use, who must approve it, or the applicable timescale, classify the row as `Needs verification`.

Return one Markdown table titled `Rebooking queue`.
Columns: queue order, case ID, appointment ID, service, original appointment type, policy rule or section, rebooking action, approval required from, policy timescale, booking constraint stated in record or policy, owner role, queue status, verification needed.

Allowed queue statuses are: `Ready for booking`, `Awaiting approval`, `Needs verification`, and `Do not rebook pending escalation`. Do not invent dates, appointment slots, specialties, or patient preferences. Sort `Ready for booking` records by policy timescale, then original appointment date.

End with `Queue controls`, a bullet list covering duplicate bookings to check, records with an existing rebooking status, and records blocked by missing approval.

Local non-attendance policy:
[Paste relevant policy text here]

De-identified Rebook records from the decision list:
[Paste records here]

Build an administrative escalation register from the de-identified records below. Apply only the local non-attendance policy provided. This is not clinical advice. Do not assess clinical risk, state that a person is safe or unsafe, or recommend a clinical intervention. Do not include identifiable patient information.

Include records where `primary route` is `Escalate` or `Needs verification`. Escalate only to the owner, team, or pathway named in the policy or supplied record. If neither names an owner, state `Escalation owner not specified, verify locally`. Do not substitute a role based on assumption.

Return one Markdown table titled `Escalation register`.
Columns: escalation order, case ID, appointment ID, service, escalation reason, triggering record field or policy rule, required decision, policy-named owner, policy timescale, information missing, interim administrative status, escalation status.

Allowed interim administrative statuses are: `Awaiting policy decision`, `Awaiting data correction`, `Awaiting named owner review`, and `Action prohibited pending review`. Sort by stated policy timescale. If no timescale is stated, place the record after timed cases and mark it `Needs local timescale`.

Then return `Escalation handover notes` as a numbered list. Each item must contain the case ID, the exact decision needed, and the specific evidence available. Keep each item to two sentences or fewer.

Local non-attendance policy:
[Paste relevant policy text here]

De-identified Escalate and Needs verification records:
[Paste records here]

Reconcile the de-identified missed-appointment source list against the Contact worklist, Rebooking queue, Escalation register, and master decision list below. This is an administrative completeness check only. Do not provide clinical advice, infer missing information, or include identifiable patient information.

Match records using appointment ID first and case ID second. Each source appointment must have exactly one primary route in the master decision list: `Contact`, `Rebook`, `Escalate`, or `Needs verification`. A record may appear in an operational list only if that list matches its primary route, except that `Needs verification` records may appear in the Escalation register.

Return three Markdown tables:

1. `Reconciliation exceptions`
Columns: appointment ID, case ID, exception type, source route, list where found, likely cause, action required, owner role.

2. `Route totals`
Columns: route, source count, operational-list count, difference, pass or fail.

3. `Distribution-ready lists`
Columns: list name, included appointment IDs, excluded appointment IDs, reason for exclusion, release status.

Use only these release statuses: `Ready to distribute`, `Hold for correction`, and `Hold for policy review`. End with a single line in this format: `Overall release status: [status]`. Set it to `Ready to distribute` only if there are no unmatched records, duplicate primary routes, route mismatches, or unresolved decision-blocking fields.

De-identified source missed-appointment list:
[Paste source records here]

Master decision list:
[Paste decision list here]

Contact worklist:
[Paste contact worklist here]

Rebooking queue:
[Paste rebooking queue here]

Escalation register:
[Paste escalation register here]