Most folks that use LRS in their Epic shops have learned about the print workflow changes in the post-Epic 2017 era. The introduction of webservice transmission was a major change. Epic’s shift from proprietary output formats to open formats like PDF and XPS before sending the data to VPSX was another. Both of these have affected the way we manage documents from Epic applications.
High Availability
The importance of High Availability (HA) functions seems to increase with each passing year. Health systems are getting larger and are serving more patients than ever before. As such, outages must be avoided. My colleague Brent Black pointed out in a recent talk that 99% uptime is simply not good enough. 99% uptime means that for one day out of every 100, printing doesn’t work. Imagine if every three months or so, no one could print After Visit Summary (AVS) documents, barcode armbands, tamper-proof prescriptions, and other critical output. No, there must be a bunch of digits after that decimal point to really accommodate the need. The closer to 100 the uptime percentage is, the more acceptable it will be to the organization. (Not “better” or “good”, but acceptable!)
The obvious path to such reliability numbers is redundancy. Spread the burden of Epic application printing across two or more VPSX servers, right? Okay. Problems solved. Let’s go home.
Well, no… it’s not really that simple. LRS has long worked to make this a possibility in our environment, and can, for the most part, handle document availability just fine. But there are hitches. Some printers will get confused when being sent jobs from more than one queue. Labels can intermix at the printer or go away entirely. Documents may go missing if the printer is not robust enough to handle document issues like these.
Another problem area that is the search for failed print jobs. If there is a printing problem, which server is highlighting the issue? Which job needs to be examined or redirected?
In an Epic environment, a basic LRS recommendation is to separate the conversion of data from the delivery of data. Create two or more servers that simply convert the output into print-ready form. These servers can run in parallel and deliver documents simultaneously with no problem. Next, you can establish two servers where all the printers are defined. Only one of these servers should be active at a time, and you can have LRS’ AlertX utility monitor the overall environment for problems. That way, only one queue will deliver to a printer at any one time, eliminating a potential source of conflicts. With this configuration, any server can be pulled out of the rotation for maintenance with no effect on printing.
Vendor interaction
Everyone knows that LRS and Epic software solutions work well together. The primary reason for this is simple – both companies want our mutual customers to succeed. Many of our customers – perhaps all our customers – have been in situations where Epic and LRS technical personnel are on the phone working toward a common goal. This has always been and will continue to be the case.
What fewer customers know about is the Epic AppOrchard program. A few years ago, Epic started promoting the use of Epic APIs to vendors. While the LRS relationship pre-dated this program, LRS decided it best to join and participate so that we have more knowledge about Epic’s abilities and its customer’s needs. To take advantage of the Epic AppOrchard program, there are things customers must do in addition to what LRS and Epic do behind the scenes. Because our VPSX solution is an official App in the Orchard, LRS is issued Client IDs. These Client IDs must be used with the Epic APIs to identify the vendor.
What does this mean to the customer? Well, each LRS customer that is an Epic user must register with the AppOrchard. Most LRS customers have done this, but if you work for one that hasn’t, please do so. Epic has documentation for how to do this. LRS has a copy of this documentation as well, and we are happy to share it with you.
The other important bit is to stay current with the integration software. You are probably aware that the Client IDs are placed in the Epic Endpoint record (E0A) when these are defined to the various EPS servers. What you might not know is that starting with the February 2019 release of Epic software, the Status calls must provide the client ID as well. The way a customer can ensure that this is in place is to simply make sure that their VPSX/EI software is at V1R2 patch level 10 or higher. Also, please remember that there are two client IDs – one for production and one for everything else. So, you need to check that the VPSX/EI interface shows which servers are production so that we send the correct Client ID.
Labels
In the pre-Epic 2018 world, LRS used Epic executables for the formatting of labels. Starting with Epic 2018 and later, these executables are no longer available to the VPSX software. As such, LRS had to provide a new mechanism that can handle the labels as we receive them from Epic (usually in PDF or XPS form) and create print-ready data streams for the many types of label printers out there. LRS created our new PDF to ZPL transform for this purpose, and we now require our Epic customers to run this transform.
The name is a little deceptive. From the product title, one might think that it simply creates the Zebra print language (ZPL), but we have continued to expand the product capabilities to print in other ways as well. If your company uses Intermec or Datamax devices, for instance, that do not print ZPL, we have mechanisms that allow the creation of those native languages as well as most any label device.
LRS continues to evolve our solutions to meet the meet the needs of our Epic customers. But the most important element is you, the customer. If you notice printing issues or have questions, please contact us. You can do that through our support organization or through the sales side of the house. We are committed to the success of your organization, your IT team, and the patients you support.