Composition Block Data Extension

Canonical	../StructureDefinition/composition-block-data
Status	draft · 1.26.0
Base	Extension (constraint)
Context	Composition.section (element)
Source	FSH · JSON

One section's structured value, for a render kind whose value is more than the narrative beside it.

Overview

An Attachment, whose contentType says what the payload is -- typically application/json -- because the shape belongs to the render kind rather than to this specification and R4 has no element typed for it. This is the section's own structured value, NOT its structured clinical content: Composition.section.entry is that, and the two are expected to coexist on one section.

REACH FOR SDC FIRST. Where a render kind is really a FORM -- a screening instrument, an intake questionnaire -- the modelled answer already exists and is not this extension: a Questionnaire plus a QuestionnaireResponse, which is the problem SDC was written to solve and which gets you section.entry for free.

The test is what the block's values ARE, not how the block looks. A block whose values are answers to its own questions is a form, and belongs in SDC however plain it renders. A block that writes each value to the chart record that owns it as the value is recorded -- an Observation, a vital, a Procedure -- is not a form however form-like it renders: those values are clinical facts in the record already, and what the block stores here is that visit's account of them. Use this extension for a payload that is genuinely a render kind's own state and not a set of answers to questions.

Why an Attachment and not a bare string. A JSON string in a valueString is self-describing to nobody: a reader cannot tell what it holds without recognising the render kind first, and no published international IG carries editor state that way. Attachment is what R4 already provides for an opaque payload, and contentType makes the envelope readable even where the contents are not. A text section needs none of this at all.

The narrative is authoritative for reading. A consumer that has never heard of the render kind renders section.text and is not missing clinical content, so nothing a reader needs may live only in here. A value that cannot be parsed reads as no structured value rather than as an error: one malformed section must not put a whole clinical document out of reach. Unreadable is not absent -- a writer that cannot parse a stored value must round-trip it untouched rather than drop it.

FIRST PASS. The canonical is settled on the same terms as composition-block-type. One design question is not: whether a render kind's structured value belongs in an extension at all, or in Composition.section.entry, which this guide already nominates as a section's structured counterpart. They hold different things today, for the reasons given above. The evidence that would settle it is a render kind that promotes its own facts to entry on save -- a vitals block is the obvious first -- because that is the case where the two would genuinely overlap.