The problem with Web access to PACS

Posted by Martin P in PACS General

Oct
28

For at least the last 10 years, access to PACS via a web browser has been sexy. Back in the days just before the turn of the millenium I had a big chip on my shoulder about PACS web clients. At the time, I was immersed in building my first enterprise-scale PACS and looked at as many different ways of doing almost everything as I could. I looked on as the notion of ‘web everywhere’ (in the first incarnation of the .dot-net bubble) as being mis-sold into a place where it simply did not belong.

Browser-based delivery of applications, being a form of thin-client delivery, wasn’t new even then. And neither was the fundamental understanding that thin-client delivery IS SIMPLY NOT APPROPRIATE FOR DATA INTENSIVE OPERATIONS. Sorry for shouting. Even today, over 10 years later, I hear complaints about how long data transfers take over a network to a web browser that is simply not designed to deal with such data.

But, to be fair, things change. Bandwidths have improved out of sight – on WAN links as well as LAN. New ways of taking advantage of browsers (such as AJAX) make a difference in terms of user experience. Vendors pitched themselves at the time as visionary, but I’m more than a little bit sceptical. In any event, BROWSER-BASED REPORTING WORKSTATIONS ARE STILL WRONG.

I’ll tell you why. Reporting monitors cost a lot of money. And rightly so – the technology to get the brightness, contrast resolution and uniformity out of those monitors is impressive (I’m an ~~anorak~~ physicist by training – I kinda like that stuff!). But a lot of the cost of those monitors is in technology to get 12 bits of contrast resolution rather than the 8 bits (if you’re lucky) that standard monitors offer. But there lies an issue – to take advantage of the additional 4 bits of resolutions an application needs to hook directly into the proprietary API of the board/monitor combination.

BROWSERS CAN NOT DO THAT. Any browser-based application being displayed on high-end monitors is ~~pissing~~ throwing away half of the value of that monitor.

To take full advantage of the significant investment you make in hardware – avoid browser-based reporting access. In fact, avoid anything other than local Windows applications that specifically use the API supplied by the board/monitor manufacturer. Ask the question of the vendors – do they use the dedicated API or not. I know of at least one who does not, and still sells full 12-bit workstations that can only use 8. I’d like to bet there are many more.

Will that change? Perhaps. Just last week, Mozilla announced a new initiative (Prism) intended to present existing Web applications (Gmail, Zimbra, Facebook, Webmail etc) as what appears to all intents and purposes to be a desktop application. While details are still a bit sniffy, one comment caught my attention:

…… we’re also working to increase the capabilities of those apps by adding functionality to the Web itself, such as providing support for offline data storage and access to 3D graphics hardware.

Hey. Not quite a bullseye but certainly a move in the right direction. I’ll keep an eye on that.