LearnGrokNothing here is clinical advice, and nothing here should touch identifiable patient information.
Use this workflow to turn a referral, supporting documentation and payer requirements into a submission-ready checklist and draft narrative. It is for referral coordinators and revenue-cycle teams who need a consistent administrative pack, while keeping identifiable patient information out of the model.
The result is not a clinical decision and does not determine whether a service is appropriate. A qualified clinician and authorised staff member must confirm the record, apply local policy and submit through the approved payer route.
Stop
Keep patient data out
Do not paste names, dates of birth, member IDs, addresses, phone numbers, account numbers, full dates, scanned documents or unredacted clinical notes into the model. Work only from a de-identified fact sheet.
1. Start a fresh submission worksheet
Create one worksheet for each requested service. Use your approved local system for the source records and final submission. In a separate, de-identified working document, create these fields:
- Request ID: your internal non-identifying reference
- Payer and plan type: payer name and relevant product or network
- Requested service: plain-language service description
- Service code fields: placeholders or approved non-identifying code references
- Ordering role: for example, referring clinician or department, without a name
- Site of service: care setting, if required
- Requested timing: routine, urgent, or another payer-defined category
- Documentation available: referral, clinical note type, test result type, prior treatment summary, or other supporting item
- Payer requirements source: policy title, portal checklist, form name, and access date held in your local record
- Missing items: facts or documents not yet confirmed
Replace every person-specific value with a label such as [PATIENT], [MEMBER ID], [DOB], [CLINICIAN] and [DATE]. If a clinical fact is unusual enough to identify someone in your context, generalise it or leave it out of the model prompt.
Key point
Build from fields, not documents
The model should receive a de-identified fact sheet and payer requirements, not referral attachments or clinical notes.
2. Separate payer rules from case facts
Read the payer policy or portal instructions in your approved environment. Record only the operational requirements needed to assemble the pack. Examples include whether the payer asks for a form, service codes, records for a stated period, a signed order, site-of-service detail, or a named contact route.
Do not ask the model to infer a requirement from a diagnosis, treatment history or clinical guideline. If the payer policy is unclear, mark the requirement as UNCONFIRMED and route it to the payer portal, contract contact or internal escalation path.
Then make two short lists in the worksheet:
| List | Include | Do not include |
|---|---|---|
| Payer requirements | Required fields, attachments, form sections, submission channel | Assumptions about what the payer might accept |
| Case facts | De-identified facts already supported by the local record | Clinical interpretation, guessed dates or invented history |
This separation prevents a common failure: a tidy narrative that appears complete but quietly fills gaps with assumptions.
3. Ask for a pack structure before drafting
Give the model the two lists and ask it to organise, not decide. Use a prompt like this:
Create a prior-authorisation submission pack from the information below.
Rules:
- Use only the supplied facts.
- Keep all placeholders exactly as written.
- Do not infer clinical facts, eligibility, coverage, urgency or medical necessity.
- For each payer requirement, mark it as PRESENT, MISSING, or UNCONFIRMED.
- Put unsupported statements under NEEDS CONFIRMATION.
- Draft an administrative cover note, an attachment checklist, and a field-by-field completion checklist.
PAYER REQUIREMENTS:
[paste de-identified requirements]
CASE FACTS:
[paste de-identified fact sheet]
Ask for these sections in this order:
- Submission summary: payer, request type, requested service and placeholders for required identifiers.
- Requirement map: each payer requirement, the evidence item that supports it, and its status.
- Attachment register: document type, local file label, whether it is required, and whether it is present.
- Draft cover note: a neutral administrative note that points the reviewer to the attached record. It must not add clinical reasoning.
- Staff completion checklist: fields to enter in the payer portal or form, plus unresolved items.
Note
Treat the draft as a work product
The draft can organise evidence and expose gaps. It cannot verify the source record, payer eligibility, provider status or submission outcome.
4. Draft only from supported wording
Review the draft cover note against the local record. Keep it factual and traceable. A safe pattern is: “Supporting documentation is attached for review. The attached referral and records address the items listed in the payer requirements.”
Remove statements such as “meets criteria”, “medically necessary”, “approved indication” or “urgent” unless an authorised person has supplied that exact approved wording through your local process. The model must not supply clinical justification or make a coverage determination.
For each statement in the pack, staff should be able to answer two questions:
- Which local document supports this?
- Which payer requirement makes it necessary?
If either answer is missing, move the statement to NEEDS CONFIRMATION or delete it.
5. Run the two-pass check
Do not submit after one read. First check completeness, then check fidelity.
Pass one, completeness: Compare the requirement map with the payer policy or portal. Confirm every required field, form, signature, attachment and routing detail has a status. MISSING and UNCONFIRMED are not submission-ready statuses.
Pass two, fidelity: Open each source item in the approved system. Compare it line by line with the corresponding pack entry. Check service description, code placeholders, requested setting, ordering information, document labels and any timing language. Replace placeholders only inside the approved local system, never in the model conversation.
Check
The pack is ready only when every requirement is traceable
Each required item must be marked PRESENT, linked to a local source document and checked by the staff member responsible for submission.
How to spot a wrong output
A polished pack can still be unsafe or unusable. Stop and correct it if you see any of these signs:
| What you see | Why it is wrong | What to do |
|---|---|---|
| A fact not present in your worksheet | The model has inferred or invented it | Delete it, then add a source-backed fact only if authorised |
| A claim that criteria are met | This is a clinical or coverage conclusion | Replace it with a neutral reference to attached documentation |
| A requirement marked PRESENT without an attachment | The map is not traceable | Change it to MISSING and obtain or confirm the item |
| Patient-specific text in the prompt or output | Identifiable information has entered the working draft | Stop using that draft, follow your organisation’s privacy process and restart with de-identified facts |
| A confident answer to an unclear payer rule | Payer requirements may vary | Confirm it through the current payer materials or internal escalation route |
Payer processes and model behaviour are version-dependent. Check the current xAI documentation overview before relying on a workflow feature or handling guidance that may have changed.
When the workflow does not work
If the draft is too generic, give it clearer payer requirements and document labels, not more patient detail. If it invents facts, shorten the prompt and repeat the rule that unsupported statements must go under NEEDS CONFIRMATION. If a payer requirement is ambiguous, do not ask the model to settle it. Pause the pack, confirm the rule through your approved channel, update the worksheet and run the two-pass check again.
