A generated summary's structured result, as a JSON string, on the Composition that files it.
THE CARRIER IS WRONG, AND THIS GUIDE SAYS SO ELSEWHERE IN THE SAME RELEASE. It should be an
Attachment with contentType = application/json, not a valueString. The composition-block
payload extension states the rule plainly: "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."
Every word of that applies here. This payload is opaque by design -- its keys are the producing
capability's own and are explicitly not specified below -- so a consumer that does not recognise the
summary kind cannot tell a JSON object from a sentence, and nothing in the element says which it is.
Attachment answers that without saying anything about the contents: contentType declares the
envelope, data carries the bytes, and language and creation are there if ever wanted.
One release, one question, two answers. The other one is right, and it was argued at length forty
lines away from this file.
Transitional. It carries no fact the summary's own narrative and its nexus-attributed-fact
citations do not also carry. It exists because this guide does not yet specify a structured read
model for a generated summary, and it is withdrawn once one is declared. A new consumer should read
section.text -- which is complete on its own -- and the per-claim citation trail on the summary's
Provenance, and should reach for this only where a field-by-field structured view is needed today.
The object's shape is not specified here. Its keys are the summary type's own fields, they
differ between summary kinds, and they move with the producing capability rather than with this
guide. Parse defensively, tolerate unknown keys, and fall back to the narrative when the value is
missing or unparsable rather than failing.
It is not an AI-attribution signal. Whether a machine produced the content is the AIAST
security label in meta.security; which graph produced it is the logical Device on author.
Presence or absence of this extension says nothing about either.
Readers should expect two canonicals. This publishes under this guide's base; Nexus EMR writes
it today at https://nexus.awaremd.com/summary-id/StructureDefinition/summary-payload (FHIR-377),
an address this specification does not publish. It is live in stored Composition.extension values
and in code, and is under migration to the canonical declared here. Match both addresses exactly.
The two do not share a final segment, so a suffix rule does not reach the pre-migration one and a
reader built on it misses every summary written before the writer moves.
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.
The summary's structured result, as a JSON object serialized to a string
Definition
The producing capability's own summary object, serialized as JSON. Keys are the summary type's own fields and are not specified by this guide. Not base64, not a pointer -- the JSON text itself.