Archive for the ‘PACS’ Category

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

Failover Strategies in Mirrored Configurations of Medical Image Management Systems

Tuesday, June 28th, 2011

The subject of Failover and Resynchronization is near and dear, as I’ve been configuring mirrored systems for years.  I have become quite familiar with how various vendors address this requirement.  The principal reason for building a mirrored Picture Archiving and Communication System (PACS) or a mirrored Vendor Neutral Archive (VNA) solution is Business Continuity.  Most healthcare organizations realize that they cannot afford to lose the functionality of a mission critical system like a PACS and an Enterprise Archive, so they need more than a Disaster Recovery strategy, they need a functional Business Continuity strategy.   Unfortunately, it’s really tough to build a dual-sited, mirrored PACS that actually works.  The sync and re-sync process drives most PACS vendors nuts.  There are very few PACS that can support multiple Directory databases.  I think this shortcoming of most PACS systems is why we have been configuring mirrored VNA solutions from the beginning…if you can’t configure the PACS with a BC solution, then you should at least configure the enterprise archive with a BC solution.

In the dual-sited, mirrored image management system, there are two nearly identical subsystems, often referred to as a Primary and a Secondary.  The two subsystems are comprised of an instance of all of the application software components, the required servers, load balancers, and the storage solutions.  Ideally these two subsystems are deployed in geographically separate data centers.  While it is possible to make both subsystems Active, so half of the organization directs its image data to the Primary subsystem and the other half directs its data to the secondary subsystem, the more common configuration is Active/Passive.  In the Active/Passive configuration, the organization directs all of its data to the Primary subsystem and the Primary backs that data up on the Passive Secondary subsystem.

When the Primary subsystem fails or is off-line for any reason, there should be a largely automated “failover” process that shifts all operations from the Primary subsystem to the Secondary subsystem, effectively making it the Active subsystem, until the primary subsystem is brought back on-line.  When the Primary subsystem comes back on-line, there should be a largely automated “resynchronization” process that copies all of the data transactions and operational events that occurred during the outage from the Secondary back to the Primary.

Business Continuity operations can be even more complicated in an environment where there is a single instance of the PACS and a dual-sited, mirrored VNA configuration. In this environment, the failover and resynchronization processes can be somewhat complicated, giving rise to numerous questions that should be asked when evaluating either a PACS or a VNA.  I thought it would be beneficial to pose a few of those questions and my associated answers.

Q-1: If the hospital-based PACS and Primary VNA are down, how does the administrator access the offsite Secondary VNA and subsequently the data from the offsite VNA? Is the failover automated, or manual?  If manual, what exactly does the admin do to initiate the failover?”

A: The response depends very much on the VNA vendor and exactly how that VNA is configured/implemented.  Some VNA solutions have poor failover/resynchronization processes.  Some look good on paper, but don’t work very well in practice.  With some VNA vendors, system failover and resynchronization in a mirrored environment is a real strong suit, as they support many options (VMWare, Load Balanced-automatic, Load Balanced-manual, and Clustering).  Some VNA vendors have limited options, which are costly and actually create down time.  The better approach is a Load Balanced configuration with automatic failover (which requires certain capabilities existing on the customers network-VLAN/Subnet/Addressing), with manual failover being the second option (and more common).  VMWare is becoming much more common among the True VNA vendors, but many of these vendors will still implement the VMWare clients in a load balanced configuration until customers are able to span VMWare across data centers and use VMotion technology to handle the automatic failover.  There is also the option of using DNS tricks.  For example, IT publishes a hostname for the VNA which translates to an IP in Data Center (DC) A, the DNS has a short Time to Live (TTL), such that if DC A fails, IT can flip the hostname in the DNS and the TTL expires in 1-5 seconds, then all sending devices automatically begin sending/accessing DC B.

There is also a somewhat unique model that implements the mirrored VNA configuration in an Active/Active mode across both Data Centers – whereby the VNA replication technology takes care of sync’ing both DC’s, the application is stateless so it doesn’t matter where the data arrives, because the VNA makes sure both sides get sync’d.

The point in all of this is simply that the better and obviously preferred approach to failover is a near fully automated approach, ONCE THE SYSTEM IS SET-UP.  Resynchronization of the data should be automated as well.  Only updates/changes to the user preferences might require manual synchronization after a recovery.

Q-2: What do the UniViewer (zero client, server-side rendering display application) users have to do to access the secondary instance of the UniViewer? Do the users have to know the separate URL to login to that second UniViewer?

A: If implemented correctly, the UniViewer should leverage the same technology as described above for the VNA.  The user’s URL call goes to a load balancer, which selects the Active UniViewer rendering server.   If the Primary UniViewer (Active) has a failure, another node, or another data center takes over transparent to the end user. The rendering server in turn points to a load balanced VNA such that the users need to do nothing differently if the UniViewer servers or the VNA servers switch.

Q-3: Where do modalities send new studies if the onsite PACS and/or the Primary VNA are down?

A: Once again, this is highly variable, and there are several options.  [1] If the designated workflow sends new data to the PACS first and that PACS goes down, then I’d argue that the new data should be sent to the onsite VNA.  That means changing the destination IP addresses in the modalities.  [2] Vice-versa if the designated workflow sends the new data to the VNA first.   Most of the better VNA solutions can configure a small instance of their VNA application in what I refer to as a Facility Image Cache (small server with direct-attached storage).  One of these FIC units is placed in each of the major imaging departments/facilities to act as a buffer between the Data Center instance of the VNA and the PACS.  [3] In this case, the FIC is the Business Continuity back-up to the PACS.

If both the PACS and the local instance of the VNA are down, the new study data should probably be held in the modality’s on-line storage, for as long as that is possible.  The modalities could also forward the data across the WAN to the Secondary VNA in the second data center, but the radiologists would probably find it easier to access and review the new study data from the modality workstations.

Of course all of these back-up scenarios are highly dependent on the UniViewer.  In the case of those PACS with thin client workstations, if the PACS system goes down, the workstations are useless.  In the case of fat client workstations, most are capable of only limited interactions with a foreign archive.  See the next question and answer for additional detail.

Q-4: Do the radiologists read new studies at the modalities and look at priors using the UniViewer whose rendering server is located in the offsite data center?

While that is possible, my recommendation would be to use the UniViewer for both new and relevant priors.  Some of the UniViewer technology is already pretty close to full diagnostic functionality, some of the very advanced 3D apps being absent. There are already examples of this use of the UniViewer at a number of VNA sites…not only for teleradiology applications, but also diagnostic review if the PACS system goes down.  My prediction is that the better zero client server-side rendering UniViewer solutions are going to be full function diagnostic within a year.   This is a critical tipping point in the VNA movement…a real game changer.  Once the UniViewer gets to that level of functionality, the only piece of the department PACS that is missing will be the work list manager.   As soon as it’s possible to replace a department PACS with a solid [1] VNA, [2] UniViewer, and [3] Work List Manager, the PACS vendors will have a very difficult time arguing that their PACS (less the Archive and Enterprise Viewer) is still worth 90 cents on the dollar, as they are doing today.

Q-5: Does the EMR, if linked to the onsite UniViewer, have a failover process to be redirected to the offsite UniViewer so that clinicians using the EMR still have access to images through the EMR, or do the users need to have the EMR open in one browser and another browser open that points at the offsite UniViewer which they login to separately?

A: Failover from Primary to Secondary UniViewer should be and can be automated (see 1 and 2 above), if implemented correctly and support by the UniViewer technology.

In conclusion, most healthcare organizations are highly vulnerable to the loss of their PACS, because most PACS cannot be configured with a Business Continuity solution.  That problem can be remedied with a dual-sited, mirrored Vendor Neutral Archive paired with a dual-sited UniViewer.  While most VNA vendors can talk about Business Continuity configurations, their failover and resynchronization processes leave something to be desired.  The reader is encouraged to build a set of real-world scenarios, such as those presented here, and use them to discover which VNA will meet their Business Continuity requirements.  The Request For Proposal (RFP) document that I have created for VNA evaluations has an entire section on Business Continuity and the underlying functionality.

Posted in PACS, PACS Optimization, PACS-Neutral Archive, Strategic Planning, Workflow Issues

What’s it going to take to achieve Meaningful Use of Images?

Monday, May 17th, 2010

The other day a friend of mine forwarded to me a link to the Imaging Technology News eNews web site.  My friend encouraged me to look on the left bar of the web page and find the invitation to participate in their current survey.  The question was “Will PACS/RIS meet the meaningful use criteria to qualify for incentive dollars?”  If the survey is still running, you can check out the current results here.

Last time I checked, 33% thought that PACS/RIS would meet the criteria and another 30% thought that there’s a good chance it will.

I’d love to see the demographic of the survey participants, and I’d love to see a list of their assumptions.

I’m among the 30% that responded with a solid “no”, convinced that the PACS/RIS as we know it will not qualify for Meaningful Use, because it simply doesn’t have what it takes, and most likely never will.

If the survey participants gave serious thought to the question, they should have realized that the most critical component of what it takes to sustain Meaningful Use will be “ease of use”.  Most physicians are far too busy to learn and remember how to use more than one image viewer.  Most physicians are far too busy to switch back and forth between multiple viewers to assemble a montage of all the relevant clinical information in a single viewing window.  That’s exactly what will happen if we continue on the present path of developing individual URL links between the Physician Portal and the data elements being stored in each of the specialized departmental PACS, and using those department PACS viewers to view the data.  This approach shouldn’t make sense to IT, and it won’t make sense to the physician users.  So the participants must have been assuming that an all-encompassing Enterprise PACS will emerge, a single PACS that will embody all of the specialized department PACS requirements and thereby become the Uni-PACS.

In my opinion, it is highly unlikely that a current generation Radiology or Cardiology PACS or any other departmental PACS for that matter, will evolve in the next few years into an Enterprise Data Repository capable of managing the patient’s longitudinal record of all clinical information.  I seriously doubt that they will be able to manage all of the image information, much less all of the non-DICOM and non-image data objects.

Managing all of this clinical data is probably the easier part.  The harder part will be providing all of the expected display and processing applications that are specialized for each of the contributing imaging departments.  This is not to say that some of the larger vendors won’t try to become an all-encompassing enterprise PACS, or at least claim to be the Whopper of PACS, but I don’t see that happening.

In my opinion, the more likely scenario will be the Enterprise Neutral Archive fulfilling the role of the Enterprise Data Repository, and the (interfaced or embedded) UniViewer will provide the unified set of viewing tools that the physicians will use to access and view all of a patient’s clinical information, both the image and the non-image data being managed by that Neutral Archive.

Today, more and more Health Care organizations are “getting it”.  They see all of the advantages of separating the “archive” data management applications from the departmental PACS.  And it’s a natural to add a viewer to this new generation Archive.   Sooner or later, each of the PACS vendors will “get it”, and at that moment the push will be on in their R&D groups to further differentiate their department PACS products with the specialized applications unique to that department.  Their PACS will have to become an even better, specialized tool for each department, because the Neutral Archive will have already become the tool of choice for the Enterprise.  Meaningful Use will be much easier to achieve if the physicians know they only have to go to one repository and only have to use one viewing application to assemble all of the relevant clinical information in a single viewing session.  Get it?

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

Next Generation PACS will be Smaller

Wednesday, March 31st, 2010

I read an article today in the Health Imaging & IT electronic publication.  In this article on the next generation PACS, the author states his belief  that the next generation system will have to become bigger, become all-encompassing, become a PACS for every department; or at least be able to interface with the other systems across the enterprise.  For good measure, the article mentions the need for a web product good enough to support meaningful use.

There’s nothing much new here, in fact the vision is distorted.

The major PACS vendors have been working on their Enterprise PACS for some time now, assuming that the “enterprise” consists of Radiology and Cardiology.  How’s that been working out?  How many vendors have achieved fully functional Radiology and Cardiology application packages that run on a single platform with a consolidated Directory database and can exchange image data with each other?  After all this time, there are perhaps two, depending on one’s interpretation of the adjectives I used in the definition.  History suggests that folding in Pathology, Ophthalmology, Dental, etc. is going to take some time.  I don’t think we can afford to wait.

As for interfacing with other systems across the enterprise…that certainly sounds easier for the major PACS vendors to achieve than trying to be pretty good at all those individual department PACS applications.  Unfortunately that’s not going to be easy either, because there are simply too many idiosyncrasies in the way the individual vendors have implemented DICOM.  Don’t misunderstand, the implementations are largely “conformant”, they’re simply not completely compatible.  You know that, right?

I offer as simple irrefutable evidence two well known issues:  [1] data exchange between PACS via CD is problematic, and [2] replacement of one generation PACS by another requires a costly and time-consuming data migration.

I’m making an issue of this issue again, because it is my opinion that the next generation PACS is not going to become the bigger Enterprise PACS, nor is it going to suddenly start playing nice with the other PACS.

In my opinion, the next generation PACS is going to get a lot smaller, focusing on and becoming very good at supporting a specific imaging department’s workflow and providing its diagnostic tools.  Some of this functionality will most likely migrate up-stream to the actual modalities and their associated workstations, making this generation PACS even smaller.  The next generation PACS will also lose a lot of weight.  There will be the appropriate but minimal working storage, but certainly nothing like the TeraBytes of girth in the current systems.  As for short-term and long-term archiving…nothing.  That’s not where to put archiving.

Basically the next generation of PACS will be individual department-specific applications sitting on their own dedicated servers, each embellished with the logo of that department’s favorite vendor, and interfaced to a PACS-Neutral Enterprise Archive.

The Neutral Archive will dynamically manage all those cross-vendor idiosyncrasies, which the PACS vendors should really  appreciate, because that means they can stop pretending that they are going to fix the problem they created in the first place.  The PACS vendors can go back to doing what they do well, building work flow and diagnostic tools.  The Neutral Archive vendors will take over the significant task of managing all of the data from across the enterprise, assuring full interoperability between the PACS, and providing the level of Information Lifecycle Management that is long overdue in this industry.

As for the holy grail…enterprise-wide access to all of the enterprise data through the EMR Portal using a single viewer…the PACS Vendors can give up trying to figure that one out as well.  Most of their “Web Viewer” solutions can barely lift a radiology image.  There are some truly good “UniViewers” as I call them on the market, and more in the works.  What’s more,  they’re simple, standalone applications that don’t have to be embedded into the bowels of the Archive.  They could be as easily changed as a tie, albeit more expensive than a tie, but you get my point.

My point is that rather than looking for PACS to become more than they already are, and rather than taking up pitch forks in the name of DICOM convergence, think small.  It’s time to think specialization.  Award true excellence that has been surgically applied to a specific task: a department-specific PACS, a Neutral Enterprise Archive, and a UniViewer for the Portal.  Think “meaningful use”.

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

PACS is about more than Pictures

Sunday, November 20th, 2005

In The Beginning…

Back in 1980, medical imaging departments attributed most of their problems to their dependence on film. As a result, early PACS were designed as replacement technology for film. Hence the name, Picture Archiving and Communications System.

In the 80’s and 90’s film was much more expensive and many figured they could pay for PACS based on film savings. “Going film-less” became the mantra for both vendors and the market.

Fast Forward 25 Years

We finally have the technology to replace film:
* Interfaces to connect modalities
* High-speed networks for moving massive amounts of image data
* Fail-safe servers for 99.9% availability and reliability
* A variety of standards-based compression schemes (including J-PEG 2000) to improve performance and reduce hardware costs
* Reasonably priced, “off-the-shelf” storage solutions
* High resolution displays that rival the image presentation quality of film

All of this has made it possible to replace the film-based process with an electronic process.

Lessons Learned

Based on our experience, we’ve made some surprising realizations. The first is that the economics of the medical imaging business have changed.

In response to the perceived threat of PACS, the film companies started dropping their prices. Using those lowered film prices, materials and labor savings alone would not produce a break-even or produce an operational profit. In fact, operational deficits with PACS often ran six figures year after year.

Over the past few years, it has dawned on us that film is not the only important piece of information in the film jacket. The other “P” in PACS is for paper. For example:
* Patient/exam history
* Print of the order or requisition
* Any and all clinical notes
* Release forms
* Technologist worksheets/reports
* Radiologist reports

This paper supports the internal workflow of the department that the traditional Radiology Information System (RIS) does not reach. It might also represent the workflow that the PACS will not reach unless the system is properly designed.

In order for the PACS to be successful, the radiology department needs to eliminate all of the study-related documents (1) because there will be no one to move it, nowhere to store it, and no way to find it when the Jacket goes away. That means replacing the paper exchanged between the Emergency Department and Radiology to note preliminary impressions, and the occasional discrepancy or incidental finding. That means eliminating the hardcopy of the requisition, simply because the radiologists use its bar code to open the dictation file. If you stop an d think about it, This means eliminating a lot of paper forms you have invented for good reasons and have gotten very used to using.

Lessons Learned Summary

For a department considering its first PACS, PACS is a zero gain initiative – at best, costs will equal savings. The goal of PACS should be to “go jacketless” rather than “film-less”. And that means developing a new workflow that successfully eliminates the use of paper [1] to announce the readiness of a patient or study, [2] to communicate clinical information to the radiologist, [3] to communicate results to the referring physician.

In the process of determining this new paper-less workflow, it was also discovered that the technologists will have to play a larger role in preparing the study for interpretation. The technologists and not the system administrator will have to take responsibility for study QC. The Technologist must determine if all the clinical information needed by the radiologist for interpretation is present and accurate and attached to the electronic study.

Current Meaning of PACS

The epiphany that there is more to PACS than film clearly lead to a new goal: the delivery of clinical information (images and reports) in the most expeditious and cost-effective manner throughout the healthcare enterprise.

The term PACS has become an anachronism, pictures are no longer the only focus. The market has matured to become more centered on information management.

The advice is simply this, “don’t spend $2 million on a PACS only to realize that you need to spend more money to automate the other half of what’s in the film jacket”.

State of the Art PACS

The ideal PACS today is more than just a PACS. It must manage all forms of data prior to interpretation, enable the creation of multi-media reports and distribute the reports quickly at a cost-effective price. This ideal information system is comprised of:
* PACS as we knew it
* RIS as we know it
* Technologist workstations with PACS and RIS features
* Voice-to-text and multi-media reporting
* Workflow engine that directs operations
* An enterprise oriented data repository and distribution system

New Paradigm, Same Old Name

The next time you are talking to someone about PACS, be sure to find out which PACS they are talking about…

And as you review this web site, know that the PACS I’m talking about is the new PACS, not the old.

Posted in PACS

Time Lines

Friday, November 18th, 2005

How long does it take to do it right?

Proper planning prevents poor performance

The process for mapping out an image and information management plan is rather involved.

It is appropriate to observe the current workflow in radiology and determine what changes will be affected by the PACS. That means observing how the Technologists, Clerical staff and Radiologists do what they do. How is the RIS used today, and how will that change? How should that change? How is study QC done today, and how will that change?

How will paper be used after the PACS, and how will its information be captured and managed by the PACS?

In order to determine the best data storage solution, it is necessary to collect study data and convert it to digital equivalents. What are the daily, weekly, yearly digital equivalents of the new studies, and what are the digital equivalents of the relevant priors? What is your projected growth in each of the imaging areas? What level of compression will you use for new studies, priors, and the legal archive?

How will you role out the digital display technology to the referring physicians? What kind of services will you provide them to help them with this major adaptation to your new system? Discussing the possibilities or pre-selling the intended solution is a necessary and touchy project.

The technology of PACS is still quite complicated, and that technology is constantly changing and evolving. Regardless how many individuals are responsible for selecting the system and the vendor, those making the decisions should have a reasonable level of knowledge on the subject. There are numerous ways to go about gaining this education. Requests For Proposal (RFP) projects have been used by many organizations to learn about PACS technology and to make a vendor selection. Each component of the project has its own Time Line.

Properly done, the process from planning through vendor selection can last 3 to 6 months.
* Planning – 2 months
* RFP – 3 months

That’s assuming of course that you are starting from scratch…that you have done little or no data collection, workflow mapping, physician interviewing, or investigation of the underlying PACS technology. Good preparation can significantly reduce the amount of time and effort required in the formal Planning and Vendor Selection projects.

So it is important to plan early, get started early and schedule the project before time has run out to do the job right.

Posted in PACS

Not for the faint of heart

Saturday, October 15th, 2005

Buying a PACS can be daunting – there is little room for error in such an expensive undertaking.

Challenges include:
• A working knowledge of rapidly changing technology
• An unbiased insight into the business strategies of potential suppliers
• Incorporating existing equipment
• Considering changes to current operations, especially the role of the radiology technologist
• Accounting for the various skills and apprehensions of a multitude of potential users
• Accommodating complex practice patterns of radiologists and referring physicians, especially in the Emergency Room, Operating Rooms, and Exam Rooms
• Impact of organizational changes within the enterprise
• Impact of changes in the health care industry
• Impact of the emerging PACS-Neutral Archive as a consolidated multi-media archive for he enterprise as well as the data repository for the image-enabled Electronic Medical Record.

Deployment Strategy

There’s an order to the deployment of a Radiology or Cardiology PACS. The expression, “the devil is in the details”, is very true in PACS deployments. Determining the optimal sequence and getting all of the potential users to accept a new way of doing things is the challenge.

A stable and long-lived infrastructure must be designed. This is especially true for the Storage Solution, if that storage will someday be separated from the PACS are reassigned to a PACS-Neutral Archive.

A successful deployment schedule must string “little successes”, simple but effective changes in the operations of the department whose very effectiveness builds acceptance and confidence.

To be successful, the system designer must
• Chose the right solutions to the right problem
• Gently nudge the professional staff just beyond the edge of their experience
• Bring a multi-phase project in under budget.
• Every enterprise is unique. Otherwise, everyone could buy the same thing with equally good results.

Two-Step Process

There is a basic two-step process to buying a PACS, planning and vendor selection.

Planning includes:

• Needs assessment
• Business case analysis
• System design
• Deployment Strategy

Vendor selection includes:

• Review and refine requirements
• Request For Proposal (RFP)
• Finalist’s evaluations via demos and site visits
• Final section and contract negotiation

Planning

Planning is a comprehensive study to make sure you don’t waste money on your PACS. You must consider:
• Organization dynamics
• Existing technology
• Lesson learned from the existing and possibly previous PACS
• Optimization of the new PACS configuration
• Phased implementation plan including the obligatory data migration

The planning process must meet the needs of:
• Imaging department’s customers
• Department professional, technical and clerical staff
• For both immediate needs and future

Planning is based on:
• Operation data and expenses
• User preferences and skill-sets

A resulting plan and system design must accommodate various constraints:
• Technical
• Organizational
• Political
• Operational
• Financial

Getting all the various stakeholders throughout the enterprise to all agree on the plan is also critical.

The Gray Consulting planning and design process includes:
• Current State Analysis
• Impact Study
• System Design and Implementation Strategy
• Cost Estimate
• Payback Analysis

The outcome of the planning process is a roadmap for implementing a new or replacement PACS.

Vendor Selection – Potential Pitfalls

RFPs for a Radiology PACS are very time consuming to prepare. Considerable effort is also required to prepare the PACS team to understand the responses. A good RFP must describe the design strategy and rationale in great detail. This will attract considerable debate and argument from the vendors, who will want to argue their strategy.

Many vendors today will not respond to a complex RFP unless they are already engaged in the selling process with the facility and believe that they have a good chance to win the deal. Since it is not unusual for a prospective PACS buyer to overlook a number of companies and products, the client may never discover just how good their PACS solutions may be, if those companies choose not to respond.

Gray Consulting has simplified the RFP process by creating a template. The RFP Template allows you to build your own comprehensive and precisely written RFP for PACS. The package includes the RFP on CD, Instructional Booklet, and one hour of telephone consultation. The technical section includes section after section of probing questions carefully written to expose the benefits or failures of the system. Asking for detailed information, this RFP template yields a level of detail the team will need to decide which components best fit the expectations of both the department and the enterprise.

All of the major PACS vendors have responded to the Gray Consulting RFP. Since 90% of the document remains the same with each publication (approximately 10% of the questions are new to address changes in technology or requirements), and the question numbering system remains the same, all of the major vendors have continued to respond to the invitation to submit responses. The client will not miss out on an opportunity to discover the best PACS solution.

The RFP is sent to numerous companies that the team believes has the right components. A careful analysis of the vendor Responses will weed out all but the best 2 or 3 finalists.

This RFP process gives the team much greater control over the system design and vendor compliance.

The Gray Consulting vendor selection process includes:
• Design Review of any existing system plan and strategy
• Refinement of System Specs
• Description of required vendor services to support the proposed system
• Development of RFP
• Evaluation and summary of RFP responses
• Site visit preparation
• Vendor or system integrator selection
• Negotiations

Posted in PACS