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
16 comments:
Privacy of medical information was tacked on to the Healthcare Information Portability act and has made us much more thoughtful. We don't go looking at the medical records of neighbors that we hear are in our hospital. You can have surgery without it being gossiped about. It has accomplished its goal.
If a person takes their radiology studies home on a CD, I would leave it to them to look after the CD so it is not lost or stolen.
Is there really a market for stolen radiology images?
Just a thought: Use patient's MRN as the password. This would allow for helping those who have lost their pw while maintaining a reasonable level of security.
Or: Use patient's SSN as the pw. Less security but still, in my opinion, a reasonable safeguard from random access.
About SSN: I think this would be by far the worst thing to ever do. At least for american citizen this is a 9 digits number. Find/Stole a CD leave a dictionary brute force attack running for a couple of hours, and your are done: name, SSN, street address, perfect for ID theft.
I believe the industry is moving toward encryption of PACS images as a standard. The 2008 medicare call letter requires plans to encrypt portable media. We interpret this regulation to include PACS CDs. I am in the process of attempting to locate a product that will allow us to encrypt our PACS CDs. Does anyone on this blog have any experience with a product that provides this functionality in an enterprise environment? I believe we plan on using the patient date of birth as the password. Here is the CMS regulation:
"Due to the overwhelming need to manage data protection and endpoint security solutions, we now require plans to encrypt all hard drives or other storage media within the device as well as all removable media. In addition, plans must develop and implement a policy addressing the handling of portable media that is accessed or used outside of the organization’s physical purview."
Hi Brad
I do not think that I agree with your interpretation, since the scope of the CMS Call Letteris defined to be "Medicare Advantage (MA) organizations, Section 1876 cost-based contractors, prescription drug plan (PDP) sponsors, demonstrations, and employer and union-sponsored group plans, including employer/union-only group waiver plans (EGWPs)".
There is no indication in the document that I can find that the media discussed includes the information that is handed to patients, or intended directly for patient care, as opposed to data related to billing, etc. I would be very surprised if it were CMS's intent to interfere with ordinary patient care by putting barriers to successful distribution in place without the appropriate forethought and consultation.
Also, I see no evidence at all that "the industry is moving toward encryption of PACS images as a standard"; quite the converse, the industry has been avoiding encryption of images like the plague for decades, and has relied on physical security and network layer security exclusively.
Having said that, it is certainly appropriate to consider what options for encryption are available and whether or not they are practical. I am not aware of any existing commercial product that encrypts media in a standard way that will not render it unusable by ordinary recipients.
David
Hi David,
Unfortunately, our privacy office and legal team provided the interpretation for the regulation. I am tasked with finding a solution and am not in a position to alter their interpretation. You are correct that we do not need to encrypt CDs handed directly to the patient as the patient is responsible for protecting their own PHI. However, according to their interpretation, we need to encrypt images that are sent directly to the contracted provider and are not within our control. For example, if we need to mail a CD to a provider in another state. Another example would be sending a CD to a provider when the patient is incapacitated (very rare).
In the regulation, the term "portable media" is pivotal to the interpretation. As CDs with images contain PHI and are portable, it would be reasonable to assume that they need to be encrypted.
We are one of the only HMOs that provide Medicare Advantage insurance and provide healthcare to those patients. MA plans make up 1/3rd of our business.
The title of the section in the 2008 CMS letter that I quoted is "Securing Electronic Protected Health Data through Encryption and other Means." I believe it is reasonable to assume the regulation requires encrypting PACS CDs with PHI that are out of our control, as outlined above.
I found two products that send encrypted DICOM files via email that we are investigation, I just thought some reader may have prior experience with this issue considering the nature of your blog. Information on this topic is sparse.
While it would be nice if the industry would move away from encrypting portable PHI, as someone who implements technology for a healthcare organization with over 500,000 members, I have to say that the trend appears the opposite from the technology side of things.
Thanks for your response and time.
Over the pond in the UK it is now a government requirement to encrypt all CDs, except where patient safety might be compromised (eg for emergency transfers).
DICOM Cd encryption is now a developing market over here, and everyone is frantically chasing round trying to implement a workable solution, that adds little bureden to the end user (ie works exactly the same as before, with password input being the only extra stage).
Anyone got any suggestions?
William
Instead of pushing on vendors to provide DICOM encryption, why not encrypt the storage media instead?
We are looking into using TrueCrypt, a free, open-source product that allows users to create and mount an encrypted volume (among other things). This volume is a single file on the filesystem, completely opaque without the password.
Dicom images or other PHI stored inside the encrypted volume would be protected, without needing any changes to the Dicom server software.
The encrypted volume could then be burned to a DVD. To recover the data, the volume could be mounted from the DVD on a machine with TrueCrypt installed, with the password.
Encrypted volumes can be created directly on USB keys, too.
http://www.truecrypt.org/
One solution could be implemented using a combination of symmetric and asymmetric (ie, public-key) protocols:
(1) For every CD, generate a session key Ks.
(2) Encrypt the CDs contents with Ks using an established, secure symmetric method (Blowfish, AES, 3DES et al).
(3) For every intended or potential receiver r of the CD (practitioner, hospital, patient):
(3.1) Find Kr, the public key of R
(3.2) Encrypt Ks using Kr
(3.3) Add the data pair (R, Kr(Ks)) to the CD.
(4) Any Receiver R can now use their secret key to extract Ks and read the contents of the CD.
A potential drawback is, of course, that when a new receiver R' occurs (ie, we decide to send the patient and hence his data to a new practitioner), then R' cannot read the original CD. One of the current receivers needs to decrypt Ks, encrypt it using R's public key, and write a new CD which contains the result.
This would also require any potential participant to have access to the public keys of other participants. Doctors and hospitals would need to establish a common database that can be trusted; patients would need to generate their key pair and either also add the public key to the database, or to bring in the public key on, say an USB stick.
As a radiologist and software engineer (and adept in encryption), the position Brad's privacy office and legal team has taken is disconcerting but not surprising. The purpose of the DICOM CD is to allow the patient to have physicians review the images and ultimately deliver the best care to the patient. A typical scenario is a patient leaves a DICOM CD with a clinical specialist, the clinical specialist then hand carries the CD to their radiologist(s) of choice, and verbal opinions are rendered. There may be more than one clinician and more than radiologist involved. The physicians may be in different institutions across the city or in other cities. Whatever "data protection" scheme ultimately evolves as the standard, it is undoubtedly going to lead to many instances where the physicians described above, involved in the patient's care, will not be able to open the images and view them at the time they need to...ironically, the patient for whom these regulations were supposed to protect, could actually be harmed because the treating physicians have been restricted access to information. I deal with the effects of policies like these in my practice today with patient transfers where barriers such as this prevent rapid transfer of images and can delay treatment or require repeat scanning (and thus additional unnecessary radiation exposure). I deal with many excellent non radiologist physicians but when faced with viewing images on DICOM CD, become pretty helpless (I do too sometimes because of how poor some of the embedded viewers are)...and now "we" are going to add a layer of data protection on top. This is unfortunate and I hope it is resisted for the sake of the patient.
Its been nice reading this blog! As user that will actually be tasked with providing these images its nice to see some information that is more than "uhh... well Medicare said so!"
I'm also curious why we'd have to do it for ALL patients, and not just those insured by medicare.
And another thing! :p
I asked if an exclusion could be made for transferring the CDs if it went straight from facility to facility (via courier, for example) and was cut off before really getting it out. The answer was "its pretty simple! if its not going directly in the patient's hand, it needs to be incrypted!*twitch*"
While I'm willing to accept that this rule has been interpreted in such a way as to necessitate this procedure, it would sure be nice to have a plausable sounding reason when our contracted providers call us with a giant WTF. What am I supposed to say? "Someone told me I had to cause Medicare said so?"
I assume that we have simpler solutions. Most of the solutions that I can see here are like laying carpets on the road and walking with bare legs , rather than wearing a pair of shoes. The name and DOB of the patient has to be aliased. and the real name to the alias name can be stored in the cluster or the hospital domain which are usually secure networks and data storages. Why do we need to encrypt GBs of data on the CD for that. Im sure that looking at a scan none can identify the person and the age(may be a little guessing is possible).
Hi Prasanth
Anonymizing (pseudonymizing) the CD as you suggest doesn't help and would be unsafe ... how would the recipient know (reliably) whose CD it was ? One could not even assume that a CD the patient carried was necessarily theirs, and once it was out of their hands, identity would be even less certain.
One could have some sort of network connection to somehow resolve the alias, but if we had the infrastructure to support that, we wouldn't need the CD, we would just transfer images on the network (as we should be doing anyway).
David
I don't believe that encrypting just the patient information in the DICOM file would suffice. I have worked with several modalites that include patient information directly displayed within the pixel data. US studies regularly have this information on the actual image.
Hi David. I am curious where encryption of dicom is today? I see the first post was from 2008. From a modality vendor standpoint I would pose this possibility: A customer has an equipment issue with his x-ray image (could be image quality, could be a dicom issue). The FSE copies some images to CD and returns them to technical support. They could be logged and tracked. But the complete image file could be useful for troubleshooting or evaluation. Once the images are used, they could be annonomized or even destroyed. Do you think encryption is necessary to meet HIPPA requirements, or just proper handling of the data is sufficient?
Thanks, Hal
I may be behind the curve, after all the discussion is already more than four years old.
At any rate, there is some resemblance to the hitchhiker's guide to the galaxy: We know that the S/MIME mechanisms are the answer. Now, what exactly was the question?
In my mind, the following things must be possible with DICOM media:
- one healthcare provider asks another to prepare a study. (that's the case where S/MIME works).
- one healthcare provider creates the study, e.g. in an emergency care scenario, without a priori knowledge about who is going to continue the treatment, i.e. who the recipient of the study is. One case where S/MIME breaks down.
- a study needs to be read, say, five years later, e.g. to continue an old treatment. Unless a copy of the data is available and accessible, the old media are again of no use: the certificates have expired (usually after two years).
... and a range of other real-life cases.
In fact, there are two use cases that need to be separated, and that is partly reflected in the discussion:
- the encryption problem itself: which data shall be encrypted, how, and in which data format shall it be stored? - this is primarily a technical problem.
- how can the keys to that encryption be stored, acquired and recovered, and how can people who request a key be authenticated? especially under emergency conditions? - this is primarily an organizational problem.
Every attempt to lump these two together (e.g. using a SSN as "well-known password") is asking for trouble one way or another, for instance because not every patient has a SSN (e.g. outside the US :-))
Post a Comment