4 ms·

> but that's typically more cumbersome as you have to trade keys with everybody that needs an email. What would be needed is a public key infrastructure. If o

by u801e 9y ago

> but that's typically more cumbersome as you have to trade keys with everybody that needs an email. What would be needed is a public key infrastructure. If organizations like the state board of medicine could serve as a certificate authority for physicians licensed in that state (or maybe the DEA since they issue id numbers to physicians that are needed for controlled substance prescriptions), then the key management would not be as much of an issue. In other words, it shouldn't be handled by individual organizations; it should be handled by the authorities who are responsible for licensing doctors, nurses, pharmacists, hospitals, etc. > On top of all that, each client will have to be taught how to decrypt (and encrypt) emails This is certainly something that can be automated and shouldn't have to be a manual process. A plug-in for a program like Outlook should work in the vast majority of cases. That is, if the email is sent to the wrong address, then the recipient would only see encrypted text, but it would automatically be decrypted for the correct recipient.

Clubber 9y ago
That sounds fine in theory and if implemented well it would work, but I'm not sure how well it would work in reality. I just refer to my small business tax return every year to get an idea of how many forms would need to be filled out to just send email. How would that work for offices that send non PHI emails? Would it go through that system too, or would it have to key on recipient email addresses? How hard would it be to shut down and create a new email for each employee that left, etc. Would you have to have a special email server just for PHI and another for regular? How many times would employees accidentally send PHI over a non-secured channel on accident? Also, physicians themselves rarely send emails, they have office assistants do it. They are busy providing care. How would that work? The office assistant position doesn't have any direct regulation (that I know of) so you'd either have to have the physicians send out emails (ya right), have an assistant use the physician's account (oh no), or add a bunch of regulation to office assistants (to the tune of doctors and nurses) which would make them more expensive and make office visits more expensive (etc). It sounds good as a technologist, but if you look for unintended consequences (costs), I'll bet there are a bunch I didn't even think of. Also, organizations are highly motivated to get this right because the fines have teeth. Up to $50K per incident capped at $1.5 million per annum. https://www.truevault.com/blog/what-is-the-penalty-for-a-hipaa-violation.html https://www.truevault.com/blog/what-is-the-penalty-for-a-hip...
- 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. :)

by u801e 9y ago

Clubber 9y ago

That sounds fine in theory and if implemented well it would work, but I'm not sure how well it would work in reality. I just refer to my small business tax return every year to get an idea of how many forms would need to be filled out to just send email. How would that work for offices that send non PHI emails? Would it go through that system too, or would it have to key on recipient email addresses? How hard would it be to shut down and create a new email for each employee that left, etc. Would you have to have a special email server just for PHI and another for regular? How many times would employees accidentally send PHI over a non-secured channel on accident? Also, physicians themselves rarely send emails, they have office assistants do it. They are busy providing care. How would that work? The office assistant position doesn't have any direct regulation (that I know of) so you'd either have to have the physicians send out emails (ya right), have an assistant use the physician's account (oh no), or add a bunch of regulation to office assistants (to the tune of doctors and nurses) which would make them more expensive and make office visits more expensive (etc). It sounds good as a technologist, but if you look for unintended consequences (costs), I'll bet there are a bunch I didn't even think of. Also, organizations are highly motivated to get this right because the fines have teeth. Up to $50K per incident capped at $1.5 million per annum. https://www.truevault.com/blog/what-is-the-penalty-for-a-hipaa-violation.html https://www.truevault.com/blog/what-is-the-penalty-for-a-hip...

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. :)