How to render this section -- the section's RENDER KIND, not the tool that produced it.
A code from note-block-types, bound extensible: where this specification names a kind, use
its code; where an editor ships a kind the guide has not named yet, a code outside the set is
conformant. Written on every structured section, whatever its kind -- no kind is a default
that may be left implied, and none has standing the others do not.
A section carrying NO such extension predates it, and is read as text. That is what lets every note
filed before block authoring existed -- four-section SOAP notes among them -- open with no migration.
It is tolerance for legacy data rather than a default new data may rely on, so the branch is
retirable once no untyped section remains.
A kind you do not recognise must be kept, not rewritten. A client whose vocabulary is behind the
writer's has no widget for such a section and renders it as text -- correct, because the narrative is
authoritative. It MUST still write the unrecognised code back unchanged. Rendering as text is a
display decision; storing text in its place is data loss, and leaves the record asserting that
a specialised block was prose. No binding can enforce this, which is why it is stated here.
FIRST PASS. This extension arrived with its first consumer rather than from a modelling pass,
and block authoring is expected to grow around it: kinds join note-block-types as they ship, and
the surface may widen as it does. The canonical is settled and will not be renamed. It moved to
this guide's base before the first note carrying it was filed, which was the only moment that move
was free; published canonical URLs are forever. What may still change is what the vocabulary holds,
not where this extension lives.
May be used to represent additional information that is not part of the basic definition of the element. To make the use of extensions safe and manageable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer can define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension.
Comments
There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone.
Source of the definition for the extension code - a logical name or a URL.
Comments
The definition may point directly to a computable or human-readable definition of the extensibility codes, or it may be a logical URI as declared in some other specification. The definition SHALL be a URI for the Structure Definition defining the extension.
How to render this section; absent only on sections predating this extension
Definition
The section's render kind, from note-block-types. It says HOW a consumer should render the section, not which tool produced it -- section.author answers that, and an editor widget, a letter template and a generated summary can all produce the same render kind. Written on every structured section, text included. Absent means the section was written before this extension existed and is read as text -- a legacy concession, not a default.