PACS Technologies

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.

Searching for that Next Generation PACS

I made the annual trek to Chicago this year, as usual right after Thanksgiving Day, to participate in the Radiological Society of North America meeting.  I don’t attend RSNA.  I “participate” in RSNA.  It’s like that adage that goes something like this “There are people who play the game, while there are people merely watching the game being played, and then there are those people who have no idea that a game is being played”.

I’m bringing up the adage, because I have seen it written and heard it said numerous times since the meeting that “There was nothing really new at this year’s RSNA”.  Anyone who actually holds that opinion must fall into that third group of people who have no idea that there is a game being played.

I had a number of reasons for checking out the current state of Radiology PACS.  I have clients with newly installed Vendor Neutral Archives that are now looking to replace their current PACS with a department-focused PACS that is a better fit with the VNA.  I had also recently read a very thought provoking article written by Lisa Fratt and published on line by Health Imaging on Nov 2, 2012, in which Lisa quoted lengthy comments on the state of Radiology PACS by Drs. Chang, Dreyer and Siegel.  I highly recommend reading that article, because my take away was that most of the current generation Radiology PACS, especially those in the larger booths, are not meeting the new list of expectations.

I think one of the problems that PACS vendors are having is investing development dollars at the same time they are being asked to reduce the sales price.  Today’s enlightened customer is asking for new features like multi-facility and multi-PACS workflow, powerful business analytics, and EMR integration to be packaged into a department PACS that should simply focus on what goes on inside the Radiology department.  A customer that has invested in a VNA and has already “image-enabled” the EMR with a universal viewer doesn’t need the department PACS to manage the data for its lifecycle, or provide the clinical viewer for the referring physicians.  We want the PACS vendors to add in the new workflow and analytics goodies, but reduce the overall price because of the removal of those applications that are no longer needed.  Apparently the call for a price reduction is falling on deaf ears.

Unfortunately that is the growing expectation among healthcare organizations that have invested in VNA and Universal Viewer solutions.  A growing number of providers believes that a department focused PACS is supposed to be significantly less expensive than the stand-alone, do-it-all model, that Dr. Chang refers to in the article as PACS 2.0.

Not only was I disappointed to learn after two days of RSNA booth visits that a department-focused PACS was merely 10% or so less expensive than the stand-alone model, but that the version of the PACS being demoed in the booths still does not include all the new goodies that are required.  That reminded me of yet another adage that was recently attributed to the new smaller packaging we see on the grocery shelves.  “Statements on the label such as New and Improved, really mean Smaller but just as Expensive.”

Based on what I saw at RSNA 2012, the major PACS vendors are failing to keep up with current market requirements.  So where is that next generation PACS, the one that sticks to the knitting in the department, includes the new Workflow, Analytics and EMR integration requirements, interfaces to the VNA, yet costs a good 20% less than the PACS 2.0 models?

They were there, on the floor, but you had to know where to look.  You had to be one of the people actually playing the game.

I’m going to do something I normally don’t do in my posts.  I’m going to name a few names along with the following disclaimer: I didn’t do an exhaustive search so I’m certain that I missed a few vendors and equally applicable solutions.   Therefore I am only commenting on the few that I did review.

If one were to describe the technology requirements for what we shall call the ideal next generation PACS, those requirements could be divided into three distinct subsystems: Workflow/Analytics, Visualization/Diagnostics, and Enterprise Archive/Distribution.  The adoption of the VNA and the Universal Viewer are well underway, and the arguments in favor of their deployment are well understood.  As for the other two subsystems that comprise what we think of as the department PACS, the three companies that I reviewed that offer commercially available Work Flow and Analytics Packages are: Compressus, Medicalis, and Primordial.  There are numerous companies that offer attractive Visualization/Diagnostics packages, but the application suite that I reviewed was developed by Visage Imaging.  Based on what I have seen and learned at RSNA 2012, in my opinion it is now possible to construct a next generation PACS by layering one of the three Workflow/Analytics packages on top of the Visage Imaging Visualization/Diagnostics package and interface this combination with a true VNA and the Universal Viewer package.  Once again, based on what I learned and in my opinion, that combination is substantially more potent than any of the PACS 2.0 solutions that the traditional PACS vendors are offering.

In my next blog I want to address numerous technology issues that had to be addressed by the participating vendors to make this best of bread combination work (like Directory database synchronization), and discuss some of the Service Level Agreement and Support issues that still need to be addressed.

Please stay tuned.  I think the Radiology PACS replacement market just got a whole lot more interesting.

PACS / VNA Compatibility Issues

While much has been written and stated on behalf of the Vendor Neutral Archive being the ideal strategy for managing medical image data across the enterprise, little has been said about PACS Compatibility with the VNA Solution.

There’s a good deal more to this compatibility issue than the PACS being able to communicate with and exchange data with the VNA using DICOM.

Most department PACS, including Radiology and Cardiology solutions, were not designed to inter-operate with a foreign archive.  This is not to say that PACS systems were not designed to occasionally share study files with an external DICOM conformant system.  Most PACS can accomplish this using the DICOM communications protocol.  What I mean is that most PACS system designs are predicated on the assumption that the PACS will be the sole manager of the study data for the lifetime of the system.  And because of this design assumption, many of the current generation of department PACS are ill suited to the tasks required to fully inter-operate with a VNA.

Since most organizations probably did not include this compatibility issue in their PACS selection process, it may come as some surprise to learn that interfacing their existing PACS to a VNA is going to require solving a number of significant in-compatibility issues.

I thought it would be useful to present a summary of the more significant interoperability issues, because organizations need to be aware of the potential problems when they begin the process of planning for a VNA deployment.  The right VNA solution will have to be able to address these incompatibility issues.  It might also be prudent to consider these issues when planning for the next department PACS purchase, because sooner or later, odds are the organization is going to see value in data consolidation, and system interoperability.

Here is a list of the more critical PACS / VNA compatibility issues.

DICOM and IHE…The PACS should support a full suite of DICOM SOP Classes covering the full array of image objects that belong in the patient’s longitudinal record, not just those objects created in the imaging department.  This would include most of the DICOM Structured Report objects, image objects from Ophthalmology, Endoscopy, Pathology, and some of the non-image Cardiology objects like Waveforms and Hemodynamic data.  The PACS should also support image-related objects like Presentation States and Key Image Notes.  The system should also support a few key IHE profiles including Consistent Presentation of Images Profile, Presentation of Grouped Procedures Profile, Key Object Notes Profile, Simple Image and Numeric Reports Profile, and Transparent Query/Retrieve.

Foreign Study Support…The PACS should support the import and representation of Foreign Studies.  Ideally the PACS would directly accept from the VNA, studies originally acquired/processed by another (disparate) PACS or Image Source that are being managed by the VNA.  At the very least, the PACS would be able to receive from the VNA a non-billable order and use that order to aid in the acceptance of studies originally acquired/processed by another (disparate) PACS.

Store and Remember…The PACS should be able to “Store” (archive) DICOM objects originally acquired by itself to a foreign archive (VNA), and then “Remember” that the objects are stored on the VNA when the time comes to retrieve them.

Study Aggregation…The PACS should have the ability to automatically and pro-actively search for studies in the VNA that were originally acquired by another PACS and stored in the VNA (i.e. search the VNA for relevant priors originally acquired by another PACS).

HL7 Updates…the PACS should not only be able to accept HL7 updates from the local RIS or HIS and apply those updates to the metadata in the PACS that is associated with the image data the PACS is managing, but it should also be able to forward the same metadata updates to the VNA.

Object Versioning…The PACS should have the ability to forward to the VNA any updates or changes made to the study data (both pixel and meta data) after the initial “archiving” of the study data, effectively “re-archiving” the image or study.

Retention Messaging…The PACS should have the ability to accept and utilize the messaging from the VNA that is designed to communicate what image and study files have successfully been purged by the VNA’s Information Lifecycle Management (ILM) application.

The subject of PACS / VNA Messaging is actually the most critical of the PACS compatibility issues.  Perhaps one of the more challenging aspects of PACS / VNA interoperability is keeping the two disparate systems synchronized with each other.  Most but not all PACS accept and utilize HL7 updates from the HIS or RIS.  Many PACS do not have a reciprocal mechanism for updating a foreign archive (VNA) with changes that were made to metadata or pixel data in the PACS.

An even more challenging issue is presented by the advent of the purging mechanism that is supported by many VNA solutions.  This issue is referred to in the above list as Retention Messaging.  If a PACS is configured with a small local cache, and it is programmed to allow the oldest studies to fall off of that cache when the watermark is reached, how does it communicate to the VNA that it no longer has that study?  Correspondingly, if the VNA purges a study that has reached its retention limit, how does the VNA communicate to the PACS that the study no longer exists?

A number of the more advanced VNA solutions are attempting to resolve this “synchronization issue” through the use of a number of standard and not-so standard messaging techniques, because the VNA vendors recognize that few PACS vendors have considered VNA compatibility in their PACS designs and fewer still have implemented the appropriate IHE profiles.  Some of those solutions include:

  1. Private DICOM messaging
  2. Custom HL7 messaging
  3. The new IHE Profile called Imaging Object Change Management (IOCM), which is still in development

The Imaging Object Change Management Integration Profile will specify how one actor communicates local changes applied on existing imaging objects to other actors that manage copies of the modified imaging objects in their own local systems. The supported changes will include (1) object rejection due to quality or patient safety reasons, (2) correction of incorrect modality work list entry selection, and (3) expiration of objects due to data retention requirements. It will define how changes are to be captured and how to communicate these changes.

The successful assimilation of disparate PACS into an enterprise Vendor Neutral Archive configuration will have its challenges.  I think it is better to fully understand these challenges in order to better prepare for them, and I suggest that this knowledge play a key role in the VNA selection process.   It also makes sense to include the knowledge of these issues in the next PACS selection process, and thereby eliminate as many future interoperability issues as possible.

True Business Continuity Requires Two Separated Instances of all Key Applications

I sat in on a webcast Wednesday, July 20, 2011, and noticed how the concepts of Disaster Recovery and Business Continuity were frequently paired…in the bullets and in the presentation…with the inference that if you had a DR solution, you had a Business Continuity solution.  That’s not the case.  A Disaster Recovery solution is basically a second copy of the data, usually stored remotely, so it can be accessed whenever it becomes necessary to replace the first copy of the data that might be lost or temporarily unavailable.  A DR solution could be as simple as an off-line digital tape cartridge or a DVD disk stored in a safe room.  It could be a near-line solution such as a tape library system or an on-line solution like a separate spinning disk system, either of which is directly attached to the PACS.  A second SAN or NAS storage solution paired with its front end gateway server could be located in a remote data center in order to increase its chances of avoiding whatever disaster might take down the PACS and/or its primary copy of the data.  The DR solution could be as elaborate as a Cloud-based storage solution, which often feature multiple data centers located in distant states.

In all of the above examples however, the original PACS application or a standalone display application like a web server is required to access and display that back-up image data. If the PACS application or any of the display applications are down, or in any way unavailable, the second copy of the data cannot be accesses and it cannot be displayed.  In this case, there is no Business Continuity.

A significant number of installed Radiology PACS are based on a single instance of the data management and display application, but they are configured with both a primary and a secondary storage solution, each located in separate data centers.  Depending on how geographically separate those data centers are, the secondary storage solution represents a solid Disaster Recovery solution.

On the other hand, very few Radiology PACS are configured with two instances of the data management application or the display applications.  And because there is only one instance of these applications, such a configuration does not have a Business Continuity solution.  With few exceptions, if the PACS application is unavailable, neither the primary nor secondary copy of the data is accessible.  If the display applications are unavailable, neither the primary nor the secondary copy of the data can be displayed.

A true Business Continuity solution requires two instances of the data management application, which can access either the primary or secondary storage solutions, and two instances of whatever display application the user prefers for accessing and displaying the data.  These two paired applications…data management and data display…should be geographically separated, so either of them can survive the disaster that might befall the other.

Since few PACS can be configured with multiple instances of its data management and display application, the current strategy for building a Business Continuity solution has shifted to deploying a dual-sited Vendor Neutral Archive and a dual-sited UniViewer.  The two separate instances of the VNA and the two separate instances of the UniViewer back each other up in the event of a disaster.  In the event that the only instance of the PACS and/or its only instance of the display application becomes unavailable, the new studies are probably interpreted at the modalities, and the priors are retrieved from whichever VNA is available and displayed using whichever UniViewer is available.  That is a true Business Continuity solution.  Take a look at my previous post regarding Failover Strategies, if you want to get a better idea of how primary and secondary subsystems back each other up.

Enterprise Archive is a Solid Concept that Doesn’t Go Far Enough

What’s in a name? Quite a bit actually.  The art of word-smithing is alive and well at some of the largest PACS companies.  Several major PACS vendors have recently announced their “Enterprise Archive” and proclaim them to be “multi-department image repositories” and “platforms for application-neutral image management”.

Sounds a lot like the concept of PACS-Neutral Enterprise Archive, but are these new Enterprise Archives really “PACS-Neutral”?

Over the last few years, most of the major Radiology PACS vendors have acquired Cardiology PACS solutions by acquiring the companies that developed those Cardiology systems.  Unfortunately the acquired technology was frequently different than the company’s existing technology, whether that was different OS, different directory database, different file structure, different programming language.  This is a major reason why so many Radiology and Cardiology PACS today stand separate, each with their separate silos of information.  So a major effort underway at the major PACS companies has been to “integrate” their Radiology and Cardiology PACS into a single platform, at least a single, shared long-term archive.  (A single shared directory database would be an even better solution.)  Now it is apparent some of the major PACS companies have finally succeeded in integrating their Radiology PACS and their Cardiology PACS into this single, ideal data management system, and the result is being promoted as “Enterprise Archive”.

Their concept of an “Enterprise Archive” is a significant improvement, but it doesn’t go far enough.

While the major PACS vendors were busy figuring out how to integrate their own PACS products into their own single, shared archive, a number of smaller more innovative companies were busy figuring out how to bring disparate PACS into a shared long-term data management system.  It seemed to the innovators that developing the technology to interconnect multiple PACS from different vendors would address a much larger problem, a problem that is far more representative of the real market.

There is nothing wrong with developing a technology and a marketing strategy that encourages Health Systems to invest in department PACS from the same vendor.  It’s just that at the end of the day (more realistically the end of five years), all those TeraBytes of data are still in a file format somewhat proprietary to that vendor.  And all the waving of the DICOM and IHE flags isn’t going to eliminate the need to migrate that data to the next archive, should the Health System decide to switch vendors at some future date.

Despite such interesting examples of word-smithing as “application-neutral image management”, the majority of this new breed of “Enterprise Archive” are not what is meant by “PACS-Neutral Enterprise Archive”.  Those archives are not capable of the high degree of interoperability (data exchange) with PACS from other vendors.  They are not capable of fixing the numerous DICOM sins that are firmly entrenched in the installed base, sins that limit our ability to effectively exchange data between departments and between organizations.

While the major PACS vendors were busy integrating their own PACS into their own Enterprise Archive, a market has emerged for the PACS-Neutral Enterprise Archive.  The former is just the latest incarnation of the vendor’s proprietary database, and the later is the multi-vendor and (finally) portable database that today’s market really needs.  And the big guys can’t catch up by simply word-smithing their marketing pieces in an attempt to hijack the better idea.

You don’t need a complicated RFP to drill down past the word-smithing and get to the truth of the matter.  Two simple and reasonably straightforward questions, if answered by the vendor truthfully, will separate what we mean by PACS-Neutral Enterprise Archive from what the major vendors are calling their Enterprise Archive.

Question#1: Is your proposed archiving system capable of Dynamic Tag Morphing?  Minimum functionality of Dynamic Tag Morphing refers to the ability to reference an internal library of PACS-specific Tag addresses (Group, Element) and Attributes (VR, VM), during the Archive’s internal process of modifying a DICOM Header in near-real-time when transmitting DICOM image data acquired on one system but destined for another.

Question #2: Does your Dynamic Tag Morphing application allow for the definition of rules around how Tags should be statically modified, typically based upon Boolean logic.  For example, if data originated at a specific facility using PACS A, is of a specific type, and is destined for another specific facility using PACS B, the archive should be able to dynamically modify any DICOM header values based upon static rules or a data source lookup (for example changing patient ID, Study Description, or Accession Number) to enable full utilization of the data by PACS B.

If you are having difficulty getting past the word-smithing, Gray Consulting has developed a useful and inexpensive Educational Program designed to introduce you and your organization to the subject of PACS-Neutral Archive.  The program consists of a 90 minute Webinar hosted by Michael Gray and based on PowerPoint slides, and a very inclusive 4-page list of Features and Functions that define the PACS-Neutral Archive.  Contact Gray Consulting at graycons@well.com for more information and a quote for the Educational Program.

New Breed of Teleradiology Poses Challenging Technology Issues

Radiology Groups reading studies forwarded from multiple, often remote facilities is not a new concept, but technical challenges frequently limit the effectiveness of this service and the resulting product of the effort is typically the final report and nothing else.

One of the major benefits of a Radiology Picture Archiving and Communications System (PACS) is its ability to preserve all of the work products associated with the study created by the technologist and radiologist during study preparation and interpretation.  Paper-based information from requisitions to consent forms can be scanned into the PACS and associated with the study.  The window/level settings, graphical- and text-based overlays created by the radiologist can be preserved as the Presentation State  of the images.  Key images can be flagged and shorthand text notes conveying the gist of the report can be created and saved as Key Image Notes.  And of course the radiologist’s final report completes the package. A PACS can preserve all of this clinical information along with the image data in an electronic file that can be accessed and viewed simultaneously by all of the caregivers responsible for the patient’s care.  And all of this radiology information can be combined with a patient’s cardiology studies, laboratory results, medication history and case summaries via the Physician Portal of the Electronic Medical Record System.

If the resulting product of a remote interpretation is nothing more than the final report, all of the caregivers are being deprived of the wealth of clinical information contained in those work products created by the radiologist during interpretation, the Presentation States, Key Image Flags and Key Image Notes.  Furthermore, it is not unusual for that final report to be delayed by several hours at best, while it loops its way through the editing and sign-off process.  That short-hand Key Image Note might easily be the first piece of clinical findings that reaches the referring physician.  In my opinion, a teleradiology solution that promises to deliver more than a preliminary finding should also deliver all of the work products along with the final report.

The technology challenges actually start at the very beginning of the teleradiology process.

It is well known that even current generation PACS are far from being truly open systems.  Idiosyncrasies in the DICOM headers can affect the way the images acquired by one PACS appear on a display screen of another PACS.  The teleradiology system needs to be able to correct for these idiosyncrasies.

Admittedly not all PACS support DICOM Greyscale Softcopy Presentations States (GSPS) or Key Image Notes (KIN), but that is bound to change in the near future, so a new Teleradiology system should support both of these DICOM SOP Classes on day one.

My point is that the deliverable product of a remote interpretation should be the final report AND all of the work products associated with that study.  That means returning the new version of the study, along with all those additional work products, back to the originating PACS.  That brings up another technical challenge.  The originating  PACS will most likely match this new version of the study with the original version, based on the patient Name, Accession Number, etc., but how does the originating PACS determine that the study status has changed from unread to read?  Hopefully the originating PACS can accept an HL-7 update from the local RIS when the associated report is received.  IF not, this is a bit of a loose thread.

Another issue is that of the relevant priors.  Does the technologist have to manually forward the relevant priors along with the new study?  Is the originating PACS capable of auto-forwarding both the new study (based on predefined meta data criteria) and the relevant priors to the teleradiology system?  And at the end of the interpretation, what becomes of the relevant priors, and for that matter the new study?  Is all of this study data simply deleted from the teleradiology system?  Seems like a waste of bandwidth to keep forwarding relevant priors over and over again, each time a new study is generated for the same patient. Wouldn’t it make sense to “archive” all of the studies received by the teleradiology system, so they are available for comparison purposes?  That means the teleradiology system would have to be able to partition its Directory database by originating facility, and possibly deal with multiple Medical Record Numbering Systems.

My argument is simply this, the product of a remote interpretation should be just as inclusive as the product of an in-house interpretation, for the benefit of the caregivers and the patient.  The technology required to achieve this application is considerably more than yesterday’s teleradiology system.  In fact the technology is beyond most current generation PACS.  The ability to accept, display, and manage radiology study data from disparate PACS and return an interpreted study with all the associated work products to the originating PACS in a format that that PACS can recognize as its own is the purview of the PACS-Neutral Archive.

Radiology Practices and Health Systems interested in remote interpretation of Radiology studies would be well served if they carefully consider their respective expectations of such a service and then fully investigate the claims of the system providers, many of which may not fully appreciate the technical requirements of such a system.

Cost-effective Business Continuity Solutions – So much more than Data Back-up

Most Radiology PACS currently in use have some sort of data back-up in place. At the very least, the Directory database and the Data database are backed up daily to digital tape. In my opinion, digital tape is not reliable and the problem is you don’t know what data you have lost until you try and retrieve it. My low opinion of digital tape is supported by a number of reports from the field. I suspect the vendors that continue to insert digital tape back-up solutions in their early round quotes, do so in order to keep the price of the system down, but a much better solution is worth a few dollars more.

The “tape-less” back-up is a much better back-up solution. Instead of digital tape on a shelf or in a mechanical jukebox, a far more reliable and performance-oriented solution is to store the back-up copy of the Directory and the Data on spinning disk. Thanks to today’s pricing, a multi-processor, multi-core server coupled with a disk-based storage solution is only slightly more expensive than a digital tape library. I think the reliability is worth the additional investment.

Why stop there?

Instead of just writing a copy of the Directory on the back-up storage solution, why not install a second instance of the Directory application (Oracle, Sybase, DB2, SQL, etc.) on the back-up server? Now you have a reasonably cost-effective Disaster Recovery solution, depending on where you have physically placed that back-up system.

Why stop there?

Why not add a second instance of the PACS application to the back-up server? Now you have a reasonably cost-effective Business Continuity solution. Of course this complicates the PACS application considerably. The optimal software configuration would have the two Servers (Primary and Secondary) functioning in an “Active-Active”mode, and that would mean that the Directories are being automatically synchronized in near-real-time, and the study data is being copied from Primary to Secondary on a fairly regular basis.

Only the newest generation of PACS can support this configuration. Most of the PACS being sold today can support a “tape-less” back-up server, but they do not support a second instance of the Directory application on that back-up server. The few that do support a second Directory do not support a second instance of the PACS application. Fewer still that support a second instance of the Directory and the PACS application have the back-up system operating in a standby mode. The Back-up takes over only when the Primary is off-line for scheduled or unscheduled maintenance. While this version of back-up may not sound so bad, the fact is that the failover and eventual reconstitution processes are often manual and labor intensive.

The point in all of this is, with today’s cost of hardware it doesn’t make sense to settle for a back-up solution with questionable reliability, when a much more reliable Business Continuity solution is affordable. The problem is most PACS currently being sold are “old” generations of system architecture wrapped in pretty GUI and flashy 3D applications. While GUI and display applications are important, I believe that the system architecture that supports a solid Business Continuity solution is more important, and sooner or later those old generation PACS are going to be upgraded. You can tell a lot about the longevity of a PACS, by investigating the various back-up solutions that it can support. Why start a five year contract with an old PACS? Do you have room for a forklift in your data center?