Attachment Packet Profile¶
| Canonical | ../StructureDefinition/nexus-attachment-packet |
|---|---|
| Status | draft · 1.26.0 |
| Base | List (constraint) |
| Source | FSH · JSON |
An attachment packet: the ordered set of chart items assembled to travel with an outbound artifact -- a letter today, an eReferral next, and forms, emails and chart prints after that.
Overview
Membership and order are List.entry. The host points at the packet with the reference element it
already has: a letter uses one Composition.section.entry, a referral uses
ServiceRequest.supportingInfo. Both are Reference(Resource) in base R4, so a packet is legal in
each without a new element anywhere.
The packet is not the sent document. It is the assembly. What the recipient received is the
rendered file stored when the host is SENT, which carries a Provenance deriving it from this
List at the version it had -- because membership, order and per-member exclusions all move.
A letter names its packets in one coded section. A Composition profiled as
nexus-emr-core-composition MAY carry a
section coded LOINC 28562-7 whose entry references packets; that is the only place a letter
records what travels with it, and the enclosures slice on that profile is where the join is
declared.
Two assembly facts ride beside the membership. Whether the render leads with a generated cover
page is the nexus-packet-cover-page extension,
declared as the coverPage slice below -- read it before treating an absent value as false, which
it is not. Which way out of the EMR the packet was built for is a meta.tag coding under
nexus-send-channel; this profile does not slice or otherwise
constrain meta.tag, because the element is open on every resource and that marker belongs to one
producer rather than to the shape every packet conforms to.
Neither of those records a send. Both say what was chosen while the packet was being assembled. A channel tag is not evidence that anything was transmitted.
An attachment packet is the ordered set of chart items assembled to travel with something going out of the EMR: a consult letter today, an eReferral next, and forms, emails and chart prints after that.
It is a List. Membership and order are List.entry, mode is working because the set is
maintained in place until its host is sent, and subject is the patient whose chart the members
came from.
The host points at the packet with an element it already has
A letter names its packet in one Composition.section.entry. A referral names it in
ServiceRequest.supportingInfo. Both are Reference(Resource) in base R4, and
ServiceRequest.supportingInfo is the element Ontario eReferral profiles for referral
attachments, so a packet is legal in each today: what this guide adds is the sanction, not the
capability.
Navigate host -> packet -> members. The back-pointer on the rendered document
(DocumentReference.context.related) exists for a reader that starts from the file, and is not a
search surface -- see the caution on that element.
Why a List, and not a section list or a document
Modelling the packet as its host's own sections works for exactly one host. A ServiceRequest
has no sections, so an eReferral needs a second design the moment it arrives, and so does every
other host in the requirement. A separate resource that every host can reference answers all of
them once.
R4 has a resource for this shape: DocumentManifest, "a collection of documents compiled for a
purpose together with metadata that applies to the collection", carrying content, recipient,
related and subject. It is the right shape and it is removed in R5, replaced by List.
So the container it would ship in is a dead end.
IHE MHD reaches the same place independently: its SubmissionSet profile constrains List, and its
intendedRecipient extension sits on that List rather than on a document -- because a recipient
belongs to the packet prepared for someone, not to the document, which may be sent twice. That is
why DocumentReference gains no recipient element here.
What a member may be
entry.item is deliberately not constrained by resource type. Enumerating the kinds that ship
today -- documents, notes, results, forms -- would reintroduce the per-type modelling this profile
replaces, and the requirement already names members and hosts this guide has not modelled. A
consumer renders the kinds it knows and reports the ones it does not, rather than dropping
them.
Per-member assembly state
A member can record which of its pages the assembler left out, with the
excluded-page extension on
List.entry: one occurrence per page, 1-based.
A page number is meaningful only relative to the render it was taken from. A lab result is pages only once something has laid it out, and a different renderer -- or the same one after a template change -- may paginate it differently. So these values record what the assembler chose, never a durable instruction for re-rendering the member later.
What the recipient actually received
Not this List. The packet is the assembly; the record of what went out is the rendered document
stored on send, which is a DocumentReference (type LOINC 11503-0, a document code, correct
there and wrong in a section slot) carrying a Provenance whose derivation entity is this List
at the version it had. One versioned pointer carries membership, order and exclusions as they
stood; naming the members individually loses the order and the exclusions.
Nothing is stored at assembly or at preview, because the render is derivable from the packet until the moment it is sent -- and after that moment it is the one version that cannot be rebuilt once the members change.