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.