{
  "resourceType": "CodeSystem",
  "status": "draft",
  "content": "complete",
  "name": "NoteBlockTypeCS",
  "id": "note-block-type",
  "title": "Note Block Type CodeSystem",
  "description": "The render kinds a structured note, letter or summary section can declare.\n\nThe note body is an ordered stack of independent blocks, one `Composition.section` each; these\ncodes say how a consumer should RENDER a given section. They describe the display surface\nrather than a clinical concept, which is why they are minted here rather than drawn from LOINC.\n\nContent is `complete`: this system lists all of its own codes. The binding from the block-type\nextension is **extensible**, so a kind this guide has not named yet is still conformant -- but where\na kind IS named here, that is the code to use. A section carrying no kind at all predates the\nextension and is read as `text` -- tolerance for data written before block authoring existed, not a\ndefault, and a section written today always declares its own kind.\n\n**A reader that meets a kind it does not know renders it as text and writes the code back\nunchanged.** Storing `text` in its place loses the fact that a specialised block wrote that section.\n\nEvery kind in this system is equal. `text` shipped first and carries no standing the others do\nnot have; a consumer that special-cases `text` and treats the rest as exceptions has the dispatch\nbackwards.\n\nA kind is named here once some stream composes the block, and not in anticipation. Kinds for blocks\nnothing composes -- `vitals`, `flowsheet` -- are deliberately absent, and the extensible binding\nmeans the day one ships it is conformant before this list catches up.\n\n**Not every named kind is stamped on the wire yet.** The note editor declares the kind on every\nsection it writes, so `text`, `heading-1`, `heading-2` and `fields-diabetes` arrive coded.\n`merge-field-body`, `cited-claims` and `enclosures` are published ahead of that: the streams that\ncompose those blocks file their sections without declaring the kind, so read them by their other\nmarkers as well -- the enclosures section by its LOINC `28562-7` code, a cited summary by the\ncitation trail on its Provenance, a merge-field body by the letter that holds it. An absent code\ndoes not mean a section is none of these.",
  "url": "https://fhir.apps.health/CodeSystem/note-block-type",
  "concept": [
    {
      "code": "text",
      "display": "Text",
      "definition": "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 block kind to ship, and the kind an untyped legacy section is read as."
    },
    {
      "code": "heading-1",
      "display": "Heading 1",
      "definition": "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, is deleted and is read on its own terms, and the section order carries the outline. The narrative is the heading element itself, so a reader that does not know this kind still renders the words as a heading; only the block's independence is lost. There is no structured value beside it."
    },
    {
      "code": "heading-2",
      "display": "Heading 2",
      "definition": "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 heading levels rather than six because it renders inside a chart page whose outline it must not outrank."
    },
    {
      "code": "merge-field-body",
      "display": "Merge-field body",
      "definition": "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 kind says it was FILLED rather than typed, which is what lets a consumer offer to re-render it against current data or show which runs came from the record. The unresolved prototype held on a letter template carries this same kind: it is the same body before resolution, not a different sort of block."
    },
    {
      "code": "cited-claims",
      "display": "Cited claims",
      "definition": "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 cannot cite. The render kind is an instruction to a consumer that knows it: surface the backing, do not render the claims as bare prose. The trail itself is on the accompanying Provenance (`nexus-attributed-fact`), because it records what the generating activity read; this code says only that the body was built to be checked against it. A reader that does not know this kind renders the narrative and loses nothing clinically -- the claims are still there, only unverifiable in place."
    },
    {
      "code": "enclosures",
      "display": "Enclosures",
      "definition": "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 chart items assembled to be sent alongside. The section carries no prose of its own -- what a reader wants is the membership and its order, which live on the packet. Rendering it means rendering the packet's entries; a consumer that does not know this kind renders the section as text and loses only the layout, because the narrative names the members. Coded LOINC 28562-7 at the section level."
    },
    {
      "code": "fields-diabetes",
      "display": "Diabetes review",
      "definition": "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 visit touched enters the block -- it shows what is due and records what was done, rather than restating the chart. The condition is part of the code, because a note template names a block by kind and cannot parameterise one; another condition is another code. The values themselves are written to the chart records that own them (Observations, vitals, Procedures) as they are recorded, so the block's structured value is this visit's account of them rather than the record of them. A reader that does not know this kind renders the narrative, which names every element and value recorded."
    }
  ],
  "experimental": false,
  "caseSensitive": true,
  "count": 7
}