Case Note to Plan Conversion

Case notes capture what happened. A case plan captures what comes next: goals, services, frequency, responsible parties, and review dates. In many nonprofit programs those two artifacts live in the same client record, often in a system like Vera Solutions, but they are written at different times and in different shapes.

Unstructured notes from a home visit, a school meeting, or a crisis call rarely map cleanly onto the plan fields a funder or supervisor expects. Conversion is the slow part of documentation: read the note, pull out goals, propose services, fill dates. It is also where details drop. A housing barrier mentioned in paragraph three never becomes an objective.

This use case is a draft step, not a decision step. An LLM reads consented case notes and produces a structured case plan draft. You still set goals, choose services, and sign off. The speed gain is the time you no longer spend copying narrative into plan fields.

If the notes are missing, too short to support a plan, or not consented for this use, the system should return empty output rather than guess.

A usable draft looks like the plan object your program already uses, not a second narrative. Map to the fields staff already edit:

• Client and episode identifiers already on the record. Do not invent IDs.
• Goal statements tied to needs the notes actually state.
• Objectives that are observable enough to review later.
• Proposed services or interventions, with suggested frequency only when the notes support it.
• Barriers and strengths the notes name.
• A suggested review date only if program cadence is configured. Otherwise leave it blank.
• Source pointers: which note date or excerpt supports each goal.

Leave fields blank when the notes do not support them. A blank service line is better than a generic "connect to resources" line that nobody requested.

Do not treat the model as a clinician of record. It does not diagnose, authorize services, or change eligibility. It rearranges language you already wrote into the shape of a plan.

Match the program's voice. If the note says "behind on rent," the goal should not become "achieve housing stability" unless that phrasing is how your plan taxonomy is defined and you map to it on purpose. Prefer the client's words where they are specific enough to stand as an objective.

When a current plan already exists, the draft should be a revision, not a replacement. Carry forward open goals the notes do not contradict. Mark proposed closures only when the notes say the work is done or the need no longer applies. Show the change against the prior plan so review is a diff, not a reread of the whole document.

The practical trigger is "note saved" or "plan due," not a free-standing chat window.

After you file a contact note in Vera Solutions or a similar case management system, a job or a button can pull that note, a short window of prior notes, the current plan if one exists, and the program's plan schema: required fields, goal categories, service catalog codes. The model fills a draft against that schema. You open the plan editor with the draft pre-loaded, edit, and save the way you save any plan revision.

For periodic reviews, run the same pattern on a packet: recent notes, the live plan, and attendance or outcome fields only if those fields are in scope for planning. The draft then proposes updates (close a met objective, add a barrier, adjust frequency) instead of a first-time plan.

Keep context tight. Dumping the entire case history invites the model to revive old goals that are no longer active. Prefer the current episode, the last few contacts, and the live plan.

Do not block note save on draft generation. Staff should be able to file the note and walk away. The draft can land in a queue or on the plan record as draft status. If generation fails, the note remains the source of truth.

This conversion starts after a case exists and notes exist. Intake Request Triage decides who gets a case opened; it does not write the plan. At-Risk Client Early Warning may flag that contacts dropped or that a plan is stale. Conversion is how you catch the plan up once you have written what you observed.

Empty output is a success condition. Design for it.

Return empty output, with a machine-readable reason the UI can show, when:

• No case notes exist for the episode, or the selected note IDs resolve to nothing.
• Combined note text is too short to support goals or services: a timestamp-only check-in, a one-line "left voicemail," or a no-show with no discussion of needs.
• Consent or program policy does not cover using these notes for automated plan drafting. Examples include a missing consent flag, a restricted note type, a legal or clinical lock, or a youth record under a tighter rule.
• The note is in a language or format the pipeline does not process, and no translation path is configured.
• The current plan is locked pending supervisory approval and a new draft would create a conflicting version.

Do not fill gaps with typical services for the program. A housing program will always be tempted to add rental assistance. A behavioral health program will always be tempted to add counseling. If it is not in the notes or the existing plan, it does not belong in the draft.

Log the empty reason so operations can see whether empty is mostly consent, mostly thin notes, or mostly missing data. Do not write a placeholder plan into the client record.

The case manager owns the plan. The model produces a draft you can reject in full.

You confirm or rewrite every goal. You pick services from the catalog your agency actually delivers or refers to, including waitlists and eligibility the model cannot see. You set or clear dates. You sign off the same way you sign any plan today: a status field, a supervisor workflow, or a client signature packet.

Supervisors should review these drafts the same way they review human-written plans: alignment with the note, over-promising, and missing safety items. If a note mentions intimate partner violence and the draft omits safety planning, that is a review miss. It is not a reason to let the model invent a safety plan from a template unless your protocol attaches one and a human still confirms it.

Client-facing language still goes through you. A plan printed for a family meeting should not contain model hedging ("it appears the client may benefit") unless that is how you already write. Strip speculation before the client sees it.

Do not auto-save the draft as the official plan. Persist it as draft state, show diffs against the prior plan, and require an explicit save.

Once a plan is signed, downstream documents should read the plan, not re-summarize raw notes from scratch. Agentic Referral Letter Generation is the usual next hop: a referral that quotes goals and services you already approved, rather than a second interpretation of the same visit note.

Keep identifiers stable across note, plan, and letter so the audit trail stays intact. When a referral is generated, it should cite the plan version you signed, not the discarded draft.

If you measure this work, measure time from note save to a signed plan, and the share of drafts that staff accept with light edits versus discard. Do not treat a model's completeness score as outcome data. A complete draft is not the same as a plan the client and funder can live with.