Is Open Source reliable enough for Enterprise PACS?

Posted by Martin P in Open Source, PACS General      No comments

Nov
13

Isn’t Open Source software written by long-haired herbal tea drinkers with “LOVE” tatooed across their knuckles? How can we responsibly put the trust of a critical clinical resource into the hand of ‘such people’?

I’ve heard that question (or variants of it) a number of times. The fact is, 70% of the world’s web servers run on Open Source Software, some of the worlds biggest banks rely on open source databases and major airlines the world over recognise the value of open source infrastructure, and I can go on listing. But sometimes it’s tough to overcome first impressions.
And yes, there is untidy, poorly-engineered open source software available. In most cases, as untidy as it is, it does a job for at least the guys who wrote it, but it isn’t ready for the ‘enterprise’. But that does not mean that that limitation applies to all open source software.

If there is one industry that knows what ‘reliability’ means, its the military. To quote Brigadier Gerneral Nickolas G. Justice in the US DoD Open Source Conference:

“Open source software is part of the integrated network fabric which connects and enables our command and control system to work effectively, as people’s lives depend on it. When we rolled into Baghdad, we did it using open source.”

… and to paraphrase Matt Asay’s notes on the conference:

If open source can meet the performance and security demands of the US Department of Defense….

… it must be doing something right. The key is – to be one of those that do it right.

Open Source PACS is Hot Hot Hot

Posted by Martin P in Open Source, PACS General      1 comment

Nov
8

Wow this space is warming up. A press release from Hx technologies announces a new open source player in the Medical Imaging market (unlike us, with an actual product). It looks good, and I’m hoping to get a chance to evaluate it over the next week or so – I’ll report back here, of course.

I’m not quite sure, though, about one comment made on the product page:

Those developing and distributing open source applications under the GPL license are free to use Xebra under the GPL license. Commercial OEMs, ISVs, and VARs wishing to embed, resell or otherwise distribute Xebra as part of their own commercial solution and who do not license and distribute their souce code under the GPL can contact HxTI to purchase a Xebra commercial license.

Lads – that’s not what the GPL says. Selling (always), distributing (always) and embedding (in principle) whether as a commercial solution or not, DOES NOT require a commercial license under the GPL. Sorry for shouting. Maybe I’m being a little unfair.  Maybe its just the wording.

Radiology vs Cardiology PACS

Posted by Martin P in PACS General      No comments

Nov
6

.. or indeed Orthopaedic or otherwise!.. Auntminnie has a interesting perspective on a market report from IMV (admirably discosed as AM’s owner), which analyses why implementations with Cardiology PACS overlap so little with Radiology PACS when in fact they have so much overlap in functionality.

One reason given is cost – it seems the Cardiology department can not (or will not) pay as much for PACS as radiology. Score one for Cardiology. Too many radiology departments pay way too much for PACS.

But another snippet is revealing:

When asked about the relationship between vendors for each system, while there was some correlation between the vendor of radiology PACS and CPACS systems within hospitals in the IMV survey, that correlation exists only among a few of the largest vendors, according to Mary Patton, director of online market research at IMV.

In other words, only the largest vendors have the product set (by acquisition or otherwise) to sell into both Radiology and Cardiology. That is in spite of the huge functional overlap between the two. By and large, that’s due to the cost of the sales process. The money and effort that goes into supporting PACS sales channels into a department is huge – and that is why (one reason) they cost so much. Ask next time half a dozen dark suits arrive on a speculative visit who exactly is paying for them to be there? If a vendor doesn’t believe the return on investment for supporting those sales channels is sufficient, then they just won’t bother with extending the functionality.

Contrast that with an Open Source solution. Even if there is a ‘primary’ vendor, it’s irrelevant whether they think a new set of functionality is worthwhile, or not. As long as somebody thinks it’s worthwhile, it can happen.

But couldn’t the same thing happen with Open Standards? In theory, yes. As they say, in theory, theory and practice are the same thing. In practice, they’re not. Between HL7 (more specifically the slowly evolving IHE) and DICOM (disregarding for a moment the minor blips in interpretation between vendors), in theory, there’s enough of a standards base for full interoperability, but as in the case of Cardiology PACS:

The reason for that startling finding? Cost, and the complexity of integration with other existing systems in the hospital such as the radiology PACS, RIS, HIS, and electronic medical record (EMR), were mentioned as obstacles to the effective integration of CPACS.

Why on earth, given the experience of now-commonplace interfaces, would such systems not be easily interfaced?

In most cases the vendors are not even the same for the two systems, the report found.

Is PACS a medical device?

Posted by Martin P in PACS General      1 comment

Nov
1

The question is important, for at least two reason:

• Whether it is ‘right’ or not, marketing, positioning and perception are important in the world we live in. Brand names carry weight that are very often the consequence of an advertising campaign rather than actual quality. We know that – we all live in the real world.
• Considerable amounts of time and investment are needed to carry new products through the FDA 510k procedure. OK, not everybody is based in the US (I’m not), and the FDA carries little weight outside of the US, but the US is (for the moment) the largest single market for technology products. Ergo, 510k is important.

The definition of the term ‘PACS’ has been confused historically (for good reasons as well as bad), and by vendors who insist that the correct designation of a PACS is what they happen to be offering at the time.

To answer the question, lets first ask what is PACS? To answer that, lets ask what a PACS is not! A PACS is not a modality. It is not a part of the CR or the CT or the MRI. A PACS transcends all of those and should be considered entirely seperate. This is an important point. To consider PACS in the context of an individual modality means that choice – the freedom to have the best modality for your needs and the best PACS for your needs – is not only limited, but virtually destroyed. Of course, it is a perfectly valid choice to have modality and PACS provided by the same vendor, if that is what suits your needs. But to pitch that as the only option serves only the handful of mega-vendors that can open that door.

A PACS is not a RIS. Just as it is not a HIS, a PAS, a LIMS, or an electricity generator. A PACS may need to have connections to any or all of those, some more than others, but they all do different jobs.

Does a PACS absolutely have to have the latest 3D virtualoscopy algorithms to be a PACS? In my view, that would be crazy. To make the assumption that a single vendor can be relied upon to maintain best practice in archiving, communication, workflow, and visualisation and data analysis (for all modalities) in my view, is overly restrictive. That is not to say Radiology departments should not aspire to those technologies as well, but they are specialized items often at the ‘bleeding edge’ and should be sourced from vendors who specialize in those technologies. To do otherwise can only stifle innovation, which is bad for everybody.

In my view, a PACS at its minimum should be defined by the benefits it confers and not the features it achieves that with. That is, to provide any functionality needed to fulfill the services provided by a Radiology department/practice prior to PACS implementation, and deliver the additional benefits.

But I am me, and the FDA is important. Lets consider what the FDA has already said in its “Guidance for the submission of Premarket Notifications for Medical Image Management Devices“:

In many cases it is difficult to decide if a device should be classified as a Medical Image Communications Device, A Medical Image Storage Device, or as a Picture Archiving and Communication System. In such cases the classification is determined by the additional functions performed by the device. Simple manipulations which do not alter the image data, such as window and level, pan and zoom, and image annotation are considered to be within the scope of the communications and storage functions, and do not preclude a system from these classifications. However, imaging processing functions which are intended to alter the image data (e.g. filtering, multiplanar reconstruction, and 3D reconstruction, are considered to be outside the scope of the storage and communication functions.
…
…are treated as picture archiving and communications systems, which are Class II devices, and premarket notification is required.

Now in terms of language that’s a little confusing because it says that the two classifications with “device” in their name are ‘effectively’ not a device, while the one that does not, is. But getting past that as a semantic blip, it also says that a system only becomes the FDA designation of “PACS”, and therefore a medical device, when data [i]modification[/i] or advanced visualisation in involved. The FDA contradict themselves a little in the same document:

…. would be exempt from premarket notification requirements if they did not utilize irreversible (lossy) compression.

That kind of suggests to me that data transformation generally need not designate the system as a device if it were reversible, in which case as long as the original is kept, the clause need not apply.

But that again is splitting hairs. While I agree that storage & simple forms of display manipulation need not be scrutinised as a device, I certainly agree with the contention that ‘advanced’ algorithmic transformations – both as theory and in implementation – should be regulated. In fact, I don’t think the FDA goes far enough. One element of any PACS which does not fit into that paradigm is display on high-resolution monitors. As long as a vendor limits the functionality to that which the FDA considers ‘Class I’, they can deploy the system on a high-resolution monitor with impunity. That does not mean that the quality improvements promised by the use of such a monitor are actually delivered. If the display of images on specially-built monitors is not a Class II device, I don’t know what is.

So what is the answer to the original question? Simple. Some bits of a PACS are a medical device, and some are not. Aside from the one exception I’ve noted, I think the FDA have it just about right, although I also think they contribute to the confusion with the terminology they use.

What of the bits that are not? Caveat emptor. The FDA have reasonably solid methodologies for that software that is scrutinised, but much software is not and I’ve seen some right donkeys in my time (if I see another Access database running a critical application I’ll scream!). There is a light at the end of the tunnel, however, and perhaps CCHIT can take up the slack on that front. It isn’t a regulatory body at present but may move in that direction. Having worked in a hospital IT department for 10 years – I can bear witness just a thing is needed, and not just in the US.