1.7 5708 Check-in is not one transaction
If you have an appointment that you run through the check-in process up to the point at which you have the visit editor open, and then you close the visit editor window with the top-right X or you press the Cancel button, then you are left with the visit created and a task in the worklist - BUT the appointment is still status Pending.
Hence, we are not grouping the check-in actions as one transaction - so that when the visit editor is aborted (by Cancel button or window close) then we are not backing out the visit and task - though the appointment status update is not done.
Suggestion - move the appointment status change into the same transaction as the task and visit creation and complete this transaction BEFORE displaying the visit editor. Then if you abort the visit editor, the appointment status will still be checked-in matching the fact that the task and visit exist.
Alternatively [to allow the check-in of the wrong appointment to be aborted when the user sees the visit editor and realises that it is the wrong patient], do not end the transaction until the visit editor is OK'ed - but in this case the user should be warned (when they press Cancel or the top-right X) that they are about to abort the check-in.
My preference is for this second solution.
Note that the bug revealed itself because RxWorks is very good about warning you if you close a window when there is a set of changes in progress. Hence Reception are used to closing a window with no ill effects [because RxWorks would warn if there was partially updated data]. On day 2 of OpenVPMS they are still adjusting to different ways of doing things.
[This also explains why yesterday when we were having problems with the worklist, they were able to check-in an appointment multiple times.]
We will get around this problem by staff education - "always OK the visit editor", but it would be nice to get a fix so that poor work practices do not screw up the system.
Regards, Tim G
Re: 1.7 5708 Check-in is not one transaction
We don't maintain transactions across http requests, so its not just as simple as putting the Check-In workflow in a single transaction.
By the time the Visit editor is shown, there may be:
Once the Visit Editor is displayed, medical records can be added, modified, and deleted.
Cancelling the Visit editor will cancel saving changes to the Invoice, but if Apply has been pressed, the saved instance will be retained.
It could be changed so that if Cancel/Close is pressed, it (in order of increasing complexity):
1. warns that changes have been made that need to be manually backed out.
2. warns that changes have been made that need to be manually backed out, and list what has changed.
3. automatically backs out new records, and warns that modified records need to be manually backed out.
Rollback of finalised invoices and record deletions wouldn't be supported.
4. automatically backs out new records, rolls back changes to some modified or deleted records
Rollback of finalised invoices wouldn't be supported.
Note that no approach can roll back records that have subsequently been changed by another user.
Regards,
-Tim A
Re: 1.7 5708 Check-in is not one transaction
I think a rollback at this point could be dangerous.
I have seen a number of times where reception staff get distracted during checkin and leave it open on the VISIT screen....ie dont press OK. In some cases the vet then consults and creates a note....which would be associated with the created visit.... I am sure TA can code around these sort of loop holes, but Rollacks being performed potential 1/2 hr later after creation doesnt sound like it would produce much consistent data?
Ben
Re: 1.7 5708 Check-in is not one transaction
The objects being rolled back would need to be restricted:
1. not edited by another user
2. not historical (e.g. patient history)
3. not an investigation (may have been submitted to lab)
That said, rolling back would not be my preferred option, as it could lead to inconsistencies (e.g. a patient form handed to the customer that used data that has been subsequently rolled back).
I would prefer to just list the objects that have changed, to allow the user to manually back them out.
-Tim