Requisition Signature Extension

Canonical	../StructureDefinition/nexus-requisition-signature
Status	draft · 1.26.0
Base	Extension (constraint)
Context	ServiceRequest (element)
Source	FSH · JSON

The clinician's electronic signature on a laboratory requisition: who signed it, and when.

Overview

An attestation, not a cryptographic signature -- and R4's Signature datatype is built for exactly that. Its type binds ISO/ASTM E1762 attestation kinds (Author's Signature among them) rather than algorithms, and data is optional, so a signature with no digest and no key is valid. A future revision of this extension carries a Signature as its value for that reason; what follows describes the shape written today. This is not the R4 Signature datatype and carries no digest, no signed blob and no key. It records that the authenticated user asserted the requisition at a moment in time. A consumer must not present it as a verifiable cryptographic signature.

Presence is the flag. There is no separate stored boolean. A requisition carrying this extension is signed; one without it is not.

At most one, and a re-sign replaces it. The form prints one signature line. The sequence of signings is read from the resource's version history, where each stored version carries the signature it was written with and, separately, the reason that version was written.

The signer's name is stored on the reference, deliberately. signer.display is the name as it printed on the sheet when it was signed. A reprint must reproduce the issued document from the resource alone, so a later change to the practitioner's recorded name does not change what an already-issued requisition says.

No stamp image is referenced. A signature prints as the typed name. The stamp child below is read-only legacy and must never be produced; its absence carries no meaning about validity.