Packet Cover Page Extension¶
| Canonical | ../StructureDefinition/nexus-packet-cover-page |
|---|---|
| Status | draft · 1.26.0 |
| Base | Extension (constraint) |
| Context | List (element) |
| Source | FSH · JSON |
Whether this attachment packet leads with a generated cover page in the outbound render.
FSH
The authored source of truth: extensions/PacketCoverPageExtension.fsh (edit on GitHub). One FSH file may define several related artifacts.
// PacketCoverPageExtension.fsh
// Whether an attachment packet leads with a generated cover page. Rides the `List` itself, once.
//
// WHY IT IS ON THE PACKET AND NOT ON A MEMBER. A cover page is a property of the ASSEMBLY: it
// introduces the whole packet, it is generated at render time from what the packet already knows
// (subject, title, recipient, member count), and it is deliberately NOT a `List.entry`. Making it
// a member would mean minting a resource for a page that does not exist until the render runs,
// and every consumer counting members would then have to know which member was not a chart item.
// The per-member assembly fact -- which pages of a member were left out -- is the entry-level
// `nexus-attachment-packet-excluded-page` extension; this is the packet-level counterpart.
//
// ABSENT IS NOT `false`. THIS IS THE ONE RULE A READER HAS TO GET RIGHT.
// The value a packet starts with is decided by the channel it is being prepared for, not by this
// specification: a channel may default to leading with a cover page and another may default to
// not. So an absent value does not name either choice -- it says only that nothing was recorded,
// and a reader cannot recover from it what the assembler intended. A reader that folds absence
// into `false` reports that a cover page was declined on every packet written before the flag
// existed, and on every packet written by a producer that does not set it.
//
// WHAT A WRITER SHOULD THEREFORE DO: write it explicitly, both ways, on every packet it files.
// The value is 1..1 in this extension precisely so that carrying the extension at all is a
// statement; a writer with nothing to say omits the extension rather than filing an empty one.
//
// WHAT A READER SHOULD DO: `true` leads with a cover page, `false` does not, and absent falls back
// to whatever default the reader's own channel carries. Do not rewrite absence to a value on read
// -- that turns a reader's default into a producer's assertion the next time the packet is saved.
//
// THE COVER PAGE IS NOT THE RECORD OF WHAT WAS SENT. Like the rest of the packet, this records an
// assembly choice. What the recipient received is the rendered document stored when the host is
// sent; that render either carries a cover page or does not, and it is the artifact to read when
// the question is what went out rather than what was chosen.
Extension: PacketCoverPageExtension
Id: nexus-packet-cover-page
Title: "Packet Cover Page Extension"
Description: """
Whether this attachment packet leads with a generated cover page in the outbound render.
**Absent does not mean `false`.** The value a packet starts with is decided per send channel, so an
absent extension records no choice at all -- neither that a cover page was wanted nor that it was
declined. Writers SHOULD state it explicitly in both directions; readers SHOULD treat absence as
"not stated" and fall back to their own channel default rather than to `false`.
**The cover page is not a packet member.** It is generated at render time from what the packet
already carries and never appears in `List.entry`, so a consumer counting members counts chart
items only.
Meaningful on an attachment packet (`nexus-attachment-packet`), and constrained to one: the
extension's `contextInvariant` requires the `List` it rides to carry an identifier under the
attachment-packet naming system, so it cannot legally be stamped on a template `List` or on any
other kind. It asserts nothing about any other kind of `List` because it cannot appear on one.
"""
* ^url = "../StructureDefinition/nexus-packet-cover-page"
* ^status = #draft
* ^date = "2026-09-04"
* ^publisher = "WELLSTAR Technologies Corp."
* ^contact.name = "Nexus EMR FHIR Implementation Guide"
* ^contact.telecom.system = #url
* ^contact.telecom.value = ".."
* ^jurisdiction = urn:iso:std:iso:3166#CA "Canada"
* ^context[0].type = #element
* ^context[0].expression = "List"
// The context element alone says only "a List". An attachment packet is a List carrying an
// identifier under the attachment-packet naming system -- that marker IS the mechanism, as the
// profile's own `nexus-packet-has-identity` invariant states -- so the same test is the one that says
// this extension is on the right kind of List. Evaluated against the List, it is false for a
// template List, for a chart-item List, and for a bare List with no identifier at all.
* ^contextInvariant[0] = "identifier.where(system = '../NamingSystem/nexus-attachment-packet').exists()"
* . ^short = "Does this packet lead with a generated cover page? (absent = not stated, NOT false)"
* extension 0..0
* url 1..1
* value[x] 1..1 MS
* value[x] only boolean
* valueBoolean ^short = "true: the render leads with a generated cover page; false: it does not"
* valueBoolean ^definition = "Whether the outbound render of this packet begins with a generated cover page. Present-and-`false` is a recorded decision not to lead with one, and is distinct from the extension being absent, which records no decision."