Prepare a medical-record request follow-up list
Get the source data and prepare the review

Documentation-checked proposed route; source collection and human approval required

WHAT WAS CHECKED
Official documentation checked; all routes are proposed and have not been run in a product account. No client data, account access, installs or account writes used. Native column names are distinguished from editorial kit contracts. Missing source evidence blocks completeness claims.

BEFORE YOU START
- Clio Manage Personal Injury add-on with maintained provider request cards, or actual approved request letters and response log available locally.
- Administrative follow-up policy and explicit staff-approved follow-up dates; no patient identifiers or clinical facts in the AI tables.
- Firm-approved Excel; optional Copilot entitlement and tenant approval for the exact minimized data. Native Excel analysis can be done manually if Copilot is absent.
- Keep raw exports and identifying source pointers in a separate restricted location. The AI workbook contains only approved alias-based tables and visible policy/scope text, never raw client records on another tab.

DATA ACQUISITION LIMITS
- The Personal Injury add-on is plan-dependent. Its provider cards track request dates/status/follow-up, but this research does not verify a request-status CSV export or an AI query for the kit schema.
- Cards are staff-maintained and may be stale; last_response_date and paused require actual response/pause records. A Received label does not establish medical completeness.

DECLARED INPUT CONTRACT
request-status.csv: request_id, public_provider_id, sent_date, last_response_date, status, staff_approved_followup_date, paused
followup-policy.txt

STEP 1: Read the actual administrative request state
Tool: Clio Manage Personal Injury, or local source records
Open: Matters > selected matter > Medical Records > provider card
Access needed: See prerequisites; actual subscription, tenant configuration and permissions are untested.

Read the request date, recorded request status and follow-up date separately for records and bills. Use the provider card’s existing details if needed without saving changes. Check the latest actual response and any pause instruction locally. If the add-on is absent, read the sent request letter, receipt acknowledgment and maintained follow-up log directly; do not assume another CRM can export them.

Expected output: One verified administrative record per request type, with source evidence. Exclude treatment dates, diagnoses and record contents.
Use it next: Assign non-identifying request_id and public_provider_id; keep client/matter lookup restricted.
Check: Do not treat the card’s default Not yet requested as proof if the actual letter shows otherwise; flag contradictions.
Documentation limit: Official sources support named product features. Workflow-specific prompts, alias fields, mappings and reviewer rules are editorial adaptations, not native export promises.
Source documentation:
https://help.clio.com/hc/en-us/articles/15815962459931-Medical-Records

STEP 2: Map the observed records to the starter input
Tool: Excel and authorized staff
Open: Separate analysis workbook > Home > Format as Table
Access needed: See prerequisites; actual subscription, tenant configuration and permissions are untested.

Create request-status.csv with request_id,public_provider_id,sent_date,last_response_date,status,staff_approved_followup_date,paused. Separate records and bills into different request IDs where they have different histories. Copy followup-policy.txt into Policy; specify the review date/timezone in Scope. Unknown response/pause evidence remains unknown. Create named tables for RequestStatus. Put the policy and review scope in visible worksheets or paste them into the next prompt.

Expected output: Reviewed administrative RequestStatus table plus Policy and Scope.
Use it next: Check the mapping against each original source before using AI.
Check: Aliases and missing policy fields are staff-created; do not relabel a native export as the kit schema. Unknown stays blank/unknown, not false or zero.
Documentation limit: Official sources support named product features. Workflow-specific prompts, alias fields, mappings and reviewer rules are editorial adaptations, not native export promises.
Source documentation:
https://support.microsoft.com/en-us/excel/tutorial-import-data-into-excel-and-create-a-data-model

STEP 3: Review the bounded evidence with Copilot
Tool: Excel Copilot, optional
Open: Approved analysis workbook > Copilot icon at lower right > Chat only
Access needed: See prerequisites; actual subscription, tenant configuration and permissions are untested.

Use Chat only and submit the prompt. Without Copilot: filter actual approved dates/statuses and apply the policy row by row.

PASTE THIS PROMPT
Apply Policy to RequestStatus at the supplied review date. Return request_id, public_provider_id, observed status, approved follow-up date, pause status, recommended_review_action and evidence rows. Separate due, not yet due, paused, received, incomplete and unknown. Do not invent dates or use treatment information. Draft a neutral administrative follow-up only for a staff-approved due request with no unresolved pause/status issue. Do not include patient identity, send a message or decide record sufficiency.

Expected output: Administrative follow-up queue and safe draft placeholders.
Use it next: Copy the draft exception list to the reviewer; retain row references.
Check: Check every flagged row and the scope. A fluent answer is not evidence of completeness; no automatic workbook or source-system edits.
Documentation limit: Official sources support named product features. Workflow-specific prompts, alias fields, mappings and reviewer rules are editorial adaptations, not native export promises.
Source documentation:
https://support.microsoft.com/en-us/excel/copilot/get-started-with-copilot-in-excel
https://support.microsoft.com/en-us/excel/copilot/frequently-asked-questions-about-copilot-in-excel

STEP 4: Approve the review result
Tool: Responsible staff reviewer
Open: Reviewed local worksheet
Access needed: See prerequisites; actual subscription, tenant configuration and permissions are untested.

Records staff verify each candidate against the sent request and latest response, then the responsible lawyer approves any unresolved status. Any provider message is prepared and sent separately through the approved secure channel.

Expected output: Reviewed follow-up list with blocked/unknown requests visible.
Use it next: Any external message, source change, payment or deletion requires its own authorized process.
Check: Never infer no response from a missing log entry, or use an AI draft as authority to request more medical data.
Documentation limit: Editorial human-review gate; linked Excel documentation supports the worksheet used, not legal or accounting conclusions.
Source documentation:
https://support.microsoft.com/en-us/excel/tutorial-import-data-into-excel-and-create-a-data-model

ACCOUNT AND SOURCE CHECKS STILL NEEDED
- Actual account access, plan and source-data completeness have not been tested.

USING THE FILES IN THIS KIT
Use the exact files or source text named in the steps above. Native exports keep their own headers. The kit tables are editorial review worksheets; they are not a claim that a product exports those fields. Some routes use reviewed text directly or require additional original files. Never rename an unreviewed raw export to make it appear mapped. Keep expected-result files separate from inputs.

The source account, actual data, prompts and end-to-end workflow were not tested. Any final communication, filing, permission change, payment or publication needs its own authorized human action. This guide performs none.