Generated Summaries¶

A generated summary is a Composition the AI harness writes and maintains on a patient's behalf: "what changed since you last saw this patient", the day-sheet blurb beside an appointment, a whole-chart orientation. It lives in the chart like any other document, and the EMR loads it from the FHIR store rather than calling anything.

That last point is the design, not an implementation detail. Opening a day sheet is instant because the summary already exists as a resource with an id and a version, and "which summary was the doctor looking at" has an answer a year later. A summary generated on demand, at open, would answer neither.

The shape¶


Profile	Composition
`type`	LOINC 34133-9 "Summary of episode note" -- the class every generated summary shares, and the element to search on
`category`	which kind of summary -- see Several kinds, one classification. The profile allows `0..`, but a consumer cannot tell a day-sheet summary from an encounter recap without it, so for this* population it is required in practice
`subject`	the patient, always — see Every summary is about a patient
`author`	the harness graph, as a logical `Device` reference under `nexus-harness-graph`
`meta.security`	the `AIAST` label — a summary is machine-produced content, and carries the label every such resource carries
`identifier`	the harness business key under `nexus-harness-key` — this is what makes it update in place. The profile allows `0..1`, but a summary without it duplicates on every run, so for this population it is required in practice
`status`	`final` when the generation is complete
`attester`	absent, and that is correct — see Nobody signs a summary

Every summary is about a patient¶

Composition.subject is 1..1 and it is the patient. There is no such thing here as a summary floating free of a chart: a summary is a statement about someone's record, and a consumer must be able to get from the patient to their summaries with an ordinary search.

GET [base]/Composition?subject=Patient/4021&type=http://loinc.org|34133-9

That query returns every summary this patient has, of every kind. To fetch one specific summary, search its business key instead — see below.

These searches are required by this design and are not yet declared

Composition currently declares no search parameters in the server CapabilityStatement, and this IG's rule is that it does not publish an interaction it has not measured — which is why List gained exactly one declared parameter, and only after the query was run against the live store. The searches on this page (subject, category, and especially identifier) are what the design needs, not what the spec currently guarantees. identifier is the load-bearing one: without it a producer cannot find the summary it wrote last time, and update-in-place degrades into minting a duplicate on every run. Measuring these three against the store and declaring the ones that work is owed IG work, tracked on the 1.19.0 round.

Summaries update in place¶

A patient has one of each kind of summary, forever. When the harness regenerates the since-last-visit summary next year, it finds the existing resource by its business key and replaces the content. It does not mint a second one.

GET [base]/Composition?identifier=https://fhir.apps.health/NamingSystem/nexus-harness-key|since-last-visit-summary:Patient/4021

This is why the key carries no period. A key like ...:Patient/4021:2026-08-19 would mint a new resource on every generation and leave the chart accumulating stale summaries that nobody deletes and every query has to sort through. The superseded content is not lost: it is the resource's own version history, which is where "what did the summary say in May" is answered.

The exception, and how to tell

A summary whose period is part of what it is does key on the period — a practitioner's day sheet for one date is not an update of yesterday's, it is a different document. The test is whether regenerating would replace or add: replace means no period in the key, add means the period belongs in it.

Several kinds, one classification¶

There are semantically different summaries, and every one of them is LOINC 34133-9 about the same patient. That code is the CLASS, and it lives on type. What separates one kind from another is category, which carries a refinement from Nexus Composition Type:

`category`	What it is
`nexus-daysheet-summary`	generated ahead of a clinic day for a booked patient -- the short orientation shown beside the appointment
`nexus-interval-summary`	what happened to a patient between two points in time, typically since the last visit. There may be no upcoming appointment at all
`nexus-encounter-recap`	one encounter, summarized after it. Not interchangeable with the other two: a recap asserts that the encounter it covers took place

Read category to tell them apart. The business key still carries the harness's own capability prefix (daysheet-summary:, since-last-visit-summary:, chart-summary:) and is still what makes a summary update in place, but that prefix is a producer's namespace: a consumer that decodes an identifier to answer "what kind of summary is this" is reading someone's internals for something the record now states outright.

A whole-chart summary has no code yet

The three codes above do not cover a chart summary -- the whole record, for someone picking the patient up cold. It is 34133-9 like every other summary and carries no refinement from this system, so a consumer cannot tell it from an unkinded summary by code alone. Name it in title and category.text until a code exists for it.

Give each kind a distinct title and category.text as well, so a human reading the chart sees which is which without reading a code.

Nobody signs a summary¶

The Composition profile requires a final document to carry an attester with mode legal or professional — who is medico-legally responsible for it. Generated summaries are exempt from that invariant, deliberately.

Nothing attests to a machine-generated summary. final on a summary means "this generation is complete", not "a human has taken responsibility for the contents". The two available alternatives were both worse: leaving summaries permanently preliminary would be false, since they are complete; naming an attester who never attested would fabricate a medico-legal signature in the record.

Letters and notes are not exempt. A letter goes out over a clinician's name and is signed like any other authored document.

What a consumer must get right¶

Switch on type, and search on it too. A Composition search returns notes, letters and summaries together. Every generated summary carries LOINC 34133-9 "Summary of episode note" on type, of every kind, and an authored note never does — so one element both branches and gathers. type is 1..1, so it is always there to branch on. A surface that ignores it will render a machine-generated summary as though a clinician wrote it, and author will not save you: a scribe-drafted note also has a Device author. author says who wrote it; type says what it is. Which kind of summary it is lives on category.
Mark it as AI-generated in the UI. Read the AIAST security label, which is the portable answer to "was this machine-produced" and is the same on every resource type. The Device author is the finer-grained signal: it says which graph produced it.
Do not write summaries. The harness owns this resource; the EMR renders it. An EMR write would be overwritten by the next generation.
Expect the content to change under you. Regeneration replaces the body in place, so cache against meta.versionId rather than assuming stability.

Task Note profile — the other place a harness graph is named as an author, and the same logical-Device pattern.
NamingSystem/nexus-harness-key — the business-key contract, shared with machine-written Tasks.
AI Attribution — the AIAST label, what "in part" means, and the boundary between authorship and conversion.
Clinical Task design — how tasks, the inbox and the harness fit together; summaries are the one harness output that is not a Task, because there is no decision for a human to make.