Market adoption of the Electronic Medical Record system in the United States has soared over the last three years, and penetration is expected to continue at a brisk pace for the next few years. Markets and Markets.com estimated in June 2011 that the compound annual growth rate of EMR systems in the US market would be 18% for the period 2010 to 2015. Healthcare organizations have recognized that taking clinical records digital is a more efficient methodology for managing and communicating the patient’s longitudinal medical record. EMR sales have no doubt also been stimulated by the carrot and stick approach that the government is taking with the Meaningful Use initiatives spread over this same period.
The EMR alone is not designed to be the single central repository of all of the patient’s clinical records. Most healthcare organizations in the US quickly discover that after investing many millions of dollars, burning untold man-hours in the associated training programs, and imploring the medical staff to actually use the system…after the first 30 days of experience with the system, that frustrating question from the medical staff is
“Where are the images?”
Clearly, a key part of the EMR project must be to determine how to deliver the complete longitudinal medical record to the caregivers…including ALL of the medical images.
The long-term plan must include not just the images from radiology and cardiology, but also those from pathology, ophthalmology, endoscopy, dental, and those captured by digital cameras in surgery, burn care, dermatology, etc. Anything less is simply an incomplete plan.
One strategy for image-enabling the EMR is to interface it to the department PACS. Lots of EMRs are interfaced to the radiology PACS. Of course that doesn’t deliver access to the cardiology images, unless the radiology PACS manages those images as well. The major flaw in this strategy should be fairly obvious…it would be fairly expensive and very inefficient to push all of the images form the various imaging departments to the radiology PACS. Another flaw with this strategy is using a radiology-oriented viewing application to visualize images from each of those other departments, not to mention the non-DICOM formatted images.
An alternative is to build an interface between the EMR and each of those department PACS and free-standing imaging systems, but that strategy is flawed as well. Not only would it be expensive to build and maintain all of those individual interfaces, but the physician user would be forced to learn and use multiple viewing applications, and it would be virtually impossible to combine images from multiple disciplines on the same viewing screen.
The long-term plan should also include a methodology for delivering all of the image types to platforms far more ubiquitous than desktop computers located on desks in nursing units and offices. It means delivering them to laptops, and tablets and even smart phones. Currently the majority of department PACS systems feature clinical viewing applications that are thin clients that run on Wintel platforms. The few that are web-based are also limited to Wintel platforms and a specific browser. In this sense, the typical clinical viewing application incorporated into the department PACS is largely unsuited to image-enabling the EMR.
The superior strategy for image-enabling the EMR is to use a zero client application that features server-side rendering that can be hosted in a virtual server environment. The HTML download of the rendered image by the rendering server easily overcomes the traditional physical limitations of low bandwidth connections. The zero client means that the user can pretty much use whatever platform they choose: Windows, Mac OS, Linux, iOS, Android, etc. and any browser they prefer.
This class of standalone zero client viewing application is generally referred to as a Universal Viewer, or “UniViewer” as I have referred to it in many of my writings.
Some of the earliest Universal Viewers were add-ons to the Vendor Neutral Archive. The viewer could then draw upon the VNA for the image data. More importantly, the nature of that integration meant that the vendor could use a web services interface like WADO-RS to transfer the images between VNA and rendering server, so performance was not burdened by the relatively slower DICOM transfer protocol. Unfortunately, image-enabling the EMR in this manner means deploying a combined VNA and Universal Viewer…an expensive and time-consuming IT project.
Image-enabling the EMR should not require deployment of a full VNA.
Many of the better Universal Viewers have the ability to aggregate image data across multiple image data repositories. They can be directly interfaced to multiple department PACS as well as free-standing workstations or imaging devices that archive either DICOM or non-DICOM image data. They can take a URL call from the EMR interface and query/retrieve a specific image, a specific study, or a specific patient’s entire longitudinal medical image record scattered across multiple repositories.
Unfortunately the Universal Viewers are currently limited to the use of DICOM communication transfer protocols with the department PACS, largely because that’s the way the PACS vendors want it…standardized but slow. Consequently the EMR user’s ad hoc query through the Universal Viewer of a study being managed by a department PACS would be painfully slow. Not because the Universal Viewer is slow to render and deliver the HTML version of the images, but because the Universal Viewer is stuck with DICOM Q/R as the data retrieval mechanism. The present work-around to the DICOM bottleneck is to give the Universal Viewer’s rendering server a large image cache.
The purpose of the rendering server’s cache is to pre-stage those new and relevant prior studies that the EMR portal users are most likely to request for viewing. The larger this cache, the larger the volume of new studies that will be available for access and the larger the percentage of relevant priors that will also be available for access. An organization should be able to monitor its existing PACS in order to determine the average number and age of relevant priors that are being reviewed along with new studies. A cache large enough to manage the most recent year of all new studies would probably be holding 90+% of the relevant priors. Of course the advantage of the Cache is defeated unless the interface between the cache and the rendering server is something like WADO-RS.
There are several workflow solutions to getting the images from the PACS to the Cache. One approach is to have the Rendering Server query each PACS for new image studies on a regular basis. This approach requires that the rendering server have a mechanism for remaining synchronized with each PACS to make certain that it always has the latest version of the study. Using this approach, image availability to the portal user is highly dependent on the specific PACS, as some PACS will respond to an external query and release the images as soon as they have been acquired, while other PACS will not release the images until after the study has been read. A second approach is to equip the Universal Viewer with an HL7 Orders interface and a relevant prior algorithm, so it can use the HL7 Order feed to trigger a pre-fetch of the relevant priors from the appropriate PACS and a Q/R of the new study. There are a few other options that can be applied to very stubborn PACS solutions that are beyond the scope of this article.
Regardless how the images are retrieved from the PACS, the issue once again is the scalability of the cache as well as the directory database and file system that is managing the cache. Reducing unwanted delays in image retrieval means extending the cache to include as many probable priors as possible. There is also the issue of data purging. The Universal Viewer application needs to be able to use several variables such as study age and time-last-accessed to determine when it purges study data from the cache. Many Universal Viewers are not designed to manage a large scalable Directory or Data database, nor or they very smart about the purge strategy. At some point, the cache starts to become a somewhat sophisticated data management system. At what point is this Universal Viewer cache another island of data that becomes a burden to IT? On the other hand, a Universal Viewer that can only support a minimal cache and a simple FIFO purge policy is probably not going to keep up with performance expectations. An organization should not be surprised to see the cache continue to grow in size to meet the expectations of the users.
So here is my suggestion…start off with a Universal Viewer application interfaced to a single instance of a Vendor Neutral Archive licensed to simply act as the cache for the Universal Viewer’s rendering server. Most combinations could and would use web services like WADO-RS (not DICOM) to transfer the image data between the VNA and the rendering server. VNAs support all types of image acquisition and workflow schemes, so they could easily handle any of the existing PACS in the field. Unlike most of the Universal Viewers, VNAs can be scaled all the way up to a full VNA configuration that is managing all of the enterprise image data. Unlike the simple Universal Viewer cache, the VNA could also be performing a normalization of the incoming data, so population of the cache over an extended period of time combined with cancellation of the purge mechanism would effectively become a pro-active DICOM data migration…something that every organization will eventually have to do when those PACS are replaced. This is an ideal upgrade path for a Universal Viewer that (by itself) is limited by its cache scalability and really has no upgrade path beyond image-enabling the EMR. This is also an excellent strategy for leveraging current demands for image-enabling the EMR into the VNA that is the better solution for enterprise data management.