"I still do not understand how all of the advantages that Brad describes are gained via a Web based PACS. Whether the PACS is web or not, a system can still be brokerless, flexible, inexpensive, easy to deploy, easy to upgrade, etc. A web based PACS still requires somewhat complex servers and configurations, etc. The advantage for me, and the only one, of a web based system is the ability to 'launch' the application from the web. This opens up opportunities that are endless. Now granted, that is a huge advantage, but I just dont think that people are conveying the advantages of web based PACS very well, and espescially not in this tidbit by Brad. I would love to see data on whether web based PACS perform better, are more reliable, are more secure, etc. And for those requests, I would love to see real examples, and not any high level, marketing focused, buzz word based responses."
I can't answer this question as well as, say, Brad Levin might, but I'll try. As you probably know by now, I have Agfa Impax 4.5 at one hospital, and Amicas LightBeam at another. The former is arguably at the pinnacle of development of a non-web-based system, the latter is typical of the modern breed of web-based architecture. What are the differences to me, the end-user?
If you discount differences in the clients themselves (and I could wax poetic about that for hours and hours), there is no obvious difference in the two approaches (again, from my point of view) whilst working within the hospital. I open the studies and read them. Rocket science here, right? I should add, however, that the Amicas system checks the software on my station upon each sign-on, and allows the installation of any available upgrade (that is already on the server) before the reading session begins. Could this be done with Impax? I suppose it could, but it isn't at the moment.
The real difference to me is how the system works when I am outside the hospital. Deployment of a client is much easier with a web-based system, and there is no discrepancy in the software I use at home, in the hospital, or in Timbuktu (or in the North Woods of Wisconsin if I should happen to be there.) Again, could this be accomplished with Impax? Maybe, but Agfa chooses instead to add another box, the Web1000, as an entirely separate server and client. The later versions of Web1000 look a little more like Impax, but they remain two very separate programs. At 3AM, it is a lot easier to use what you have been using all day than adjust to something different, trust me. Moreover, being able to sit at any computer in the world with broadband Internet access (well, any Windows computer anyway) and be up and running with minimal effort is truly mind-boggling when you think about it.
I'm not well-enough versed in the underlying architecture (or I haven't had enough Versed) to discuss the relative merits of each approach. My rather simplistic view is this: The 'net was designed for rapid, error-proof, interruption-resistant transmission of data. That's what we need for PACS, yes? So why reinvent the wheel?
I think we would all love to hear from experts on both sides of this issue.
2 comments :
I appreciate the response. I see the web as a huge advantage from a users standpoint only for the sake of launching the application. You can do much more in terms of integration when it is a web app. however, I still disagree on the bullet proof, rapid fire comments that are made. How often do youo click on a link on the web and get a 'Page cannot be displayed' then click back and try it again having it work the second time around? The web does get a little flaky at times. However, while they are communicating on the same port, I think 'web' based PACS systems are much more robust than that (I hope at least). Once you are in the application (after it is launched), the web is really out of the equation. You are running an application that is installed on your local machine. Most (all I would hope) applications have some capability to auto download new clients as they are available. So, to make a long story short, web or not, if an application can be downloaded and installed/configured from a web browser and if that same application will communicate on standard web ports, then to me everything else is the same. One can be at a coffee shop or at a book store and expect to be able to 1.) Download the client and 2.) Have the ports opened to communicate on. I would love to have some validation that my thoughts are in tune with how things are really engineered out there. I may be way off, who knows. With that said, you are correct in that some companies do it better than others! Amicas, I hear, rocks as well as a few of the other companies. There are others that are not so good. They have nice applications but make deploying them tough (GE, DR, etc.)
Now, I’m not a PACS person, I’m in IT, so take my opinion with a grain of salt. I would much rather see a well designed, small fat client install which uses the internet to communicate to a backend database than to see a “thin” web app.
Time and again I have seen vendors producing web applications that will only work on IE, and only on 5.5 (or earlier). I don’t use IE, and if I did, I certainly wouldn’t be using an old version. So right out of the gate, this kills one of the main selling points of portability. Add to this the nightmare scenario (for me) of customers calling with “Ever since I installed Smiley Central, I can’t read my lab results”, and you’ve got an all around loser in my book.
An easily available web site with a small, intuitive install would be so much more preferable to a web app. Limiting the customizations possible by the end-user saves a lot of support time in the long run.
Post a Comment