TGV guide · Performance
TGV PF07: connection retention and recovery delays
TGV control PF07 asks the vendor to document the connection retention and interruption delays the PST tolerates without data loss, and whether it can reroute.
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.
This control belongs to the Performance group of the Trousse globale de vérification (TGV), the certification toolkit of Quebec’s health and social services network. The description restates the criterion from the TGV grid; the rest of the page is Sentrix’s interpretation.
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 is 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).
Need help with this control?
If you need help implementing or verifying this control, our team supports PST vendors preparing their TGV certification file, control by control. See the TGV certification support service and the TGV framework page, or contact us.
Next in the guide
Frequently asked questions
- What is the difference between PF07 and PF06?
- PF06 deals with network degradation: lost, out-of-order or stale packets. PF07 covers a complete connection drop: 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. Together the two controls describe how the PST behaves on a real-world network.
- What is a session retention delay?
- It is how long an in-progress operation is buffered before it expires. The vendor defines it, documents it and tests it through connection recovery after a short interruption, such as a Wi-Fi/cellular failover, without losing the in-progress entry. A delay that is too short causes frequent losses; one that is too long creates a risk of duplicates.
- How does the certifier check connection recovery?
- The certifier requests a demo or a test report simulating a drop during an active transaction, then verifies that the documented retention delay matches the observed behaviour. Finally they confirm that a final recovery failure is clearly communicated to the user through an explicit message, with no silent uncertain state that would leave doubt about whether the record was saved.
Let's talk about your compliance program.
Last updated: 2026-09-17