PF07 - Connection retention and recovery delays

Description of the control

Document the connection retention and interruption delays the PST can tolerate without loss of communication or data, and specify whether the PST supports packet rerouting without loss of communication or data.

What this control corresponds to

This criterion complements PF06 by covering what happens during a complete connection drop (not just degradation): how long the application can "hold" a pending session or transaction before considering it lost, and whether it can resume cleanly after a network route change.

Why this control is important

Connection interruptions (Wi-Fi/cellular failover, a brief WAN link drop) are common in clinical mobility contexts (tablet, mobile workstation). Without a documented, reliable recovery behaviour, a network interruption could lose an in-progress clinical entry - or worse, cause duplicate entry or an inconsistent record state.

How to implement it

• Define and document a session/transaction retention delay (how long an in-progress operation is buffered before it expires).
• Implement and test connection recovery after a short interruption (e.g. network failover) without losing the in-progress entry.
• Explicitly document whether the application supports packet rerouting (a network path change mid-session) without loss of communication.

How to verify it’s in place

• Request a demo or test report simulating a connection drop during an active transaction.
• Verify the documented retention delay matches observed behaviour - neither too short (frequent losses) nor too long (risk of duplicates).
• Confirm that final recovery-failure behaviour is clearly communicated to the user (a clear message, not a silent uncertain state).