Tuesday, April 29, 2008

Media Security and Encrypted DICOM CDs

Summary: CDs of images are vulnerable; encryption is possible and new DICOM mechanisms could make it easier; does the threat really justify the inconvenience and cost?

Long Version.

Recently there has been increasing interest in providing some sort of secure DICOM CD so that at least not just anybody can read the contents of such a CD that is lost or stolen. An Aunt Minnie post exemplifies the concern.

DICOM does provide mechanisms to encrypt the CD (using the same tools as are used for S/MIME secure email), but they are rarely, if ever, used in practice.

I am not sure whether this is because a) most people don't care about security or b) reading CDs is hard enough without adding an extra barrier or c) the mechanisms in DICOM are too complicated to deploy.

It is easy enough to extend DICOM to support security mechanisms that are "easier" to deploy and don't require a priori knowledge of every recipient and the use of certificates and a public key infrastructure, such as a password-based encryption mechanism, and I have put in a CP to do so (adding RFC 3211 PKCS#5-based PBE for the KEK to CMS, for those who care), but ...

... my real question is, would anybody want to use it ?

Deployment would require sending a "password" "separately" from the CD (e.g., in an email), and probably keeping track of these in order to answer calls from recipients who have lost or forgotten it, days, weeks or years later. There is no question that this would also make importing of old studies from old CDs as priors more likely to fail.

I don't think the industry will be able to resist demands to provide such capabilities from those with serious (if not excessive) privacy zeal, but is the cure worse than the disease in terms of the cost and complication it will trigger ?

If we are going to have to do this, obviously using a standard DICOM mechanism is preferable to any proprietary scheme, to support 3rd party viewers and PACS importation; however, such devices would have to be upgraded to support the DICOM media security profile. In the interim an on-media viewer that supported the DICOM encryption scheme would at least make the images viewable, though there are many reasons why on-board viewers are undesirable that don't need to be reiterated here.

With modern processors, the speed of encryption/decryption should not be a rate limiting step compared to reading the physical media, although with media that is faster than CD or DVD, such as USB memory sticks, there might be some compromises with respect to number of iterations and key length to consider.

David

Wednesday, April 2, 2008

Requirements for an "office imaging system" for requesting practitioners

Summary: Film is dying but requesting doctors hate loading slow and unpredictable CDs; they need pre-loaded images on a system in their office; specific requirements for such systems are defined; there is no need for them to be expensive or complex.

Long Version.

Doctors, much like everyone else on the planet, crave instant gratification. If it takes more than a negligible amount of time to gather information in the context of seeing a patient, they either won't bother or will become irritated. And after all, even in a salaried setting, time is (somebody's) money.

In the pre-digital days, it often took more time than it was worth to bother to extract and hang films properly, or even find a real view box, hence the frequent sight of films held up to the nearest window or fluorescent light, hardly optimal viewing conditions. Radiologists, with a more pressing need to view the films "properly" and in bulk, addressed the film handling problem with pre-loaded panel viewers on which trained but relatively low cost staff "hung" the films in advance. Some radiologists rarely lifted their foot off the pedal as the films scrolled mechanically by whilst they dictated rapidly.

During the transition to soft-copy interpretation of digitally acquired images, the importance of effective work lists and hanging protocols to efficiently report increasingly complicated large studies has been obvious to radiologists. Such features are a vital component of any modern PACS. In an inpatient setting, or an ambulatory clinic attached to a large facility that does its own image acquisition, an enterprise-wide PACS can (in theory) provide ready access to images when and where they are needed, in an appropriate presentation, whether it be in the examination room in the clinic, in the operating theatre, or somewhere convenient during ward rounds. Where appropriate, dedicated staff are deployed to optimize the performance of the process when it cannot be totally automated.

Yet in a traditional ambulatory environment, in which radiology facilities and requesting practitioners office are geographically and organizationally separated, as films disappear and imaging centers insist on handing out CDs to outpatients instead, there is a growing problem.

For the busy doctor, CDs suck; there is just no question about it. They are relatively slow to load, regardless of how fast the drive is, they usually have some awful viewer that one is not familiar with and which takes a while to start (making the process even slower) or fails to work. Once started, there is usually no clue which images are important out of the hundreds or thousands present. Even though these CDs are increasingly standard DICOM and IHE PDI compliant as the vendors finally get their act together (with a few notable and reprehensible exceptions), and there is talk of faster, higher capacity media (DVD and even USB memory sticks), that doesn't get around the fundamental problem that handling and loading physical media "on demand" is inherently troublesome.

The key issue is the handling and loading of the media. The obvious solution is to pre-load it.

When a patient is referred to a large facility with a PACS, whether it be for a specialist consultation or further imaging, typically any "prior" films and CDs will be requested in advance, and these will be pre-loaded into the PACS, so that they are available for review and comparison using the normal tools and work flow. Any necessary "import reconciliation" of foreign patient identifiers will be performed, etc.

Clearly, a scaled down version of this process would be feasible in a small office, even for a solo practitioner. Patients do not walk directly off the street into the examining room. There is always some sort of reception facility. At that time, a clerk could take the media and "import" it into a system of some sort. This would require no technical expertise, and the media would either load successfully (if it were DICOM and IHE PDI) or not (if it were proprietary Philips/Stentor or Amicas rubbish). Loading an entire CD should take no more than a matter of a few minutes. If the receptionist was really busy, then a dedicated staff person might be necessary. Media that failed to load would be dealt with by clerical staff interacting with the offending imaging center, which argues for having the media sent in advance of the patient's visit if at all possible.

Reconciliation of identifiers could be performed automatically (if the imaging center's numbering scheme was recognized), or semi-automatically (by patient name matching confirmed by the clerk), or manually (by typing in or selecting from a list of scheduled patients) as required.

Perhaps the report (quite likely not on the CD, and perhaps faxed separately), would also be scanned into the system, or be available in whatever electronic document handling system the practice used, or perhaps just be present in the paper chart in the old fashioned way.

The images would now live on a fast central server in the office, and be available anywhere the necessary display hardware and software was located. Prior images might or might not also be archived on the system, but the primary goal here is to describe how to make images available, not address questions of whether or not and how the requesting practitioner should archive them.

Ideally, every exam room would be equipped with an appropriate display, perhaps just a reasonable sized color LCD, unless the specialist practice was of a type that demanded a high intensity calibrated grayscale display. As is standard security practice, the display would need to be blanked and locked unless the doctor was in the room and then only the appropriate patient's images would be visible. For example, the doctor could apply their finger to a biometric keypad to activate the system, which would then display nothing until the patient's ID from the paper chart was read with a bar-code wand, at which time the images would instantly appear, preferably jumping directly to the key images if they had been flagged as such on the CD in the first place (using the standard DICOM objects for this purpose). One could imagine ways to use RFID tags creatively to make this almost totally automatic, with the presence of both the patient and the doctors RFID tags in the room activating the display automatically.

The doctor would already be familiar with the "viewer" since it would not be the one on the CD but rather whatever was installed on the system and on which they were trained. It would have the necessary features that they had chosen (such as orthopedic templates or 3D cardiac visualization or whatever, depending on their specialty).

Exactly the same strategy can be applied in the operating theatre, whether it be in an inpatient setting in the absence of an enterprise PACS, or for outpatient surgery. Images should be preloaded and made available in the OR to which the patient is assigned or in which they are currently located. The physical type, mounting and interaction with displays is more complex, but these issues are not specific to this discussion.

How hard or expensive would all this be ? It is pretty straightforward really , when one considers the simple work flow and similarity to existing systems. The use of off-the-shelf consumer computer, display, network, biometric and bar-code hardware and software could make this very low cost. There are obviously already free and open source tools to implement this if one is technically sophisticated, and there are no doubt already commercial systems that are designed for this purpose or which could be re-purposed easily enough. One could clearly add potentially expensive bells and whistles like integrating with practice management systems, room scheduling systems, electronic medical record systems and the like, as desired.

In future, as Internet transfer of images directly from the imaging center to the recipient's system becomes commonplace, this mechanism could replace CDs as the transport media. Still though, the images should be ready to view on the local system, and there should be no need for the physician to wait to load them on demand from some off-site local over a relatively slow connection, or be forced to learn how to use whatever web-deployed client that particular imaging center used.

To repeat the key message, regardless of the transport mechanism, the requesting practitioner should have the images pre-loaded on their own system and accessible to them at the point of care instantaneously and using their own preferred tools.

The bottom line is that there are few excuses for whining about "slow" media or problematic viewers, when a small investment in each user's office could produce a near optimal solution.

David