Web-Based PACS

A recent AuntMinnie.com thread rehashes the proper definition of a web-based PACS. This comes up periodically, and in July, 2003, Brad Levin from Amicas posted this lengthy but highly precise description:

First a bit of a disclaimer -- As my screen name explicitly describes, I'm Brad Levin and I'm the Director of Strategic Marketing for AMICAS. Prior to AMICAS, I was a PACS Subject Matter Expert for both Cap Gemini Ernst & Young and prior to that, Xtria Healthcare. I've experienced PACS for 10 years+, as the industry has made generational changes from the earliest military days of MDIS which was highly proprietary PACS (resulting in the Unix guts of most of today's traditional PACS), to the first DIN-PACS which spurred industry to go the route of rudimentary integrated RIS/PACS and heavily brokered systems, and most recently to Web-based PACS.

I'll try to provide you a snapshot of this market segment as it exists today -- it's a long response, but I hope this provides some clarity for you:
What is Web-based PACS? While there is no Webster's definition, Web-based PACS is PACS with the guts of a Web server under the hood. In other words, Web-based PACS delivers images and reports via a URL-based mechanism (e.g., what you typed in your browser to get to AuntMinnie.com). Some Web-based PACS vendors have URLs literally in their graphical user interface (GUI), while others use this mechanism, but choose not to have the URL accessible explicitly in the GUI.
Why Web-based PACS? Traditional approaches to PACS are tried and true - there's no argument there, as every vendor can ultimately move around images and reports. But to continue the automobile metaphor, these methods require significant "elbow grease" to be successful. This level of effort has both frustrated PACS customers and vendors alike. Why? Because these approaches lead to PACS with brokers, multiple databases, multiple operating systems, restrictive Radiology-centric workflow, expensive workstations/clinical viewers, multiple levels of archive, proprietary hardware (purchased through PACS vendors), a separate/non-scaleable Web-server and multiple user interfaces for different PACS viewing applications: telerad, distribution, clinical viewing and diagnostic workstations. The paradigm shift of PACS is challenging enough on its own (e.g., change management, training, system rollout) let alone to be hampered by the technical complexity of these disparate systems that must be implemented, maintained, and synchronized. It's complex because it's inherent in the model.

What has been the result of these valiant efforts for PACS? Vendors have had no choice but to pass through (with profits) the complex development, support and integration costs onto the PACS consumer marketplace. By virtue of real-world experience alone, the majority of industry consultants are most familiar with this complex model of PACS and it is continually demonstrated in their RFPs. RFPs have marginally changed from the early days of PACS despite the significant differences in approaches to PACS. So, rather than make generational changes in architecture, many traditional vendors have continued to deliver "complex" PACS via this model, charging several million dollars per PACS, plus several hundred thousands dollars per year for support. That is why so many traditional PACS buyers have a hard time cost justifying PACS, because ROI (using "hard" numbers) is difficult to achieve in a model that does not have the tools to eliminate the production of film. And if you can't eliminate the film, you'll chase, but never get to ROI. That doesn't mean that PACS can't be justified with this model, because consultants and PACS customers have learned how to be creative using this approach with so called "soft and hard" savings. Just go to any conference or read the mags and you'll learn how. Early adopters have worked the system in this fashion simply because the technology and inherent high costs have led them in this not so pleasant direction.

So why Web-based PACS now? Simply speaking, the market dynamics changed and PACS customers are more demanding - on their terms. While literally one or two vendors have been in Web-based PACS for years, the PACS marketplace has clearly taken a decisive turn in the past 3 years. Today, there are probably a half dozen or more vendors offering Web-based PACS, and a similar handful of RIS vendors offer Web-based solutions as well.

As I said earlier, PACS early adopters (e.g., academics > 400 beds) are in upgrade mode now, but have had great difficulty accepting the costly terms of upgrading their traditional PACS. They are questioning "why spend millions on a model that was created in the early/mid 90s"?. I don't think anyone would purchase a 286/386 PC today. The same rationale exists for PACS, except when you purchase/upgrade your system, you are tied to your purchase for at least 5 years+. Combined with this is the reality that the broader marketplace (e.g., <400>

So, the only way for traditional PACS vendors to address this market opportunity is to come up with a model that meets the "demand" with a "solution" that can be delivered with scale (to provide wide image/report access and thus, allow film printing to nearly cease); reduce architectural complexity to "simplistic" models that can be deployed fast, supported over the Web with minimal resources, upgraded over the Web, etc.; provide integration platforms to electronic medical record (EMR) systems through Web server calls; leverage PACS for the enterprise and not just for Radiology; integrate through brokerless interface engines; and perhaps most important of all, to be able to be sold for less to meet the market demand head on.

And what is the outcome of the above? PACS powered by the Web allows adopters to move to PACS faster, with far greater simplicity, and thus, far more affordably than has historically been the case for PACS. It's a confusing time in the marketplace for sure -- but make no mistake -- the rules for PACS have been and are continuing to be rewritten, allowing ROI to be a reality, not the fallacy from the past. There are many flavors to Web-based PACS out there. Some use proprietary means, others focus on standards. Some offer more restrictive solutions than others for enterprise workflow, integration, off the shelf hardware, etc.

In closing, the main message of my response is that for those who have been in the industry a long time the momentum is fairly obvious -- the Web is clearly the direction of the emerging PACS vendors and most of the traditional vendors are either on board with the Web, have released partial Web-based products, or you can almost certainly be sure the Web will play a part in their future releases. If they don't move, they and their customers will be left behind. And as in the past, one day the market dynamics will have its way with the Web --- it is almost inevitable. But when that day will come is anyone's guess. The wave of the Web is in it's infancy and will likely ride for many years to come. Just remember that the PACS penetration rate outside of the academics is in single digits today, and this is the target market for all of the traditional vendors. Some can play in this space today, others can't.

The real final message is that astute and novice PACS buyers have no choice but to filter out PACS for their own best fit model. The change from the past is that the business of Radiology for the <300~400>

Thanks for listening and I hope this was helpful.
blevin@amicas.com

It was very helpful Brad. Based on what we've seen over the past 2 years, I think he hit pretty close to the mark.

This information has formed the basis of my own definition of web-based PACS, i.e., that it is a web-server at its core, utilizing web technology overall, and not simply adding a server as an appendage to a more traditional architecture.

Note that the top KLAS-mates over the past few years have all been web-based products, Amicas, DR, Stentor. I said in an AM post after SCAR 2003 that most major vendors either had or will have web-based architecture based on the above definition. This seems to be coming true, slowly but surely.