Difference between revisions of "Prescription start times are in the past"
Line 9: | Line 9: | ||
Whatever the reason, if the session is terminated in the background while the booking in screen is still open, and somebody then books something in without reloading the page, the start time of the prescription can be assigned the time when the session was last actively updating. | Whatever the reason, if the session is terminated in the background while the booking in screen is still open, and somebody then books something in without reloading the page, the start time of the prescription can be assigned the time when the session was last actively updating. | ||
=Solution= | =Solution= | ||
Truthfully the most correct solution is to not attempt to interact with a web page that has been left dormant long enough for the session to expire, and this is good advice for any dynamic web page. However we do acknowledge that the PTS workflow encourages the booking in screen to be left open on certain PCs. | |||
The problem was addressed in PTS v5.0.3.4, and prescription start times are now not allowed to be set to before the creation time, except in specific circumstances (such as e-prescribing). | |||
To fix the problem retroactively, this T-SQL script will modify the start times of any applicable prescriptions and set it to be the same as the creation time, and retain the delta between the new start time and the target times: | To fix the problem retroactively, this T-SQL script will modify the start times of any applicable prescriptions and set it to be the same as the creation time, and retain the delta between the new start time and the target times: |
Revision as of 11:09, 11 August 2022
Sometimes prescriptions are booked in with their start times set to several hours in the past (sometimes in the middle of the night), resulting in inaccurately long turnaround times.
Symptoms
Having booked in a prescription, usually the first one of the day, it is immediately given a turnaround time of several hours or more and counting. Viewing the prescription details reveals that PTS thinks it was booked in several hours ago. The problem might be picked up when reports show that prescriptions were supposedly booked in when the dispensary was closed.
Cause
PTS is web based software and while this confers huge benefits PTS is also exposed to the nature of the web in that sessions can and will time out, or be otherwise terminated if a page is left open and not interacted with for some time. This normally results in the user being returned to the login screen when they next try to use parts of the system.
As the booking in screen is typically left open for long periods of time - sometimes overnight - it is particularly vulnerable to this aspect of the web. PC's going to sleep and users being logged out of Windows while the page is open can cause the same problem.
Whatever the reason, if the session is terminated in the background while the booking in screen is still open, and somebody then books something in without reloading the page, the start time of the prescription can be assigned the time when the session was last actively updating.
Solution
Truthfully the most correct solution is to not attempt to interact with a web page that has been left dormant long enough for the session to expire, and this is good advice for any dynamic web page. However we do acknowledge that the PTS workflow encourages the booking in screen to be left open on certain PCs.
The problem was addressed in PTS v5.0.3.4, and prescription start times are now not allowed to be set to before the creation time, except in specific circumstances (such as e-prescribing).
To fix the problem retroactively, this T-SQL script will modify the start times of any applicable prescriptions and set it to be the same as the creation time, and retain the delta between the new start time and the target times:
UPDATE Prescriptions SET [Started] = [Created], [Requested] = [Created], [TargetCompletionTime] = DATEADD(ss, DATEDIFF(ss, [Started], [TargetCompletionTime]), [Created]), [TargetDeliveryTime] = DATEADD(ss, DATEDIFF(ss, [Started], [TargetDeliveryTime]), [Created]) WHERE ([created] > [Started] OR [created] > Requested) AND DATEDIFF(ss, [Started], [Created]) > 60 AND [Requested] = [Started]
Please ensure that a database backup is taken first in case you do not like the results.