Note Block Type CodeSystem Code system¶
| Canonical | ../CodeSystem/note-block-type |
|---|---|
| Status | draft · 1.26.0 |
| Content | complete |
| Source | FSH · JSON |
The render kinds a structured note, letter or summary section can declare.
The note body is an ordered stack of independent blocks, one Composition.section each; these
codes say how a consumer should RENDER a given section. They describe the display surface
rather than a clinical concept, which is why they are minted here rather than drawn from LOINC.
Content is complete: this system lists all of its own codes. The binding from the block-type
extension is extensible, so a kind this guide has not named yet is still conformant -- but where
a kind IS named here, that is the code to use. A section carrying no kind at all predates the
extension and is read as text -- tolerance for data written before block authoring existed, not a
default, and a section written today always declares its own kind.
A reader that meets a kind it does not know renders it as text and writes the code back
unchanged. Storing text in its place loses the fact that a specialised block wrote that section.
Every kind in this system is equal. text shipped first and carries no standing the others do
not have; a consumer that special-cases text and treats the rest as exceptions has the dispatch
backwards.
A kind is named here once some stream composes the block, and not in anticipation. Kinds for blocks
nothing composes -- vitals, flowsheet -- are deliberately absent, and the extensible binding
means the day one ships it is conformant before this list catches up.
Not every named kind is stamped on the wire yet. The note editor declares the kind on every
section it writes, so text, heading-1, heading-2 and fields-diabetes arrive coded.
merge-field-body, cited-claims and enclosures are published ahead of that: the streams that
compose those blocks file their sections without declaring the kind, so read them by their other
markers as well -- the enclosures section by its LOINC 28562-7 code, a cited summary by the
citation trail on its Provenance, a merge-field body by the letter that holds it. An absent code
does not mean a section is none of these.
| Code | Display | Definition |
|---|---|---|
text |
Text | A plain rich-text block -- a run of narrative the author typed. Its stored value is the markup itself, in the section's narrative, with no structured value beside it. The first bl… |
heading-1 |
Heading 1 | A first-level heading: one line of plain text naming the run of the note beneath it. It is a section in its own right, not a property of the section that follows -- so it moves, i… |
heading-2 |
Heading 2 | A second-level heading -- a run named inside a run. Identical to heading-1 in every other respect: one line of plain text, its own section, narrative only. The note carries two … |
merge-field-body |
Merge-field body | A letter body composed from a stored template by resolving its merge fields against the patient, provider and clinic. The section's narrative is the finished prose; the render kin… |
cited-claims |
Cited claims | A body whose every claim is backed by a citation to the source it was drawn from -- the shape the summary graphs emit, under a generation contract that refuses to state a fact it … |
enclosures |
Enclosures | A block whose content is what TRAVELS WITH the document rather than part of it: one reference to an attachment packet (a List profiled as NexusAttachmentPacket) holding the char… |
fields-diabetes |
Diabetes review | The diabetes care elements a visit reviewed and recorded: each entry naming the element, the value or attestation recorded against it, who recorded it and when. Only what the visi… |