So, for the last month or so I had open a brief poll on why sites who do not have PACS are in that position. The results are below in MS Office Excel format, as well as Open Document Format (Open Office). The number of responses is modest (19), largely as the promotion of the poll was largely through discussion boards and mailing lists. However, since there was no suggestion of reward at the end, I think it can be assumed that those completing the survey did so in good faith, although I did weed out a couple of responses that were clearly at odds with that assumption. On the whole, for a web survey, despite the modest sample size, I think the data quality is fair.
Here’s the results:
Every now and again, I’ll take a look at the site traffic & while the hit counter hasn’t reached the point where I’m tempted to drop in Google adwords (and by golly would resist when it does!), there’s a steady stream of interest and even (gasp) some returning visitors. So here is a request for help.
While we have our own ideas of why PACS – despite being a no-brainer, hasn’t infiltrated every corner of the globe, we’d like to know what other people think. We’ve put together a VERY short survey 1-2 minutes only. It would be a great help if you could spare the time to fill it in, and there’s no sneaky stuff.
The survey is here, for Radiologists and institutions without a PACS.
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 ………..
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.
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.
Latest from the Blog:
- High Availability
- Lessons learned
- Open Source
- PACS General
- Project matters
- Martin Peacock on Virtual Servers and PACS
- Edward Mangiola on Virtual Servers and PACS
- Globalstorage on Business Continuity Planning in Health IT
- Martin P on Window/Levelling in a browser – CANVAS or server-trips?
- Martin P on 3D can be a dangerous game