Shared Folder Security Snafu

Posted on February 11, 2006 I Written By

John Lynn is the Founder of the HealthcareScene.com blog network which currently consists of 10 blogs containing over 8000 articles with John having written over 4000 of the articles himself. These EMR and Healthcare IT related articles have been viewed over 16 million times. John also manages Healthcare IT Central and Healthcare IT Today, the leading career Health IT job board and blog. John is co-founder of InfluentialNetworks.com and Physia.com. John is highly involved in social media, and in addition to his blogs can also be found on Twitter: @techguy and @ehrandhit and LinkedIn.

I’ve been finding out that every EMR deals with attachments differently and unfortunately it seems like many haven’t created a well thought out plan of what to do with them. The key from an emr end user perspective is to be able to access the attachment, but still be able to audit who, what, where and when the attachment was viewed. Since an attachment is a file that doesn’t naturally fit in a database it was originally thought that you just put a pointer in the database to a file on a shared drive. This is fine for functionality, but does little for privacy. In fact, here’s a little story from my own experience.

We had our attachments originally stored in a shared folder on the server with pointers in SQL. Some good people in HIM pulled up one of the images using the default Windows Picture and Fax Viewer from our EMR. Something didn’t look right so they wanted to see what other pictures were tied to that patient’s record. Of course at the bottom of Windows Picture and Fax Viewer is the arrows to see the next/previous image. So, they click next and started scrolling through all the images stored on the shared drive regardless of patient. Once they made it to some very personal pictures of a patient they called and let me know of this nice “feature.” Needless to say all the images are stored in the DB now.

When we had the images coming from the database we had to move the existing images into the database. I must admit that I was impressed that we were able to convert 4 gig of images into the database easily on a Saturday. My db backup now is only 3 gig. So, I’m not sure what kind of compression or optimization they are using, but having the images in the database has definitely saved space. I do have to be a little more careful with my backup scheme and when I do backups and restores.