Introduction
This document is a result of the dialog at the last EHRI SIG meeting. I wanted to recap and present to
everyone what happened in a much less dynamic fashion then what occurred on the phone. As the old
phrase goes, “You had to be there,” but this document hopes to restate the takeaways as if you were
there for those who couldn’t attend. I also begin with a disclaimer that this is in no way complete and
there could be oversights and mistakes. The idea is to evolve and review with others for refinement.
The focus of our discussion was on how to technically implement the use case we have developed. Two
patterns emerged which are described below, and we plan to review these with you in order to gather
additional input. This document will also address how this relates to the Nationwide Health Information
Network Exchange and the Nationwide Health Information Network Direct Project. It also describes the
work the CONNECT team needs to do with the next release to support these exchanges.
Two Design Patterns
Two design patterns emerged that address a number of the problems presented by the group.
The patterns will be referred to as: Provider to Provider One Gateway (PPOG) and Provider to Provider
Two Gateways (PPTG).
The PPOG (see the image on the next page) accepts as input an application, a fax, a scanned image,
email message or pen. So basically, anything that can generate a requesting message and if required
associated metadata for the profile can be an input device. If the request is to send a document such as
a C32, the gateway would do a “fetch back” to the EHR, locate the requested document and send it to
the receiver. In this case, the receiver does not have a gateway but rather an email address identified by
the sender’s request. The major capability to add to CONNECT is the ability to take the request and
have the capability to post a mail message using SMTP. This would work nicely for sending documents
and reminders to patients and to doctors. The critical need is to get information to providers today who
do not have a system, but want information to consider before treating the patient.
The PPTG (see the image below) accepts as input devices that generate a file such as an application, a
fax, a scanned image, email message or pen. So basically anything that can generate a requesting
message, and if required, associated metadata for the profile can be an input device. In the case of a fax
image/tif file, the user interface would need to collect additional information to support the transfer.
The file transfer adapter would call document submission and the contents would be exchanged with
the receiving gateway. In this case, the receiver does have a gateway. The major capability to add to
CONNECT is the ability to have the file transfer adapter take the request and call document submission
service. This would work nicely for sending documents to CMS ESMD program using email. The critical
need is to present an interface to a user to gather information and deliver it to the right gateway. This
would be a useful for exchanging lab results or any other information using a push by simply dropping a
file into a folder.
A third diagram depicts how this would work for ESMD.
How Does the work of EHRI SIG related to DIRECT?
There are two parts to this answer.
Part One. The work required will span over at least two releases of CONNECT. In order to prepare for
Direct Project implementations there is work to be done to prepare CONNECT. File Transfer Adapter
working with Document Submission will benefit everyone using the gateway today. Adding Mail
Services to the gateway and interacting with email clients are another must have to prepare for Direct.
The third activity, not explicitly stated above, would be the support of S/MIME Clients that generates
the email input we described above.
Part Two. There are three primary specifications related to Direct and they are Addressing, Content
Container and Security. There is a fourth specification emerging called XDD or a lighter weight XDR
without all of the metadata required by XDR. Today, our work will follow the addressing, content
container specification and security. The XDD as it gains consensus and becomes clearer will be a target
of opportunity which we will embrace. Over the next three months, there is work to be accomplished in
the following areas:
1) What do we do with Direct exchanges that do not or cannot support the existing metadata
requirements in the profiles today?
2) Will this require a new service to exchange information between Direct and the exchange?
3) How can a healthcare information service provider (HISP) inside the Nationwide Health
Information Network Exchange communicate between a HISP outside the Exchange?
4) How do we respond to messages that are not deliverable?
5) Will there be a Direct header in the SOAP message similar to what was requested for the
Nationwide Health Information Network Exchange headers but was not
supported/approved/specified?
I look forward to hearing from the community.