An Epic Journey - Part 2
Thursday, July 21, 2016
by Mike Renshaw
In my recent Blog post, I recalled the history that led LRS and Epic developers to create a documented and supported interface between our solutions. In short, neither software company was chomping at the bit to develop integration to connect with the other vendor’s software. The requirement came from the same place where most good ideas originate: a demanding customer base.
But why did these customers insist that LRS and Epic provide them with a tightly-integrated solution? What was the problem they were trying to fix? It was not anything Epic was doing wrong. But Epic software, like so many other business applications across all computing platforms, was designed to use the core services provided by the operating system. These services included the spooling subsystem and, in the case of Epic printing, that was the Windows print spooling subsystem.
Unfortunately Windows printing was really designed to address single user requirements. In that use case, error recovery depends on a user manually checking the printer for output, and manually reprinting from the application if the print job failed. The Windows spooling subsystem was not really designed for the demands and flexibility required for production use. Especially not for production use where patient safety was at stake.
To be fair, Microsoft has tried to improve the Windows server printing subsystem over the years but there are core design points that have never been overcome. For example, if a physical printer malfunctions (“What? A hardware failure in this day and age?”), there is no way to systematically direct all queued and new print jobs to an alternative printer while the broken one gets fixed. Similarly, there’s no way in the Windows printing subsystem to reprint jobs — which may be necessary for reasons as mundane as a user mistakenly grabbing more than one document from the output tray. And, possibly even worse in a healthcare environment, there’s no way to tell if the job had even been printed in the first place. This can lead to potentially serious security exposures. It certainly could be very important to know whether someone mistakenly walked away with a sensitive report or whether it never actually printed due to a technical problem.
Not only does the Windows printing subsystem make it very difficult to manage day-to-day activities like these, it significantly increases the burden on overall system administration. For example, if you have multiple Windows print servers and lots of printers defined across all of them, there is no simple way to view all of the Windows print queues in one single interface. If you are looking for an issue, like a print job hanging up a printer, you have to go from server to server trying to locate the problem. Adding to that complexity, if a change needs to be done to a printer defined across multiple servers, you have to manage that process one server at a time as well. Talk about creating excessive workload and significantly increasing the complexity of the overall printing environment! These are just a few of the time-consuming, business-interrupting issues associated with using Windows printing for production solutions.
It makes sense to match the right tools to the right business needs. As one Epic customer, Charles Harris at Duke University Health System in North Carolina recently said, “You do not use Microsoft WordPad that comes with Windows Operating Systems as your word processor; you buy Microsoft Word. For the same reasons, why would you use Windows Print Server software to handle output from your business critical applications? We chose LRS to handle that function for us.” You can hear Charles talking about his experiences at this link and see many other relevant customer quotes at this link. These and other Epic customers explain why they have turned to LRS for true enterprise-wide output management solutions.
Over the years, we have added many performance improvements and reliability enhancements including the ability to operate in load-balanced environments, support for the Epic Status Messenger feedback loop, output transforms to support Zebra label printers, and significant cost-saving and security improvements associated with Troy prescription printers. In addition, LRS now provides advanced secure pull-printing solutions and addresses the growing need for Epic printing capabilities in support of health care provider mobility across the workplace. Why? Because health care systems continue to evolve and we will be right there evolving with them, staying relevant and saving them money.