Next Generation PACS will be Smaller

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”.

Next Step in Image Sharing…Beyond the CD/DVD

The task of getting a patient’s medical images into the hands of the Specialists, Surgeons and Primary Care physicians becomes considerably more complicated, when those images are produced in an “outside” Organization.  The practice of forwarding film-based images ahead of or with the patient is increasingly rare, having been replaced with the conveyance of digital copies of the patient’s images on CD or DVD.   While this method of data exchange between organizations is considered more efficient and less expensive than forwarding films, the problems associated with data exchange using the CD/DVD are now legendary.

Aside from such obvious issues as viewing software and media compatibility, the principal problem is frequently basic data incompatibility.  The DICOM standard allows a significant degree of “customization” of the DICOM image data header by the PACS vendors.  In a white paper recently written by Dr. Wayne DeJarnette, titled Context Management and Tag Morphing in the Real World and posted on their informational web site, there are 10 examples sited where certain key pieces of information stored in the DICOM header need to be created, modified or moved in order for one PACS to be able to properly interpret the data created by another PACS.  I highly recommend reading this paper to catch up on the subject generally referred to as Tag Morphing.

Apparently the problems associated with sharing medical image data using CD/DVD media has reached critical mass, because a number of solutions in the form of Data Exchange Servers and Data Exchange Services have recently entered the market.  The focus of these new products and fee-per-study services is clearly to provide an end to the pains of data exchange.  Unfortunately there is now yet another set of issues.

Clearly the  most exciting solution to the data exchange issue is the “Image Share Service in a Cloud”.  How can one not get excited about anything in a cloud?  I counted a half dozen such “cloud” service solutions being exhibited at the 2009 RSNA or being advertised since.  The simple, high-level summary description of this fee-per-study service is as follows.  An authorized organization/user accesses the upload application through a secure web site.  A couple of simple clicks and data insertions later and a patient’s medical image data is uploaded to a central server in the cloud.  There are a number of methods for announcing the availability of these images in the cloud to the intended recipient, ranging from email notification to a phone call.  The authorized organization/user then accesses the secure web site hosted by the cloud server and is granted access to only those images intended for their use.

Here is the interesting part.  The intended user then downloads to their PC a very small piece of client software, in some cases there is no client software (zero), and this allows the user to view the images on their PC.  Most of the display applications I have seen associated with this version of the cloud service are based on what is called “server-side rendering”, meaning all of the image rendering, processing, etc. being directed by the user is actually being executed on the server in the cloud.  The result of this rendering, an HTML page, is all that is actually downloaded to the user’s PC.  The actual image data itself is not downloaded to the user’s PC.  The actual image data itself does not leave the secure server in the cloud, making this a very HIPAA-compliant application.

The current state of server-side rendering display applications allows for support of full-fidelity (loss-less) images and a full range of image processing features (2D, 3D, even Orthopedic templating), so the display application associated with most of these cloud-based image exchange services should be well received by a wide range of physicians seeking access to a patient’s images that were produced in an “outside” organization.

What I find most interesting about this approach to image sharing is that this solution totally avoids the data incompatibility problems encountered when an organization attempts to actually import digital image data from an “outside” PACS into their local PACS.  Instead of importing “outside” study data into the local PACS, so the images can be accessed and viewed by the physicians using the local PACS web viewer, the cloud solution depends on its own embedded display application to access and display the image data.  Just like all PACS that customize the image header of incoming image data, the cloud server only has to make the incoming study data produced by the contributing PACS completely compatible with its own display application.  Moreover these new server-side rendering display applications frequently offer a wider range of features and functions than the incumbent local PACS “web Viewer”.   It’s a clever solution that simply avoids the data incompatibility problem.  As mentioned, this version of image sharing is available as either a purchased/leased “appliance” or a fee-per-study cloud-based service.

However clever this solution appears, it is important to remember that this version of image sharing does not solve the data incompatibility problem.  If an organization wishes to assimilate a patient’s image study data created by an outside organization into that patient’s local longitudinal medical record (acquire the outside study data into the local PACS and add the study to the patient’s local folder); the data must first be modified,  more specifically the DICOM headers must first be modified, to satisfy the idiosyncrasies of the receiving PACS.  That means executing Tag Morphing of the type and complexity mentioned in the DeJarnette white paper.  Unless the contributing and receiving organizations have only a few studies a day to exchange, a manual approach to this Tag Morphing would be too labor intensive to be practical, not to mention fraught with the potential for human error.   In short the exchange of study data between two different organizations, and especially between disparate PACS requires an appliance or a fee-per-study service that can automatically execute Dynamic Tag Morphing on the incoming DICOM image data headers, prior to exporting the data to the recipient PACS.  Any solution that does not support this key process, is naively  relying on “DICOM conformance”, and we already know the problems with that approach.

In summary, I think an appliance or a cloud-based service that can provide the physicians with HIPAA-compliant internet access and display of a patient’s outside images is a significant advance over the CD/DVD method of data exchange.  I think the display-only approach is a clever way to avoid the problems inherent in exchanging data between disparate PACS.  The participating organizations simply need to understand their needs and make sure that the chosen solution will meet their expectations.  Products or Services that suggest that actual data exchange between the PACS is an option should be expected to provide evidence that their product or service supports Dynamic Tag Morphing.  Otherwise the organizations will likely end up right back where they are today with their CDs and DVDs.

Note: Currently there’s not a lot of information available on DICOM Tag Morphing out there on the web.  In addition to the DeJarnette paper already mentioned, you might want to focus your favorite search engine on “vendor-neutral archive”, as I’m sure any of those vendors can provide additional info on this subject.

Is it a PACS-Neutral Archive or Vendor-Neutral Archive?

I guess that depends on how far back in time one extends the search.  I began writing about a PACS-Neutral Archive back in 2007, and those posts are still available on this web site.  I chose the term PACS-Neutral, because I believed that it best described the focus of the neutrality.  The archive would be neutral with respect to the individual PACS systems that would inter-operate with it.  A key to the Neutral Archive’s ability to exchange data between disparate PACS is the feature now commonly referred to as bi-directional dynamic tag morphing.  In this sense the term PACS-Neutral did not refer to the absence of any vendor preference or vendor logo, it referred to the ability of the archive to effectively exchange data between PACS (systems) from different vendors.

As time moved along, the term Vendor-Neutral Archive emerged.  I am not certain of the initial source or sources of this term, or of the logic behind its creation.  Perhaps it came to be simply because the term PACS-Neutral Archive was already in the literature.  (Branding is such a personal thing to some organizations and individuals.)

I have been told that the term Vendor-Neutral Archive refers to an Archive that is neutral with respect to Vendors.  Presumably that means PACS vendors and Server vendors and Storage Solution vendors, because there is clearly a neutral archive application vendor with a vested interest in the system.

I can almost see and hear Andy Rooney of 60 minutes explaining to us “PACS-Neutral, Vendor-Neutral, it’s the same thing, and why people have to invent multiple names for the same thing is beyond me.”.

So just to go on record, as far as I’m concerned, the two terms are interchangeable, and hopefully none of the vendors (both those with the technology and those without) will mount a sinister campaign claiming that one name refers to a technology that is either superior or more feature-rich than the other.  We’re just getting something going here, so let’s make an effort not to confuse everybody.

Besides, months from now, I suspect we will all be simply using “Neutral Archive”, and we will all know what we mean.  At least that is my fervent hope.

RSNA 2009 Meeting signals beginning of a Paradigm Shift in Medical Image Data Management

Based on my conversations with both the vendors that really have  PACS-Neutral (Vendor-Neutral) Archive technology and those that do not, a significant number of attendees of this year’s RSNA meeting in Chicago (Nov 29 thru Dec 4), were seeking information on the subject.  Numerous motivations were sited for the surge in interest including: time and costs associated with data migrations, difficulty exchanging data between disparate PACS, and the requirement to image-enable an Electronic Medical Record system.  Having written extensively on the subject of  Neutral Archives, I find it encouraging that a growing number of Health Systems large and small are finally “getting it”.

My perception of the overall “buzz” on the subject at this year’s RSNA reminds me of 1992, as seventeen years ago the radiology PACS market had come of age and the degree of misinformation and deliberate obfuscation on that subject during that RSNA was shameful.   As Yogi Berra has said, “It’s deja  vu all over again”.  Numerous vendors that actually do not have Neutral Archive technology were actually claiming at this year’s RSNA that their Radiology PACS could effectively function as a neutral Archive.

Now that the vendors (both the haves and the have nots) are preparing their marketing strategies for Neutral Archive, the industry consultants are also coming out of the woodwork, preparing their statements of work.  It’s a good thing there are some good articles on the subject, so the consultants don’t have to learn the material the hard way.

So I guess if the vendors and the consultants are all over it, the age of the Neutral Archive has arrived.

Accurately defining what constitutes the Neutral Archive should be the next order of business for any Health System with serious interest, and especially for those organizations that have any of a number of problems whose solutions require this technology.  While there are at least ten key feature/functions included in that list, the one most important would be the ability to execute bidirectional dynamic tag morphing.

A good deal of information on this key feature/function has already been written and posted on this web site and on the new web site hosted by DeJarnette Research and I suspect a good deal more will be forthcoming in the next few months.  This time, if we are going to avoid a good number of the missteps and detours experienced in the early years of radiology PACS deployment, we need to make sure that detailed and accurate information on the subject is readily available to the decision makers.  My advice to the interested Health System is simply this, pay attention to the source of information on this important subject and always confirm the information with multiple trusted sources.

And now a word from our sponsor:  Gray Consulting has developed a simple but effective 3-Step Action Plan that will assist a Health System in understanding the subject of Neutral Archives, determine the compatibility of existing PACS with such an archive, and determine the costs of future data migrations that could be avoided.  Contact Gray Consulting for a description of the 3-Step Action Plan and a quote.

ARRA Incentive Funds Should Reward “Meaningful Use” of Image Data . . . Now Not Later

With all due respect to the learned leadership in the department of Health and Human Services and the Office of the National Coordinator for IT, it is my opinion that the early phases of the plan to award incentive payments to hospitals and physicians for  “meaningful use” of “certified” electronic health record systems is missing a key foundational component.  Without the appropriate technology foundation for clinical systems to capture, store and share image data objects across all ‘ologies, the EHR technology deployed by the providers will present a substantially incomplete view of the patient’s record.

According to a paper written and published by the  Markle Foundation Connecting for Health, 2009 titled “A Framework for ‘Meaningful Use’ and ‘Certified or Qualified’ EHR – Achieving the Health IT Objectives of the American Recovery and Reinvestment Act”, there are seven Principles for Meaningful Use and Qualification for Certification of EHRs.  The first four of these seven principals are actually quite revealing.

  1. The overarching nationwide goals of health IT investments are to improve health care quality, reduce growth in costs, stimulate innovation, and protect privacy.
  2. These goals can be achieved only through the effective use of information to support better decision-making and more effective care processes that improve health outcomes and reduce cost growth.
  3. Meaningful use should be demonstrable in the first years of implementation (2011-12) without creating undue burden on clinicians and practices.
  4. The definition of meaningful use should gradually expand to encompass more ambitious health improvement aims over time (i.e. image data).

The first three principals represent the kind of thinking that led to the decision to initially focus on what may seem to be the type of data objects that are relatively easy to access in electronic format.  At first glance it seemed to me that the early phase focus on Medication Management, Laboratory Results and Care Summaries, and the postponed inclusion of Medical Images, was a calculated attempt to capture, manage and distribute the kind of small data objects that are still being recorded on paper.  Score one for the Primary Care physician struggling to manage a barrage of paper-based information trapped in an inch thick manila folder.  I’m thinking “It’s a noble effort and besides, they’re little objects, so that should be easy!”

Then I began looking at this decision from another perspective.  Perhaps IHE and the Imaging Device manufacturers have been so successful convincing everyone that medical image data is so well organized under DICOM and therefore so easily distributed, that our thought leaders believe that there is no need to offer incentives to hospitals or physicians for meaningful use of image information.  Obviously Medical Image data is easily accessible within the hospital’s network and the internet or via those ubiquitous CDs.  With image data so clearly under control, the focus of those financial incentives should be placed instead on bringing the remaining paper-based sectors up to the same enviable status of Medical Imaging.

Forgive me, but I don’t see it that way.

From my perspective, working as a consultant to the Radiology PACS and Enterprise Archive market segments, DICOM is not so tight a standard that data exchange between disparate systems is assured.  In fact, the PACS vendors have deliberately created separate silos of medical images that (by their design) sequester their image content from universal access.  Once the images are delivered to another application, there is just enough proprietary information in a DICOM image header to assure that the best delivery and rendering of the image will be achieved by the vendor that created the image (Imaging Device) or by the vendor that modified and currently stores it (PACS).  The problems encountered during attempts to exchange image data between disparate systems using CDs are legend.  As for replacing the use of film by the referring physicians, most PACS have inadequately addressed the imaging needs of those physicians working in the hospital and especially those working in their offices and clinics off campus.  The consequences are complex, cumbersome and expensive. Can’t get the film anymore, but can’t get the electronic copy?  Not a problem, just redo the exam.

So the American Recovery and Reinvestment Act of 2009 (ARRA), the economic stimulus package enacted by Congress last February, is designed to reward hospitals and physicians with Medicare and Medicaid incentive payments for making “meaningful use” of “certified” electronic health records systems.  Back in May, Cheryl Proval in an article for Imaging Biz.com quoted Mr. Charles Christian, CIO and health systems manager of Good Samaritan Hospital, Vincennes, Indiana, and chair of the HIMSS board of directors. “The Medicare and Medicaid health IT incentives alone – which will be distributed through the states – could add up significantly for both hospitals and physicians. A 75-bed hospital, for 2011 through 2014, stands to reap $3.5 million: That’s probably twice what its annual bottom line is.  A 250-bed hospital has the potential to earn almost $6 million over four years, and a 750-bed hospital could qualify for nearly $12 million.”  The incentive bonanza estimated for the hospitals was used by PACS Consultant Michael Cannavo to launch a thread on Antminnie.com the very next month.  Vendors and Providers alike have been speculating ever since as to how to get their fair share of the funding.

Forgive me once again, but I think it’s going to be much more difficult than anticipated to collect on those incentives, if the focus of the first two years is on the accessing, sharing, and meaningful use of the electronic copy of Medication Management (recent medications), Laboratory Results, and Care Summaries.  While it’s a reasonable assumption that these data objects might be accessible and deliverable via HL-7, the last time I looked at the HL-7 “standard”, it was more open to interpretation than DICOM, and we know how well that’s working out as the type of standard that assures data exchange.

With the hope of finding significant movement towards interoperability between the type of systems that manage Medication, Lab Results, and Care Summaries, I recently visited the IHE website, specifically the Frameworks tab and discovered that there are no profiles as yet for Medication Management systems and that the Lab profiles were only recently tested in February at a European connectathon.  My hope is that Care Summaries would either be created in the electronic charting component of the EHR or could at least be managed as scanned documents.  My interpretation of the results of my research is just this: [1] Medication Management is not even on the radar and [2] the process of interconnecting Laboratory systems with external data repositories for the purpose of accessing and sharing lab results is just getting started, ergo [3] the sharing of Care Summaries through the EHR may be the only achievable objective of the first two years.

My conclusion is that the effort to access and distribute Medication and Laboratory data is many years behind the Radiology community’s efforts to standardize data format and communication protocol based on the DICOM standard.  If conformance to a single flavor of HL-7 is a requisite for accessing and sharing the kind of data that is the focus of the next few years, and the vendors proceed at the same pace as we have witnessed in the Radiology and now the Cardiology markets, it is going to take a tremendous volume of Care Summaries to justify the $Millions in incentive payments through 2011.

Here is my suggestion, and I make this in all seriousness to the hospitals and independent delivery networks out there.  Tuesday, August 25, 2009. in an article appearing on the HealthImaging.com website, the following was reported: “The Department of Health and Human Services (HHS) and the Centers for Medicare & Medicaid Services (CMS) are asking for industry help through an official Request for Information (RFI) in determining the current status of the U.S. health IT infrastructure, and the steps needed to be taken to further develop that infrastructure.”

I suggest that we collectively lobby for the inclusion of Image Data along with Medications and Laboratory in the first phase.  Image data makes up approximately 85% of the patient’s medical record.  Repeating a lab test because we can’t find the result does cost time and money, but not of the magnitude of time and money that it takes to repeat a CT.  We are so close to being able to reliably and easily exchange Radiology and Cardiology study data and push it out to the most remote and clunky desktop (via a Server-side Rendering UniViewer).  All that is needed is a little funding for the PACS-neutral Archive movement, and we can set a fine example for Medication Management, Laboratory, and the more ambitious health improvement aims that would focus in the future on such data types as problem lists, allergies, vitals, findings, procedures, care plans, hospital discharge summaries, patient registration forms, etc.

Let’s argue that an incentive plan that focuses on the short term unattainable is no incentive plan, and that investing an appropriate expenditure in Neutral Enterprise Image Archiving is exactly what is needed right now to provide the required technological foundation to support “meaningful use” of images and then all of the other data objects to follow.

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

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

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

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

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

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

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

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

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

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

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

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

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

New Breed of Teleradiology Poses Challenging Technology Issues

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

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

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

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

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

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

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

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

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

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

What Image Management Technologies will Qualify for ARRA Stimulus Funding?

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

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

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

“What aspects of ‘meaningful use’ would the PACS-Neutral Archive fulfill?”

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

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

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

“Would a departmental PACS system qualify for stimulus finding?”

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

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

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

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

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

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

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

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

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

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

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

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

PACS-Neutral Archive Action Plan

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

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

Actually that’s not far from the truth.

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

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

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

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

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

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

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