4 ms·

> How would that work for offices that send non PHI emails? They could encrypt those emails as well. While sending a non-encrypted email that contains PHI is

by u801e 9y ago

> How would that work for offices that send non PHI emails? They could encrypt those emails as well. While sending a non-encrypted email that contains PHI is a problem, sending an encrypted email that doens't contain PHI shouldn't be an issue (as long as the intended recipient can decrypt it, which they should). > How hard would it be to shut down and create a new email for each employee that left, etc. That comes down to revoking the certificate or using shorter intervals for the duration where the certificate is considered valid. For example, if the organization requires that one changes their password every 60 days, then a certificate should not have more than a 60 day period where it's valid. > Would you have to have a special email server just for PHI and another for regular? This wouldn't be server dependent. This would be dependent on the email client handling the encryption and decryption. The more that's automated, the less chance that there's a mistake with regards to email containing PHI. > Also, physicians themselves rarely send emails, they have office assistants do it. They are busy providing care. Physicians have to do all sorts of things like writing progress notes, dictating admission and discharge summaries, calling in prescriptions, writing orders, etc. The system they use could also be used to securely send PHI containing email to other physicians, pharmacists, or hospital systems. But regulation could be a good incentive against physicians allowing others to use their account credentials to do things like sending PHI information to other organizations. No physician would like to be summoned by the board of medicine of the state they're licensed in over something like that. But I think that a lot of the problems could be addressed by those who have cross-domain knowledge about technology and health-care (speaking as someone who went through medical school and subsequently changed fields to computer science/software development).

Clubber 9y ago
Good discussion, but I think you are solving a problem that has already been solved, but you are proposing a much more cumbersome and complex way. The current method is for insurance companies to install software on their SMTP server and that's about it. Much less overhead, much less chance of mistakes, much less cost to the physician's office, much cheaper overall and just as good for protecting PHI (since it's automated, no accidents). Also, the vast majority of communication containing PHI is with insurance companies and the government, so your solution moves the onus of protecting PHI from the insurance companies to the small physicians, which I don't think is overly helpful. Of course there is no way to really tell unless we complete vet it out and put cost associations with everything and do PHI leak risk assessments. I'm perfectly happy leaving this as a thought experiment though. :)
- u801e 9y ago
  > The current method is for insurance companies to install software on their SMTP server and that's about it. I would hope that they require TLS encryption for any connection to their SMTP server. Otherwise, any communication containing PHI could easily be intercepted. This also doesn't address the issue of securing the IMAP or Exchange and MTA server(s) that the sender uses to send the email to the insurance company. > much less chance of mistakes Unless the sender CCs a copy to another address where the MTA doesn't require TLS encrypted connections and doesn't have any such software installed on the MTA. That's why the solution I proposed (having the client program automatically encrypt the email before sending it and relying on PKI to handle decryption on the other end) would be more fool-proof since, even if the email was CC'd to another address, it couldn't be decrypted by the unintended recipient. As for the cost argument, I think it could be implemented as a nominal cost on top of the costs that the physician already incurs in the process of applying/renewing their license, the practice license, etc (e.g. name, mailing address, telephone number, fax number, email address along with your PKI state board signed certificate). > Also, the vast majority of communication containing PHI is with insurance companies and the government Doctors have to communicate with other physicians outside of their group practice, hospitals they may not be affiliated with, and pharmacies. How is PHI communication in this context currently handled? > Of course there is no way to really tell unless we complete vet it out and put cost associations with everything and do PHI leak risk assessments. That is true. But I think that the technology we currently have to secure communication between clients and webservers (that allows us to do things like buy things online, interact with the bank, file taxes, etc along with client side certificates) should work perfectly well with PHI containing information. The problem is setting up the PKI for that type of communication. Since governments, universities, and private companies have already done this, there's no reason why hospitals (especially university affiliated hospitals), state boards, and health care providers can't also do this.
  - Clubber 9y ago
    Based on that response, I don't think you are understanding how it works (or I didn't explain it well). This is for emails originating from insurance companies. Software intercepts any queued or targeted outbound email, then: 1. Replaces the body with a hyperlink to a web site and instructions, removing all PHI. 2. Hyperlink instructs recipient to login create account / login to view mail over SMTP. 3. Recipient logs into website (with TLS obviously) and reads email with PHI over secured channel. 4. Recipient can now read and reply using the website. Pretty simple. As far as physicians communicating with each other and pharmacies, they typically use faxes and phone calls.

by u801e 9y ago

Clubber 9y ago

Good discussion, but I think you are solving a problem that has already been solved, but you are proposing a much more cumbersome and complex way. The current method is for insurance companies to install software on their SMTP server and that's about it. Much less overhead, much less chance of mistakes, much less cost to the physician's office, much cheaper overall and just as good for protecting PHI (since it's automated, no accidents). Also, the vast majority of communication containing PHI is with insurance companies and the government, so your solution moves the onus of protecting PHI from the insurance companies to the small physicians, which I don't think is overly helpful. Of course there is no way to really tell unless we complete vet it out and put cost associations with everything and do PHI leak risk assessments. I'm perfectly happy leaving this as a thought experiment though. :)

u801e 9y ago
> The current method is for insurance companies to install software on their SMTP server and that's about it. I would hope that they require TLS encryption for any connection to their SMTP server. Otherwise, any communication containing PHI could easily be intercepted. This also doesn't address the issue of securing the IMAP or Exchange and MTA server(s) that the sender uses to send the email to the insurance company. > much less chance of mistakes Unless the sender CCs a copy to another address where the MTA doesn't require TLS encrypted connections and doesn't have any such software installed on the MTA. That's why the solution I proposed (having the client program automatically encrypt the email before sending it and relying on PKI to handle decryption on the other end) would be more fool-proof since, even if the email was CC'd to another address, it couldn't be decrypted by the unintended recipient. As for the cost argument, I think it could be implemented as a nominal cost on top of the costs that the physician already incurs in the process of applying/renewing their license, the practice license, etc (e.g. name, mailing address, telephone number, fax number, email address along with your PKI state board signed certificate). > Also, the vast majority of communication containing PHI is with insurance companies and the government Doctors have to communicate with other physicians outside of their group practice, hospitals they may not be affiliated with, and pharmacies. How is PHI communication in this context currently handled? > Of course there is no way to really tell unless we complete vet it out and put cost associations with everything and do PHI leak risk assessments. That is true. But I think that the technology we currently have to secure communication between clients and webservers (that allows us to do things like buy things online, interact with the bank, file taxes, etc along with client side certificates) should work perfectly well with PHI containing information. The problem is setting up the PKI for that type of communication. Since governments, universities, and private companies have already done this, there's no reason why hospitals (especially university affiliated hospitals), state boards, and health care providers can't also do this.
- Clubber 9y ago
  Based on that response, I don't think you are understanding how it works (or I didn't explain it well). This is for emails originating from insurance companies. Software intercepts any queued or targeted outbound email, then: 1. Replaces the body with a hyperlink to a web site and instructions, removing all PHI. 2. Hyperlink instructs recipient to login create account / login to view mail over SMTP. 3. Recipient logs into website (with TLS obviously) and reads email with PHI over secured channel. 4. Recipient can now read and reply using the website. Pretty simple. As far as physicians communicating with each other and pharmacies, they typically use faxes and phone calls.