UniViewer

Non-DICOM Imaging Studies Should be Accessible thru the EMR

Image-enabling the Electronic Medical Record (EMR) is generally the last step in providing the clinician with access to the patient’s complete Medical Record. The EMR itself is reasonably capable of managing and displaying the discrete data about the patient such as that data forwarded by measuring or monitoring devices, the medication list, documented allergies, etc.  An Enterprise Content Management (ECM) solution is the ideal way to manage the unstructured data associated with the patient such as scanned documents, diagnostic reports, lab results, care summaries…the non-image data. This unstructured data is easily accessed and displayed through a link from the EMR to the ECM solution.  Accessing and displaying the structured data associated with the patient, the medical images, has historically been more problematic.

Until recently, accessing and displaying the patient’s radiology and cardiology studies was reasonably straightforward.   The clinicians would directly access and launch the clinical display application associated with the radiology or cardiology PACS.  Alternatively those images being managed by a PACS could be accessed through the EMR by invoking a link to the studies associated with the radiology report being displayed by the EMR. Unfortunately there are number of problems with this approach to accessing/display a patient’s medical images.

  •  The clinician has to learn and remember how to use multiple viewing applications.
  •  Each display application is limited to displaying only those images being managed by that PACS.  There is generally no way to display images from different imaging departments (radiology and cardiology) on the same screen at the same time. This means the clinician has to bounce back and forth between two viewers to display disparate studies related to a single episode of care.
  • PACS-based imaging studies represent a fraction of the medical images that belong in the patient’s complete Medical Record.  There are imaging studies in other departments like Endoscopy and Ophthalmology that are not yet being managed by a PACS.  There are also all of those non-DICOM images that are being managed on mobile devices and PC’s.

The strategy for image-enabling the EMR should include a methodology and timetable for accessing the DICOM images (studies being managed in PACS and non-PACS scenarios), as well as what I refer to as the “informal images”, those images that are typically acquired in non-DICOM data formats like JPEG and MPEG. Examples include: [1] a series of JPEG images representing a burn wound that were captured by a digital camera or iPhone in the burn unit, [2] a series of JPEG images illustrating a skin rash that were captured during a series of dermatology office visits, [3] a series of MPEG clips taken during visits to the podiatry clinic representing the patient’s gate with and without the orthotic appliance. All of these imaging examples are clinically relevant to the patient, whether there is an associated formal report based on those images or not, and they rightfully belong in the patient’s complete Medical Record.

Current generation department PACS are focused on a specific imaging department.  They can acquire, manage and display most DICOM objects, therefore DICOM imaging studies, and the features and functions of the display are customized for the type of studies performed in that department.  These PACS typically do not handle non-DICOM image objects unless they are wrapped with a DICOM header and are associated with an existing DICOM study.  Department PACS typically do not handle imaging studies comprised solely of non-DICOM image objects.  These inherent limitations of the current generation of PACS is the major reason why the UniViewer (universal image viewer) was developed to image-enable the EMR.

There are a number of commercially available UniViewers that can accept and display non-DICOM images, but in many cases those images once again have to be wrapped with a DICOM header and associated with an existing DICOM study (added to the DICOM study as a new series) in order to be properly managed and recalled.  It may be appropriate to associate a series of JPEG images of a wound with the X-rays of the underlying broken bone, but in many cases, there is no formal DICOM study to which this type of informal imaging study can be associated. It is a standalone medical imaging study in its own right.

The ideal UniViewer application can accept, temporarily manage (if necessary) and display the non-DICOM images in their native format and therefore treat the set of images as an independent study.Slide1

The question is, how are these images acquired from the capturing device, assembled into a formal study, and how is the appropriate metadata that identifies the patient, the study, and describes the study type created and associated with the study?  Should this “acquisition application” be associated with the UniViewer, perhaps the VNA, or an enterprise workflow application?  Is there an argument for it existing as a freestanding application?  Regardless the source or configuration of the application, a methodology for creating an informal imaging study comprised of non-DICOM image objects should be a component of a healthcare organization’s strategy for image-enabling the EMR, because the clinicians will argue that they need access to the patient’s complete Medical Record, which should contain all of the clinically relevant images, not just radiology and cardiology.

Image-Enabling the EMR – a Hybrid Approach

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.

Standalone UniViewerThe 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.