An Epic Journey — Part 1
Thursday, July 14, 2016
by Mike Renshaw
The last decade has seen a huge increase in the “meaningful use” of electronic medical record (EMR) systems by hospitals and other healthcare providers. In that time, both LRS and its customers have learned a lot about the role of healthcare documents and the best practices for managing them. In this article, I’d like to spend some time looking back at how our solutions for managing Epic EMR output have evolved and where they are headed in the future.
It was a May 2006 meeting in Galveston, Texas when I was first approached about integrating our VPSX product with a customer’s systems for an enhanced Epic printing solution. Their initial request was to simply use VPSX software for the backend Epic text printing from their UNIX servers, as they firmly believed that their Epic installation would be completely paperless within the next 3 to 4 years. To meet this immediate need, the LRS print submission utility, LRSQ, was installed on their UNIX servers to provide a more reliable print job transmission facility than the old FTP protocol. In addition, the VPSX solution was installed on a Windows cluster, which quickly resolved the missing print job issues they had been experiencing.
We took a significant step forward in July of 2006 when I was working with another customer high in the mountains along the border of northern California and Nevada. That customer requested a marathon two-day onsite working session between Epic developers and LRS. The goal: find a way to integrate the customer’s Epic Print Service (EPS) printing with the VPSX solution.
In that two-day period, we considered countless possibilities for a workable integration. It was during those sessions that the customer pushed both LRS and Epic for enhancements. At the project leader’s request, the Epic team developed a way to pass user IDs and job names with the Epic print jobs. That type of information had not been needed when just sending output to Windows print servers or directly to printers. But given the high level of management functionality available in our VPSX software, it made a lot of sense to provide more information regarding print jobs.
During those two days, the Epic team created the precursor to the VPSX_parse.pl script to communicate effectively to the VPSX solution. It was also during that session that we first discussed the concept of providing intelligent feedback from the VPSX server to the Epic solution (similar to the way we handled SAP print status). This would enable the VPSX system to notify the originating application that printing was successfully completed. After several more years, Epic implemented this same capability using the Epic Status Messenger functionality, and when they did, LRS was quick to add support for this function in the VPSX software.
Another year passed as the solutions grew until, while working with another California customer, the Epic development team enabled a crucial new function. This was the ability to run the EPS ERTF-to-PDF transform as an executable (EpicPrintService.PrintHost.exe) instead of solely as a Windows service. That new function worked in conjunction with three other components: the Epic comcli.pl print script, the advanced Vpsx_parse.pl script (enhanced so that Epic could send output to VPSX using the advanced LRSQ functionality), and the Epic EPS configuration file (eps.config). Together, these were the foundation of the solution that has been used by many customers throughout the intervening years.
As more and more customers have looked to LRS to enhance their Epic printing, LRS has continued to improve our solutions for Epic environments. For example, our program that runs the ERTF-to-PDF transform and prepares the output for printing has evolved over time. Starting as a simple Windows batch file, it became an advanced Perl script, and more recently advanced to a compiled interface called VPSX/EI (EI = Epic Interface). But we have no intention of stopping there. As the output requirements of our healthcare customers evolve, we advance with them to keep our solution relevant to their changing business needs.
So now you know a little about how specific customer requirements have helped improve our overall healthcare output management offerings. But just as important as how this happened is why we continue to work on improving the speed and reliability of EMR document delivery. Look for my next Blog post to learn the rest of the story.