Composition Note Setup Extension¶
| Canonical | ../StructureDefinition/composition-note-setup |
|---|---|
| Status | draft · 1.26.0 |
| Base | Extension (constraint) |
| Context | Composition (element) |
| Source | FSH · JSON |
The editor setup an encounter note was opened on: the visit type the provider chose, and the template the note started from. Present so that a draft reopens on the footing it was left on rather than as a blank note.
Overview
Both parts or neither. A reader that finds only one of the two has no usable setup -- a template without its visit type cannot be offered again, and a visit type without its template does not say what the note started as -- so both sub-extensions are required when the extension is present. The extension itself is optional and is absent on notes written before it existed.
It records what the note was OPENED FROM, not what it contains. A provider may switch templates
mid-note, delete every heading the template gave, or type their own. The authoritative structure of
a note is always Composition.section; this element is editor state, and a consumer reconstructing
the note's content from the template code rather than from the sections will be wrong.
The two vocabularies are separate systems, and the template one is NOT the stored template
registry. encounter-note-template names the fixed catalogue of note structures compiled into the
application. CodeSystem/nexus-template is a different value space -- the per-tenant slugs of
template List resources, which a letter carries on meta.tag to say which stored template it was
composed from. Both are kebab-case slugs and they are not interchangeable.
Both bindings are extensible, deliberately. Each set is closed in the application today, but a required binding would make this guide a release gate on the note editor: ship a template and every note carrying one is nonconformant until the guide cuts a release. A reader that meets an unrecognised code MUST write it back unchanged; normalising it destroys the record of what the provider actually started from.
FIRST PASS. This extension is declared from its production shape rather than from a modelling pass. See the file comment for the canonical it publishes under and why that is not the URL the software writes today.
MIGRATION. Nexus EMR writes this extension today at
http://services.well.com/fhir/StructureDefinition/composition-note-setup. That address is live in
stored notes and in code, and is under migration to the canonical declared here (FHIR-370). Write
the canonical; when reading, match on the URL suffix composition-note-setup so that notes filed
under either address are seen.
Terminology bindings
| Path | Strength | Value set |
|---|---|---|
Extension.extension.value[x] |
extensible | Encounter Visit Types |
Extension.extension.value[x] |
extensible | Encounter Note Templates |