Gray Consulting

Tue, 23 Jun 2009 20:57:04 GMT

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.

Thu, 18 Jun 2009 18:53:01 GMT

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.

Thu, 28 May 2009 20:30:47 GMT

What Image Management Technologies will Qualify for ARRA Stimulus Funding?

Recently I have received a number of inquiries regarding the stimulus funding that will become available under the newly enacted American Recovery & Reinvestment Act. "What image management technologies will qualify? More specifically, "Would a PACS-Neutral Archive qualify for stimulus dollars?" I thought it would be useful to post my opinions on this subject, here on my web site.

In my opinion, yes. I believe a PACS-Neutral Archive would qualify under two scenarios. The most obvious scenario is as the multi-object content manager for the Electronic Medical Record system. This assumes of course that the PACS-Neutral Archive "package" includes the appropriate Display software. This scenario is applicable to organizations that have an EMR. Since most (if not all) current EMR solutions do not include their own image display application, the PACS-Neutral Archive "package" would be expected to include an "integrated" display application.

The second scenario is as the self-contained multi-object content manager and simple display application (zero foot print / server-side rendering) that could be accessed directly over the internet (not through a Portal). The display application should have HIPAA-compliant security and logging capabilities to handle direct access. This would meet ARRA requirements for simple and inexpensive internet access. This second scenario would be applicable to organizations large or small that do not have an EMR, so this solution would support image access and display via direct access over a LAN or directly across the internet.

"What aspects of 'meaningful use' would the PACS-Neutral Archive fulfill?"

I believe that the intent of "meaningful use" is providing the physicians with the ability to quickly and easily access imaging reports and associated images. The keys are quickly and easily, because anything less will not be used by the physicians. Another key feature would be the ability to assemble images from multiple disciplines (Radiology, Cardiology, Pathology, etc.) in the same viewing session. This is something that cannot be done today in an environment where each imaging department PACS has its own URL interface to the EMR Portal and its own separate display application for its own images. In my opinion, this approach would discourage use, because learning different viewers would be tedious and flipping back and forth between viewers would be time consuming.

The built-in audit logs could be used to create reports that would indicate the level of physician usage: how often they used the system, what they were viewing, and the length of the session. This method of reporting would meet the government's requirement for a simple usage report that would not overly burden the organization.

In this context, it is interesting to point out that the most meaningful usage would probably be skewed towards the attending physicians, who are primarily report users. The significance being that this user profile would most likely be satisfied with the J-PEG lossy version of the image that could easily be server-side rendered and delivered to almost any kind of computer platform because the display application would be very small if not zero. In contrast, the specialists/surgeons are already using some kind of image access, probably directly to the Radiology or Cardiology PACS, because they have to work with the images. It is the attending physicians who actually make clinical decisions that affect patient care that would benefit the most from a multi-modality image delivery system that was easy to use and fast. I think this is what the government wants to stimulate, as timely clinical decisions are directly related to length of stay and therefore cost!

"Would a departmental PACS system qualify for stimulus finding?"

In a my opinion, no! A department PACS can provide physician access to that department's reports and images, but it typically does not support access to all of the clinical information and images from those other departments. It is widely known that most Radiology PACS have failed miserably to meet the needs of the referring physicians. The display applications intended for use by the referring physician are frequently difficult to use and time consuming.

I suppose an argument could be made on the behalf of the department PACS, IF the referring physician display application were improved, but in a situation where a referring physician had a choice between using a department PACS display application or a multi-modality display application, my money would be on the later, and I think the usage logs would bear that out.

It is also important to point out that the department PACS are unlikely to be able to aggregate clinical information from other information systems (lab, medication, and care summaries) anytime soon. It is also highly unlikely that a department PACS would be able to aggregate image data from other departmental PACS. The absence of these capabilities would further decrease the usefulness of the department PACS in the context of "meaningful use".

Mon, 27 Apr 2009 18:38:19 GMT

Federal Stimulus Funding for Health IT will drive adoption of PACS-Neutral Archives

A post on AuntMinnie's PACS Forum on April 21 posed the question "Will EHR impact PACS?". A number of the regulars on this forum, including myself have posted their opinions. I find it interesting to see a number of individuals suggesting that the Electronic Health Record (EHR) will morph into some kind of Super PACS supporting Radiology, Cardiology, etc. and featuring a universal viewer.

Last time I checked, the major PACS vendors were still having difficulty integrating their own Radiology and Cardiology PACS into the same platform, so I don't hold out much hope for these PACS solutions suddenly becoming EHR systems, nor do I believe the EHR vendors are going to burden their development schedules with the effort it would take to add Radiology and Cardiology data management and display applications to their systems.

PACS will continue to focus on the individual imaging departments work flow and diagnostic applications, and EHR will continue to focus on aggregating all sorts of clinical information required to manage a patient's course of treatment or general healthcare. I realize that all this stimulus money targeted at EHR usage will "stimulate" the market, but I don't think there is enough time for any of the vendors of any of these systems to reinvent their wheels. The fastest route to market is to simply sell what already exists.

EHR systems have historically deferred to the PACS for the image management and the clinical review applications. A relatively simple interface, currently based on a URL call, retrieves the image data referenced in the EHR listing and activates the corresponding PACS display application to display the images. This model has been working just fine for some time now, with Radiology PACS being the principal data management system.

Unfortunately, as additional department PACS are deployed, each additional PACS would require its own URL interface to the EHR. Multiple interfaces mean individual, separate viewing sessions based on individual separate display applications. The physicians would have to learn to use separate and different display applications. There would be no way to consolidate all of a patient's images from separate departments into a single viewing session within a single viewing application.

My answer to the question posed by the AuntMinnie thread is that the stimulus package will most likely have an immediate impact on the PACS-Neutral Archive rather than the department PACS.

Assuming the EHR will continue to defer to another system for the image data management and display applications, it makes much more sense for that other system to be a consolidated PACS-Neutral Archive (PNA) than multiple department PACS. The PNA is much further ahead of even the best departmental PACS in managing image data from disparate systems. The PNA is much further ahead of the best departmental PACS in managing image data for the lifetime of the study. The PNA is the better platform for managing non-DICOM image data and supporting a multi-modality universal viewing application. Even before the promise of stimulus money, the PNA had a very positive ROI based on the cost of future data migrations avoided.

In conclusion, I don't see PACS enveloping the EHR applications, and I don't see the EHR enveloping the departmental PACS applications. I see the EHR and the PACS remaining pretty much what they already are, separate entities. Because of that focus, I do see them becoming more proficient at their respective tasks. As a consequence, I see the PACS-Neutral Archive coming into its own as the central multi-modality image data repository and provider of the UniViewer display application.

Thu, 16 Apr 2009 22:08:19 GMT

PACS-Neutral Archive Action Plan

Interest in the concept of PACS-Neutral Archive is growing as evidenced by the number of new inquiries reported by several vendors responding to my informal poll. However a significant number of those inquiries are for basic information: "What exactly is a PACS-Neutral Archive?", and "Which PACS are compatible with a PACS-Neutral Archive?". So my suggested Action Plan would start appropriately at the beginning with a foundation in the concept.

Obviously it would be useful to have a consolidated list of features and functions that comprise a PACS-Neutral Archive (PNA). Not only would that list help explain the concept, it would help differentiate the various vendor solutions in the current market. Unfortunately that list does not seem to exist. Vendor-Neutral Archive, PACS-Neutral Archive, Enterprise Archive are just some of the terms being used to describe what is supposed to be the same concept. Frankly I believe that all of these different names and the associated product descriptions are causing confusion. It almost seems like the concept is being invented and reinvented as we speak.

Actually that's not far from the truth.

The basic concept started with a few simple objectives like consolidation of separate PACS archives and replacement/upgrade of old storage solutions, and soon included normalization of all of the data to a standard data format, hence the "PACS-Neutral" moniker. This last feature was tacked on as soon as it became obvious just how painful and expensive DICOM data migrations were going to be in future years. In truth, the list of Features and Functions for the PNA has been evolving at a rapid pace, as each new problem surfaces and a matching solution is developed. At this point in time no consolidated Feature/Function list exists, at least none that I am aware of. And while the list would surely stretch to nearly 100 items, the following major features will easily separate the more promising solutions from the pretenders.

Open Storage Solution - supports multiple media vendors and multiple storage solutions
Dynamic DICOM Tag Morphing - on-the-fly conversion of data formats in support of data exchange between disparate PACS
Methodology for accepting and managing both DICOM and non-DICOM data objects
HL-7 interface support
Pre-fetching and Auto-routing support
Automated and Manual QA/QC support for interfaces with non-PACS data sources
Intelligent Information Lifecycle Management - data movements internal and external to the system based on meta data
Automated Data Purge with manual supervision
Set of integrated display applications, one for simple viewing, the other for advanced viewing of the image data through the EMR Portal
Pseudo Master Patient Indexing capabilities and optional full-featured MPI
Creation of XDS-I manifest and optional XDS-I Registry and Repository applications
Integrated remote system monitoring application capable of tracking hardware and software operations

Step two of my suggested Action Plan is to find out if a specific PACS is compatible with a PNA. That's not an easy question to answer as there are a lot of issues that affect "compatibility". Once again, there is no simple list to check. The best way to assess the degree of compatibility for a specific PACS is to simply submit basic vendor/model and software version information to a PNA vendor and request a formal PACS Compatibility Assessment. If that vendor has experience with the specified PACS, they should be able to provide a reasonable assessment.

A high degree of compatibility would support the recommendation to deploy a PNA, migrate the oldest data from the PACS first, and then set up the PACS to use its own archive for new data and access the PNA for the old data.
A low degree or no compatibility would support the recommendation to deploy a PNA based on a very basic but upgradeable hardware platform and simply begin migration of the PACS data to the PNA to reduce the future data migration costs.

Step three of my suggested Action Plan is to conduct a Migration Liability Assessment for your organization. This is essentially a matter of running study volumes, study sizes, growth rates, retention policies and associated business objectives through a spreadsheet that calculates projected data volumes in future years and the cost of migrating that data from the current PACS to a new PACS. The two most important pieces of information needed are: how much the migrations will cost and how long the migrations will take. Given the complexity of data migrations from PACS-A to PACS-B, it is not unusual for the migration to span several years and cost hundreds of thousands of dollars.

If you have a clear understanding of the concept of the PACS-Neutral Archive, understand where your current PACS stands with respect to compatibility, and have solid numbers to support a sense of urgency, you have the three main tools you need to develop a working strategy to address this major data management problem.

If you need help performing the PACS Compatibility Assessment or the Migration Liability Assessment, Gray Consulting has considerable experience in these areas and would be happy to provide assistance.

Wed, 25 Feb 2009 16:47:45 GMT

Strategic Approach to PACS Storage Expansion

If your Radiology or Cardiology PACS is at least two years old, you're probably running out of on-line storage capacity. A more strategic approach to expanding the PACS on-line storage capacity is to deploy a completely separate storage solution, rather than simply adding more media to the storage solution that came with the PACS. The right standalone Storage Subsystem could be the seed that grows into a PACS-Neutral Enterprise Archive.

In the two or more years since your existing PACS was installed, advances in CT and MR imaging have produced larger and larger data sets. The addition of Full Field Digital Mammography has also added a large volume of digital image data to the PACS. Echo and Cath Lab runs are also growing in data volume. It is easy to understand how the amount of on-line storage you originally projected for the PACS can no longer meet today's actual storage requirements.

Up until a few years ago it was a common practice to configure a Radiology or Cardiology PACS with sufficient on-line storage media to manage the most recent 18 to 24 months of study data and install a Hierarchical Storage Management system to support near-line media in a jukebox, for example a digital tape library. The near-line library has nearly unlimited expansion capabilities if it is linked to a shelf storage repository. While this approach creates a sense of unlimited storage capacity, the practicality of the near-line library is limited by cartridge access rates and the manual loading and unloading of the tape cartridges. All of this activity results in delays in image access. After a few years of experience with the work flow associated with tape management, it is clear why the better solution is the expansion of the on-line storage solution.

Even if the Radiology PACS was configured with an all-spinning storage solution, the volume of storage required two or more years later has probably been underestimated. Whether the PACS is configured with a single or multiple tier storage solution, a storage upgrade is probably inevitable. The question is, "What is the most strategic upgrade solution?".

Adding additional media (drives), especially of the same type to the existing storage solution may not be the best solution. In the last two or more years, the storage media technology has changed dramatically. If the existing storage solution is approaching five years in age, it should probably be replaced, not expanded.   A completely new storage solution based on the latest technology would represent the best value, the most capacity per dollar invested.

Of course this type of upgrade, total replacement of the existing storage solution with a current generation storage solution with three to four times the capacity for the same dollars, will require a media to media data migration.   This type of data migration is not the onerous DICOM data migration that is required when one changes PACS, and that is the point! A simple media to media migration moves all of the study data over to a new storage solution, preserving all of the ID errors, and retaining all of the DICOM idiosyncrasies of the existing PACS. In my opinion, this could be viewed as a wasted opportunity.

The need for a storage expansion should be viewed as an opportunity to upgrade the storage technology AND normalize the image data format.

There are numerous arguments in favor of creating a PACS-Neutral Enterprise Archive: [1] Consolidation of multiple department PACS storage requirements into a single centrally administered storage solution, [2] Elimination of the cost of future DICOM data migrations, [3] Provision of data Acquisition and Management resources for imaging departments that have no PACS resources, and [4] Creation of a consolidated data repository for the Electronic Medical Record, accessible through the Physician Portal, viewable by a UniViewer display application. The most significant problem limiting the deployment of this Enterprise Archive is the initial expense.

The same problem limited the early development of the Radiology PACS market. Full-featured PACS was pretty expensive back in those days. What finally got the PACS market going, what put the market on the upswing of the technology adoption curve was the invention of baby steps in the form of Teleradiology Systems and mini-PACS, individual systems that addressed individual needs that might be upgraded expanded or assimilated in to the larger more encompassing PACS that is commonplace today.

The emerging PACS-Neutral Enterprise Archive market needs a baby step, a "starter kit", a "mini-PACS".   I suggest that that starter kit could be a PACS-Neutral Storage Expansion subsystem for an existing PACS. In my next post, I'll attempt to describe what I mean by a Neutral Storage Expansion subsystem, and why I believe that such a system is the right strategic move for any organization facing the need to expand their image storage.

Thu, 03 Jul 2008 22:23:11 GMT

Enterprise Archive should be more than a Long-term Storage Solution

The original concept of the Enterprise Archive was to provide a centralized long-term storage solution for multiple department PACS, like Radiology, Cardiology, etc. Deploying the individual "archives" incorporated into each of the Health System's department PACS often requires supporting multiple technologies. That and the obvious redundancy means higher cost of ownership. Several years ago, the simple solution was to deploy a single storage solution that could be shared by the various department PACS, and with a growing number of Radiology and Cardiology PACS vendors supporting open storage solutions, this simple solution was a reasonable solution.

While this solution reduced some of the redundancy, it did nothing to standardize the data. As more and more Health Systems began to realize that replacement of an old PACS with a new PACS required a migration of the data to the new PACS, it became obvious that a solution was also required to address this problem. Thus the original concept of the Enterprise Archive was modified to include a solution to the expensive and painful problem of data migration.

A storage solution alone is not equipped to handle the data migration issue. The management of Radiology and Cardiology data objects requires a feature-rich layer of DICOM services on top of the storage solution. More specifically a DICOM service is required to convert the idiosyncrasies in the DICOM format used by vendor A into the idiosyncrasies in the DICOM format used by vendor B. Simply put, the tools typically used by the data migration service organizations to migrate data from PACS A to PACS B would need to be integrated into the DICOM services package that sits on top of the storage solution. The common term for this format conversion is Tag Morphing. The integration of Tag Morphing into the DICOM layer of a storage solution would enable any PACS to forward image data to this storage solution as well as retrieve image data deposited by itself or any other PACS.

Tag Morphing eliminates the need for future data migration, and Tag Morphing enables data exchange between disparate PACS. Hence the term PACS-Neutral Archive.

The evolution from shared storage solution to PACS-Neutral Archive was a pretty nifty evolution in concept, and it was clearly the genesis of an emerging new segment of the image management market. There are at least six vendors in the United States that offer a product that meets the basic requirements of a PACS-Neutral Archive: Acuo Technologies, Agfa Healthcare, DeJarnette Research, Emageon, InSiteOne, and TeraMedica. There are already several installations of such systems in the United States, and several more in Europe.

But the Enterprise Archive needs to be more than a PACS-Neutral Archive.

Several years ago the concept of accessing image data through the Electronic Medical Record (EMR) was popularized. Then and now, the concept of an EMR is that the vast majority of physicians in a Health System would post their charts and research their patient's study results in the EMR. Therefore it would be convenient if they could access the images associated with those results while remaining in the EMR application. To date EMR products do not include the specialized viewer software required to view Radiology, Cardiology, Ophthalmology, etc. images. Furthermore the EMR is not typically configured with the volume of digital storage required to store a copy of all of these modality images. Instead of incorporating the Image Viewer in the EMR and instead of creating yet another image data repository in the EMR, a much better solution has evolved. A URL interface links the patient study instance in the EMR to the corresponding Department PACS that provides the long-term digital archiving of the study data, as well as the viewing application for the display of the images. The EMR user clicks on a study listed in the EMR and a link takes the user directly to the PACS where the images related to that study are being archived. The viewing application is the same viewer that would otherwise be accessed if the user logged directly into the department PACS. In this case, the user has the benefit of using the department PACS without having to really leave the EMR environment.

This approach is really a major step forward in information access, but it didn't take long to foresee two significant problems. First, enterprises with multiple department PACS would have to support separate URL links between the EMR and each of those PACS. In really large Enterprises, the number of separate PACS is a big number. Second, the physicians who choose to view images from within the EMR application have to learn how to use multiple viewers, each supported by the different PACS.

A PACS-Neutral Archive can obviously become the EMR Data Repository, as it is the single enterprise archive where all image data from all PACS is stored. But the PACS-Neutral Archive alone is not equipped to provide the EMR with a viewing application. Archives are typically not expected to support a viewing application, but that is exactly what is needed to solve this new problem. The ideal Enterprise Archive would first of all be a PACS-Neutral Archive and therefore be the EMR data repository, and secondly it must support a thin client or web-delivered image viewing application that could display any of the image objects that have been committed to the Enterprise Archive. The trick of course is being able to display different types of images (Radiology, Cardiology, Pathology, Visible Light, etc.) with the same viewing software, maybe on the same display screen and in the same working session. This would be the ultimate multi-modality medical image viewer!

The PACS-Neutral Enterprise Archive configured with a Multi-modality Viewer for the EMR would be extremely useful to even a small enterprise. But there are still more key issues that need to be resolved before one could accurately describe this new kind of Archive. What kind of data objects can it accept? How does it treat different types of data objects? Does every object have to be DICOM? What display feature set is appropriate for the EMR user? Interestingly enough, all of these issues are inter-related, and there is a significant difference of opinion on these issues among the developers of the new Enterprise Archive. In my next post, I'll present some interesting positions on these issues and attempt to defend my own personal opinions.

Wed, 27 Feb 2008 18:08:41 GMT

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?

Tue, 12 Feb 2008 00:29:47 GMT

The Problem with Proprietary Data/Object Formats - their Impact long after Data Migration

This is another take on a long-standing problem with most of today's Radiology PACS: proprietary Data/Object Formats. It has been at least four years since Presentation States and Key Image Notes were included in the DICOM standard, yet the majority of PACS vendors continue to treat these key work products as proprietary objects. The most consistent excuse is "There are many more features on our engineering schedule considered to be more important to our users."

I can almost believe that story, since I have found that most users are not aware of the implications of proprietary data objects. Since almost every PACS supports the creation and display of Presentation States and Key Image Notes, the fact that most PACS treat these as proprietary objects is lost on most buyers and eventual users. Provided that these objects are kept within a given PACS, there is no apparent negative to their being proprietary. The user may not experience a situation where the proprietary nature of these objects presents a problem.

The problem arises when the user of one of these proprietary PACS tries to forward study data to another Facility or Health System that is using a different PACS. Whether that other PACS is DICOM conformant or not, unless it is the same PACS, those presentation States and Key Image Notes cannot be transferred, accessed, or displayed. Physicians using the other PACS will not have the benefit of seeing exactly what the radiologist interpreting the study saw in the images or what he may have typed as a text message. The benefit of these "work products" is lost.

The problem also arises when a user of one of these proprietary PACS tries to copy study data to a CD/DVD. The proprietary work products either cannot be copied, or they cannot be accessed and displayed by another PACS. This is one of the reasons why there is so much consternation over the current CD/DVD copying solutions on the market. The vendors of these proprietary PACS typically have to place a copy of their own viewing software on these CD/DVDs, because their proprietary viewer is the only way to view their proprietary study data.

The real problem will manifest itself only after the user has decided to replace the proprietary PACS with the next PACS. Data migration services will typically migrate the study pixel data to the next PACS, but few of these services currently migrate any proprietary study-related data objects. To do so would require knowing where these objects were stored in the PACS, how to extract them and how to convert them to their DICOM counterparts. This extraction, conversion, migration is not being performed and as a result, those proprietary data objects are lost forever. The images are available for historical comparison in the next PACS, but none of the proprietary work products are available. Now imagine the implication of having to window and level all of these priors again, when they are recalled for viewing with the new images. Imagine not having the spine labels, and not having any other annotation or overlay graphics created when the prior was first interpreted. That's working without benefit of prior information, or a possible expenditure of time redoing all that work.

A PACS should treat Presentation States, Key Image Notes, .wav files, Technologist Notes, Scanned Documents, even the Radiology Report as DICOM Objects, not only so they can be shared with other systems today, but also so they can easily be migrated and used in the next PACS. DICOM-conformance is always in the user's best interest.

Now if a prospective buyer knew the negatives associated with proprietary data objects, would they choose a proprietary PACS anyway? Logic suggests that they should think twice. At the very least, if an organization goes ahead with the purchase of a PACS that still creates any proprietary data/object formats, that organization should negotiate a "no-cost" data migration clause in their contract that pins the cost of moving these proprietary objects to the next PACS on the vendor who has continued to choose NOT to conform to the standard.

Lack of DICOM conformance is a type of vendor lock. I believe that the PACS vendors still believe that anything that complicates moving to another vendor's PACS may persuade the organization to stay with the incumbent. It's time to make them pay for that strategy.

Tue, 05 Feb 2008 00:18:10 GMT

Coming Up For Air

Here it is February. Where did January go? For that matter, where did December go? My bad! I've been so negligent with keeping my site up to date. It's not that I was chasing snow or anything. I've been very busy with a number of projects; two separate RFPs for Radiology PACS, a Project Plan for a large multi-site health system, and a PACS-neutral Archive project.

I really did want to publish a commentary or two on my RSNA '07 observations. There certainly was plenty of inspirational Material.

GE finally has a decent Radiology PACS (through acquisition). Now what?
A number of vendors start talking about PACS-neutral archives, but you really have to look hard for the vendors, and then look even harder for anyone who can speak to the subject.
It's truly amazing how few vendors consider themselves DICOM-conformant, yet they do not support DICOM Presentation States.
Apparently 3 MP color display panels are now the norm in Diagnostic display stations.

Let's just say I have some new things to say about some old subjects, and a few things to say about some new subjects. Sorry for the tease, but I need a little time to collect my thoughts. Check back in a few days and you'll find some posts on such subjects as:

The problem with proprietary data/object formats, their impact long after data migration
The beauty of media-neutral storage solutions
Cost-effective Business Continuity Solutions, so much more than data back-up
Double-check that quote configuration, because there are lots of hidden costs that sneak into the picture at contract time.

Thu, 27 Sep 2007 22:13:19 GMT

Take the Archive Out of PACS

Those of you that have been following my recent posts on the subject of PACS-Neutral Archive might find it useful to visit the HIMSS or Emageon web sites to access a webinar delivered today to an audience of 70+ members of HIMSS.

The seminar covered the subject of Tag Morphing and explained how some very common problems faced by Health Systems today can be resolved by deploying a PACS-Neutral Archive; problems such as the sharing of a single archive among multiple dissimilar PACS, and the elimination of future data migrations. The Emageon web site offers the visitor the option of downloading a collection of white papers that describe the concept of PACS-Neutral Archive and Tag Morphing in more detail.

Check it out.

Wed, 26 Sep 2007 17:37:48 GMT

Is new Stark Exemption an Opportunity?

I came across an article in Imaging Economics titled "Surveys Show Paper Legacy Tough to Shake"

What caught my eye was the second paragraph statement "A new Stark exception allows hospitals to donate health information technology in the form of an EMR to private physicians."

I was wondering if the definition of "EMR" could be extended to radiology web viewer? Is this possibly a mechanism for providing the necessary hardware (PC), software and connectivity services to the referring physician office to get them to stop requesting paper and film?

The article is worth reading as it explains why "more than 50% (hospitals) continue to print and distribute paper lab and imaging reports." This does not come as a surprise to me, but it occurs to me that if so many hospitals are still printing paper radiology reports, a similarly large number must also be distributing hardcopy images.

Clearly the success of a Radiology PACS depends on turning off a large percentage of hardcopy and getting the referring physicians to access images and reports from their offices electronically. I have long argued that the cost of providing a suitable PC and basic connectivity services is more than paid for by the value of the hardcopy. Many clients were concerned about the Stark implication. Is this exception an opportunity?

The article goes on to explain that 62% of hospital executives surveyed in February said their organization had no plans to donate technology. "They're waiting to see how the government changes the landscape. How will it affect their nonprofit standing, that kind of thing." Once again, I think this is a shortsighted point of view. The continued printing of hardcopy films is certainly affecting their bottom line. Why not take advantage of this opportunity to legally equip their referring physicians with a much less expensive method to access images and reports?

Tue, 25 Sep 2007 20:39:18 GMT

Separating Storage from the PACS is Good First Step

I was browsing today when I came upon an all too brief article that appeared in HealthCare Informatics in August, 2007. The title of Stacey Kramer's article is A Two-Tier Solution, and the first sentence states that "Memorial Hospital found it takes two vendors to handle imaging properly - one for PACS and one for storage."

According to the article, Memorial Hospital decided to combine a McKesson PACS with "IBM's tiered storage solution". Unfortunately the article provides no real information on the actual configuration, or any explanation as to why this was the ideal combination.

Without any detail, I am left to speculate that this is merely an example of the customer requiring the PACS vendor to substitute the customer's favorite storage solution for the storage solution originally proposed by the PACS vendor. If this is the case, this is hardly a breakthrough.

If in fact, "IBM's tiered storage solution" was their GMAS configuration featuring Bycast's potent Information Lifecycle Management software, that would be a significant upgrade over the typical PACS configuration that features direct attached storage, but once again, hardly a breakthrough.

There is no evidence to suggest that there is a separate data Directory on this separate storage solution, and that the data is in any way being managed independently of the PACS application. Bottom line, the McKesson PACS still controls the study data, and years from now, when Memorial Hospital decides to replace this PACS with another PACS, they will have to migrate all of that study data through the McKesson PACS and through the new PACS, even if this migration is right back to the same IBM storage solution.

Choosing a separate Storage Solution was a good First Step, but the next step would have been to interface the McKesson PACS to a PACS-neutral Archive. There are a number of PACS-neutral Archive software applications that could utilize the same IBM storage solution, but in this case, the study data would be controlled by the PACS-neutral Archive and not the McKesson PACS application. The study data would not have to be migrated downstream, when the McKesson PACS is replaced.

The good news is that it is never to late to build a PACS-neutral Archive, and pro-actively migrate the study data to this archive long before the data migration task gets that much bigger and much more expensive.

I have written several White Papers on the subject of Pro-active Data Migration and PACS-neutral Archives. The papers are too lengthy to publish on this web site, but they are freely available to anyone forwarding an email request.

Wed, 19 Sep 2007 18:40:13 GMT

That Centricity Name is Quite the Catch-All

So what's in a name? A recent news item appearing in Imaging Economics boasted in its headline "Most US News & World Report Top-Ranked Hospitals Are GE Centricity Users". That came as surprise to me, because I immediately associated "Centricity" with the radiology PACS Imaging solution. When the article referenced Johns Hopkins Hospital at the top of this list, I knew something was up, because Johns Hopkins migrated all of its radiology study data from a Siemens Magic PACS system some time ago to an Emageon PACS. So I read on. Turns out that the Centricity name covers a wide range of GE IT products, mostly information/business systems. According to the brief article, only three of the eighteen top-ranked hospitals are using "one or more Centricity Imaging solutions". Just goes to show you how important it is to read the fine print.

Another way to interpret this information is that only 3 of the 18 top-ranked hospitals are Centricity Imaging Solutions users. This is well under the market share currently associated with GE PACS. I find that informative.