Archive for the ‘PACS Technologies’ Category

« Older Entries

PACS / VNA Compatibility Issues

Monday, February 20th, 2012

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.

Posted in PACS, PACS Technologies, PACS-Neutral Archive, Strategic Planning

True Business Continuity Requires Two Separated Instances of all Key Applications

Thursday, July 21st, 2011

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.

Posted in PACS, PACS Technologies, PACS-Neutral Archive

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

Tuesday, June 23rd, 2009

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.

Posted in News, PACS Technologies, Pitfalls

New Breed of Teleradiology Poses Challenging Technology Issues

Thursday, June 18th, 2009

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.

Posted in News, PACS Technologies, Workflow Issues

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

Friday, February 27th, 2009

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?

Posted in PACS Technologies

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

Monday, February 11th, 2008

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.

Posted in News, PACS Technologies, Strategic Planning

Take the Archive Out of PACS

Thursday, September 27th, 2007

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.

slide1

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.

Posted in News, PACS Technologies, Strategic Planning

Is new Stark Exemption an Opportunity?

Wednesday, September 26th, 2007

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?

Posted in News, PACS Optimization, PACS Technologies

Separating Storage from the PACS is Good First Step

Tuesday, September 25th, 2007

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.

Posted in PACS Technologies

PACS for the Smaller Organization

Thursday, September 6th, 2007

Over the last several months a number of posts have shown up on auntminnie.com and pacs-admin@yahoogroups.com asking readers opinions on some of the smaller PACS solutions in the market. I assume that most of these questions are being posed by members of small imaging operations performing less than 40,000 procedures per year who assume that they can only afford the relatively inexpensive PACS solutions offered by the small vendors. In the past, this was probably the case, but that is no longer the case.

Today, several of the biggest vendors in the PACS market, creators of the really big and fully featured PACS, have achieved a scaling feature that allows them to offer effectively the same fully featured PACS at a price point within reach of even the smaller imaging operation.

These vendors have achieved this scaling by reducing the number of servers in the cluster, without eliminating robustness or reliability. They have retained the basic display features, including hanging protocols, but made many of the more advanced display features (like 3D) line item extra-cost options, so they can be added for a modest license fee if needed. They have made many of the professional services that were automatically included in the big system, line item options in the scaled down package. The site that can follow directions and set up their own modality interfaces, complete their RIS interface on their own, and perform their own network testing can save some money.

Perhaps the best feature of this new generation of scaled down PACS is that their upside potential is not artificially limited. If the study volume suddenly jumps by 100%, the small system can be expanded to accommodate growth, without a wholesale exchange of hardware or a whole new tier of software licensing. The user truly pays for only what they need, and only as they need it.

In this scenario, there is no reason for the smaller imaging organization to risk an investment in a fragile company and purchase a bargain-basement PACS with limited features and limited support. It is now possible to afford the economical version of the same PACS being used by the big boys.

Posted in PACS Technologies

« Older Entries