John Gage wrote:
> 
> I would like to start a thread on the role of electronic mail in
> medical computing.
> 
> I will begin with the punch-line: I believe that an entire medical
> record system that would actually be used by physicians and other
> providers can be constructed using IMAP server technology.

In principle, yes, and I agree there is a lot of mileage to be had
from e-mail as a ubiquitous message transport protocol.

> 
> With open source components including Exim, Mozilla (an IMAP client if
> ever there was one), and one of the open source IMAP servers (
> http://asg.web.cmu.edu/cyrus/
> ftp://ftp.cac.washington.edu/mail/imap.tar.z [be careful with the
> latter as it just shoots the server, all 6 megs-worth at you]) a
> completely secure system can be placed on the 'Net today.

Complete security never, but adequate security could be acheived
with the set-up you describe provided that well-executed public
key encryption is added to the mix. And therein lies the rub. 
Implementing PKI (public key infrastructure) well on a large-scale
basis is expensive and difficult, even when open source components
are used exclusively.

> 
> HL-7 compatibility?  Well, in the e-mail world view, HL-7 is just
> another MIME-type, is it not?  If one thinks about it, there really is
> no such thing as a message "body" in e-mail: that's just another name
> for an e-mail *attachment* that's plain ASCII text.  The sort of
> e-mail message that one would find in a medical information system
> based on e-mail would simultaneously fulfill several roles: a plain
> text message that humans could understand, an HL-7 version that other
> (benighted) medical computing systems could understand, a billing
> version that third-party payors could understand, a comma-separated
> text version that databases could understand, a prescription, a
> referral, etc.  These are all accepted MIME-types and can be generated
> automatically in the same message.  They also, with a little Exim-Perl
> magic, can find their way to the appropriate destination
> automatically.

Yup. Note that Perl-scripted Exim is not the only way to do this. Many 
languages (including Perl and Python) can manipulate IMAP mail stores
directly.

> 
> Medical records fulfill two, orthogonal purposes.  First, they serve
> as communications between medical providers to further care given to a
> particular patient.

Including communication between a medical provider and her/himself at a 
later date.

>                     This is their clinical role, and the only role
> that clinicians are really interested in on a day-to-day basis.  These
> communications, per force, are couched in human language.  Yes, they
> can be highly stylized and stereotyped human language, but medicine
> just has not reached the point where human language can be eliminated.
> 
> Second, medical records fulfill an audit role.  They are used for all
> the things that have nothing to do with day-to-day care of patients:
> billing, regulatory compliance, science, education, administration,
> etc.  This role is burgeoning and it captures an undue proportion of
> the interest of medical informaticians.  It has absolutely nothing to
> do with immediate patient care except indirectly.

As an epidemiologist and population health informaticist, I fall into
the 
latter group, but as an ex-clinician (not quite ex-, but almost), I 
completely agree with you on this point. So many systems are put in
place
with billing efficiencies or performance monitoring as the primary goal,
and the result is often less than felicitous, especially when the 
clinicians who use the system have no direct financial interest in
billing
efficiency, and are more concerned with the effectivenes of patient care
than the monetary efficiency with which it is delivered. Shame on them!

> 
> The first purpose of medical records: communication is very poorly
> captured by current EMR's.  In contrast, a system based on e-mail
> would capture it perfectly AND would have no learning curve:
> physicians are already familiar with e-mail.

Yup, but there is a steep learning curve associated with a PKI.

> 
> The law, which is completely reliant on human language, has embraced
> e-mail completely.  Many law firms will now only accept pleadings etc.
> in the form af e-mail.

Do they use encryption? Probably not, since things like pleadings are
designed to be recited in public. Not so medical records.

> 
> I am struck by how simple it would be to implement an EMR using
> e-mail. And, it could be done piecemeal with total scalability.

Simple except for the PKI...

> 
> I would close with a reiteration of my comment about security.  This
> system is totally secure.  How?  Very simple.  You put a copy of Exim
> on all the clients.  In this way, not only is each client a client, it
> is also a mail transfer agent.  It has total control of who it talks
> to and what path it uses to transfer mail.  The system would exist in
> parallel with other e-mail systems.

You've lost me there. My understanding is that Exim is a replacement for 
Sendmail and the like. But it still uses SMTP and the other elements of
the
whole Internet email infrastructure for message transport, doesn't it?
Thus, the destination of a message can be specified, but you have no
control 
over what route the message takes.

At each stage of the journey, a copy of the message, in plain text, is
stored
(possibly transiently, possibly not) on unknown mail servers along the
way. Check
the mail header of this message as it makes its way from Australia to
Europe
and then to you in the US. Possibly via Bulgaria for all I know or can
control
(no slight against Bulgaria intended there). Hence the absolute need to 
strongly encrypt the message payload if sent via Internet 
email. And a PKI is the only way of addressing the "key distribution 
problem" when there are a large number of participants in an encrypted
message exchange system.

Note that IMAP is only a better, more secure method for email clients
to interact with their local (or not local) mail servers. It has nothing
to do with the way messages are transferred between mail servers.

> 
> Comments?
> 

Although PKI implementation is difficult and expensive, it can be done
(um, anyone know of any **good** examples of PKI implementation in the 
health context?). I think.

Tim C

Reply via email to