********************************************************************** To be removed from this list, go to: http://snip.wedi.org/unsubscribe.cfm?list=privacy and enter your email address.
--- Begin Message ---We totally agree with Eddie that SMGs do not address patient to provider messaging. They are designed to address B2B email (a BIG piece of the puzzle!)
For B2C, our recommendation would be to use secure provider portals (using SSL on a message specific basis -- like credit card transactions). That way you avoid the administrative nightmare of individual certs. We are actively talking with the Commonwealth of Massachusetts about exactly this combination of solutions.
Not perfect, but a major improvement over today's unprotected messaging environment.
Ben, anything to add?
Jan Root <[EMAIL PROTECTED]> wrote:
Eddie
Joe would have to respond regarding any particulars of MHDC's efforts. If there were going to be good computer authentication (i.e., fairly high non-reputiation), particularly on the patient end, you'd need a one-key-per-person app. The problem is cost. Using PKIs is probably not feasible on a patient level: I read somewhere that within a large organization it costs about $150/year/employee to deal with forgotten/lost passwords. It would be more expensive than that to deal with lost/forgotten/expired keys as the process of replacing a key is more complex than issuing a new password.Does anyone out there have a system for patient's to query their own physicians or to look at their own medical records? If so, what does your system use to authenticate the patient?
The patient query systems I've seen so far use basically the same thing my bank does: a name/acct # and a PIN: no PKI there. It seems that, for patients anyway, the most manageable form of computer authentication is name + PIN + maybe one other piece of info (DOB?). So this appears to be 'reasonable and appropriate' for now. And, for the most part, this system seems to work. There doesn't seem to be an urgent need for a highly robust authentication system like PKI. Eventually there may need to be a medical, hopefully national CA (working across different CA's introduces a somewhat lethal level of additional complexity, particularly if you are giving keys to health care professionals that may be licensened under a wide variety of state laws) but, right now there simply doesn't appear to be a benefit that makes individual-key PKIs worth the cost.
Hence, the gateway approach used by MHDC. It seems to be the most pragmatic, biggest-bang-for-your-buck approach. It's not perfect, but, with some cooperation between vendors, it at least works and actually gives you a way to exchange secure email in a completely transparent app. I saw a demo put on by MHDC and it was simple - it just looked like I was sending an email, nothing special at all. Pretty cool!
Jan Root
Eddie Anderson wrote:
Jan:IF I understand this initiative (I believe I do but please correct me if I am wrong) it will have no impact on patient to physician email exchange and very little help for even physician to physician email exchange due to the fact that they are ONLY looking at server level certificates. In other words, unless your email provider organization has an S/MIME gateway you can't participate?? Going with model#1 (one key per person) has there been any continuationn ot parallel of the WEDI project to define a PKI with 'medical" defined extensions? ie I amd a patient, RN, LPN, X-RAY Tech, Physician, Licenesed in xState, Yemployer, etc. I understand the magnitude of managing somthing like this so I don! 't want to rekindle that debate but I also know that medicine revolves around local hospitals, regional medical centers and state level licensing authorities. I think somthing is badly need to manage authentication at whatever scale is manageble TODAY for healthcare e-everything to take off. This needs to be a "generic" medical CA and certificagte model that local medical authorities could adopt. This goes WAY beyond provider/payer EDI and email. ie. Diagnostic orders/results, RX, etc, etc. Any updates you are aware of in this specefic area of authentication? Hope you are doing well.Regards:Eddie Anderson-----Original Message-----
From: Jan Root [mailto:[EMAIL PROTECTED]]
Sent: Monday, May 06, 2002 9:10 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: Transmitting Patient Information via Internet (Email)
Sean
I reached Joe Miller of the MHDC just to see what their take on how things were going with regards to secure email. Below is Joe's response. MHDC has studied this topic for several years. I should preface his email by saying that, there are generally two approaches to secure email: (1) every individual has their own key, and (2) organizations each have their own key. Approach (1) is probably the most intuitive approach but you end up with a large number of keys to manage. This, in turn, has always been a significant hurtle to overcome (managing large number of keys, particular from different CAs can be quite costly and a hassle for the end user). In an effort to limit the number of 'keys' in use MA went with a gateway approach to secure email. That is, the organization's server had a key rather than each individual person having a key. This greatly reduces the number of keys that need to be managed.<begin clip>
Inter-operability is clearly still a major issue... and I believe our initiative is the only "cross vendor" secure email solution being explored in the marketplace. We are making slow but steady progress in MA. Two organizations (Tufts Health Plan and CareGroup hospital system) have purchased S/MIME Gateway -SMG- products (from two different vendors!) with software that meets the spec we have submitted to the IETF. They are beginning to send encrypted emails to one another. More importantly, the Commonwealth of MA is interested in addressing Secure Email and we have presented to several different groups within the state. They are very interested in the SMG approach and I expect them to test it with 2-3 healthcare agencies in the next 6 months. If the state chooses this approach, I expect a bandwagon effect will influence other MA healthcare orgs to pursue SMGs.This web site
has most of the relevant information
<end clip>For those of you who are not familiar with how digital signatures work, UHIN has a powerpoint presentation on the topic. Go to www.uhin.com - Education and scroll down to the "presentations" section. Look at "UHIN's Digital Signature Presentation". It's a little out of date, but the basics still apply.
Jan Root
Sean Steele wrote:
Jan,As I recall that study (announced by Mass Health Data Consortium on
4/24/01) became one of the main factors in vendors' standardization on
X.509v3. The major difference being that proprietary "extensions" to
X.509 were accounted for in v3 whereas they had impeded interoperability
in previous versions.Interoperability was a major problem with the industry, but I have not
seen or heard any significant mention of it (in the context of
cross-enterprise secure mail exchange) in more than a year.Everyone should know to avoid proprietary cryptography (and PGP) like
the plague; Network Associates recently put its main PGP security
products out to pasture.--
Sean Steele
National Account Manager
Tovaris, Inc.
[EMAIL PROTECTED]
v +1.703.465.0964
f +1.703.465.2435"Jan Root" wrote:
> One more point to add (sorry to keep raining on a good idea): Interoperability has always been a major challenge to doing secure email. If I buy secure
> email system X and you buy secure email system Y, can we exchange secure email? Probably not.
>
> The Massachusetts component of HealthKey (the Mass. Health Data Consortia) did an interoperability project for secure email. I think they started with 6
> (5?) secure email vendors, all of which claimed to have implemented the X.509 (v3?) standard. However, when tested, none of these systems could read
> each other's email. This was a couple of years ago so perhaps this problem has been solved, but interoperability is something to consider if you are
> looking at secure email systems.
>
> And then there is the problem of trying to send secure email to someone who doesn't have secure email facilities. Vendors have come up wi! th clever
> ways to deal with this, but it is far from being automatic or transparent. Secure email still seems to be much more difficult than it appears on first blush.
>
> Jan Root
**********************************************************************
To be removed from this list, go to: http://snip.wedi.org/unsubscribe.cfm?list=privacy
and enter your email address.
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness--- End Message ---
