One section's structured value, for a render kind whose value is more than the narrative
beside it.
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.
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 render kind's own structured value, as a typed attachment
Definition
The section's own structured value. contentType says what the payload is -- application/json for a kind carrying a JSON object -- so the envelope is readable even where the contents are not described here. Readers that do not recognise the render kind ignore this element and render the section narrative instead; a reader that cannot PARSE it must still write it back unchanged, because unreadable and absent are different facts.
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.
What the payload is; application/json for a JSON kind
Definition
Identifies the type of the data in the attachment and allows a method to be chosen to interpret or render the data. Includes mime type parameters such as charset where appropriate.
Requirements
Processors of the data need to be able to know how to interpret the data.
If both data and url are provided, the url SHALL point to the same content as the data contains. Urls may be relative references or may reference transient locations such as a wrapping envelope using cid: though this has ramifications for using signatures. Relative URLs are interpreted relative to the service url, like a resource reference, rather than relative to the resource itself. If a URL is provided, it SHALL resolve to actual data.
The calculated hash of the data using SHA-1. Represented using base64.
Requirements
Included so that applications can verify that the contents of a location have not changed due to technical failures (e.g., storage rot, transport glitch, incorrect version).
Comments
The hash is calculated on the data prior to base64 encoding, if the data is based64 encoded. The hash is not intended to support digital signatures. Where protection against malicious threats a digital signature should be considered, see Provenance.signature for mechanism to protect a resource with a digital signature.