Ledger, sync, offline and hardware requirements
Offline behavior and printing
Local operation, offline printing.
How to read status labels: In the pilot (v0.2.0, synthetic data) Simulated in the pilot Coming (Wave 2, rolling out) Designed, not yet built Open decision Not offered / no claim made Planned partner integration
C0951Can the clinic keep working and print records when sync or transfer is down?
No. The specification describes it, but the pilot does not include it. REQ-3201 says when sync or server transfer is down, the on-site main computer must continue full clinical operation and must be able to print records. Its acceptance check: with WAN disconnected, a print job completes.
C0952How would printers be connected to keep printing off the network?
REQ-3202 is a top-priority requirement for all three tiers: printing must use a wired, non-networked printer directly attached to the main computer (or print server on the closed LAN with no route outside). Not yet. It is designed in the specification and not built in the pilot. To verify it, the specification says network scan of printer finds no reachable interface from outside the LAN.
C0953Is every print job recorded?
The offline behavior and printing part of the specification (REQ-3203) says every print job must be an audit event with user, hashed patient reference, time and terminal, queued locally while offline and appended to the ledger on reconnect. Designed, not built: there is no code for this in the pilot. Acceptance check: offline print log appears on ledger after reconnect in order.
C0954Would printed pages be watermarked?
How would it be tested? The specification says watermark placeholder renders; format parameter exists. That is the check for REQ-3204: printed pages must carry a watermark with user and time; the exact format is (still an open decision). This is on the design side of the line. Nothing in v0.2.0 does it. Parts of it are explicitly marked as open in the specification.
C0955Is there a limit on how much one user can print?
No. The specification describes it, but the pilot does not include it. For reference, REQ-3205 (a top-priority requirement, all three tiers) says print rate limiting must be enforced per user and terminal; values are (still an open decision) (design example 50 prints/day per user, proposed). Check: exceeding rate requires step-up and raises an alert. Parts of it are explicitly marked as open in the specification.
C0956Does printing a highly restricted compartment need extra steps?
Printing of C4 compartment content must require purpose and step-up. That is REQ-3206, a top-priority requirement for all three tiers. Not yet. It is designed in the specification and not built in the pilot. Test in the specification: c4 print without purpose is refused.
C0957What happens to printed downtime reports?
Designed, not built: there is no code for this in the pilot. REQ-3207 says printed downtime reports must be locked, sealed, logged and shredded on refresh. Its acceptance check: refresh cycle records shred confirmation.