case-context-ledger

name

case-context-ledger

description

Create or update a durable elder-care case context ledger for long-running Medicare, Medicaid, SNF, facility, payer, and regulatory matters. Use when the user says "case memory", "case context", "update the case file", "track deadlines", "remember this for the appeal", "build a case ledger", or needs canonical facts, contacts, deadlines, document inventory, evidence register, open questions, and decision log across multiple skills and large record productions.

Case Context Ledger

Maintain a local, structured case-context folder that every other skill can read before drafting, reviewing records, or preparing filings. This is the plugin's durable memory layer: canonical facts live in files under the user's case folder, not in chat history.

Use this skill whenever a matter will span multiple sessions, agencies, documents, or appeal rounds — especially 500+ page SNF chart reviews where the key facts are distributed across PDFs, findings files, emails, and deadlines.

When to invoke

• The user asks to create, update, or summarize a case file / case memory / case ledger.
• New events occur: payer determination, facility call, JFS/ODM letter, new HIPAA production, regulatory complaint, attorney consult, deadline change.
• Another skill is about to draft or review and needs canonical facts loaded first.
• A large chart review is starting and the reviewer prompt needs case background without re-asking the user every time.

Outputs

Create or update a folder named case-context/ under the user's selected case workspace unless the user specifies another location.

Minimum files:

• case_profile.md — stable identifiers, POA block, facility/payer/JFS contacts, stay window, active posture.
• deadlines.md — appeal, document-hold, Medicaid, records-request, complaint, and consult deadlines.
• document_index.md — records productions, document maps, payer letters, JFS/ODM letters, facility correspondence, complaints, appeal drafts.
• evidence_register.md — cited facts with source file + page, tag, confidence, and downstream use.
• issue_log.md — active issues grouped by Medicare appeal, Medicaid, discharge planning, quality, billing, records access, legal referral.
• open_questions.md — factual gaps and who/what can close them.
• decision_log.md — major choices made, rationale, and date.

Use references/case_context_template.md for the exact structure.

Inputs to collect

Ask only for missing facts needed for the requested update. Do not interview the user exhaustively if a partial update is enough.

1. Case workspace — where to create or update case-context/.
2. Update type — profile, deadline, document, evidence, issue, question, decision, or summary.
3. Source material — user narrative, file path, email text, finding citation, agency letter, or log entry.
4. Sensitivity / privilege — whether the material is privileged, attorney-client, attorney work product, or should be excluded from shareable packets.
5. Downstream use — appeal, Medicaid letter, state complaint, legal referral, admin log, or human-only note.

Update rules

1. Read the existing ledger files before editing so facts remain consistent.
2. Preserve exact dates, names, case numbers, and citations. If uncertain, mark [uncertain] rather than guessing.
3. Every evidence-register entry must have a source: filename + page, email/date, log entry date, or agency letter date.
4. Every deadline entry must include: deadline, owner, source, consequence of missing it, and next action.
5. Do not overwrite prior facts silently. If a fact changes, add a dated correction note and preserve the earlier source.
6. Mark privileged or attorney-sourced material explicitly so later skills do not accidentally include it in complaints or public filings.
7. Use tags consistently with snf-records-review: APPEAL, LTC-DISPUTE, MEDICAID, QUALITY, TIMELINE. Add administrative tags as needed: RECORDS, BILLING, LEGAL, DEADLINE, CONTACT.

Recommended workflow with other skills

1. Run case-context-ledger first to create case-context/ and capture the case profile.
2. Run snf-inventory and snf-document-map on new HIPAA productions; add inventory_summary.json, document_map.md, OCR limitations, and expected-document statuses to document_index.md.
3. Run snf-review and add value-3 findings to evidence_register.md.
4. Add not_found and indeterminate_ocr document-map items to open_questions.md with the document or remediation action that can close each question.
5. Use admin-interaction-log for new communications, then mirror strategic facts into issue_log.md or evidence_register.md.
6. Before snf-appeal-supplement, state-agency-complaint, medicaid-caseworker-correspondence, or legal-referral-intake-packet, read case_profile.md, deadlines.md, evidence_register.md, and open_questions.md.

Chat-summary conventions

After updating the ledger, summarize only non-sensitive metadata in chat:

• Files updated.
• New deadlines added or changed.
• Evidence entries added by tag count.
• Open questions that need user input.

Do not paste PHI-heavy ledger contents into chat unless the user explicitly asks.

Guardrails

• This is a case-management aid, not medical or legal advice.
• Keep PHI in the user's local case folder. Do not sync case-context folders to public repositories.
• If the user plans to share a packet externally, distinguish source evidence from strategy notes and privilege-marked content.
• If a fact is important enough to affect a filing, require a source citation before treating it as canonical.
• If a conflict appears between two sources, keep both and create an open_questions.md entry rather than resolving it by assumption.