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.