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.
Salient fields
The profile's synthesized-accessor contract: fields TypedFhir surfaces as first-class typed properties, each computed from the instance by a restricted FHIRPath expression. See Salient Fields for what they are, how they shape LLM contexts, and how to declare them.
Key
Type
Expression
Rendered as
Description
status
code
status
preliminary (draft) | final (signed) | amended (edited after signing) | entered-in-error i
type
coded
type
What kind of document this is: note, summary or letter i
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.
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.
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.
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.
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.
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.
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.
Comments
A Practitioner, or a Device for AI-drafted content.
The whole note body, as XHTML -- every section's narrative, joined
Definition
The note text, as XHTML. Complete on its own: a consumer that reads nothing but this value, and no extension in this guide, must still get the clinically meaningful content of the note -- negative findings included. See the contract above section.text. This is the value the chart renders and the value 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. DERIVED, and READ-ONLY. It is every section's narrative joined, so it exists nowhere in the resource and there is no way to redistribute an assigned string back across the sections it came from. To WRITE a note body, build the blocks and assign section.
Comments
Every section's narrative, in stored order, joined. A block-authored note stores one section per authoring block, so this is the whole note body rather than its first block; a note filed as SOAP sections reads the same way. A consumer needing the blocks apart -- their headings, their kinds, their structured values -- walks section, which reads back as a typed collection of authoring blocks, rather than reading this.