Accommodating Non-DICOM Images: Is Your Enterprise Imaging Strategy Diverse Enough?

I recently wrote an article on Enterprise Imaging for Radiology Business Journal.  While I cannot reprint that article here, you can access it using this URL link to the Journal’s e-publication. The article reinforces the concept of broadening the scope of enterprise imaging beyond consideration of the traditional, DICOM-oriented departmental PACS to include images produced during such procedures as surgery, endoscopy, ophthalmology, and numerous other “oscopies” and “ologies” from bronchoscopy to urology.  It also emphasizes the need to include non-DICOM as well as DICOM images, still-frame images as well as video clips, image sets that are the result of ordered procedures, as well as image sets that are simply captured on mobile devices during office visits or encounters in departments such as dermatology and emergency.

Organizations planning on replacing a PACS, deploying a VNA, or image-enabling their EMR with a universal viewer really should develop their Enterprise Imaging Strategy before making any major system purchase.  Every component in the Enterprise Imaging Strategy needs to plug and play with all of the actors up and down the line.

 

What is the Concept of “Enterprise Imaging”?

In the world of medical imaging, the term “Enterprise Imaging” has become the latest buzzword. Exactly what is meant by this term depends on who is doing the talking. In my experience, there seems to be a considerable amount of confusion surrounding this subject, which inevitably leads to shortsightedness.

Over the last nine months, I have been asked by numerous healthcare organizations to help them develop their “Enterprise Imaging” Strategy.  Early on it occurred to me to ask the individual or organization to define their meaning of the term “Enterprise Imaging”, since defining the scope of a project is key to meeting expectations. Depending on the individual(s) participating in the initial conversation, the term “Enterprise Imaging” can mean any of the following:

  1. Providing physicians and other caregivers access to the images being managed by their radiology and possibly cardiology PACS through their smart phones and tablets.
  2. Consolidating the majority of the organization’s medical image data in a Vendor Neutral Archive (VNA).
  3. Image-enabling the organization’s Electronic Medical Record (EMR) system.
  4. Providing PACS-like functionality to imaging departments other than radiology and cardiology.
  5. Managing and Displaying clinically relevant, digital photos and video clips taken with mobile devices (personal smart phones and tablets).
  6. Exchanging medical images with affiliated (but outside) healthcare organizations, clinics, or physician groups.

In my opinion, focusing on any ONE of the above is shortsighted, as all of the above will eventually become the objective, assuming the ultimate goal of the healthcare organization is to provide all physicians and caregivers access to each patient’s complete longitudinal medical record and making this data displayable with a general-purpose viewer than can handle all of these diverse data objects.  The complete medical record would include the patient’s medical images (structured data), diagnostic reports, laboratory results, prescription details, and care summaries (unstructured data), and the multitude of health details collected during years of office visits such as age, weight, smoking status, etc. (discrete data).

The EMR currently manages the discrete data, but the unstructured and structured data is typically spread all over the enterprise in various independent silos that often do not interact with each other. To say that there exists an interfacing and data exchange issue here is a massive understatement.

Healthcare Leadership must come to terms with the breadth and complexity of this more comprehensive concept of “Enterprise Imaging”.  In order to convey this concept and eventually define the true End State of the Enterprise Imaging Strategy, I find it useful to look at the subject through several different lenses.

Thestructorr_Magnifying_Glass_clip_art_mediumThe first lens organizes the data by object type and location.  In the following summary list, we see how all of the data that should be in the patient’s longitudinal medical record is organized.

  1. Unstructured Data
    • Scanned Documents
    • Care Summaries
    • Laboratory
    • Pharmacy
    • Voice Clips (WAV, AIFF, MP3, etc.)
    • Etc.
  2. Structured Data
    • “Ologies” (image-based diagnostic procedures)
      1. Radiology
      2. Cardiology
      3. Ophthalmology
      4.  Pathology
        • Biopsy
        • Anatomical
      5. Otolaryngology
      6. Urology
      7. Others
    • “Oscopies” (examination of an organ, body cavity, or joint by viewing through an endoscope)
      1. Endoscopy
      2. Arthroscopy
      3. Laparoscopy
    • Surgery (digital video documentation of a procedure)
      1. Minimally Invasive
      2. General
      3. Robotic
    • Point-Of-Care Ultrasound (POCUS)
    • Mobile Imaging (capture of JPEG and MPEG digital images with a smart phone or tablet)
      1. Dermatology
      2. Wound Care
      3. Emergency
      4. Etc.
    • Outside Images (electronic image sharing between organizations)
  3. Health Information Exchange (structured and unstructured data sharing between organizations)

The Unstructured data is best managed by an Enterprise Content Management (ECM) solution. Most EMR solutions are well equipped to mange the Discrete data associated with the patient, but their frequently limited indexing capabilities make them ill-equipped to efficiently manage either Unstructured or Structured data objects.  In most healthcare organizations, the Structured (image) data is currently being managed in department PACS or a Vendor Neutral Archive (VNA).  Another glance at the above list will confirm the observation that most healthcare organizations have barely scratched the surface when it comes to managing the Structured data associated with each patient (radiology and cardiology and frequently the endoscopy departments that have their local PACS). The questions that must be addressed by the Enterprise Imaging Strategy is how to acquire, manage and display all of the Unstructured data and the rest of the Structured data (image data) produced outside of those departments with a PACS.  The concept of a universal viewer must include more than just the ability to display the image data managed by the department PACS.

The first two categories in the above list cover data that is internal to the organization.  The third category covers the data associated with the patient that either must come from an outside affiliated organization, or must be transferred to an outside but affiliated organization. The interfacing and data exchange issues are even more critical in making this Health Information Exchange a reality.

The second lens organizes the data by object type and location.  In the following summary list, we see how all of the image data is divided based on how/where it is managed.

  1. PACS – Department-based data management
    • Radiology
    • Cardiology
    • Endoscopy
    • Dentistry
    • Ophthalmology
  2. Non-PACS – Modality-based data management (optional back-up server)
    • Endoscopy Camera systems
    • Otolaryngology Camera systems
    • Point-Of-Care Ultrasound system
    • Surgery Camera systems
  3. Informal – Mobile device-based data capture /management
    • Dermatology
    • Wound Care
    • Emergency
    • Etc.

Once again, most organizations have barely scratched the surface regarding enterprise access to their image data.  Besides the big imaging department PACS (radiology, cardiology, and sometimes endoscopy), a large percentage of the patient’s image data is tucked away in the smaller imaging departments either on the individual imaging modalities/devices or on an optional back-up server in that department. Neither the modalities or the back-up server in these non-PACS environments are typically connected to another department’s PACS, a VNA, or a universal viewer tied to the EMR.  Consequently, all of these images are currently undiscoverable and inaccessible. The Enterprise Imaging Strategy must consider how these images will be included in the patient’s medical record and thus made available to the EMR viewer.

The Informal image category presents numerous challenges. First of all, in many healthcare organizations there is already a significant amount of “informal imaging” already in use.  Caregivers and physicians are using their personal mobile devices to take digital photos or video clips of wounds, rashes, numerous clinical conditions, and evidence of physical abuse. If these images remain on the personal device, or end up on “C” drives under the desk or on thumb drives, they are HIPAA violations waiting to happen. Transferring these mobile images to the EMR presents a different set of challenges such as how to assign unique identifiers to the images so finding them is easier and faster than searching through all of the images in the typical film roll of a camera app.  As previously stated, EMR solutions are not designed to effectively index either Unstructured or Structured data. The Enterprise Imaging Strategy must consider how these informal images will be captured, edited, appended with unique patient/study identifiers and a study description, where they will be managed, and how they will be displayed. If they are clinically relevant, they belong in the patient’s medical record.

The third lens also organizes the data by object type, but in this case we simply distinguish between DICOM and non-DICOM.

  1. DICOM
  2. Non-DICOM
    • PDF (document)
    • JPEG (still frame digital image)
    • MPEG (digital video)
    • WAV, AIFF, MP3, AU (audio files)

Most medical imaging devices in the larger imaging departments (radiology, cardiology, endoscopy, etc.) support the DICOM standard.  Consequently, most department PACS are designed to manage and display DICOM image data objects, whether the image data is stored in the PACS as a DICOM object or not. But most of the imaging devices in the other Ology and Oscopy departments that use imaging do not create DICOM image objects. Scopes and cameras produce JPEG and MPEG objects.  Voice clips and audio files can be one of several object formats.  A majority of the Unstructured data objects in the Enterprise Content Management system are PDF objects. The Enterprise Imaging Strategy must consider how to deal with both DICOM and non-DICOM data objects.

If the healthcare organization considers what truly belongs in the patient’s complete longitudinal medical record, then the term “Enterprise Imaging” becomes much more inclusive. When we view the contents through the three lenses I have presented in this document, we begin to appreciate the complexity and therefore the challenges in developing the more comprehensive strategic plan.

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.

What is Enterprise Imaging WorkFlow?

The current generation of department PACS was designed over ten years ago. That statement also applies to the workflow and worklist components of the PACS solution as well as the system architecture. The workflow application was designed to assemble images for interpretation by a single physician group working in a single imaging department, working with a single department PACS. The concept of prioritization was placing a STAT icon next to a study ordered by an Emergency Room physician, and perhaps applying a background color to that line item in the list. Today, even mid-sized healthcare organizations are commonly made up of several amalgamated radiology groups (some owned, some affiliated). They have multiple EMRs and PACS solutions. These organizations have to manage complex cross-site credentialing issues while trying to deliver a common standard of care across the new integrated enterprise. In addition to this, the organization has to hold each physician group to similar performance goals. The worklist of each individual physician absolutely has to consider such input as: physician availability (schedule, locations, etc.), turn around time, physician RVU loading, sub-specialty reading, credentialing, critical results reporting, and peer review. None of the current generation department PACS have a workflow application that addresses today’s issues much less future issues we can barely imagine. A new generation of workflow application that is applicable to the enterprise is clearly needed.

Slide4

Enterprise Workflow Launching Most Suitable Display Application as determined by Study Descriptors

There have been improvements over the last ten years in the features and functions of the diagnostic display application, and yet most imaging departments have had to augment their core PACS application with a number of third-party specialty display applications. The physicians have to work through a pull down list of these applications in order to find the one that is the most suitable to use in the interpretation of the study they have pulled off their worklist. Similar to the way the enterprise workflow solution needs to provide a federated view of available studies to read, the enterprise workflow needs to provide federated access to all the available diagnostic display resources within a site or across a multi-site enterprise.

An enterprise workflow/worklist application is also one of the key components of the next-generation PACS. The PACS 3.0 configuration that I describe in the white paper recently published as a three-part series on AuntMinnie.com. is based on a Vendor Neutral Archive. The various diagnostic display applications that might be used in one or more imaging departments to interpret the images are simply plug-ins to the VNA. As the brain of the PACS 3.0 configuration, the enterprise workflow/worklist application is the entry point of all of the interpreting physicians in all of the imaging departments. The individual physician worklist presents the highly specific list of studies to be read and the underlying workflow launches the most appropriate diagnostic display application based on the pre-defined choices of the physician and the specific type of study selected from the list.

The new diagnostic imaging paradigm, PACS 3.0, is relevant to more than the radiology department. Medical imaging has always been an enterprise operation. Radiology and cardiology are the most obvious medical imaging operations, but many more clinically relevant medical images are generated in other departments. The images captured during an endoscopic procedure do in fact comprise an imaging study that is interpreted. Images captured during an office visit (dermatology) or throughout the course of treatment (wound care) are perhaps not considered an imaging study, but they nonetheless are clinically significant and should be retained as part of the patient’s medical image record.

The PACS 3.0 paradigm should be extended to all of the departments in the enterprise that utilize imaging. The endoscopy study can be ingested by the VNA and the enterprise workflow application can create the worklist for the Endoscopist, and that workflow application would most likely launch a basic clinical display application to review the study, whether the images are DICOM or JPEG.

A similar scenario can be applied to each of the other imaging operations, whether those images are DICOM or non-DICOM. The later may require a front-end application to create the study from a collection of individual images and associate the proper patient and study metadata to the study, but the VNA is the data repository and the enterprise workflow application is the entry-point for the physicians responsible for interpreting the images.

Now is the time for a single workflow/worklist application that can be used across the entire enterprise. Not only does a single workflow application simplify physician access, a single workflow application consolidates software applications, simplifies IT support, and makes economic sense.

The white paper I recently wrote on Enterprise Workflow would be useful in your strategic planning. The paper describes a key attribute of Enterprise Workflow being [1] its ability to auto-route the new image study and its relevant priors to the server hosting the display application that is most suited to the interpretation of the study, and [2] its ability to launch that display application in patient context when the study is selected from the worklist. This functionality is based on the workflow application’s ability to recognize and use the study descriptors and the physician reading preferences to determine the most suited display application. In this sense, the enterprise workflow application is really the brain of the enterprise medical image management solution.

What is PACS 3.0 and why is it the next thing in Enterprise Medical Imaging?

I recently wrote a rather lengthy white paper on the subject of PACS 3.0.  It was published as a three-part series on AuntMinnie.com.  I strongly urge anyone considering a radiology PACS replacement to read the series.

In Part 1 of this series, I share some of the problems and “myths” associated with the conventional, current generation of radiology PACS, referred to in the series as R-PACS 2.0.

In Part 2 of this series, I focus on the impact of vendor neutral archive and universal viewers (UniViewers) on the current radiology PACS paradigm and examine the opportunities of embracing these technological advancements.

In Part 3 of this series, I describe the PACS 3.0 concept and explore the benefits of making the switch to this new PACS paradigm.

At present, the PACS 3.0 market is clearly in the “innovators” stage of Geoffrey Moore’s technology adoption curve, but it’s important to gain an understanding of the concepts covered in this series if you are preparing for a change of PACS.  A move to the PACS 3.0 construct requires a “best-of-class” mentality, but a best-of-class approach to PACS should no longer be a cautionary strategy for a healthcare organization, especially those with specialized imaging departments, because many traditional R-PACS 2.0 configurations have already become best-of-class due to the various third-party applications that are currently required to meet the stated requirements.  The end of the R-PACS 2.0 paradigm has begun.

 

Current Generation of Radiology PACS is Ending

Radiology PACS is changing.  Something of a paradigm shift is occurring; from a current generation radiology PACS supporting interfaces to multiple third-party specialty applications, to a Vendor Neutral Archive (VNA) configured with multiple specialty display and workflow application plug-ins. In the former case, the PACS application is at the center of data management, and the PACS vendor continues to own the data.  In the later case, the VNA is at the center of data management, and the healthcare organization owns the data.

Slide1Ten years ago when the current generation of radiology PACS (termed R-PACS 2.0) was first introduced, the core PACS application provided all of the features and functions that a radiology department needed. This single-source, turnkey package included the tools for image acquisition and QC, both the diagnostic and the clinical display applications, and the worklist and workflow applications. The system focused almost exclusively on whatever was required to acquire, display and interpret radiology image data.  DICOM and HL7 were the ubiquitous data exchange interfaces.  The radiology PACS was a standalone system and data exchange with any other system was not considered a requirement (much to the delight of the vendors).

Slide2Over the ensuing ten years, most of the current generation PACS fell further and further behind in meeting the ever-changing needs of the evolving radiology department.  Unable to meet the requirements with in-house development, the easiest solution for many PACS vendors was to simply bolt on to their PACS the third-party applications that could meet those new requirements.  Examples include specialty processing applications for Nuclear Medicine, Digital Breast Imaging, 3D, and Fusion, as well as Discrepancy Reporting, Peer Review, and Analytics.  The latest zero-client, server-side rendering clinical viewers that so many organizations wanted to use to image-enable their EMR systems also became a bolt-on to the PACS.  The department PACS was no longer a single source solution.  Of necessity it had become a best of breed, multi-vendor solution.

Unfortunately the ten-year old current generation PACS is not even close to best-of-breed.  [1] A fat display client that requires a full pixel set download to the display platform is old technology and incapable of meeting performance expectations.  [2] The dependence on DICOM as both a data format and a transfer interface is severely limiting.  [3] The requirement that any third-party application be bound to the idiosyncrasies of the PACS is simply inefficient.  [4] The inability to support a dual-sited, fully mirrored configuration means there is no Business Continuity.   For these and many other reasons, the era of R-PACS 2.0 is coming to an end.

The PACS paradigm has shifted Slide3to PACS 3.0, which is definitely a best-of-breed ensemble of [1] VNA, [2] various diagnostic and clinical display applications, and [3] an enterprise workflow/worklist application, all of which simply plug into the neutral VNA.

A Best-Of-Breed solution implies a more difficult support paradigm, and that rightfully suggests risk.  However one must consider the fact that the R-PACS 2.0 solution that requires multiple third-party applications effectively makes those systems a multi-part solution as well…and most of the PACS vendors are not going to include those third-party apps in their SLA or their system monitoring solution.  It seems to me that meeting all of the requirements of today’s radiology department virtually demands a best-of breed solution.  Since most of the PACS vendors have clearly stated that their service support packages do not cover many of those third-party applications, these hybrid R-PACS 2.0 solutions present some degree of risk as well.

The greater risk however is the fact that these R-PACS 2.0 solutions will most likely have to substantially evolve in the next few years in order to meet the market challenges being presented by those companies whose display applications already feature the more advanced server-side rendering display technology and true BC configurations.  Such a dramatic overhaul to the R-PACS 2.0 architecture will most likely cost significant upgrade dollars…costs that are unlikely to be covered by the yearly software maintenance fees.  Unfortunately, if the PACS vendor that the healthcare system chooses to partner with does not make these dramatic upgrades, that organization will effectively be saddled with old technology for many years to come.

I invite the reader to learn more about the paradigm shift from R-PACS 2.0 to PACS 3.0 by reading my latest White Paper on the subject.  Aunt Minnie is publishing the paper as a three-part series, with the first part appearing on September 25, 2014.  Part 1 can be found at http://www.auntminnie.com/index.aspx?sec=sup&sub=pac&pag=dis&ItemID=108618

 

Today’s Radiology PACS – Shiny But Not New

It may seem a little late for commenting on observations from RSNA 2013, but then nothing has changed in the Radiology PACS market since then, so I think observations from three months ago are still valid.  Come to think of it, nothing really significant seems to have changed in Radiology PACS for several years now.  Pesky little things like bug fixes get attention each year, and functions that should have been standard years ago have finally shown up, but there have been very few major changes in system architecture.  Some semblance of Disaster Recovery has always been there, but a true Business Continuity configuration is still a reach for many of the PACS vendors.

Lots of radiology PACS on the market today are old.

havana3Interesting to see some of the PACS vendors developing a clinical display application based on server-side rendering and a zero (or at least near-zero) client. Why is the diagnostic application suite still a beefy client that requires delivery of the full lossless dataset to the remote display platform?  While the EMR user can access and view data on their Windows or Mac laptop, mobile tablet or phone, why is the radiologist still limited to a glorified PC?  Clinical image distribution and display has historically played second fiddle to the diagnostic application suite.  Why this sudden shift in focus from diagnostic to clinical?   Could it be that image enabling the EMR is the “new thing”, or simply the easier and less expensive engineering effort?  In the absence of meaningful change in system architecture and diagnostic display technology, perhaps the thinking is that a shiny new clinical viewer will serve as a differentiator among a handful of radiology PACS solutions that are otherwise old, and effectively the same core systems they were nearly ten years ago.

From my perspective, it seems that today’s Radiology PACS market is a zero sum game.  While some vendors with old technology are clearly losing market share, vendors with even “decent, old PACS” tend to lose as many existing customers as they gain new customers each year.  At 95+% market penetration, it’s a replacement market, where vendors attempt to take market share from each other.  Price pressure takes its toll on system sales revenue, so the real money is in service contracts.  But once again, if there is no net increase in customer base from year to year, that revenue stream is not growing. Only so much R&D funding is available each year, and apparently there is not enough revenue to fund “the next big thing” for Radiology PACS.   When revenues are flat or falling, profits also fall unless costs are reduced.  In addition to cutting R&D, that typically means vendors cut costs by eliminating staff through layoffs, or euphemistically “rightsizing”, “reorganizing”, spinning off or shutting down under-performing parts of their businesses.  When the Radiology PACS market went cold, the size of Radiology PACS companies shrunk.

In addition to standing pat with their existing technology, the Radiology PACS vendors have fallen behind in enhancing their solutions with those features and functions that radiologists and radiology departments need today to provide good patient care and stay competitive in their market. By and large, today’s Radiology PACS solutions do not support advance Breast Imaging packages to cover Full Field  Digital Mammography and Breast Tomosynthesis, as well as the ability to display multi-modality breast imaging presentations.  They do not include advanced diagnostic Nuclear Medicine packages to cover all the variations on mixed modality image fusion.  There is no advanced worklist functionality that can escalate studies on the read list to meet TAT requirements, no ED preliminary findings and discrepancy reporting, no call functionality and follow-up.  3D is basic if available at all, and remote access is typically poor. Today’s Radiology PACS frequently have no business analytics or data mining that would enable the department to discover and monitor the drivers of their business.

All of these highly desirable, if not necessary, features and functions are third party plugs-ins developed by smaller, more nimble and innovative vendors.  In too many cases, however, the interfaces required to plug these tools into the core Radiology PACS are not yet developed for a specific combination of vendor solutions.  It’s as though cooperating with the third party vendors to expand the core PACS through the addition of these plug-ins would be seen as an open admission that the PACS vendor has fallen behind.

Based on last year’s RSNA observations, it’s time for the PACS vendors to admit their system deficiencies, and start working on the solutions.  If keeping up with current requirements through in-house development is not feasible, then the PACS vendor must embrace the concept of third party plug-ins and get on with the development of the interfaces.  They should think of this strategy as a business necessity.  The VNA is steadily pulling image management from the department PACS.  Advanced clinical viewers that address both DICOM and non-DICOM objects will easily outperform those new PACS clinical viewers.  If a PACS vendor can’t keep up with all of the new radiology department application requirements, it will be a struggle to sell any new systems a few years from now, and that is the beginning of the end for the installed base.

Havana2As I departed Chicago last December, one strong image came to mind.  Pick any upscale neighborhood in Havana and you’re likely to see shiny cars parked at the curb.  The interesting thing is, none of these are new cars, they’re shiny old cars.  Some have new wheels, but they’re still old cars.  Today’s Radiology PACS conjured up images of Havana streets…shiny cars that are not really new, with underlying layers of faded paint covered in super-high-gloss wax.

Upgrading Department PACS with Entry-Level Vendor Neutral Archive Components

Organizations that appreciate the benefits that the Vendor Neutral Archive (VNA) will bring to the organization, sometimes find it difficult to finance the complete VNA solution in a single budget cycle. It is most unfortunate if the decision comes down to deploying none of the solution, due to a lack of funding for all of the solution. In my opinion, continued investment in a proprietary Picture Archiving and Communications System (PACS) archive and the continued accumulation of proprietary data is a flawed strategy.  In a paper sponsored by an unrestricted grant from IBM Systems and Technology I propose an alternative to the full VNA deployment, and discuss an affordable entry-level phase to a multi-phase VNA deployment strategy.

Any IT initiative that is focused on an upgrade to a department PACS storage solution, a refresh of the existing storage solution or a replacement of the disaster recovery (DR) storage solution initiated by an end of life letter, is an opportunity to carefully consider the value to the organization in continuing the proprietary PACS archive paradigm. Migrating the image data from the PACS to a properly configured entry-level VNA is the organization’s opportunity to once and for all normalize its image data and end the cycle of expensive and time-consuming data migrations that are required with every PACS replacement project. The hardware agnostic, entry-level VNA gives the organization the opportunity to apply advanced storage technology to all of its data management applications. All of these benefits can be realized at a fraction of the cost of a fully configured VNA, and in many instances for a price very close to that being quoted for the proprietary PACS archive solution.

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.

Unified Approach to Internal and External Image Sharing

Continuity of care, especially for patients that are transferred between organizations, suffers from the lack of any organized, efficient methodology of collecting and forwarding the required records and diagnostic images required for treatment. Healthcare organizations have been struggling with these problems for many years, and despite all of the digital technology and social media that connects us as individuals, our healthcare system remains broken. Rather than disparate and mostly unconnected solutions for transferring records and sharing images both inside and outside the organization, we desperately need a single, unified solution that will assure timely arrival of records and images to the caregivers that are responsible for the patient’s treatment.

This is the opening paragraph of a white paper I recently wrote under an unrestricted grant from eHealth Technologies.  The paper can be retrieved from the eHealth Technologies web site using this link.  The video of the webinar on the same subject can be viewed from the eHealth Technologies web site using this link.  The paper can also be downloaded from this web site using this link.

The choice of technologies is interesting, because of the multiple packaging options that are supported.  One combination of the technology components becomes a standalone electronic image share solution designed for image sharing between organizations as well as between the organization and outside physicians…a replacement for the dreaded CD exchange program.  Another combination of the components becomes a universal viewing application that supports image sharing within the organization through image-enabling of the Electronic Medical Record system.  A third combination of the components becomes a method for image enabling the local Health Information Exchange.  Each of the three image sharing problems can be solved individually, or a single unified configuration can be used to solve all three image sharing problems.

The title of the paper, “Unified Approach to Sharing all Images and Records to Streamline Continuity of Care and Achieve Meaningful Use” is a mouthful, but the paper itself does a good job of presenting the problems, critiquing traditional solutions, and presenting the eHealth Technologies solution suite.  I recommend reading the paper and taking a look at the webinar video, if you prefer a visual presentation