Nexus EMR profile for an AUTHORED clinical note -- principally the encounter note (progress
note, consult note, telephone note) written by an EMR user or drafted by an AI scribe and
attested by a clinician.
Elements / Details
Every element this profile touches, with its full definition. Element names in the tables link here.
An authored clinical note (encounter note, consult note, telephone note)
Definition
A clinical note authored in this EMR: its narrative, its lifecycle state, who wrote it, who
signed it, and the encounter it belongs to.
Contrast DocumentReference, which references a document that exists as a file. A Composition
IS the note; a DocumentReference POINTS AT one.
Comments
While the focus of this specification is on patient-specific clinical statements, this resource can also apply to other healthcare-related statements such as study protocol designs, healthcare invoices and other activities that are not necessarily patient-specific or clinical.
The metadata about the resource. This is content that is maintained by the infrastructure. Changes to the content might not always be associated with version changes to the resource.
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.
The version specific identifier, as it appears in the version portion of the URL. This value changes when the resource is created, updated, or deleted.
Comments
The server assigns this value, and ignores what the client specifies, except in the case that the server is imposing version integrity on updates/deletes.
When the resource last changed - e.g. when the version changed.
Comments
This value is always populated except when the resource is first being created. The server / resource manager sets this value; what a client provides is irrelevant. This is equivalent to the HTTP Last-Modified and SHOULD have the same value on a read interaction.
Identifies EMR instance & pipeline version the resource came from
Definition
A URI that identifies the EMR pipeline and version from which this resource originated. This tells you which EMR instance (recommend using the instance identifier), and the version of the pipeline code/transformations.
Comments
In the provenance resource, this corresponds to Provenance.entity.what[x]. The exact use of the source (and the implied Provenance.entity.role) is left to implementer discretion. Only one nominated source is allowed; for additional provenance details, a full Provenance resource should be used.
This element can be used to indicate where the current master source of a resource that has a canonical URL if the resource is no longer hosted at the canonical URL.
It is up to the server and/or other infrastructure of policy to determine whether/how these claims are verified and/or updated over time. The list of profile URLs is a set.
Security labels applied to this resource. These tags connect specific resources to the overall security policy and infrastructure.
Comments
The security labels can be updated without changing the stated version of the resource. The list of security labels is a set. Uniqueness is based the system/code, and version and display are ignored.
Tags applied to this resource. Tags are intended to be used to identify and relate resources to process and workflow, and applications are not required to consider the tags when interpreting the meaning of a resource.
Comments
The tags can be updated without changing the stated version of the resource. The list of tags is a set. Uniqueness is based the system/code, and version and display are ignored.
A set of rules under which this content was created
Definition
A reference to a set of rules that were followed when the resource was constructed, and which must be understood when processing the content. Often, this is a reference to an implementation guide that defines the special rules along with other profiles etc.
Comments
Asserting this rule set restricts the content to be only understood by a limited set of trading partners. This inherently limits the usefulness of the data in the long term. However, the existing health eco-system is highly fractured, and not yet ready to define, collect, and exchange data in a generally computable sense. Wherever possible, implementers and/or specification writers should avoid using this element. Often, when used, the URL is a reference to an implementation guide that defines these special rules as part of it's narrative along with other profiles, value sets, etc.
Cardinality
0..1
Type
uri
Modifier
yes — This element is labeled as a modifier because the implicit rules may provide additional knowledge about the resource that modifies it's meaning or interpretation
The base language in which the resource is written.
Comments
Language is provided to support indexing and accessibility (typically, services such as text to speech use the language tag). The html language tag in the narrative applies to the narrative. The language tag on the resource may be used to specify the language of other presentations generated from the data in the resource. Not all the content has to be in the base language. The Resource.language should not be assumed to apply to the narrative automatically. If a language is specified, it should it also be specified on the div element in the html (see rules in HTML5 for information about the relationship between xml:lang and the html lang attribute).
Resource-level narrative summarizing the note. Distinct from section.text, which is the note
CONTENT. For a single-section encounter note the two may be near-identical; where they differ,
section.text is authoritative for clinical content and this element is a summary.
Comments
Contained resources do not have narrative. Resources that are not contained SHOULD have a narrative. In some cases, a resource may only have text with little or no additional discrete data (as long as all minOccurs=1 elements are satisfied). This may be necessary for data from legacy systems where information is captured as a "text blob" or where text is additionally entered raw or narrated and encoded information is added later.
These resources do not have an independent existence apart from the resource that contains them - they cannot be identified independently, and nor can they have their own independent transaction scope.
Comments
This should never be done when the content can be identified properly, as once identification is lost, it is extremely difficult (and context dependent) to restore it again. Contained resources may have profiles and tags In their meta elements, but SHALL NOT have security labels.
May be used to represent additional information that is not part of the basic definition of the resource. 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.
May be used to represent additional information that is not part of the basic definition of the resource and that modifies the understanding of the element that contains it and/or the understanding of the containing element's descendants. Usually modifier elements provide negation or qualification. 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 is allowed to define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension. Applications processing a resource are required to check for modifier extensions.
Modifier extensions SHALL NOT change the meaning of any elements on Resource or DomainResource (including cannot change the meaning of modifierExtension itself).
Requirements
Modifier extensions allow for extensions that cannot be safely ignored to be clearly distinguished from the vast majority of extensions which can be safely ignored. This promotes interoperability by eliminating the need for implementers to prohibit the presence of extensions. For further information, see the definition of modifier extensions.
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.
Cardinality
0..*
Type
Extension
Modifier
yes — Modifier extensions are expected to modify the meaning or interpretation of the resource that contains them
Business identifier for the document -- stable across amendments
Definition
The source-system identifier for this document.
OPTIONAL (0..1), RELAXED FROM 1..1 IN 1.19.0. It was required when this profile modelled a single
document kind -- the encounter note, which is the unit source EMRs key on and the gateway must map
onto (OSCAR casemgmt_note), and an unidentified note cannot be reconciled across a sync boundary.
That case is still real and is still the reason to populate this element. What changed is the
population: the profile now holds three document kinds, and a document born here with no external
record to reconcile against has no identifier to carry. The server-assigned id already answers
"which document is this", and forcing a writer to mint a business identifier yields a meaningless
value that LOOKS like a key into something -- worse than absence. Letters shipped in exactly that
shape, off-profile, because the requirement could not be met honestly.
WHEN TO POPULATE IT -- stated rather than enforced, because the obligation differs by population:
* A document synced from, or reconciled to, a source system SHOULD carry that system's identifier.
This is the encounter-note case the element was written for and it has not weakened.
* A generated summary MUST carry its harness business key under
NamingSystem/nexus-harness-key. That key is what makes the summary update IN PLACE instead of
minting a second resource on every run; without it, regeneration silently duplicates.
* A document that originated here and answers to neither case MAY omit it entirely.
WHICH identifier to put here: R4 gives Composition exactly ONE identifier slot, so where the
document came from a source system, that source identifier SHOULD be the one carried -- it is the
more useful of the two, being the only handle that reconciles back to the originating EMR.
Where the document originated here and has no source identifier, omit it: no canonical system is
mandated, and a document with a single free slot is better left empty than filled with an
identifier that reconciles to nothing.
Unlike the repeating-identifier profiles in this IG, there is no invariant enforcing a
preference, because with a single slot such an invariant would forbid rather than recommend.
STABLE ACROSS AMENDMENTS. This identifies the document, not the version of it. Amending a signed
note produces a new version of the same resource with the same identifier -- see status.
ONE SLOT, SO NO SECOND IDENTIFIER. Earlier text here invited implementers to carry a source 'raw
code' as an ADDITIONAL identifier, which the repeating-identifier profiles in this IG can do and
this one cannot: Composition.identifier is singular in R4. Where both a source identifier and a
raw code exist, the identifier above wins the slot and the raw code is not carried here.
Comments
Similar to ClinicalDocument/setId in CDA. See discussion in resource definition for how these relate.
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.
A coded type for the identifier that can be used to determine which identifier to use for a specific purpose.
Requirements
Allows users to make use of identifiers when the identifier system is not known.
Comments
This element deals only with general categories of identifiers. It SHOULD not be used for codes that correspond 1..1 with the Identifier.system. Some identifiers may fall into multiple categories due to common usage. Where the system is known, a type is unnecessary because the type is always part of the system definition. However systems often need to handle identifiers where the system is not known. There is not a 1:1 relationship between type and system, since many different systems have the same type.
Establishes the namespace for the value - that is, a URL that describes a set values that are unique.
Requirements
There are many sets of identifiers. To perform matching of two identifiers, we need to know what set we're dealing with. The system identifies a particular set of unique identifiers.
The portion of the identifier typically relevant to the user and which is unique within the context of the system.
Comments
If the value is a full URI, then the system SHALL be urn:ietf:rfc:3986. The value's primary purpose is computational mapping. As a result, it may be normalized for comparison purposes (e.g. removing non-significant whitespace, dashes, etc.) A value formatted for human display can be conveyed using the Rendered Value extension. Identifier.value is to be treated as case sensitive unless knowledge of the Identifier.system allows the processer to be confident that non-case-sensitive processing is safe.
The Identifier.assigner may omit the .reference element and only contain a .display element reflecting the name or other textual information about the assigning organization.
preliminary (draft) | final (signed) | amended (edited after signing) | entered-in-error
Definition
The note's lifecycle state. This is the element that answers "is this note a draft or is it
signed?" -- there is no extension for it and none should be created.
| Note state | status |
|-----------------------------|---------------------|
| draft, being typed | preliminary |
| signed | final |
| signed, then edited | amended |
| voided / created in error | entered-in-error |
AMENDMENTS ARE VERSION HISTORY, NOT NEW RESOURCES. When a signed note is edited, update THIS
resource in place and set status to amended. The server's version history preserves the
as-signed content. Do NOT create a second Composition and relate it back -- that leaves two
resources where the chart must know to display one, and every consumer must learn to filter.
relatesTo is deliberately left unprofiled. It stays available in core R4 if a true ADDENDUM
workflow later appears -- original untouched, new signed content appended, with its own author
and sign-off date -- which is a genuinely different clinical act from an in-place correction.
It is not the mechanism for ordinary amendment.
⚠ IMPLEMENTER WARNING -- this model depends on infrastructure this IG has not yet declared.
Version history is server-local: _history does not travel in bundles, $everything, or sync
pipelines, all of which move current versions only. Across a system boundary, an amended note
arrives as its amended text with the as-signed content absent. Furthermore this IG currently
publishes NO CapabilityStatement, so no versioning policy or supported-interaction set is
declared anywhere, and meta.versionId is type id -- server-opaque in R4 and unconstrained
here. Consumers MUST NOT infer ordering, authorship, or "which version was signed" by parsing
or sorting versionId. Reconstructing the as-signed note is, today, only reliable on the
authoring server. Declaring the version-history contract is tracked as outstanding IG work and
is a prerequisite for relying on this model across boundaries.
Requirements
Need to be able to mark interim, amended, or withdrawn compositions or documents.
Comments
If a composition is marked as withdrawn, the compositions/documents in the series, or data from the composition or document series, should never be displayed to a user without being clearly marked as untrustworthy. The flag "entered-in-error" is why this element is labeled as a modifier of other elements.
Some reporting work flows require that the original narrative of a final document never be altered; instead, only new narrative can be added. The composition resource has no explicit status for explicitly noting whether this business rule is in effect. This would be handled by an extension if required.
Cardinality
1..1
Type
code
Must Support
yes
Modifier
yes — This element is labelled as a modifier because it is a status element that contains status entered-in-error which means that the resource should not be treated as valid
What kind of document this is: note, summary or letter
Definition
What kind of document this is, at the coarsest useful level: an authored note, a generated
summary, or a letter. Three codes, and this element carries exactly one of them.
This is the element to switch on, and the element to search. It is 1..1, so it is always
present, and its vocabulary is small and closed enough that a consumer can branch on it exhaustively.
A surface that renders Compositions decides here whether it is showing clinician-authored content or
machine-generated content -- and author will not answer that, because a scribe-drafted note and a
generated summary both carry a Device author. author says who wrote it; this element says what it
is.
| code | what it is |
|---|---|
| LOINC 34109-9 "Note" | a clinician-authored note |
| LOINC 34133-9 "Summary of episode note" | a generated summary, of any kind |
| LOINC 51852-2 "Letter" | a letter |
The finer question goes on category. Which kind of note (progress, consult, discharge,
history and physical), and which kind of summary (day-sheet, interval, encounter recap), are
refinements of what this element already says. They are repeating and open-ended, which is why they
belong on a 0..* element rather than this one. See category.
Converted data usually needs remapping here. In OSCAR, every casemgmt_note arrives with LOINC
11488-4 "Consult note" whatever the note actually is. That is a refinement code, not a class code: a
converter should write 34109-9 "Note" here and carry 11488-4 on category, rather than putting a
refinement in the class slot.
⚠ IMPLEMENTER WARNING -- an extensible binding is not silent in TypedFhir. A required binding
grades at ERROR; extensible and preferred both grade at WARNING; example is not checked. The
check fires only for a code OUTSIDE the bound set, so a document typed with something other than the
three codes above raises a validation warning. That is the intended signal here: the class axis is
small and this set enumerates it, so a code outside it is usually a refinement code in the wrong
slot. A warning is not a rejection -- extensible keeps a genuinely unclassifiable document
conformant.
Where this code was mapped from a source system's own vocabulary, carry the raw coding alongside the mapped one, flagged userSelected = true. See Carrying the raw code.
Requirements
Key metadata element describing the composition, used in searching/filtering.
Comments
For Composition type, LOINC is ubiquitous and strongly endorsed by HL7. Most implementation guides will require a specific LOINC code, or use LOINC as an extensible binding.
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.
A reference to a code defined by a terminology system.
Requirements
Allows for alternative encodings within a code system, and translations to other code systems.
Comments
Codes may be defined very casually in enumerations, or code lists, up to very formal definitions such as SNOMED CT - see the HL7 v3 Core Principles for more information. Ordering of codings is undefined and SHALL NOT be used to infer meaning. Generally, at most only one of the coding values will be labeled as UserSelected = true.
A human language representation of the concept as seen/selected/uttered by the user who entered the data and/or which represents the intended meaning of the user.
Requirements
The codes from the terminologies do not always capture the correct meaning with all the nuances of the human using them, or sometimes there is no appropriate code at all. In these cases, the text is used to capture the full meaning of the source.
Comments
Very often the text is the same as a displayName of one of the codings.
Refinements of the type: which kind of note, which kind of summary
Definition
The finer classification of a document, refining what type has already said at the class level.
Repeating and optional: a document may carry several refinements, or none.
Switch on type, not on this element.type is 1..1 and always present; category is 0..
and may legitimately be absent. A consumer keying off category alone will miss documents.
What belongs here:
- which kind of note -- LOINC 11506-3 "Progress note", 11488-4 "Consult note", 18842-5
"Discharge summary", 34117-2 "History and physical note"
- which kind of summary -- the codes in nexus-composition-type: a day-sheet summary written
ahead of a clinic, an interval summary covering the gap since the last visit, a recap of a single
encounter. LOINC has no concept for any of them, and they are not interchangeable
- a repeat of the type code, which is allowed: the bound value set contains all three class
codes precisely so the repeat validates
- administrative or workflow labels a source system carries that have no place on typeA refinement does not restate the class, it narrows it. A progress note is type = 34109-9
"Note" and category = 11506-3 "Progress note". A day-sheet summary is type = 34133-9 "Summary of
episode note" and category = nexus-daysheet-summary. Reading type alone always tells a
consumer which of the three populations it is holding; reading category tells it which kind
within that population, when the producer knew.
Bound preferred, deliberately weaker than the binding on type. LOINC's document axis is
large and this guide does not enumerate it. A producer holding a more precise code than the ones
listed should write it here and should not earn a warning for being more precise.
This profile and the DocumentReference profile differ on which element classifies, for a reason.*
That profile directs classification to category rather than type; this one puts the class on
type. The difference follows from the base cardinalities: DocumentReference.type is 0..1 and may
be absent, so category has to carry the load there. Composition.type is 1..1 and is always
present, so it carries it here.
Requirements
Helps humans to assess whether the composition is of interest when viewing an index of compositions or documents.
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.
A reference to a code defined by a terminology system.
Requirements
Allows for alternative encodings within a code system, and translations to other code systems.
Comments
Codes may be defined very casually in enumerations, or code lists, up to very formal definitions such as SNOMED CT - see the HL7 v3 Core Principles for more information. Ordering of codings is undefined and SHALL NOT be used to infer meaning. Generally, at most only one of the coding values will be labeled as UserSelected = true.
A human language representation of the concept as seen/selected/uttered by the user who entered the data and/or which represents the intended meaning of the user.
Requirements
The codes from the terminologies do not always capture the correct meaning with all the nuances of the human using them, or sometimes there is no appropriate code at all. In these cases, the text is used to capture the full meaning of the source.
Comments
Very often the text is the same as a displayName of one of the codings.
The patient this note documents. Required.
R4 permits any subject; this IG restricts to Patient, consistent with every other clinical
profile here. A note about something other than a patient has no home in this model.
Requirements
Essential metadata for searching for the composition. Identifies who and/or what the composition/document is about.
Comments
For clinical documents, this is usually the patient.
The clinical encounter this note belongs to. Optional in R4 and left optional here, because
notes legitimately exist outside an encounter (a telephone note taken before the visit is
booked, a chart correction, a note migrated from a source EMR whose encounter linkage was
never recorded).
Where the note documents a visit, populate it: it is what groups notes onto the encounter in
the chart and what lets the day sheet find them.
Requirements
Provides context for the composition and supports searching.
The composition editing time -- when the note was last logically changed.
Read the name carefully: this MOVES when the note is amended. It is not the authored date and it
is not the date the care happened. A timeline sorting notes by this element will re-position an
amended note to the date of its amendment.
Timing relationships on this profile:
- date: when this Composition was last edited (this element)
- event.period: when the documented CARE occurred -- the clinical date
- encounter: the visit the note belongs to, when there is one
Example. A progress note for an April 10 visit, written up the next morning and corrected a week
later:
- event.period.start: 2026-04-10 (the visit)
- date at first save: 2026-04-11
- date after the correction: 2026-04-18 -- and the visit is still April 10
Sort a clinical timeline by event.period.start, not by date.
This element is the FALLBACK arm of the profile's declared effective date, not the first one:
the declaration is event.period.start | date. A note that populates event dates to its care;
one that does not falls back to this element, which is a statement about resource metadata rather
than about clinical time. See the note on event above.
Requirements
dateTime is used for tracking, organizing versions and searching. Note that this is the time of authoring. When packaged in a document, Bundle.timestamp is the date of packaging.
Who is responsible for the note's content. Required and repeating: a note has at least one
author, and may have several.
Practitioner is the primary provider identity in this IG; PractitionerRole is permitted where
the clinic/role binding is part of what is being asserted (Practitioner has no organization
and so cannot express it).
AI-DRAFTED NOTES. A Device may appear as an author alongside the human. This is one of the two
mechanisms for recording that a note was scribed rather than typed; the other is a Provenance
record (NexusEmrCoreProvenance), which carries the fuller trail -- model, inputs, supervising
human. They are not exclusive and the IG does not yet rule on which consumers should read.
Absent a Device author, the origin is UNKNOWN, not "typed". Legacy notes migrated from OSCAR
Pro carry no origin information and must not be inferred to be human-typed.
AN AI AGENT AUTHOR IS A LOGICAL DEVICE REFERENCE. Reference.identifier under the
nexus-harness-graph NamingSystem names the harness graph that produced the text, with
Reference.type = "Device"; no Device resource need exist on this server, and the granularity
is the graph/feature level. This is the same mechanism NexusEmrCoreClinicalTask uses for
requester and owner, so an AI-scribed note and the review Task carrying it name their agent
identically.
That is also why author admits bare Device alongside the two profiled Device types: a
logical, identifier-only reference cannot conform to NexusEmrCoreAppDevice or
NexusEmrCoreEmrDevice, because conforming to a profile presupposes a resource that exists to be
validated against it. The profiled targets remain for a Device actually registered in this
store; the bare target is what an AI agent uses.
Requirements
Identifies who is responsible for the content.
Comments
A Practitioner, or a Device for AI-drafted content.
The note's label as shown in a chart list -- e.g. "Progress Note - 8 Apr 2025".
Mandatory in base R4, not by this profile. R4 makes title 1..1 on the reasoning that CDA left
it optional and no useful case for omitting it was known. A profile cannot relax a base cardinality,
so this element is required here whatever a primary care EMR would otherwise choose. Much of the
time there is no editorially meaningful title to write.
When there is no meaningful title, write the display name of the type coding, exactly. That is
the fallback R4's own guidance anticipates, and it is what downstream consumers expect to find. Do
not invent a label, and do not leave a placeholder string.
Renderers may suppress a title that duplicates the type. A consumer comparing title against
the display of Composition.type.coding and finding them equal may omit the title from its
presentation. The equality is the signal that no editorial title was authored.
Comments
For many compositions, the title is the same as the text or a display name of Composition.type (e.g. a "consultation" or "progress note"). Note that CDA does not make title mandatory, but there are no known cases where it is useful for title to be omitted, so it is mandatory here. Feedback on this requirement is welcome during the trial use period.
Confidentiality level, where the EMR distinguishes
Definition
The code specifying the level of confidentiality of the Composition.
Comments
The exact use of this element, and enforcement and issues related to highly sensitive documents are out of scope for the base specification, and delegated to implementation profiles (see security section). This element is labeled as a modifier because highly confidential documents must not be treated as if they are not.
Attestation -- the medico-legal signature.
REQUIRED ONCE SIGNED: a note with status of final or amended must carry an attester with
mode legal or professional (invariant composition-signed-has-attester). A signed note
with nobody identified as having signed it is not a record anyone can stand behind.
attester.time is when the signature happened -- distinct from date (last change) and from
the encounter's period (when care happened).
For AI-drafted notes, the attester is the CLINICIAN, never the Device. The Device may be an
author; it cannot attest. This asymmetry is the whole point of separating the two elements:
generation and responsibility are different acts.
Requirements
Identifies responsibility for the accuracy of the composition content.
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.
Extensions that cannot be ignored even if unrecognized
Definition
May be used to represent additional information that is not part of the basic definition of the element and that modifies the understanding of the element in which it is contained and/or the understanding of the containing element's descendants. Usually modifier elements provide negation or qualification. 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. Applications processing a resource are required to check for modifier extensions.
Modifier extensions SHALL NOT change the meaning of any elements on Resource or DomainResource (including cannot change the meaning of modifierExtension itself).
Requirements
Modifier extensions allow for extensions that cannot be safely ignored to be clearly distinguished from the vast majority of extensions which can be safely ignored. This promotes interoperability by eliminating the need for implementers to prohibit the presence of extensions. For further information, see the definition of modifier extensions.
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.
Cardinality
0..*
Type
Extension
Modifier
yes — Modifier extensions are expected to modify the meaning or interpretation of the element that contains them
The organization stewarding this note. Optional here (DocumentReference requires it) because an authored note's custodian is normally the clinic operating the EMR and is implied by tenancy.
Requirements
Identifies where to go to find the current version, where to report issues, etc.
Comments
This is useful when documents are derived from a composition - provides guidance for how to get the latest version of the document. This is optional because this is sometimes not known by the authoring system, and can be inferred by context. However, it is important that this information be known when working with a derived document, so providing a custodian is encouraged.
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.
Extensions that cannot be ignored even if unrecognized
Definition
May be used to represent additional information that is not part of the basic definition of the element and that modifies the understanding of the element in which it is contained and/or the understanding of the containing element's descendants. Usually modifier elements provide negation or qualification. 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. Applications processing a resource are required to check for modifier extensions.
Modifier extensions SHALL NOT change the meaning of any elements on Resource or DomainResource (including cannot change the meaning of modifierExtension itself).
Requirements
Modifier extensions allow for extensions that cannot be safely ignored to be clearly distinguished from the vast majority of extensions which can be safely ignored. This promotes interoperability by eliminating the need for implementers to prohibit the presence of extensions. For further information, see the definition of modifier extensions.
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.
Cardinality
0..*
Type
Extension
Modifier
yes — Modifier extensions are expected to modify the meaning or interpretation of the element that contains them
The care being documented -- what happened, and WHEN it happened
Definition
The clinical service(s) this note documents. event.period is the CLINICAL date: the time the
documented care occurred, which is not the same as when the note was written, and not the same as
when it was last edited.
Populate it whenever the note is about care that happened at an identifiable time -- which for a
progress note, a consult note or a discharge summary is always. A note whose only date is date
cannot be placed on a clinical timeline correctly: an amendment moves it.
event.detail may reference the thing being documented; event.code says what kind of care it
was. Both are optional and neither substitutes for the period.
Requirements
Provides context for the composition and creates a linkage between a resource describing an event and the composition created describing the event.
Comments
The event needs to be consistent with the type element, though can provide further information if desired.
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.
Extensions that cannot be ignored even if unrecognized
Definition
May be used to represent additional information that is not part of the basic definition of the element and that modifies the understanding of the element in which it is contained and/or the understanding of the containing element's descendants. Usually modifier elements provide negation or qualification. 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. Applications processing a resource are required to check for modifier extensions.
Modifier extensions SHALL NOT change the meaning of any elements on Resource or DomainResource (including cannot change the meaning of modifierExtension itself).
Requirements
Modifier extensions allow for extensions that cannot be safely ignored to be clearly distinguished from the vast majority of extensions which can be safely ignored. This promotes interoperability by eliminating the need for implementers to prohibit the presence of extensions. For further information, see the definition of modifier extensions.
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.
Cardinality
0..*
Type
Extension
Modifier
yes — Modifier extensions are expected to modify the meaning or interpretation of the element that contains them
This list of codes represents the main clinical acts, such as a colonoscopy or an appendectomy, being documented. In some cases, the event is inherent in the typeCode, such as a "History and Physical Report" in which the procedure being documented is necessarily a "History and Physical" act.
Comments
An event can further specialize the act inherent in the typeCode, such as where it is simply "Procedure Report" and the procedure was a "colonoscopy". If one or more eventCodes are included, they SHALL NOT conflict with the values inherent in the classCode, practiceSettingCode or typeCode, as such a conflict would create an ambiguous situation. This short list of codes is provided to be used as key words for certain types of queries.
WHEN the documented care happened -- the clinical date. Only 'start' expected
Definition
The period the documentation covers. This is the clinical relevance timeframe, not when the note
was created or last edited.
If only a point in time is relevant, use start only; for care spanning days (an admission), set
end as well. start is required when the period is present at all -- a period with no start
states nothing.
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.
The end of the period. If the end of the period is missing, it means no end was known or planned at the time the instance was created. The start may be in the past, and the end date in the future, which means that period is expected/planned to end at that time.
Comments
The high value includes any matching date/time. i.e. 2012-02-03T10:00:00 is in a period that has an end value of 2012-02-03.
The note's content. For the common encounter note this is a single section carrying the whole
narrative; a structured note (SOAP, or a scribe template with headings) may carry several.
section.code is BOUND, extensible, to the Composition Section value set
(nexus-composition-section). It is the element a consumer navigates a note by, and where a
section has a clinical meaning it should say so here: a vital signs section is LOINC 8716-3.
It is NOT the place for a document-type code. LOINC supplies both document codes and section codes,
out of one system and in one format, so nothing about a code says which axis it belongs to -- 34109-9
"Note" types a document, not a section. That is the mistake the extensible strength exists to catch:
a code from the document axis warns. The cost is accepted -- a legitimate section kind the set does
not yet name warns too, and growing the set is one line.
section.code is also not interchangeable with the block-type extension, which says how to RENDER
the section rather than what the section is. Who produced it is a third question again, and
section.author answers that.
Note the overlap with NexusEmrCoreClinicalImpression, which models the Assessment ('A') of a
SOAP note as its own resource. A note carrying an assessment section AND a ClinicalImpression
has two homes for the same text; the IG does not yet rule which is authoritative.
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.
Extensions that cannot be ignored even if unrecognized
Definition
May be used to represent additional information that is not part of the basic definition of the element and that modifies the understanding of the element in which it is contained and/or the understanding of the containing element's descendants. Usually modifier elements provide negation or qualification. 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. Applications processing a resource are required to check for modifier extensions.
Modifier extensions SHALL NOT change the meaning of any elements on Resource or DomainResource (including cannot change the meaning of modifierExtension itself).
Requirements
Modifier extensions allow for extensions that cannot be safely ignored to be clearly distinguished from the vast majority of extensions which can be safely ignored. This promotes interoperability by eliminating the need for implementers to prohibit the presence of extensions. For further information, see the definition of modifier extensions.
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.
Cardinality
0..*
Type
Extension
Modifier
yes — Modifier extensions are expected to modify the meaning or interpretation of the element that contains them
The label for this particular section. This will be part of the rendered content for the document, and is often used to build a table of contents.
Requirements
Section headings are often standardized for different types of documents. They give guidance to humans on how the document is organized.
Comments
The title identifies the section for a human reader. The title must be consistent with the narrative of the resource that is the target of the section.content reference. Generally, sections SHOULD have titles, but in some documents, it is unnecessary or inappropriate. Typically, this is where a section has subsections that have their own adequately distinguishing title, or documents that only have a single section. Most Implementation Guides will make section title to be a required element.
What the section clinically IS -- a SECTION code, never a document code
Definition
A code identifying the kind of content contained within the section. This must be consistent with the section title.
Requirements
Provides computable standardized labels to topics within the document.
Comments
⚠ IMPLEMENTER WARNING -- A DOCUMENT CODE IS IN CIRCULATION IN THIS ELEMENT, and a reader that
has not been told will lose content silently.
Block-structured note editors store one section per block. Where a block carried no code of its
own -- which was every block raised from a template that did not assign one -- the fallback
written here was LOINC 34109-9 "Note": the document code named as the example above, in the slot
this binding exists to keep it out of. It was the common shape on such a note rather than a rare
one.
WRITERS NO LONGER PRODUCE IT, AND STORED DATA IS NOT REWRITTEN. The editor now writes a section
code, and nothing recodes a note already on file: a filed record is not amended because an
unrelated release changed a default. Editing such a note preserves the code it was stored with,
by design. So this is a LEGACY shape rather than one still being created -- and the amount of it
in a deployment is fixed at whatever was written before that change, rather than growing.
READERS MUST TOLERATE IT. Do not treat a section as unclassified because its code is a document
code, and do not drop it. A reader that selects sections by section code will otherwise discard
that content without any signal: the binding raises its warning at VALIDATION, and a reader is
not a validator. Where a reader needs the whole note, take every section and use section.title
and the narrative when the code does not discriminate.
WRITERS SHOULD CODE A SECTION FOR WHAT IT CLINICALLY IS. Most blocks have an identity worth
recording -- an agenda, a reason for contact, a chronic-disease review -- and a template is the
right place to decide it once, rather than a fallback applied at save time. Where a block
genuinely has no clinical identity, 55752-0 "Clinical information" is the generic member of
the bound set. It is a section code, not a document code.
NOT 28562-7 "Chart section Set", which this release reserves. The enclosures slice below is
discriminated by #pattern on code, so a section carrying that code is INSIDE that slice by
content rather than by opting in -- it is then 0..1 for the whole document, and its entry is
typed to an attachment packet. Coding an authoring block 28562-7 therefore makes the document
invalid where a second one exists, and where it does not, a consumer resolving enclosures by code
reads that block as the document's attachment manifest.
MIGRATION -- WHAT IS NOT SETTLED. Notes already stored carry 34109-9 in this element. Whether
those are remapped, or readers are expected to accept both forms indefinitely, is open. A
remapping cannot be mechanical for the blocks that HAVE an identity: recovering it means reading
the block's title or its template, not rewriting one code to another.
Who/what the section is about, when it is not about the subject of composition
Definition
The actual focus of the section when it is not the subject of the composition, but instead represents something or someone associated with the subject such as (for a patient subject) a spouse, parent, fetus, or donor. If not focus is specified, the focus is assumed to be focus of the parent section, or, for a section in the Composition itself, the subject of the composition. Sections with a focus SHALL only include resources where the logical subject (patient, subject, focus, etc.) matches the section focus, or the resources have no logical subject (few resources).
Comments
Typically, sections in a doument are about the subject of the document, whether that is a patient, or group of patients, location, or device, or whatever. For some kind of documents, some sections actually contain data about related entities. Typical examples are a section in a newborn discharge summary concerning the mother, or family history documents, with a section about each family member, though there are many other examples.
The note text, as XHTML. Complete on its own: a consumer that reads nothing but this element,
and no extension in this guide, must still get the clinically meaningful content of the section --
negative findings included. See the contract above section.text in the FSH.
This is the element the chart renders and the element an AI reads. It is TEXT IN FHIR -- not
base64, not a blob pointer -- which is the substantive difference from the DocumentReference
model this replaced for authored notes: it is greppable, diffable, and readable without a
second fetch.
XHTML, NOT ARBITRARY HTML. Content SHALL conform to the FHIR Narrative rules: no active
content, no scripts, no external references. A gateway converting source-EMR note text (which
in OSCAR is effectively plain text with newlines) MUST sanitize and wrap it, not pass it
through.
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.
generated | extensions | additional | empty -- a note body is additional
Definition
Whether the narrative can be regenerated from the resource's structured data. Required by R4 and
easy to omit, because a writer assembling section.text by hand thinks of the div as the value.
| what the narrative is | status |
|---|---|
| a clinician's note body, a letter, an AI summary | additional |
| text a machine can regenerate from this resource's own structured data | generated |
| a block the author raised and left blank | empty, with section.emptyReason |
generated is the one to be careful with: it is a claim that the narrative is disposable, and a
consumer entitled to act on it will render the structured data alone. A note body is not
regenerable from section.entry, whatever else a section carries.
The actual narrative content, a stripped down version of XHTML.
Comments
The contents of the html element are an XHTML fragment containing only the basic html formatting elements described in chapters 7-11 and 15 of the HTML 4.0 standard, <a> elements (either name or href), images and internally contained stylesheets. The XHTML content SHALL NOT contain a head, a body, external stylesheet references, scripts, forms, base/link/xlink, frames, iframes and objects.
How the entry list was prepared - whether it is a working list that is suitable for being maintained on an ongoing basis, or if it represents a snapshot of a list of items from another source, or whether it is a prepared list where items may be marked as added, modified or deleted.
Requirements
Sections are used in various ways, and it must be known in what way it is safe to use the entries in them.
Comments
This element is labeled as a modifier because a change list must not be misunderstood as a complete list.
Specifies the order applied to the items in the section entries.
Requirements
Important for presentation and rendering. Lists may be sorted to place more important information first or to group related entries.
Comments
Applications SHOULD render ordered lists in the order provided, but MAY allow users to re-order based on their own preferences as well. If there is no order specified, the order is unknown, though there may still be some order.
References to discrete resources that belong to this section -- the structured counterpart to
section.text.
Currently unconstrained by type and expected to be sparse: today's notes are narrative. This is
the element that carries structured note generation when it arrives (a scribe filling a
structured template, or SDC extraction promoting answers to Observation / Condition), which is
why it is declared now rather than left to be discovered later.
Comments
If there are no entries in the list, an emptyReason SHOULD be provided.
Where a template declares a section that has no content, this records why it is empty rather than leaving the reader to guess between 'nothing to report' and 'not asked'.
Requirements
Allows capturing things like "none exist" or "not asked" which can be important for most lists.
Comments
The various reasons for an empty section make a significant interpretation to its interpretation. Note that this code is for use when the entire section content has been suppressed, and not for when individual items are omitted - implementers may consider using a text note or a flag on an entry in these cases.
The attachment packets travelling with this document, one entry each
Definition
The document's own account of what is attached to it: a section coded LOINC 28562-7 whose entry
references one or more attachment packets (List resources profiled as Attachment Packet). A letter
sent with enclosures carries this section; a document sent with nothing carries no such section.
This is the only record of a document's attachments. The packets do not point back, so a
consumer asking what went out with a letter reads this section and nothing else.
Resolve it by the coding, not by position. The body is the section at a known index; this one
follows it and may sit anywhere after it. Match system and code together -- 28562-7 under
another producer's system is that producer's section, not this one.
The heading is section.title. Write "Enclosures" there. 28562-7 is named "Chart section Set"
in LOINC and "Enclosures" is not a term of that concept, so it does not belong in the coding's
display.
Membership lives on the packet, not here.entry names the packets; which chart items each
holds, in what order, and which of their pages are left out are all on the packet.
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.
Extensions that cannot be ignored even if unrecognized
Definition
May be used to represent additional information that is not part of the basic definition of the element and that modifies the understanding of the element in which it is contained and/or the understanding of the containing element's descendants. Usually modifier elements provide negation or qualification. 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. Applications processing a resource are required to check for modifier extensions.
Modifier extensions SHALL NOT change the meaning of any elements on Resource or DomainResource (including cannot change the meaning of modifierExtension itself).
Requirements
Modifier extensions allow for extensions that cannot be safely ignored to be clearly distinguished from the vast majority of extensions which can be safely ignored. This promotes interoperability by eliminating the need for implementers to prohibit the presence of extensions. For further information, see the definition of modifier extensions.
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.
Cardinality
0..*
Type
Extension
Modifier
yes — Modifier extensions are expected to modify the meaning or interpretation of the element that contains them
The label for this particular section. This will be part of the rendered content for the document, and is often used to build a table of contents.
Requirements
Section headings are often standardized for different types of documents. They give guidance to humans on how the document is organized.
Comments
The title identifies the section for a human reader. The title must be consistent with the narrative of the resource that is the target of the section.content reference. Generally, sections SHOULD have titles, but in some documents, it is unnecessary or inappropriate. Typically, this is where a section has subsections that have their own adequately distinguishing title, or documents that only have a single section. Most Implementation Guides will make section title to be a required element.
A code identifying the kind of content contained within the section. This must be consistent with the section title.
Requirements
Provides computable standardized labels to topics within the document.
Comments
⚠ IMPLEMENTER WARNING -- A DOCUMENT CODE IS IN CIRCULATION IN THIS ELEMENT, and a reader that
has not been told will lose content silently.
Block-structured note editors store one section per block. Where a block carried no code of its
own -- which was every block raised from a template that did not assign one -- the fallback
written here was LOINC 34109-9 "Note": the document code named as the example above, in the slot
this binding exists to keep it out of. It was the common shape on such a note rather than a rare
one.
WRITERS NO LONGER PRODUCE IT, AND STORED DATA IS NOT REWRITTEN. The editor now writes a section
code, and nothing recodes a note already on file: a filed record is not amended because an
unrelated release changed a default. Editing such a note preserves the code it was stored with,
by design. So this is a LEGACY shape rather than one still being created -- and the amount of it
in a deployment is fixed at whatever was written before that change, rather than growing.
READERS MUST TOLERATE IT. Do not treat a section as unclassified because its code is a document
code, and do not drop it. A reader that selects sections by section code will otherwise discard
that content without any signal: the binding raises its warning at VALIDATION, and a reader is
not a validator. Where a reader needs the whole note, take every section and use section.title
and the narrative when the code does not discriminate.
WRITERS SHOULD CODE A SECTION FOR WHAT IT CLINICALLY IS. Most blocks have an identity worth
recording -- an agenda, a reason for contact, a chronic-disease review -- and a template is the
right place to decide it once, rather than a fallback applied at save time. Where a block
genuinely has no clinical identity, 55752-0 "Clinical information" is the generic member of
the bound set. It is a section code, not a document code.
NOT 28562-7 "Chart section Set", which this release reserves. The enclosures slice below is
discriminated by #pattern on code, so a section carrying that code is INSIDE that slice by
content rather than by opting in -- it is then 0..1 for the whole document, and its entry is
typed to an attachment packet. Coding an authoring block 28562-7 therefore makes the document
invalid where a second one exists, and where it does not, a consumer resolving enclosures by code
reads that block as the document's attachment manifest.
MIGRATION -- WHAT IS NOT SETTLED. Notes already stored carry 34109-9 in this element. Whether
those are remapped, or readers are expected to accept both forms indefinitely, is open. A
remapping cannot be mechanical for the blocks that HAVE an identity: recovering it means reading
the block's title or its template, not rewriting one code to another.
Who/what the section is about, when it is not about the subject of composition
Definition
The actual focus of the section when it is not the subject of the composition, but instead represents something or someone associated with the subject such as (for a patient subject) a spouse, parent, fetus, or donor. If not focus is specified, the focus is assumed to be focus of the parent section, or, for a section in the Composition itself, the subject of the composition. Sections with a focus SHALL only include resources where the logical subject (patient, subject, focus, etc.) matches the section focus, or the resources have no logical subject (few resources).
Comments
Typically, sections in a doument are about the subject of the document, whether that is a patient, or group of patients, location, or device, or whatever. For some kind of documents, some sections actually contain data about related entities. Typical examples are a section in a newborn discharge summary concerning the mother, or family history documents, with a section about each family member, though there are many other examples.
The note text, as XHTML. Complete on its own: a consumer that reads nothing but this element,
and no extension in this guide, must still get the clinically meaningful content of the section --
negative findings included. See the contract above section.text in the FSH.
This is the element the chart renders and the element an AI reads. It is TEXT IN FHIR -- not
base64, not a blob pointer -- which is the substantive difference from the DocumentReference
model this replaced for authored notes: it is greppable, diffable, and readable without a
second fetch.
XHTML, NOT ARBITRARY HTML. Content SHALL conform to the FHIR Narrative rules: no active
content, no scripts, no external references. A gateway converting source-EMR note text (which
in OSCAR is effectively plain text with newlines) MUST sanitize and wrap it, not pass it
through.
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.
generated | extensions | additional | empty -- a note body is additional
Definition
Whether the narrative can be regenerated from the resource's structured data. Required by R4 and
easy to omit, because a writer assembling section.text by hand thinks of the div as the value.
| what the narrative is | status |
|---|---|
| a clinician's note body, a letter, an AI summary | additional |
| text a machine can regenerate from this resource's own structured data | generated |
| a block the author raised and left blank | empty, with section.emptyReason |
generated is the one to be careful with: it is a claim that the narrative is disposable, and a
consumer entitled to act on it will render the structured data alone. A note body is not
regenerable from section.entry, whatever else a section carries.
The actual narrative content, a stripped down version of XHTML.
Comments
The contents of the html element are an XHTML fragment containing only the basic html formatting elements described in chapters 7-11 and 15 of the HTML 4.0 standard, <a> elements (either name or href), images and internally contained stylesheets. The XHTML content SHALL NOT contain a head, a body, external stylesheet references, scripts, forms, base/link/xlink, frames, iframes and objects.
How the entry list was prepared - whether it is a working list that is suitable for being maintained on an ongoing basis, or if it represents a snapshot of a list of items from another source, or whether it is a prepared list where items may be marked as added, modified or deleted.
Requirements
Sections are used in various ways, and it must be known in what way it is safe to use the entries in them.
Comments
This element is labeled as a modifier because a change list must not be misunderstood as a complete list.
Specifies the order applied to the items in the section entries.
Requirements
Important for presentation and rendering. Lists may be sorted to place more important information first or to group related entries.
Comments
Applications SHOULD render ordered lists in the order provided, but MAY allow users to re-order based on their own preferences as well. If there is no order specified, the order is unknown, though there may still be some order.
References to discrete resources that belong to this section -- the structured counterpart to
section.text.
Currently unconstrained by type and expected to be sparse: today's notes are narrative. This is
the element that carries structured note generation when it arrives (a scribe filling a
structured template, or SDC extraction promoting answers to Observation / Condition), which is
why it is declared now rather than left to be discovered later.
Comments
Each entry is a List profiled as Attachment Packet. Nothing else belongs here: a document, a result or a note attached to the document is a MEMBER OF a packet, not an entry of this section, so that its order and its excluded pages have somewhere to live.
Where a template declares a section that has no content, this records why it is empty rather than leaving the reader to guess between 'nothing to report' and 'not asked'.
Requirements
Allows capturing things like "none exist" or "not asked" which can be important for most lists.
Comments
The various reasons for an empty section make a significant interpretation to its interpretation. Note that this code is for use when the entire section content has been suppressed, and not for when individual items are omitted - implementers may consider using a text note or a flag on an entry in these cases.