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, and a content field carrying the section's body. Which kind you use is independent of which Nabla template used to generate the note.

{
  "kind": "ASSESSMENT_AND_PLAN",
  "content": {
    "type": "TEXT",
    "text": "..."
  }
}

Before 2026-08-25, sections used a flat top-level text field instead of content. Starting with 2026-08-25, content is required and text is no longer accepted.

The kind is intentionally decoupled from the template's section.

Use the kind that matches how the source note stores the content, not how the target template lays it out:

kind	Use it when the source note...
ASSESSMENT_AND_PLAN	keeps the assessment and the plan together in a single section.
ASSESSMENT	keeps the assessment in its own section (e.g. a SOAP "Assessment" section).
PLAN	keeps the plan in its own section (e.g. a SOAP "Plan" section).

Which of these a given template accepts is exposed by supported_source_note_section_kinds on the template detail endpoints (see Discovering which kinds a template accepts below). Over time, more kinds will be added — keep your client tolerant to new enum values.

Sending structured A&P subsections

If you already hold the previous note's Assessment & Plan broken down by problem — for example because you fetched it as content.type: "SUBSECTIONS" from a prior generate-note response (see the Assessment & Plan guide) — you can send that structure directly instead of flattening it to text:

{
  "kind": "ASSESSMENT_AND_PLAN",
  "content": {
    "type": "SUBSECTIONS",
    "subsections": [
      {
        "id": "5a1e...",
        "title": "Type 2 diabetes",
        "text": "A1c trending down on metformin 500mg BID. Continue current regimen."
      },
      {
        "id": "9f42...",
        "title": "Hypertension",
        "text": "Well controlled on lisinopril 10mg daily."
      }
    ]
  }
}

This tells Nabla the per-problem structure is already known, so it doesn't need to be re-derived — the follow-up generator can start from the given problems directly. SUBSECTIONS content is only meaningful on the ASSESSMENT_AND_PLAN kind; sending it on any other kind returns 400 BAD_REQUEST.

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",
          "content": {
            "type": "TEXT",
            "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.