As a dentist, I often want to send medical information including digital xrays to another doctor. What would be a good/easy way to do this encrypted?

Our organization currently requires that all such sent information be encrypted. Their current method is an add-on program to our email, that automatically encrypts the attachment. The problem with this though is that the recipient needs to also have this particular program installed on their computer...

I would like a way where the recipient can easily access the file without having to install new, additional software.

(to answer the question I live in America (Oregon).) (thanks for all the great responses!)

  • 2
    This sounds like you are looking for a product suggestion which is not something done here. If you are having trouble implementing email security or understanding the technology then you might rephrase and get an answer here. hth,adric
    – adric
    Commented Aug 28, 2012 at 20:19
  • 3
    This question would be a good fit for the Healthcare Industry SE proposal
    – Oleksi
    Commented Aug 28, 2012 at 20:31
  • 1
    The country in which this takes place would be good to note as various laws cover personal medical information.
    – this.josh
    Commented Aug 29, 2012 at 6:24

5 Answers 5


If you want to use emails, then you want encrypted emails. There are two canonic solutions: S/MIME and OpenPGP. The former is already supported by many emailing applications, and uses X.509 certificates. The latter requires some add-ons, which exist for many applications and are not too hard to use.

But do you want to use emails ? X-Ray pictures are often bulky, and emails are not as reliable as one would wish; in particular, the files sit in whatever email servers the doctors use, so they will have backups, or lack backups, depending on the configuration of each such server. Also, there will be no classification or index worth speaking of. Last but not least, dissemination of medical data, which is assumed confidential, is supposed to be controlled and auditable. There are a lot of legal details to take care of.

Countries which are currently trying to setup systems and networks for handling medical data and sharing it between the involved doctors (but nobody else !) are finding out that it is hard work, and requires a lot of thought and procedures. In my experience, centralized architectures are preferred (i.e. the X-Ray pictures will be stored in a central database, with access control using smartcards), rather than emails.


Sending healthcare information like that is very tricky, since you have to meet the healthcare security and privacy laws in your country (HIPAA in America). You might be able to use something like PGP to encrypt the emails and this may fine legally (I'm not a lawyer though). Encryption implemented through PGP would have fairly good support in email clients, so it should work for most places you want to share data with. However, this is a very hard-to-use solution. I'd be much better to not have to email PHI like that. You still have to worry about auditing access to the data, as well as proper access control.

What you really need is software that can enabled collaboration between two healthcare providers. This would give your organization a lot more power than what you currently have. This software would then handle the secure communication between the two healthcare practices. It would also let you share this data in a much easier, standards-based way.

As a side note, I started a Healthcare Industry Stack Exchange proposal where this question would be perfect. Those interested in questions like this should consider joining.

  • The problem is that I presume in many of these cases are one time things; e.g., former client moved to other side of the country wants medical records sent over and old and new dentist have never talked previously. What's really needed is an accepted standard way of doing this.
    – dr jimbob
    Commented Aug 29, 2012 at 15:46
  • 1
    @drjimbob There are standards for sharing medical data(DICOM, HL7), and software is the best way to get and use implementations of these standards.
    – Oleksi
    Commented Aug 29, 2012 at 17:03
  • @Oleski - I am quite familiar with DICOM and HL7 standards. First, HL7 only deals with the format of the messages (at the application level) and doesn't deal with encryption (typically done at the lower OSI layer via an SSL socket or IPSec). But setting up a business connection to connect PACS to do DICOM push from different hospitals takes weeks to months of business agreements, meetings between IT teams to setup VPN/configure access rights/setup certificates, etc. It is impractical to require each practice to manage their own DICOM server to receive images for one patient moving.
    – dr jimbob
    Commented Aug 29, 2012 at 19:47
  • @Oleski - Also just because you are using DICOM does NOT ensure that the data is either stored or transferred encrypted. It just ensures that the relevant metadata is kept with the image and that it was transferred in a reliable way. (I had to double check that encryption is not a mandatory part of the DICOM push standard). See page 7 of Part 15 of DICOM standard where they clarify "The DICOM standard does not address issues of security policies, ... [it] only provides mechanisms that could be used to implement security policies ... "
    – dr jimbob
    Commented Aug 29, 2012 at 20:24
  • @drjimbob of course it's more effort, but it's the correct solution. You only need to do these agreements and set ups a few times, and you then you can exchange data for the future much easier. There's also standards (like the IHE framework) that fill in the missing parts of HL7/DICOM use (like encryption). Certainly setting up these connections is the ideal solution for the future, despite being more effort to set up. Ideally, in the future, all of our healthcare data would be able to flow easily between any healthcare providers. Ad-hoc emailing will never support that level of collaboration.
    – Oleksi
    Commented Aug 29, 2012 at 20:27

The large hospital (~10000 employees) I work at (though not as a medical doctor despite the user name) has a secure file transfer web application that we use for this thorny issue.

The workflow works with sending doctor going to https://transfer.examplehospital.org

You sign in with your hospital credentials and upload files and specify one or more recipients and possibly add on a message. The files are stored encrypted within the web application.

They receive an email saying person A has transferred files to you from examplehospital.org, please click the link to here. If they are a new user, they create an account. They get a short-lived registration token via email, click it, and then can set a password. Now they are logged into the application and can download their images over https (encrypted).

Similarly, a doctor at another institution can send encrypted PHI to you by creating an account logging in, uploading an image and sending it to a doctor at your institution. (However either the sender or the recipient has to be at your institution).

The hospital didn't create this service themselves; the logo at the bottom indicates that its done by accellion and there are likely many similar competing products. (I have no familiarity with the cost/ease of setup/maintenance; other than from a user standpoint its relatively straightforward to use; granted you have to be careful of sending PHI to compromised email accounts). But products like this exist and work well; I'd search for something like 'secure file transfer hipaa'.

EDIT: I should clarify, this should not be used for routine file transfers; but only the types of files you may feel the need to email (e.g., for the patient who transfers to a remote clinic you've never previously worked with). For routine cases, you should setup a workflow where some doctors/patients at related institutions can push images to remote PACS in a convenient fashion.


I can't give you product recommendations, but if I were designing software to support this kind of collaboration, one option I would consider is to do it as a web service: something where you can log into a web site, upload the files, and let the other doctor download the files. This would eliminate the need for special software. On the other hand, if the files are very large, the time to upload and download them might be prohibitive.

I have a superficial impression that right now this is typically done by burning the files onto a DVD and then having the patient carry the DVD to the other doctor, or sending the DVD through the postal mail. This seems like a fairly reasonable approach, as long as you avoid certain pitfalls (e.g., use of autorun on the DVD).

See, e.g., Going to the doctor and worrying about cybersecurity by Jeremy Epstein. (Read the comments there, too.)

  • The DVD thing still happens fairly regularly, but it's slowly going away (thankfully!). Having dedicated software to enable healthcare data sharing is a much better solution that is slowly becoming more and more popular.
    – Oleksi
    Commented Aug 28, 2012 at 22:24
  • I don't think a webservice can solve this. At least I can't think of a way to implement encrypted file transfer using a plain web-application. Commented Aug 29, 2012 at 15:21
  • 1
    @CodesInChaos - this can be done on a relatively straightforward web application (not sure what you mean by 'plain') as demonstrated in my answer. I wouldn't design a system myself without several security audits, HIPAA experts reviewing, though.
    – dr jimbob
    Commented Aug 29, 2012 at 16:08

I find it interesting that no one offered this: Why not use an SFTP or FTPS server, access to it locked down by ip address, users restricted to their own home folders only which are stored on an encrypted drive? I work for a mid-sized hospital, and we use this setup to transfer HIPAA information on a daily basis. There is a lot of work for a system administrator to get it setup initially and keeping the ip access lists up to date (especially if end users have dhcp'd connections) does take a little time weekly, but once everything's in place it's a very easy and acceptable solution for what Ken is looking for.

Let me know if you'd like more information on how to get a solution like this going and I'll be glad to provide more information.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .