SMTP Interface

johnbwilliams wrote on Tuesday, December 21, 2010:

Seek community input on options for implementing a SMTP interface in OpenEMR.    PHP mailer is good for outbound SMTP, but what option exist for inbound SMTP?   A primary consideration  in selecting an SMTP interface is the effort required  to conform with community coding guidelines.

Background:  SMTP is necessary to implement  MU #21 Exchange Clinical Information and MU #18 Patient Electronic Access to Health Information, using the standards and specifications of the DirectProject.org  (formerly NHIN Direct). Direct exchange of medical records is becoming the de facto standard for HIT interoperability.

sunsetsystems wrote on Tuesday, December 21, 2010:

You don’t want to do inbound SMTP.  Far too complex.  Even managing a mail server is a complex task for a system administrator, especially in today’s big bad world of spam and malware.

What’s the requirement exactly?  Patient sends email, you need to put it in their record?  What if it has attachments, it’s a bad idea to trust them.  Is it acceptable to provide a messaging system on the clinic’s web site instead?  Tell us more.

Rod
www.sunsetsystems.com

sunsetsystems wrote on Tuesday, December 21, 2010:

Just looked at the directproject.org site… I see you’re listed as a member.  :slight_smile:

OK, secure SMTP, not public.  If you want to implement that yourself, I’d say use an established MTA, for example Postfix.  You want to do that at the clinic sites?  Might still be a local admin headache, and there may be issues if the server does not have a static IP.  Maybe use a web-based mail client like SquirrelMail for reviewing the mail.  You’ll have to tell us where you want to go from there.

But looking at their progress meter, it doesn’t seem very far along….

Rod
www.sunsetsystems.com

johnbwilliams wrote on Tuesday, December 21, 2010:

Many HISP operators (like us)  provide a stand-alone web-based “direct” messaging system for use providers seeking to participate in direct exchange HIE without a direct exchange-enabled EHR system.  This is not an ideal solutions as users will be doing a lot of shuttling of documents between the direct messaging platform and their EHR system.

Our goal with OpenEMR is to create a tigthly (as much as possible) integrated direct exchange interface in OpenEMR, as are many other EHR vendors. .  We’ve done some testing on the PHP  Mailer class library (  https://sourceforge.net/projects/phpmailer/ ) and it seems that it will do the job for oubound messages.

A question is how to integrate PHP Mailer with OpenEMR.   I am doubful that PHP Mailer will meet OpenEMR coding requirements, and suggest  that we incorporate it as an add-on module to OpenEMR,  BUT,  implement an optional direct exchange GUI,  that would meet all OpenEMR coding guidelines,   within the official OpenEMR code base

Does this make approach make sense and would it be acceptable?

sunsetsystems wrote on Tuesday, December 21, 2010:

OK, my suggestion is that you specify that a SMTP server (also known as a Mail Transport Agent, or MTA) be suitably configured to both send and receive mail with the participating entities, and that a POP3 or IMAP server also be configured to facilitate access to received mail.  There are many commercial and open source options for these.  I have used Postfix and Courier IMAP, respectively, with very good results, but you need to cater to others.  So I would not distribute the servers with OpenEMR, but rather plan to provide detailed instructions for setting some of them up.

There is also the matter of the OpenEMR user communicating with the MTA.  PHP has some native mail functions that you can read about here:

http://www.php.net/manual/en/refs.remote.mail.php

Will users need to read and respond to these emails in traditional ways?  If no, then maybe this is enough.  If yes, a general-purpose mail client is also a monstrous undertaking and I suggest you use one that already exists (or let the users use their own) and figure out a way to smoothly exchange the data with OpenEMR also.  I don’t think making some custom mods to SquirrelMail, for example, would be out of the question.

Rod
www.sunsetsystems.com

tmccormi wrote on Tuesday, December 21, 2010:

As a possible option/idea we wrote a java app a while back that does nothing but read and i-map email account, download the attachments and move the message to the ‘archive’ …  a similar process tool could be used to poll the HISP for messages and drop them into openEMR.

That app is specifically what feeds the contrib/util/import-mi2xml.php script we wrote to allow Dr’s doing offiline/home visits to send encrypted messages via email to openemr …  not unlike this process at all, I would say.

-Tony

sunsetsystems wrote on Tuesday, December 21, 2010:

The existing fax/scan GUI in OpenEMR might be a good way to process received messages, figure out which patient they are for, attach them to the patient’s chart, send a note to the doc that it’s there, etc.

Rod
www.sunsetsystems.com

johnbwilliams wrote on Tuesday, December 21, 2010:

Depending on the maturity of the OpenEMR GUI for HIE use cases, OpenEMR users may not realize that SMTP is the transport for their HIE exchanges.

Consider the  example of a provider using OpenEMR to send a referral (MU # 21,23, 2), including summary care record (CCR or CCD), to another direct exchange-subscribed provider.  The OpenEMR GUI must allow the sending provider to:  1) select the patient, 2) complete the referral information, 3) select the “referred-to” provider, and click “send”.

The first OpenEMR release of direct-exchange use cases such as this example will not have an integrated directory of direct exchange subscribes-providers, necesitating  “out-of-band” acquisition of dentination provider’s “direct” address, and manually enter this “referred-to” provider’s “direct” email address into the OpenEMR GUI, or pull it out of the referred-to provider’s entry on the OpenEMR address book, if stored there.  This is consistant with the direct exchange HIE “terms of use” where senders are required to have a pre-existing relationship with desintation providers.

The GUI of subsequent releases of OpenEMR direct exchange use cases will integrate with the standard direct exchange provider directory for selection of referred-to providers, and the OpenEMR user may therefore not have any indication that the underlying transport is SMTP.

Receiving direct exchange messages in another story, for two reasons.  The first wave of any HIE addressing, not just direct exchange addressing, identifies provider entiities, not individul providers.  E.g., a multii-physician practice will have a single direct exchange address.  Also, by definition, direct exchange HIE allows for no means of identifying patients.  The practical affect is that all inbound direct messages must be manually sorted by an OpenEMR administrator, by receiving physician and patient ID. 

A GUI for managing received HIE messages must allow an OpenEMR  administrator to  1) view a list of received messages including subject lines, sources address/alias, & date,  2) select, open & view the body of a message including attachements, for purpose of identiying and sorting destination individual provider and patient ID, and moving that message and/or attachement(s)s into a folder/directory for the appropriate destination provider & patient.

For the use case of MU #18 - Patient Electronic Access to Health Information,  we have selected a PHR provider based on their support of the direct exchange standard, tthe technical support they are providing, and the relationship that we and they have built within the HISP community.   That PHR vendor is Microsoft, and their free PHR service is HealthVault.  Patients subscribing to HealthVault will receive a “direct” email address for their PHR unique instance.  For the OpenEMR perspective, this is a send-only address to uniquely identify the patient’s PHR.  The initial OpenEMR GUI for MU #18 must allow the OpenEMR user to 1) select a patient, 2) store the patient’s “direct” address for their PHR (provided by patient), 3) manually initiate an update of the patient’s PHR (by generating and sending the patients’s CCR to the patients PHR address via SMTP)

Direct exchange SMTP is not public network.   Its is a closed network only available to credentialed providers.  HISP operaters must “credential” registration requests of providers.  Providers will receive their digital credentials for direct exchange HIE only after the HISP approves the requesting provider credentials.

tmccormi wrote on Tuesday, December 21, 2010:

This is what is required of ONC specifically (just the sending piece).

Test Procedure for §170.304.i Exchange Clinical Information and Patient Summary Record

Using the EHR function(s) identified by the Vendor, the Tester shall transmit the
Patient Summary Record to an external receiving system using the Vendor-
identified transport technology of the EHR. The receiving system may either be a
Tester’s receiving system that is configurable to use the transport technology of
the EHR system or module, or a Vendor-identified system capable of receiving
from the EHR system or module

sunsetsystems wrote on Wednesday, December 22, 2010:

… Also, by definition, direct exchange HIE allows for no means of identifying patients. The practical affect is that all inbound direct messages must be manually sorted by an OpenEMR administrator, by receiving physician and patient ID. A GUI for managing received HIE messages must allow an OpenEMR administrator to 1) view a list of received messages including subject lines, sources address/alias, & date, 2) select, open & view the body of a message including attachements, for purpose of identiying and sorting destination individual provider and patient ID, and moving that message and/or attachement(s)s into a folder/directory for the appropriate destination provider & patient.

Again, the fax/scan GUI in OpenEMR is very much like that.  I think you could leverage some stuff there and in so doing keep a consistent interface.

Rod
www.sunsetsystems.com

sunsetsystems wrote on Saturday, January 01, 2011:

John, that sounds pretty cool.  Although I don’t know of a cross-platform way in a web browser to get a drag-and-drop effect across frames.  Am sure you can do it within one frame that has a suitable layout.  I think there’s some stuff like that for jquery… did you have a particular tool or software method in mind?

Rod
www.sunsetsystems.com

tanjera wrote on Saturday, January 01, 2011:

Bearing in mind I’m brand new to openEMR, I don’t know how the sql tables are set up, etc etc, I just got a rough solution in my head and thought I’d share.

So, start with a tree view (uh, not sure what php/java calls it, but c# literally calls it a treeview) with the patient’s tree of documents. For increased functionality, have sorting/searching options. Have a selection method (checkboxes on each tree node, selected nodes, list box with multi-select… however you want). Now, bearing in mind that this doesn’t actually have to be encapsulated in the treeview (in fact, a php for() loop could spit out a table that would be equivalent to the “tree view”.

Then, with that laid-out document listing, user selects what they want. Click’s the “Attach” button.

Parse with php (foreach $array is $selected) or w/e the grammar is (ie C#: “foreach (document eachDocument in selectedArray)”), just attach to the message. The only limiting factors will be what layout you decide on. As Rod said, frames may limit things, and I don’t know the full extent of js/php. But I think what I described could be a pretty user-friendly solution, with minimal steps/interactions involved for the correct intended result.

Hope it helps. Just my $0.02

Ibi

johnbwilliams wrote on Monday, January 03, 2011:

Would using the OS clipboard work for transfering files between the patient document tree (OpenEMR web site) and the direct exchange read/compose mail screens ( SecureMail web site)?

I.e.,  when I right-click on a file in the document tree, is there an option to copy to and paste from the OS clipboard?  ( Am I wrong to assume that copy/paste files to/from the clipboard is a cross platform function?) 

tanjera wrote on Monday, January 03, 2011:

I wouldn’t say it’s a bad assumption, because clipboards are pretty universal as far as operating systems go, but I think it’s not the most stable direction to take a program, relying on the operating system’s clipboard.

The simpler you make something, the stronger it typically is. The more complex you make something- or the more modules and systems you rely on- the bigger the chance of introducing bugs.

Considering that browser functionality is in a transitional period, where Microsoft’s next browser is going to evaluate and execute code and scripts in a different manner, setting a new standard for how browsers render- primarily for security concerns- I could see potential friction between that and a program trying to utilize OS resources as far as file caching and handling.

Besides, if (and most likely) there is an operating system that it wouldn’t execute successfully on, then there’d be no way to fix it without writing OS-specific code, which is… not something anyone’s gonna wanna do. I’d keep it all centralized, unified, and gracefully elegant in its simplicity.

johnbwilliams wrote on Monday, January 03, 2011:

I understand your points.  Right now I suggest our goal is to implement the minimal functionality to meet OpenEMR requirements and NIST requirements for 1) Exchange Clinical Information,  2) Patiient Electronic Copy of Health Information, and maybe other MU-1 cert reqs. 

I can  think of 100 imporvements Ito achieve a slick integration of direct exchange messaging and OpenEMR, but it probably  makes sense to evaluate the HIE-related MU-2 requirements before prioritizing these improvements.

(Some improvements are no brainers … adding a field in the OpenEMR provider directory for direct exchange provider address probably makes sense to do fairly soon.  Asecond is adding an smtp address field in OpenEMR patient demographics fo those patients using a direct exchange PHR service)