ChartSync — follow-up note generation

ChartSync lets a clinician carry context from one note into the next. Instead of regenerating a note purely from a transcript, you provide a source note that Nabla then updates and completes based on what was discussed during the encounter rather than starting from a blank page. This source note should include the relevant sections of either an in-progress draft or the patient's last signed note.

This is the same workflow a clinician does manually during a follow-up visit: open the previous assessment, review what has changed, and edit the plan accordingly. ChartSync expresses that workflow as a structured API input.

When to use it

A typical signal that ChartSync applies: the provider has something written before the encounter starts that they want preserved, refined, or built upon.

• Follow-up encounter: the provider wants the previous visit's Assessment & Plan to be used as the baseline.
• Pre-populated draft: the provider has typed a few bullets ahead of the visit (chief complaint, current thinking) and wants Nabla to expand on those in the new note.

Anatomy of a source note

ChartSync relies on two concepts to work: the source note and the semantic section kinds.

1. The source note: where the text came from

A source_note has a type field describing its provenance:

type	Meaning
DRAFT	The provider's in-progress note for the current encounter (e.g. pre-visit notes, typed live).
LAST_SIGNED	The patient's most recent signed note from a previous encounter.

The type indicates to the note generation process how to use the source note in combination with the transcript. A DRAFT is generally treated as authoritative provider intent for this visit while a LAST_SIGNED is historical context that the transcript may explicitly override.

2. Semantic section kinds: what each piece of text means

A source note is a list of sections, each tagged with a kind that names its clinical role. Which is independent of which Nabla template used to generate the note.

{
  "kind": "ASSESSMENT_AND_PLAN",
  "text": "..."
}

The kind is intentionally decoupled from the template's section. A SOAP note's "Assessment" + "Plan" pair and a merged "Assessment & Plan" section both carry the same semantic content, so the API exposes one semantic kind (ASSESSMENT_AND_PLAN) that can flow into either layout. Over time, more kinds will be added — keep your client tolerant to new enum values.

Why this split matters

A clinician thinks "I want to bring last visit's A&P forward". That sentence has both pieces: the source (last visit) and the content kind (A&P). The API mirrors that split so each can evolve independently — new source types (e.g. notes from another EHR) won't disturb section kinds, and new section kinds won't disturb source types.

Integrating ChartSync

Sending a source note

ChartSync rides on the existing generate-note endpoints. The source note is added to the existing structured_context:

POST /v1/core/server/generate-note
{
  "audio": "...",
  "note_template_key": "GENERIC_MULTIPLE_SECTIONS_AP_MERGED",
  "structured_context": {
    "source_note": {
      "type": "LAST_SIGNED",
      "sections": [
        {
          "kind": "ASSESSMENT_AND_PLAN",
          "text": "1. Type 2 diabetes — A1c trending down on metformin 500mg BID. Continue current regimen.\n2. Hypertension — well controlled on lisinopril 10mg daily."
        }
      ]
    }
  }
}

The same shape applies on the User API (POST /v1/core/user/generate-note) and on the async variants.

Discovering which kinds a template accepts

Not every template can receive a source note today, and the set of supported kinds will grow over time. Rather than hard-coding assumptions, discover support at runtime via the template introspection endpoint:

GET /v1/core/server/generate-note/templates/{template_key}?locale={note_locale}
GET /v1/core/user/note-settings/templates/{template_key}                       # User API

The template detail response now carries supported_source_note_section_kinds:

{
  "key": "GENERIC_MULTIPLE_SECTIONS_AP_MERGED",
  "title": "...",
  "description": "...",
  "sections": [...],
  "supported_source_note_section_kinds": ["ASSESSMENT_AND_PLAN"]
}

• An empty list means the template does not currently support follow-up generation — don't send a source_note with this template.
• A non-empty list is the allow-list of kind values you may send for this template.

Putting it together, a typical client flow looks like:

1. Fetch the template detail once (cache it per template + locale).
2. For each kind you want to send in source_note.sections, confirm the template's supported_source_note_section_kinds includes it.
3. Send the generate-note request.

Frequently Asked Questions

What is the difference between source_note and current_note?

These two inputs solve different problems and can be used independently.

• source_note carries clinical context forward — an in-progress draft or the patient's last signed note — so the generated note builds on prior clinical reasoning.
• current_note carries a Nabla note already generated in this same session, so that when the clinician has manually edited the note and then resumes the encounter you can extend it with new transcript_items instead of discarding those edits and regenerating from the full transcript.

In short: source_note is about what the clinician knew before the visit; current_note is about preserving manual edits when you resume a generation you already started.