Best-of-Breed VNA Looks Good on Paper, but can it be Built and Supported?

November 1st, 2011

The initial focus of the Vendor-Neutral Archive concept was two-fold [1] to consolidate individual department PACS archives and [2] facilitate data exchange between those PACS.  As the concept evolved, so did the complexity of the configuration.  Today’s VNA configuration will probably include a pre-fetch and routing application, an HL7 interface, one or more methodologies for acquiring non-DICOM image objects, a QA/QC application suite, a universal viewing application…the list goes on.  It is highly likely that a second party is providing one or more of these numerous applications.  Different vendors will most likely provide the hardware infrastructure.  The system solution package will be comprised of multiple professional services components, which may very well be provided by different vendors.

The composition of the ideal VNA and the specific configuration that best meets the initial and long-term requirements of the healthcare organization will likely be an assembly of best-of-breed components and subsystems from multiple vendors. Therein lies a well-known problem.  Multiple vendors means multiple Service Level Agreements and multiple 800 numbers to call for support.  Is it possible for a single vendor to offer technology choices, multiple configurations, then actually build and support that custom solution?  Can a site-specific, best-of-breed VNA succeed?

Sponsored by an unrestricted grant from Dell Healthcare, I recently completed a white paper that addresses this very subject.   The paper was published/released November 27, 2011, on the opening morning of RSNA.  You can download a copy of the paper from this web site, or visit the Dell website through this link to find my paper and other related information from Dell.

The paper explores the complexity of the VNA and presents some of the options available to organizations looking for a best-of-breed VNA implementation.  It also looks at the profile of an ideal partner that has the software, hardware and services expertise to integrate, deploy and support multiple best-of-breed solutions.

A webinar also sponsored by Dell Healthcare and based on this paper was given on Thursday, November 17, 2011.  Follow this link to the Dell web site to retrieve the replay of that webinar.

 

True Business Continuity Requires Two Separated Instances of all Key Applications

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.

Failover Strategies in Mirrored Configurations of Medical Image Management Systems

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.

Total Cost of Ownership Models Favor Hybrid Vendor Neutral Archive Configurations

June 23rd, 2011

My recently completed white paper  The Anatomy of a Vendor Neutral Archive (VNA) Done Right: The Case for Silo Busting focuses on the subject of Vendor Neutral Archive, but it is more than just another rehash of the technical argument.  Well, there are the obligatory opening paragraphs that present the technical background, but that’s just to make sure we are all on the same page with respect to system descriptions and vocabulary.  The real meat of this paper is a presentation of system architectures; specifically architectures that support business continuity, and a brief look at a real world Cost Model.

Since a dual-sited VNA is both large and complex, requiring geographically separated data centers, the obvious questions are: [1] what are the best deployment options, and [2] what are the associated Total Cost of Ownership (TCO) figures?  The paper considers concepts like Cloud Infrastructure and Software as a Service, because they can have a significant impact on TCO.  In my opinion, organizations that do not already have a remote secondary data center and have limited IT resources need to seriously consider any strategy that simplifies system management and lowers costs.

The Cost Model is very revealing, as it compares a dual-sited, on-premise, self-managed VNA to a dual-sited, on-premise/off-premise, vendor-managed (SaaS) VNA.  The later is now being referred to as a Hybrid VNA.  The model was built for five different organization profiles using comparable configurations, and real world infrastructure and operational costs.

Comparisons - 5 year TCO for Capital and Hybrid VNA

In the Table reproduced here, you can see the encouraging results.  The paper was sponsored by an unrestricted grant from Iron Mountain, and I assure the reader that I was involved in assembling the components of the model and approved every one of the line item costs.

Organizations that are getting serious about deploying a VNA will need a positive cost model to win project approval.  As part of that process, I strongly encourage looking at the Hybrid VNA.

Putting Half of the Vendor Neutral Archive in the Cloud Makes Sense

May 25th, 2011

Organizations looking at deploying a Vendor Neutral Archive have some hard decisions to make.  While there are several motivations for moving all of the enterprise image data, radiology, cardiology, endoscopy, etc. from disparate PACS archives to the consolidated VNA, the economic realities will make it a tough sell in many healthcare organizations. A properly configured VNA, one that provides reliable Disaster Recovery and Business Continuity, should have mirrored Primary and Secondary subsystems located in geographically separate data centers.  That will make a VNA is at least twice as big as all of the organization’s PACS combined!

Furthermore the VNA application suite is considerably more sophisticated than that of the department PACS.  Additional FTE resources, several with specialized expertise, will be required to administer the tag-mapping library, create and manage the retention policies, and monitor overall system performance, the security programs, and storage consumption.

All of which is to say, a properly configured VNA is going to be expensive to deploy and expensive to operate.  Making the economic argument for the VNA is going to be very difficult, because the Total Cost of Ownership of a VNA will almost always be higher than the TCO of a Heterogeneous PACS environment, simply because most department PACS have a weak DR solution, and no Business Continuity solution.  While the VNA will make a number of future data migrations unnecessary, the costs of those future data migrations avoided are typically not allowed in the cost models.

One possible solution to the economic challenge is to leverage Cloud Infrastructure and Software as a Service.  Rather than capitalizing and self-managing the Secondary VNA subsystem in a second geographically remote data center (which most organizations do not now have), the entire Secondary subsystem is operationalized and hosted in a Public (multi-tenant) Cloud Infrastructure.  Additional savings can be realized if the entire VNA, both the on-premise Primary and the off-premise Secondary subsystems, are managed under a Software as a Service contract.  In this scenario, both the on-premise and off-premise storage is delivered and billed on an as-needed basis, and all of the management resources and off-premise hardware infrastructure are shared across multiple organizations.

Hybrid VNAThe VNA configuration with the Primary subsystem on-premise and the Secondary subsystem off-premise in a Cloud is referred to as a Hybrid VNA.  If the organization does not believe that it has the IT resources to manage the on-premise Primary subsystem, there are Hybrid VNA vendors that will manage both on-premise and off-premise subsystems under a Software as a Service contract.  A Hybrid VNA managed entirely under a SaaS contract can have a 30% lower TCO than its capitalized, self-managed, on-premise counterpart.  That 30% savings can be used to make a positive economic argument for deploying the VNA.  For healthcare organizations with limited IT resources and no existing remote data center, the Hybrid VNA may be the only strategy that makes sense.

Role of Cloud Infrastructure in Vendor-Neutral Archive Adoption

December 6th, 2010

With all the recent hoopla around Cloud Infrastructure, I thought it would be worthwhile studying up on the subject, in order to learn how private and public Clouds might impact the adoption of Vendor-Neutral Archives.  While the concept of remote storage has been around for some time, the new twist that makes the subject much more interesting is the use of web services (HTTP) to exchange data with the Cloud.  Coincidentally, there has been an effort underway since early 2010 to develop a web services methodology for communicating (exchanging) medical image data between diagnostic workstations, PACS server, Vendor Neutral Archive, Intelligent Storage Solution, and freestanding UniViewer server.  The proposed web services protocol for medical imaging is called Medical Imaging Network Transport (MINT).  You can read more about MINT on their web site.  It is being suggested that MINT would replace the use of DICOM as the traditional interface between these devices.  The move from DICOM to web services is motivated by significant performance improvements (DICOM communications involves considerable overhead), as well as the opportunity to take full advantage of the rich meta data that must be included with the image data in a web services protocol.  Rather than attempt to summarize my opinions on this subject in this blog, I invite you to read the recent white paper that EMC commissioned me to write on this subject.  I think that you will find the subject somewhat stimulating.

The Dilemma Presented by non-DICOM Image Data Objects

October 25th, 2010

The primary impetus for deploying a PACS-Neutral Archive is the consolidation of the massive volume of Radiology and Cardiology image data objects into a single, centric,  enterprise-class repository.  Important secondary objectives include ending costly image data migrations, supporting image data sharing across disparate PACS, and image-enabling the Electronic Medical Record portal.   In all of these cases, we are focusing on DICOM image data objects.  The DICOM image data object is very well defined and the vast majority of diagnostic medical imaging systems are based on the use of DICOM.  It is a natural then for the PACS-Neutral Archive to focus on the acquisition, management and display of DICOM image data objects.

What is to be done with those non-DICOM image data objects?

There are a number of medical image data Sources (modalities) that produce non-DICOM data objects.  In some cases these objects are the images, and in some cases these objects are clinical information associated with the images or the study.  Object types include PDF, JPEG, MPEG, TIFF, WAV, and other consumer image formats.

What is the best strategy for acquiring, managing, and viewing these non-DICOM image data objects?  My opinion, one that is shared by others, is that we should take advantage of all the benefits of the DICOM standard and convert non-DICOM image data objects to DICOM image data objects.

In my latest White Paper titled Best Practices Strategy for non-DICOM data in Neutral Archive, which was edited and contributed to by a number of leading developers in the industry, I discuss the Best Practices Strategy for Dealing with non-DICOM Image Data Objects in a PACS-Neutral Archive.  The paper includes DICOM conversion methodologies, shortcomings of managing non-DICOM image objects in their native format, and the future role of XDS-I in image data object management.

There’s a lot of confusing information out there on this subject.  This paper is a must read for those that are just planning or already deploying a Neutral Archive.

Three-Step Strategic Plan for Achieving Meaningful Use of Medical Images

August 26th, 2010

These are difficult times for Healthcare’s C-level administrators, as there are a number of major challenges looming on the horizon, appearing as dark clouds threatening to merge into a perfect storm. First and foremost I suppose would be figuring out how to support and encourage Meaningful Use according to the July 13 release of the final Stage 1 guidelines. Still no specific use of the word “images” in the text, but the same two objectives that reference the exchange of “key clinical information” are now codified in the 14 core objectives that hospitals are required to comply with at least six months before November 30, 2011 deadline. That’s the last day for eligible hospitals to register and attest to receive an incentive payment for FY 2011.

The incentives drop for every year of delay, so in this case, delay will be expensive, and effectively cost the organization precious development money.

While one may argue whether medical images should or could be included in the term “key clinical information”, there is no argument that exchanging images with outside organizations and providers based on data copied to CDs is problematic. It’s also expensive (labor and shipping costs). No wonder then that there are now twelve vendors offering either Electronic Image Share appliances or Cloud-based Image services. Should the C-level administrators look into solving this problem at the risk of taking their eyes off of the Meaningful Use issue? If the two issues are mutually exclusive, probably not.

Perhaps the darkest cloud on the horizon, because it is associated with hundreds of thousands of dollars in service fees, is the upcoming PACS data migrations. This cloud might appear to many as faint and unspecified, but make no mistake…it is there, it is coming, and it is going to be bad. Once again, should the C-level administrators spend time worrying about future data migrations, when there is only a year left to get the Electronic Health Record system up and running and meeting those Stage 1 objectives? If these two issues are mutually exclusive, probably not.

Here’s another important date bearing strong negative implications…2015; the year when Medicare payment adjustments begin for eligible professionals and eligible hospitals that are NOT meaningful users of Electronic Health Record (EHR) technology. “Adjustments” is political nice-nice for lowered reimbursements. Medical Images will most certainly be a stated inclusion in the Meaningful Use criteria by that time.

One way to look at the big picture is that there are a maximum of four years of financial incentives available for hospitals that can demonstrate support of Meaningful Use of key clinical information, for every year of eligibility. Deploying an IT and Visualization infrastructure over a five year period that will ultimately deliver all of a patient’s longitudinal medical record data to the physicians and caregivers is going to be expensive. It makes perfect sense to develop a Strategic Plan that goes after every bit of incentive funding available. That plan should and can weave all of the looming challenges into a single cohesive step plan. The aforementioned challenges are not mutually exclusive.

If one takes the position that electronic sharing of medical images outside of the organization is supportive of Stage 1 objectives, Step 1 of the Strategic Plan would be to deploy an electronic Image Share Solution. Whether that solution is an on-site, capitalized appliance or a Cloud-based service is another discussion, as the pros and cons are very organization-specific. Just make sure that the solution has upgrade potential, and is not a dead-end product.

By mid 2011 it’s time to start deploying Step 2 of the Strategic Plan…image-enabling the EHR. This might seem like an early jump on the image access issue, but we don’t know if specific mention of images will show up in the core objectives for Stage 2 or Stage 3, so why risk having to scramble to catch up? Perhaps the easiest way to image-enable the EHR would be to deploy a standalone universal viewer (display application). There are already a number of good universal viewers that require minimal server resources, feature server-side rendering, and require zero or near-zero client software. The IT department develops a simple URL interface between the EHR Portal and the universal viewer, and then individual interfaces between the universal viewer application and all of the image repositories in the enterprise (i.e. PACS). Ah but there’s the rub. All those PACS interfaces are going to be expensive to develop and maintain and replace with each new PACS, and there is no assurance that the universal viewer will be able to interpret all the variances in those disparate PACS headers.

Those of you that have been following my posts on this web site, see where this is going. The best solution, certainly the best long-term solution, is the deployment of a PACS-Neutral Archive and an associated Universal Viewer (aka UniViewer). The EHR is not designed to manage image data, relying instead on interfaces between its Physician Portal and the various established image data repositories in the enterprise. The PNA solves most of the organizations data management problems by consolidating all of the image data into a single “neutral” enterprise repository, which directly supports and encourages Meaningful Use of all the data objects that will constitute the patient’s longitudinal medical record. The problem is, most organizations will not be prepared to deploy a PACS Neutral Archive in 2011, so this would be a bit much to schedule for Step 2.

My Step 2 would be to expand the Image Share solution from Step 1 to include more storage…enough storage to accommodate the image data that the organization will start migrating from each of its department PACS. Of course this would mean making sure that the Image Share solution that is chosen in Step 1 was capable of becoming a PACS-Neutral Archive. At a minimum it would have to support bi-directional tag morphing. By the time the organization has completed the migration of the most recent 12 to 18 months of PACS image data, it will be possible to support Meaningful Use of the most relevant image data both inside and outside the organization. It is important to appreciate that the set of features/functions of a PACS-Neutral Archive required to meet the objectives of Step 2 (while the data is being migrated) is a fraction of the full set of PNA features/functions, so the cost of the software licenses required for Step 2 should be a fraction of the cost of the licenses for a complete PNA. Fortunately there are a few PNA vendors that appreciate this subtlety.

Step 3 could occur out there sometime beyond 2012, when the organization has sufficient funds approved to turn on all of the features and functions of a PNA, and purchase sufficient storage to accommodate all of the enterprise’s image data.

In this Strategic Plan, all of the major challenges looming over the horizon that have to do with images are addressed and solved in three creative yet logical Steps. Using the infrastructure to support and encourage Meaningful Use, in turn qualifies the organization for significant financial incentives that should go a long ways toward financing the Plan.

Hospitals required to demonstrate Electronic Image Sharing in 2011

May 24th, 2010

Despite the key role that medical imaging plays in patient care, the inclusion of medical images in the Meaningful Use criteria for ARRA funding was supposedly all the way out in 2015.  One would think that that would give a healthcare organization plenty of time for planning, choosing a solution, budgeting and picking a vendor.

In theory, there are a number of ways to support Meaningful Use of images through the Physician Portal.  Whether you believe the best approach is [1] an Enterprise Archive with a UniViewer, [2] a multi-department PACS with its UniViewer, or [3] a continuation of individual department PACS, each with their own viewers; four-plus years would seem to be plenty of time to watch what the early adopters deploy and figure out your own strategy.

I think those four years just disappeared…in a puff.

In a recent article, Keith Dreyer, D.O., Ph.D., included a statement in his conclusion that came as something of a surprise to me.   That statement is worth repeating here in its entirety.  The underlines are mine.

“The Centers for Medicare and Medicaid Services proposed rulemaking of December 2009 suggests that providers will be required to demonstrate cross-provider patient medical data sharing by 2011. Furthermore, at least 80% of patient requests for electronic medical data must be able to be delivered within 48 hours. It is expected that medical imaging will be an important component of these requirements. As the federal government begins to require even more communication among all healthcare providers, the need for standards-based technology will undoubtedly become an integral part of the medical imaging IT infrastructure.”

“By taking a proactive approach and deploying technology such as image sharing applications, your department—and organization—will be better prepared for the impending future.”

Since this admittedly came as a surprise to me, I did a search and came up with an article in Healthcare IT News that listed the actual wording of the December rulemaking that Dr. Dreyer was interpreting.  Sure enough, in # 15 and #17 in the list of 23 Stage 1 Meaningful Use criteria, there appears a reference to “diagnostic test results”, and one can easily agree with Dr. Dreyer that that should be interpreted to include the actual images themselves.

What a timely discovery!

Medical Image (data) Sharing is already a hot subject.  By my count there are already 20 companies pitching some version of electronic Image Sharing…data transfer from site A to site B over a Virtual Private Network (VPN) or through an encryption application over the internet.  In most cases, these products are simply replacing the method of data transfer, replacing CDs with a network.  Most of these solutions fail to address a more subtle problem with data exchange between systems.  That problem is data compatibility.

All PACS systems are largely DICOM-conformant, but that conformance in and of itself does not guarantee data compatibility between different PACS.  Image data formatted by PACS A is not necessarily going to be fully compatible with PACS B just because the data is in the DICOM format.  I’ve already posted a piece on this subject on this web site. These new electronic image sharing products/services must be able to perform bi-directional dynamic tag morphing on the image data being transferred between systems in order to assure compatibility on the receiving end.

What makes Dr. Dreyer’s conclusions regarding electronic image sharing in 2011 so interesting is that they link Image Sharing with the larger subject of Meaningful Use by 2015.

I believe Meaningful Use in 2015 will depend on Ease of Use, and that strongly suggests a single consolidated image data repository and a single UniViewer, and the foundation of that concept is dynamic tag morphing…the ability to make image data from disparate PACS compatible with a single viewer.   So the PACS-Neutral Archive and the Image Sharing System have a very important key ingredient in common…Bi-directional Dynamic Tag Morphing.

There may be plenty of time to build the infrastructure necessary to achieve Meaningful Use of image data in 2015, but there’s no point in overlooking opportunities to build the stepping stones of that infrastructure this year.  An Image Sharing solution that includes the tag morphing application might easily be expanded, step-by-step, year-by-year to become the Neutral Archive an organization will need in 2015.

Picking the right Image Sharing solution, the one that grows into Neutral Archive, means having the bigger plan in place for the Neutral Archive.  Getting from 2011 to 2015 with the least number of dead-ends, restarts, forklifts, etc, means taking the time to build the big plan now.  Thank you, Dr. Dreyer, for providing a more immediate motivation.

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

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?