The problem with Web access to PACS

Posted by Martin P in PACS General      No comments

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.

Interprocess Communication

Posted by Martin P in Development, IHE      No comments

Oct
28

Any system as complex as RIS/PACS is inevitably made up of a number of elements.
RIS elements will include:

• HL7/IHE interfacing for registration, scheduling, and order notification and trnsmission.
• Independent scheduling (i.e. independent of HIS/PAS)
• Independent registration
• Worklist generation
• Dictation system integration
• Transcription management

… amongst others

In the case of PACS these may include:

• A DICOM services module
• A Storage management module
• HL7/IHE interfacing
• Worklist generation
• Image viewing (simple)
• Image viewing (advanced visualisation)
• Security management

….and many others

We’ll evolve this list & flesh it out in other posts on this blog.

One way to implement these elements is to generate a monster monolithic lump of software that does everything.  While some vendors choose to go in that direction (largely, to be fair, due to decisions made in the dim and distant past), from a software engineering perpective, that is self-destructive.  Even in proprietary software development, it is long appreciated that development teams should be kept modest in size.  In community-driven Open Source software there simply is no alternative but to provide features in self-contained modular units that small community teams can maintain.

Many of those modules will want to communicate with each other, or indeed with a central marshalling point, for a number of information transfers.  To avoid having to implement periodic polling (a heinous practice but unfortunately inevitable in many cases) , for example, the DICOM services may need to pre-emptively notify the image viewing modules that a new image/series/study is available.  In this example, the communication is almost certainly across different physical machines.

Equally, the modules themselves may be implemented via different technologies.  Technologies anticipated which may need to be involved in message transfer include Java, C#/CLR, PHP, Javascript, and likely others.

It is clearly beneficial to minimise the number of different mechanisms involved, and we are aspiring in the initial instance to a single mechanism.  We have enough experience in the crucible of real-world development to accept that ambitious aspirations sometimes fall by the wayside, and we are ready to adapt if necessary.

We have noted above that the requirements for messaging include cross-technology and both local and remote.  There is one other which we are considering a core requirement, and that is cross-application.  We believe that one (if not THE one) reason why healthcare applications have poor penetration globally is that they do not talk to each other very well. While HL7 messaging has become mainstream (and crucially so), ‘mainstream’ has only really happened since the turn of the century.  But end users do not get to see HL7 messaging – it happens in the background.  End users see RIS/PACS/LAB/PAS/HIS/ED/ICU et al sat on their desktop and each one must be logged into seperately.  Each time the patient view changes – the same patient must be found in each application.  This raises a risk that two applications on one desktop are focussed on different patients – and that simply has to be an invitation for mistakes.  How many times have tests/procedures been ordered for the wrong patient because the orderer didn’t notice the patient context in two applications is different?  I’ll bet it happens, and it shouldn’t.

It shouldn’t because its dangerous, but mostly it shouldn’t because it needn’t. The HL7 CCOW protocol is specifically designed to prevent (mostly) this scenario, but CCOW takeup is even slower than HL7 messaging.  I believe and have for some years that CCOW is one of the keys to IT truly working for Heathcare and we consider full CCOW support to be non-negotiable.  Of course that does not help with the other applications on the desktop, but I believe that in time CCOW will make its presence felt (despite the vendors).

CCOW comes with two mechanisms built in – ActiveX and HTTP. Disregarding ActiveX immediately as platform specific, we are left with HTTP. The question we have wrestled with is:

Can we use HTTP generally as a mechanism for IPC and specifically, build on the CCOW protocol to provide all of our messaging needs?

In fact it doesn’t take much scratching the surface to decide that the answer is no.  There are a number of scenarios with are not suited to the CCOW standard at all – specifically those involved in generating lists, or arrays of information.  But using the HTTP protocol as a transport layer, there are other higher-level layers that are specifically designed to fulfill those needs – XML and JSON being two in particular.  Of those, it is generally recognised (IMHO) that JSON is the more suited for regularised data transfer.

So for the moment, our plan is to use HTTP as a transport layer, with data-specific protocols layered over – certainly CCOW and JSON should see a good start to communication requirements and we can be prepared to add to that catalogue if necessary.  That means that each of the modules must have a embedded HTTP server serving at least those interfaces necessary for York.  In one sense that creates a complication but if we can keep the interface definitions simple (as, indeed, CCOW is once one  works out how to read the documentation), then the goal of modularity is made simpler.

Choosing a platform

Posted by Martin P in Development      No comments

Oct
23

To a large extent (excepting those areas where we stand on the shoulders of giants), we have found ourselves with a clean sheet of paper with regard to the platforms and technologies we use to build a ‘whole product’. Those of us who are developers have our own preferences but on the whole are happy to stray out of the comfort zone where necessary (not very often hopefully).

There are guiding principles which we kept pasted on the wall (figuratively, anyway) during discussions. In some cases, these principles conflicted but I feel the choices made, while imperfect, are a good balance.
Those principles are:

• There should be nothing in the ‘whole product’ which requires any user (or developer) to pay for the privilege of using (or contributing).
• The ‘whole product’ should embrace fully the concept of ‘open’ as defined by the OSD.
• The barrier to participation and contribution should be as low as humanly possible. As well as code, that includes feedback, bug reports, use cases etc. Where there are options (and generally there are), the option most accessible should be chosen.
• Wherever possible, functionality, whether visible or not, should not be duplicated. For example, a data service which returns a worklist should be used wherever a worklist is required, regardless of the use to which the worklist will be put.

The task facing us is significant, however, and of course, as in life, these principles may on occasion conflict with each other. But we can say that we’ll make our best stab at navigating those conflicts in good faith.

So where does that leave Project York in terms of platform – both development and operating?

We can consider first web-based access – perhaps the simplest. The trend towards Rich User Interfaces in the browser is well established, particularly with AJAX techniques. So browser-side this is the platform – HTML with CSS and Javascript/AJAX. There is at least one exception to this where Java makes a brief appearance but I will discuss that in a later post (on inter-process communication). Server-side we have chosen PHP. This because:

• It is of course (along with Python and Perl) a component of the LAMP platform – freely available and easy to deploy.
• It has a very low barrier to entry.
• The additional support/help/infrastructure available from Zend renders issues of performance and reliability irrelevant, as long as money is involved.

But while web access is (or more precisely, can be) good enough for remote access and referring clinicians, a true local application is critical for reporting workstations – from a performance and data display perspective, there simply is no choice. Since one of the key principles is to be freely avalailable, it would be desirable to at least allow for deployment on a free operating system (e.g. Linux). This however creates a problem when we move to using high-resolution monitors. The drivers for those monitors are on the whole (indeed perhaps exclusively) Windows-based.

So unless something changes in the availability of display drivers for platforms other than Windows, Windows must, at least at the outset, be the primary platform for Project York. Having said that, I certainly hope that progress can be made in that direction, and it is an important, if secondary, objective, that no decisions are made that rule out being platform-independent at some point in the future.

I actually have a bit of a chip on my shoulder about PACS clients and display APIs so I’m going to go off on a tangent briefly and vent my spleen (credit: Jane Austin) for the next post.

Back from the venting, the question of platform for the desktop viewing application remains. From a cross-platform perspective, I have looked closely and deeply at the option offered by C# via .Net/Mono with a Gtk+ user interface. Not, admittedly, truly platform-independent but heading in the right direction. Gtk is a good fit – it IS platform independent, and of course as it originates in the GIMP image processing application, there is strong aligment with PACS requirements.

I have had doubts, though. The future of Mono is a little fuzzy around the edges largely due to the uncertainty around Microsoft’s OSS credentials, but I am more concerned that the barrier to entry for the C#/.Net development environment is higher than ideal. While considering possible strategies for breaking down this barrier I came across what I feel may be the answer: Gtk-PHP – a Gtk binding for PHP which will, if the code is structured appropriately, allow for (at least some) re-use of PHP code used in the web access mode. But this raises a question – does a scripted language not come with performance issues? I don’t think so. Much of the heavy processing should be done within the Gtk widget set, which leaves the scripting side to organise the widgets and manage the data.

I’m intrigued by Gtk-PHP, especially in combination with a UI designer like Glade. The edges between the 3 components need to be smoothed down a little, and there is considerable work to be done in the way of documentation, but I think this has the potential to be the Visual Basic of its day. Back in the early ’90s I was horrified at the low barrier to entry VB offered, and the fact that any punter with two brain cells could lash together an application which looked like it really came out of a professional software house. It undoubtedly happened. I recall having to install and support just such an application which was there as what was then called a “document management system”. The fact that Documentum has gone on to be a market leader in the space just shows how much I know.

The intention is to proceed with the web-access features first, and PHP/HTML/JavaScript is ideal for that. We will keep in the back of our minds, however, that the server-side PHP could potentially be re-used as a scripted local client.

A Rose by any other name

Posted by Martin P in Project matters      No comments

Oct
22

We have had our own discussion about this, but I think (and have for some time) that until a project takes on an identity, it cannot work itself up to full speed. Of course, in this case, this is a FOSS project and the identity will (if we get it right) grow with a community. For the moment, however, the choice of a working name falls to me. Long may democracy be as easy as it is with a community of 3.

Welcome, then, to the York project.

Why York? Well firstly, and self-indulgently, York is the Viking name for the English city of York – the county capital of the county of my birth. Secondly, (and in some eyes, even worse), the city of York was founded by Vikings at the confluence of the river Ouse (a significant commercial thoroughfare in the days when such things were), and the river Foss (’nuff said?).

So, in anticipation of the sweet smell of success ………..

A Vision

Posted by Martin P in Project matters      No comments

Oct
22

What EXACTLY are we trying to do? That is a good question on a number of fronts, without the answer,:

• How do we know how to get there?
• How do we know when we DO get there?
• Importantly, how do we know how NOT to get there? As with any software project of any significant size, it would be very easy to go off on a tangent and lose sight of the target.

While we do not at this point in time have a precise view on what the final product would look like, we do have some idea, and certainly we have a precise vision of what we want to achieve.

Quite simply, we want to offer an alternative to those healthcare institutions who cannot or will not pay extortionate and unnecessary prices to take full advantage of imaging technologies and informatics processes that have been around for longer than the World Wide Web. To do this, we must follow 4 core principles:

• The core objective is to provide a package which allows for the efficient, reliable, and appropriate utilisation of digital radiographic images, of a quality which rivals if not exceeds commercial alternatives.
• This must be effected in a way conformant with the Open Source Definition.
• Any functionality on which the core objective is dependent will also be included, although :
• Functionality which may also normally reside in other packages can do so, and will be fully supported through appropriate industry standards, the implementation of which will not only be to the letter, but to the spirit also.
• Anything which does not make progress towards the undisputed benefits of PACS is of low priority.

Is this vision set in stone? I hope not. The world changes and the unbendable tend not to survive. But it will do to begin.

The undisputed benefits of PACS

Posted by Martin P in PACS General      No comments

Oct
22

I have seen projects succeed, and I have seen projects fail. One of the commonest reasons for projects failing (in total or in part) is a lack of focus on real-world, measurable objectives that actually make a difference to patients, clinicians and other users, and the institutions they work for. Those that fail start by addressing the problem as a function of the solution: “Our problem? We need a PACS!”. Those that succeed keep a firm grip on the actual, tangible problems a solution is intended to fix.

So I asked myself (again) about the cost/benefit balance of PACS, and particularly, which of the benefits have true potential and which are vapour?

• Cost savings. I’ve always been a little bemused at the notion of PACS deployment generating cost savings, and even a little sceptical about the notion of positive financial Return On Investment (ROI) – I have to see a comprehensive comparison of the real TCO (Total Cost of Ownership) against ROI. Waking up briefly to smell the coffee, an ‘enterprise’ level PACS for (lets say) a 500 bed hospital will cost up to $5M capital, and $500K-$750K annually recurring. This, to replace the traditional distribution method (film + chemicals + storage) delivered on an annual budget of $300K. Of course the ‘Return’ part of ROI is more than financial – as I will discuss below, but that is still a tough sum to balance, and I’m sure there are areas in many healthcare institutions where that $5M could be used to good effect. Conclusion? To achieve the remaining benefits is likely never going to be cost-positive, but in my view the balance is currently weighted too far in one direction.
• Process Improvement. The potential for improving the process of diagnostic imaging comes about in many ways, and in IMHO is the core driver behind PACS implementation:
• Lost films. Films going walkabouts after being reported (and therefore not available for retrospectives) is bad enough. But films not even making it to the Radiologist’s desk is even worse, and happens more often than many would like to admit. Of all of the advantages PACS can bring to the table, this should be the simplest to achieve. That doesn’t always happen – poor storage implementations from even the top tier ‘enterprise’ vendors does not always safeguard the data sufficiently, and moving from one vendor to another brings with it the risk of not being able to migrate historical data (this happens – I have personal experience of a vendor retiring a product whilst in the process of M&A activity effectively locking us out of their proprietary data store). The bottom line is – data security should be the easy bit.
• Easy, immediate, and simultaneous access to images. This can be a huge benefit in reducing the time-to-completion of a diagnostic process, and also in reducing the amount of time staff (often junior clinicians) waste looking for images.
• Collaboration both amongst Radiologists and referring clinicians.
• Clinical effectiveness. In a healthcare setting, decisions are often made with an incomplete information view simply because those decisions are necessarily time-constrained. Having images ‘simply’ available is one more step to rectifying that deficit. And putting the information into electronic form allows for the potential to apply new perspectives to that information. Nuclear medicine is one area where new algorithms appear regularly and can even(depending on vendor and quality of implementation) be applied to historic information. 3D visualisation of CTs and MRs is becoming mainstream and virtualoscopies will probably follow (has anyone even set up a Radiology practice in Second Life yet?).
• Radiation safety. While the reduction in plain-film retakes is as much to do with technology at the modalities as PACS, it is certainly true that the options to improve, adjust and annotate images necessarily reduces the need to retake examinations.

There are probably others I’ve missed. But if those aren’t enough you’d need your head examined.

A FOSS Project underway – PACS

Posted by Martin P in Project matters      1 comment

Oct
20

I would like to take this opportunity to introduce the beginnings of an Open Source PACS aimed squarely at challenging those proprietary vendors currently enjoying a joke at the expense of Healthcare providers, and specifically, those who provide the funding. I hold the opinion that the elitist, proprietary nature of the PACS market is fundamentally inequitable despite the fact that 95% of the technology behind PACS is “yesterday’s news”.  It is time for those left behind in the technology race to have a bite at the cherry, and “Open Source”, as a development and product model is very good at enabling just that.
I personally have strong views on the direction that the PACS industry has taken since the mid-90s or so. I feel that for the amount of money changing hands (both up front, and recurring -usually in the form of service fees), the healthcare providers that have been taken to the cleaners can look forward to:

• Quality that is no better than any other half-decent software in the Healthcare arena.
• Bundled hardware that is 5 years out of date and not supported by anybody other than that PACS vendor and certainly not by the original hardware vendor.
• Interoperability that has a laugh at the DICOM standard – one of the the first true interoperability standards in any industry. DICOM implementations do little to encourage a diverse vendor ecology and why should they – that is not how proprietary vendors work in any industry! Is anybody else frustrated with the IHE process which has rumbled on for years while vendors come to agreement on a “least common denominator” view of the world when in reality, every hospital/practice has a slightly different perspective of how to do things?
• Service that starts with “well of course if you’d bought all of your equipment from us……”
• First-line engineers that are expected to be experts in Hardware, databases, web servers, specialist monitors and who are often discouraged from escalating to 2d and 3rd level support groups.
• The prospect that all of your data now belongs to somebody else. The hardware may well be in your physical possession, but if you can’t get to your data without the goodwill of the vendor, you have a problem (contractual agreements are not a good way to protect oneself – no amount of contractual verbiage can transfer the duty of care).

I know, from my own experience in this industry as well as others, that it is possible to create quality systems where everybody takes benefit from the process and it is my own conviction that to do so in a way that allows Healthcare Providers the freedom to manage, and utilise, the digital images that have been around for decades, is only a rational thing to do.

So I, along with a couple of friends, am putting my coding fingers where my mouth is.

This is very much a beginning. Call it a ‘gestation’. There will be some time before even a ’0.1′ release (when we’ll release the first core code), and we’re not at a point to even lay a schedule. There will be standalone components that may be of value in their own right, and those may well be released independently (watch for a coming post on inter-process communication).

However, there are decisions to be made – technical, organisational and even, down the line (hopefully), governance. I and my colleagues can make a stab at most but I’m a big fan of openness and I firmly believe that with the help of those very many people who know more and different things and have different experience to me, this project can start in the right direction.

There are of course a number of very good open source projects in and around the area of medical imaging, from toolkits and APIs, the impressive OsiriX (which alas is targeted only at Macs), to the complete WorldVista package. Some of those we’ll be able to include (and contribute back as much as possible), but some not – for a number of reasons. The one common factor (the one ring to bind them?) will be the Open Source Definition. It is our intention that the entire code base will be licensed under the GPL. GPL2 or GPL3? Don’t know, and thankfully its a little (i.e. a lot) too early to make that decision.

Eric Raymond has written that “Every good work of software starts by scratching a developer’s personal itch”. Well this itch has become annoying.