In my Radiology department we have a huge backlog of files to be processed through our Patient Administration System. These thousands of files have traditionally been processed manually, which accounts for the main reason they were backlogged. To process them all would take a staggering amount of man-hours, and yet that was the plan.
As I tend to do, I looked at this task and decided it was incredibly inefficient, and came up with a workaround. I first discussed with our database designer the possibility of directly interfacing with the PAS database to process the files quickly, and after we dug around for a while realised this would not be possible in the current system. The solution then, would have to be to automate the processing through the PAS front-end.
My first iteration was to use the excellent keyboard & mouse macro software TinyTask Portable. I recorded the key and mouse movements/clicks required to process a single file and prepare to process the next. This did not fully automate the process, I still had to manually enter one piece of data per file, but it removed 95% of the repetitive clicking and inconvenience, and sped up the process.
This was not good enough however!
In my second iteration, I wrote an application using AutoHotkey to perform a similar job to TinyTask. It clicks an enters text, however it’s far more intelligent, and is 100% self sufficient. Once you’ve given it a pile of work to process, it will repeat the following process (simplified here):
While this process is simple, there are a lot of checks involved to verify that we are at the correct stage of the process. Unlike a dumb macro that will play and play, this macro reads text from the screen to confirm that particular windows are up and in particular locations. If the window is not up, it checks a few more times (in case the computer is a bit slow), and if the correct window still does not appear, it will halt and request user input.
The application can also handle a number of possible eventualities, such as duplicate files, patient IDs not existing in the database, etc.
These safeguards are what ensure that you can leave the application unattended.
Due to the logistics of having to tie up an entire PC to run this application, and that PC not always being in the same room you’re in (after all, the whole idea is to free up your time as an employee to perform other tasks, and you may need another PC for this), you can’t always directly monitor the application. What if you get it running, it halts after 2 minutes, and you don’t return to it for five hours?
So, I modified my application to record a log as it runs with some useful current and historical statistics. Such as the last time it processed a file, and how many files in total it has processed since I created the application. Then, I wrote a very small program to read this data over the hospital network, and alert the user if the application has not processed a file within a set interval.
The end result? We are saving a staggering amount of man-hours which can now be tasked to other things, as well as saving our own sanity in not having to click on the same things repeatedly for hours on end. And the best part? Putting this together was fun!