Thoughts on Email communication.

[kdt...@gmail.com]

Hey All,

We are just finishing up our latest application: VistA Messenger. It
is an email connection that is designed to keep copies of all messages
from and two patients as new documents visible in CPRS.

But before we start using it in our office, we ran this by the
attorney at our malpractice carrier to see if we are taking unsafe
risks. He didn't have much experience in the issue, but started
saying things like we needed to encrypt all the messages etc.

We plan on obtaining a signed release on all patients before emailing.

I found this guideline:
http://www.ama-assn.org/ama/pub/about-ama/our-people/member-groups-sections/young-physicians-section/advocacy-resources/guidelines-physician-patient-electronic-communications.shtml

There are a few items in this list that I will need to implement, such
as the auto acknowledgment feature.

Any thoughts on email communication with patients that I should be
aware of?

Kevin

[I, Valdes]

It is best done with generic notifications in their regular email box
of the 'you have mail' variety and then both users login to a system
that communicate in an encrypted way. As I am sure that you already
know regular email with no encryption should be considered (a little
hyperbole here) nearly the equivalent of posting the information in a
public square. I discourage it with my Psychiatric patients for a
variety of reasons.

-- IV

On Nov 21, 12:27 pm, "kdt...@gmail.com" <kdt...@gmail.com> wrote:
> Hey All,
>
> We are just finishing up our latest application: VistA Messenger.  It
> is an email connection that is designed to keep copies of all messages
> from and two patients as new documents visible in CPRS.
>
> But before we start using it in our office, we ran this by the
> attorney at our malpractice carrier to see if we are taking unsafe
> risks.  He didn't have much experience in the issue, but started
> saying things like we needed to encrypt all the messages etc.
>
> We plan on obtaining a signed release on all patients before emailing.
>

> I found this guideline:http://www.ama-assn.org/ama/pub/about-ama/our-people/member-groups-se...

[Crawford Rainwater]

Kevin:

I would suggest what is sometimes referred to as an "archive and
discovery" for compliance and CYA reasons. The simple version of this
idea is a repository of any and all emails sent to and received by the
email server for all email user accounts. So for one user, there is a
second account with all of the emails sent/received mirrored. This
account will retain the emails for the desired retention period (e.g.,
1 year, 2 year, 5 years, forever) so that in the event of any "well,
you emailed me this..." issues, they can be reviewed for such.

--- Crawford

The Linux ETC Company
10121 Yates Court
Westminster, CO 80031 USA
voice: +1.303.604.2550
web: http://www.linux-etc.com

On Nov 21, 11:27 am, "kdt...@gmail.com" <kdt...@gmail.com> wrote:
> Hey All,
>
> We are just finishing up our latest application: VistA Messenger.  It
> is an email connection that is designed to keep copies of all messages
> from and two patients as new documents visible in CPRS.
>
> But before we start using it in our office, we ran this by the
> attorney at our malpractice carrier to see if we are taking unsafe
> risks.  He didn't have much experience in the issue, but started
> saying things like we needed to encrypt all the messages etc.
>
> We plan on obtaining a signed release on all patients before emailing.
>

> I found this guideline:http://www.ama-assn.org/ama/pub/about-ama/our-people/member-groups-se...

[Nancy Anthracite]

From the documentation for meaningful use proposed testing from CCHIT, there
is a CMS standard http://www.ietf.org/rfc/rfc2630.txt called the IETF
Cryptographic Message Syntax (CMS) RFC-2630, -3852 you might like to look at.

--
Nancy Anthracite

[kdt...@gmail.com]

Thanks Crawford and Nancy,

I will be using VistA itself as the means of storing all the emails.

Nancy, my program will use SSL to get the mail from me to Google, and
from Google to the user. It's just that big Google that patients will
have to decide if they trust or not. If they do, fine. If not, we
will stay with the old methods.

Kevin

On Nov 22, 12:00 pm, Nancy Anthracite <nanthrac...@earthlink.net>
wrote:

> From the documentation for meaningful use proposed testing from CCHIT, there

> is a CMS standardhttp://www.ietf.org/rfc/rfc2630.txtcalled the IETF

[Nancy Anthracite]

I have not had time to dig into all of this yet, and I am not looking forward
to it.

--
Nancy Anthracite

[kdt...@gmail.com]

The attorney said that the law was going to be changing early 2010 as
part of this stimulus stuff, so he was going to see what the expected
regulations say. I'll let you know if there are any gotchas

Kevin

On Nov 22, 9:26 pm, Nancy Anthracite <nanthrac...@earthlink.net>

wrote:
> I have not had time to dig into all of this yet, and I am not looking forward
> to it.  
>
> On Sunday 22 November 2009, kdt...@gmail.com wrote:
>
>
>
> > Thanks Crawford and Nancy,
>
> > I will be using VistA itself as the means of storing all the emails.
>
> > Nancy, my program will use SSL to get the mail from me to Google, and
> > from Google to the user.  It's just that big Google that patients will
> > have to decide if they trust or not.  If they do, fine.  If not, we
> > will stay with the old methods.
>
> > Kevin
>
> > On Nov 22, 12:00 pm, Nancy Anthracite <nanthrac...@earthlink.net>
>
> > wrote:
> > > From the documentation for meaningful use proposed testing from CCHIT,

> > > there is a CMS standardhttp://www.ietf.org/rfc/rfc2630.txtcalledthe IETF

[Crawford Rainwater]

Kevin:

Since you are using a third party (Google in this case) to send the
email, then it will not be compliant is my current understanding.
This will also permit others to subpoena Google without notifying you
of cause to obtain the email(s) if need be. Slashdot has more
information on this a few weeks ago for reference.

--- Crawford

The Linux ETC Company
10121 Yates Court
Westminster, CO 80031 USA
voice: +1.303.604.2550
web: http://www.linux-etc.com

On Nov 22, 7:14 pm, "kdt...@gmail.com" <kdt...@gmail.com> wrote:
> Thanks Crawford and Nancy,
>
> I will be using VistA itself as the means of storing all the emails.
>
> Nancy, my program will use SSL to get the mail from me to Google, and
> from Google to the user.  It's just that big Google that patients will
> have to decide if they trust or not.  If they do, fine.  If not, we
> will stay with the old methods.
>
> Kevin
>
> On Nov 22, 12:00 pm, Nancy Anthracite <nanthrac...@earthlink.net>
> wrote:
>
> > From the documentation for meaningful use proposed testing from CCHIT, there

> > is a CMS standardhttp://www.ietf.org/rfc/rfc2630.txtcalledthe IETF

[Jason Hernandez]

I agree with Crawford's concerns. Google gets tons of subpoenas and
they usually comply without giving anybody time to contest them. I
think you might want to check Google's terms of service as well,
because they could contain disclaimers or outright prohibitions on
using Gmail for communicating confidential information.

I *strongly* dislike using regular email for anything that I don't
mind being available to everyone.

Here's the chain of communication and some threats to consider:
(1) Patient's computer -(2)-> (3) Google mail servers -(4)-> (5)
Kevin's computer

1) Patient's computer (security concerns on this end ultimately depend
on the patient)
Snooping from other users
Weak email passwords
Malware
Typos in email address / selecting wrong recipient
Forwarding email to other accounts--this will be routed insecurely
Sending emails through another SMTP server

2) Connection to Google servers
Not using SSL for email on every client *This is my greatest concern.
It allows anybody on the same network to snoop.

3) Google mail servers
Admins snooping
Insecure routing of email between servers? SMTP isn't secure on its
own, and I don't know how Google routes its email amongst its servers.
If patients use other email services, insecure routing of email is
guaranteed.

4) Kevin's connection to Google servers
Not using SSL for email on every client
This is under your control, and not difficult.

5) Kevin's computer
If he's already following reasonable security practices and complying
with HIPAA, this shouldn't be an issue.

I really like the idea of having this kind of contact, but I would
propose two alternatives:
A) https / SSL webpage with contact form. The site can email users
"you have a new message in your secure message center." The users then
log in to your secure website and view / send messages. This is what
every bank I do business with does.

Advantages: This forces the patient to use SSL, makes it impossible
for them to forward messages to other email accounts, and reduces
patients' ability to send emails to the wrong person. You can also
expand the features of the secure website to do scheduling, display
lab results, and anything else over time once you've set it up.

Disadvantages: You will want to purchase an SSL certificate. I see a 5
year certificate for $325. You will also have to set up and maintain
the secure webpage. It looks like there are some companies out there
that host SSL web forms if you don't want to do it your self.

B) Public key email encryption
Advantages: When done right, it's highly secure. Just make sure not to
include anything sensitive in subject lines, since they're not
encrypted.
Disadvantages: The majority of end users / patients will screw it up.
Requires separate email client. I can provide details if anyone's
interested. The amount of support / training required is very
burdensome.

I can provide more details if anyone's interested.

Jason Hernandez

On Nov 23, 12:12 pm, Crawford Rainwater <crawford.rainwa...@linux-

[Jason Hernandez]

I forgot to credit Ignacio. I'm giving a more verbose description of
the system he describes in my option A and the issues with standard
email communication.

Jason Hernandez

[kdt...@gmail.com]

Jason and Crawford,

I agree with both of you. Use of Google is NOT secure. The question
is whether patients will want to allow communication through an
insecure channel. I.e. they want to waive their rights of privacy. I
will be having them sign a form that spells out in explicit detail
that Google may keep their email indefinitely for purposes that we
don't know. And likewise, if they want cell phone messages, the cell
companies likely keep these posts forever.

But I actually think that patients will still want to use it. The
vast majority of the messages that we get are stuff like, "I need a
refill of my blood pressure pill", or "I have a cold, can you call me
in some medicine." I personally would not mind Google looking over my
shoulder for such messages. They already have access to the rest of
my email. So, I think that many will want this service.

Jason, I agree that the arrangement you describe would be more secure,
but it has a bigger hassle factor. Especially on my part, since I
just finished writing an app that is designed to interact with an IMAP
server, and I doubt those secure portals work that way.

Anyway, I asked for feedback, and I appreciate everyone's input.

Kevin

[fred trotter]

Hi,
       Whether or not plain-text emails are appropriate for the exchange of health information has long been debated. The regulatory environment has shifted constantly and it is unclear whether this will be allowed. Even if it is allowed by regulation, it will be the type of thing lawyers might advise against because of liability concerns. Being right does not mean you win the lawsuit in America.

       I have thought about creating a "trivial secure email system for doctors" that would allow for a system like Kevins to assume that they were sending plaintext email using SMTP but in fact would ensure that all messages from the doctor to the patient where encrypted.

       Kevins system would receive and send email as normal. The send portion would need to use SMTP. Kevin would configure his system to send SMTP messages to a special program instead of directly to a SMTP system (like gmail). This gateway would create a unique URL with the contents of the message living inside. Instead of forwarding the message directly to the patient, the gateway would forward a link to the URL. When the patient clicked the URL (of course protected with https), they would be challenged with an OpenID login. They would use their Google/Yahoo/AOL/Microsoft password to login (the gateway would never know the password, just that the user was the owner of the target email) and then gets to see the message.

In the past I have gone so far as to create a whole messaging infrastructure protected in this fashion. But I think this is overkill.

Would this be welcome?

-FT

--
http://groups.google.com/group/Hardhats
To unsubscribe, send email to Hardhats-u...@googlegroups.com

--
Fred Trotter
http://www.fredtrotter.com

[kdt...@gmail.com]

Fred see below,

On Nov 24, 2:05 pm, fred trotter <fred.trot...@gmail.com> wrote:
> Hi,
>        Whether or not plain-text emails are appropriate for the exchange of
> health information has long been debated. The regulatory environment has
> shifted constantly and it is unclear whether this will be allowed. Even if
> it is allowed by regulation, it will be the type of thing lawyers might
> advise against because of liability concerns. Being right does not mean you
> win the lawsuit in America.

I did have a chance to talk to the attorney for my malpractice carrier
today. He felt that email was becoming so wide spread, that people
have come to accept less security in trade for more convenience. And
as long as we explicitly let patients know that the information is
outside our control after we send it, and if we give them the option
to use this or NOT use this, then we could show that we had used due
diligence in protecting their private information. And if I follow
the guidelines put out by the AMA (I gave a link to this earlier),
that I should be OK overall. Of course someone can always find a
reason to sue. We are lucky that our office is small enough that we
can usually keep a close watch of patients needs and wishes. And as
long as they are happy, we are happy.

> I have thought about creating a "trivial secure email system for
> doctors" that would allow for a system like Kevins to assume that they were
> sending plaintext email using SMTP but in fact would ensure that all
> messages from the doctor to the patient where encrypted.

Just a quick point. We are using aopen-sourc mail code library called
INDY. It allows SSL communication with SMTP. In fact, I think Google
requires it.

>        Kevins system would receive and send email as normal. The send
> portion would need to use SMTP. Kevin would configure his system to send
> SMTP messages to a special program instead of directly to a SMTP system
> (like gmail). This gateway would create a unique URL with the contents of
> the message living inside. Instead of forwarding the message directly to the
> patient, the gateway would forward a link to the URL.

This sounds similar to the solution that Jason proposed. I personally
have no desire to offer an email server on a computer in my office. I
am commited to not opening up my firewall or any of our computers to
the internet (except through SSH). After I test my VistA Messenger
app and get it released, someone else would be free to use it to
connect to your special email server, as long as it offers IMAP, and
SMTP.

Personally, I think patients would not like getting a URL that then
requires them to go somewhere and log in to get a reply from their
doctor. I think they would prefer to take their risks with Google.
The few that I have asked seemed OK with Google.

Again, I appreciate everyone's feedback.

Kevin

[Jason Hernandez]

Fred, Kevin:
This is what I was thinking about as a means of working with Kevin's
existing code. One could set up a https web server that patients would
log into and convert the input to email via some PHP and other
scripting languages that would be available from an IMAP server on the
same machine. A very simple web content management system might do the
trick on the web side of things, and the mail server would be a
simple, private configuration only accessible on the doctor's LAN.
OpenID logins aren't a bad idea for streamlining the login process. I
would look at what is out there before writing up a whole new system.
I think this easier to solve configuring a combination of existing
Free software.

I can definitely appreciate not wanting to deal with the
infrastructure of running a web / email server, and deal with SSL
certificates on top of it. On the up-side, you don't have to deal with
spam or spoofed emails dumping garbage into your system.

If I was to venture a guess, I would suspect that most of the work
done in Kevin's new code was parsing incoming emails and figuring out
what to do with them, not speaking to the IMAP server. That same code
used to parse the emails could probably be fed information from a file
generated by the website instead of an email.

Liability might not be much of an issue, since patients would probably
have to do something to expose themselves to security issues. If you
limit the scope of what you communicate to the mundane--scheduling,
prescription refills, etc., you might not have much of an issue. I
would just advise patients not to use an email account they check at
work, since employers can monitor computer use and are involved in
insurance in the US.

Most of the webmail services I've seen encrypt login information and
then run the rest of the session over plaintext http. Gmail has the
option to always use https, but it's not default. I expect that you
would fetch the emails over an encrypted link, but it's what the
patients do that gets complicated.

I don't think requiring a separate web login is too burdensome for
something like communicating with my doctor. I log in to read the
Washington Post, post on LinuxQuestions.org, and buy stuff at Amazon.
I would say that communicating with my doctor is at least in the same
ballpark.

In the end, you have to trade off between security and convenience. A
"secure website" still has to deal with phishing and SQL injection
attacks among other things.
I tend to favor the more secure side... whether it's RFID shielded
wallets or using SSH keys and obscured ports. (It seems that there's
some bot-net guessing SSH passwords.)

Jason