# 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[​](#when-to-use-it "Direct link to 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[​](#anatomy-of-a-source-note "Direct link to 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*[​](#1-the-source-note-where-the-text-came-from "Direct link to 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*[​](#2-semantic-section-kinds-what-each-piece-of-text-means "Direct link to 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[​](#why-this-split-matters "Direct link to 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[​](#integrating-chartsync "Direct link to Integrating ChartSync") ### Sending a source note[​](#sending-a-source-note "Direct link to 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[​](#discovering-which-kinds-a-template-accepts "Direct link to 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[​](#frequently-asked-questions "Direct link to Frequently Asked Questions") ### What is the difference between `source_note` and `current_note`?[​](#what-is-the-difference-between-source_note-and-current_note "Direct link to 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*.