Summary Payload Extension¶
| Canonical | ../StructureDefinition/nexus-summary-payload |
|---|---|
| Status | draft · 1.26.0 |
| Base | Extension (constraint) |
| Context | Composition (element) |
| Source | FSH · JSON |
A generated summary's structured result, as a JSON string, on the Composition that files it.
Overview
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.