Free EMR Newsletter Want to receive the latest news on EMR, Meaningful Use, ARRA and Healthcare IT sent straight to your email? Join thousands of healthcare pros who subscribe to EMR and EHR for FREE!

Direct Messaging: The Logistics of Exchange

Posted on June 12, 2014 I Written By

Julie Maas is Founder and CEO of EMR Direct, a HISP (Health Information Service Provider) whose mission is to simplify interoperability in healthcare through the use of Direct messaging EHR integration and other applications. EMR Direct works with a large developer community to enable Direct for MU2 and other workflows using a custom, rapid-integration API that's part of the phiMail Direct Messaging platform. Julie is passionate about improving quality of care and software user experience, and manages ongoing interoperability testing within DirectTrust. Find Julie on Twitter @JulieWMaas.

Once you enable digital health data exchange via Direct instead of by fax, you’ll want to share your address with other providers, so you no longer have to deal with all those pesky scanned attachments, subtly linked to electronic patient records.

Direct directories are enabling address lookup to meet this need, and you can also let your most common business partners know your address by including it on document templates you already exchange today, so they can begin to exchange with you via Direct when they’re ready.  You can also contact your referring docs using another method you trust (such as the fax where you usually send them medical records, or their business phone number) to ask for their Direct address.

It’s wise to confirm expectations with exchange partners about the use cases/data payloads for which you intend to exchange via Direct, as Direct isn’t used just like email by everyone.  Some will use Direct solely for Transitions of Care and patient Transmit, others may use it for Secure Messaging with patients, and still other providers will be happy to conduct general professional correspondence with patients and other providers over Direct.  This service information may or may not be reflected in the first provider directories.  And even within the Transitions of Care use case, if standards aren’t implemented for optimal receiving, a sending system may generate a CCDA (Continuity of Care Document) with a subtly different structure than a receiving system is able to completely digest.  So, just a heads up as you receive your first message or two from a system with whom you haven’t exchanged before: you’ll want to carefully monitor what data is incorporated by the receiving system and what is not, and you may need to iterate slightly between sender and receiver to get the data consumption right.  You’ll still be miles ahead of the custom interfaces model.

All in all, Direct is easy to use and is working much better than the naysayers would have you believe.  Direct software follows the specification outlined in the document lovingly known in the industry as the “Applicability Statement”, crafted by consensus through a public/private collaborative effort known as the “Direct Project” and led by the Office of the National Coordinator of Health Information Technology (ONC).   Direct Project volunteers have also written reference implementations following this specification which have been used by many HISPs and EHRs as the basis for their own Direct offerings.  Other private entities have developed their own APIs and implementations of the protocol from scratch.  These different systems and varying configurations regularly test and collaborate with each other, to make Direct work as seamlessly as possible for the end users.  Because the whole system only works as well as our joint efforts, HISPs (Health Information Service Providers who provide Direct services) within the DirectTrust Network take interoperability seriously and work together to iron out any kinks.

A tremendous amount of collaboration is taking place to bring interoperability to fruition for Direct’s well-established standards and policies, and this work is producing a larger and more robust network each day.

What Does Direct Messaging Look Like for MU2?

Posted on June 11, 2014 I Written By

Julie Maas is Founder and CEO of EMR Direct, a HISP (Health Information Service Provider) whose mission is to simplify interoperability in healthcare through the use of Direct messaging EHR integration and other applications. EMR Direct works with a large developer community to enable Direct for MU2 and other workflows using a custom, rapid-integration API that's part of the phiMail Direct Messaging platform. Julie is passionate about improving quality of care and software user experience, and manages ongoing interoperability testing within DirectTrust. Find Julie on Twitter @JulieWMaas.

I’m often asked what EHR integrations of Direct are supposed to look like.  In the simplest sense, I liken it to a Share button and suggest that such a button—typically labeled “Transmit”—be placed in context near the CCDA that’s the target of the transmit action, or in a workflow-friendly spot on a patient record screen.

Send a CCD Using Direct Messaging

Send CCD using Direct in OpenEMR

The receive side is similarly intuitive: the practice classifies how their incoming records are managed today and we map that process to one or more Direct addresses.  If we get stuck, I ask, “What is the workflow for faxes today–how many fax numbers are there, and how are they allocated?”  This usually helps clear things up:  as a starting point, a Direct address can be assigned to replace each fax endpoint.

The address structure raises an important question, because it is tightly tied to the Direct messaging user interface.  Should there be a Direct address for every EHR user?  Provider?  Department? Organization?  A separate address for the patient portal?  A patient portal that spans multiple provider organizations? One for every patient?

The rules around counting Direct messages for Transitions of Care (ToC) attestation do not require each provider to have their own Direct address, as long as the EHR can count transactions correctly for attestation.  As far as meaningful use is concerned, any reasonable address assignment method should be acceptable in ToC use cases (check the rules themselves, for full details).  Here are some examples.

records@orthodocs.ehrco-example.com is clearly an address that could be shared by multiple users, though it could be used by just one person, and might be used for both transitions of care and patient portal transmit.

janesmith@orthodocs.hisp-example.com could also be dual-purpose.  Jane might be the only authorized user of this address, or this address may be managed by a group of people at her practice that does not necessarily even include Jane.  Alternatively, this address could be used for Jane’s ToC transactions, while a patientportal@someother.domain-example.com address could be used for patient portal transmit.

So, any of the options proposed above are possible conventions for assigning Direct addresses.  Also, a patient does not need their own Direct address to Transmit from as part of the View, Download, Transmit measure (170.314(e)(1)), but might have their own address to transmit to.  Note that adding a little extra data can elevate a View, Download, Transmit implementation to BlueButton+ status.

It makes sense for patients and providers to have their own Direct addresses if they are using Direct for Secure Messaging – 170.314(e)(3) – for which Direct is an optional solution.  Or, if patients have their own Personal Health Record (PHR) and Direct address, Direct is a great way to deliver data to the PHR.  Incidentally, there are free services such as Microsoft HealthVault and many others that issue patient Direct addresses.

Direct addresses are nearly indistinguishable from regular email addresses, but a word of caution: Direct is incompatible with regular email, and has additional requirements beyond traditional S/MIME.  Although it’s not a requirement, you’ll often find the word “direct” somewhere in the domain part of a Direct address, to help distinguish a regular email address from a Direct address.

Now that you know what Direct is, and what Direct Messaging and Direct addresses look like, I’m sure you’ll start noticing Direct popping up in more and more places.  So, be a not-so-early adopter and go get yourself a Direct address!

What is Direct?

Posted on June 10, 2014 I Written By

Julie Maas is Founder and CEO of EMR Direct, a HISP (Health Information Service Provider) whose mission is to simplify interoperability in healthcare through the use of Direct messaging EHR integration and other applications. EMR Direct works with a large developer community to enable Direct for MU2 and other workflows using a custom, rapid-integration API that's part of the phiMail Direct Messaging platform. Julie is passionate about improving quality of care and software user experience, and manages ongoing interoperability testing within DirectTrust. Find Julie on Twitter @JulieWMaas.

John’s Update: Check out the full series of Direct Project blog posts by Julie Maas:

The specialist down the street insists he wants to receive your primary care doctor’s referrals, but only if it’s digital: “Sure, I’ll take your paper file referral sent via fax. But the service will cost an extra $20, to pay the scribe to digitize the record so I can properly incorporate the medical history.”

Does it really sound that far off? Search your feelings, Luke…

Will getting medical treatment using paper records soon be like trying to find somewhere to play that old mix tape you only have on cassette?  Sound crazy?  Try taking an x-ray film to a modern radiology department, and see if they still have a functioning light box anywhere to look at it.  It’s all digital now.

There are, of course, other factors.

Because MU2.

Because nobody, and I mean no small company and no large company, wants to be referred to as a data silo anymore.

Direct Exchange is a way of sending and receiving encrypted healthcare data, and certified EHRs must be able to speak it, beginning this year.  Adoption of Direct is increasing rapidly, and its secure transfer enables patient engagement as well as interoperability between systems that were previously dubbed silos.  Here is a brief overview of where Direct is currently required in the context of MU2 (please refer to certification and attestation requirements directly, for full details):

Certified ambulatory and acute EHRs need to use Direct for Transitions of Care (170.314(b)(1) and (b)(2)). They have to be able to Create a valid CCDA and Transmit it using Direct, and they have to be able to use Direct to Receive, Display, and Incorporate a CCDA. In the proposed MU 2015, the Direct piece may be de-coupled from the CCDA piece and modularized for certification purposes, but the end to end requirement would remain the same.

EHRs or their patient portal partner additionally need to demonstrate during certification that patients can View, Download, and Transmit via Direct their CCDA or a human readable version of it.  Yes, you heard correctly, I said patients.  As in patient engagement.

So, how does a healthcare provider get Direct?

1. Get a Direct account through your Direct-enabled EHR vendor

One way HIT vendors offer Direct is through a partnership with one or more HISPs (OpenEMR, QRS, Greenway, and others).  Others run their own HISPs (Cerner, athenahealth, and others).

2. Get a Direct account through an XD* HISP that’s connected to your EHR

HIT vendors alternatively enable access to Direct through an XD* plug-and-play (mostly) connector.  These “HISP-agnostic” EHRs allow healthcare organizations a choice between multiple XD*-capable HISPs when meeting MU2 measures (MEDITECH, Epic, Quadramed, and other EHRs have implemented Direct this way).  EMR Direct, MaxMD, Inpriva, and a few other HISPs offer XD* HISP services; not every HISP offers XD* service at this time.  Of course, there is a trade-off between this flexibility and the extra legwork required of the practice or hospital in setting up Direct.

3. Get a web-based or email client-based Direct account not tethered to an EHR or Personal Health Record (PHR)

 

Direct doesn’t have to be integrated into an EHR to transfer information digitally. Non-tethered accounts cannot attest to the sending side of (b)(2) nor the receiving side of (b)(1) on their own, but they can be Direct senders and receivers nonetheless, participating in Transitions of Care or data transfer for other purposes.  They may also be used to exchange health data with patients, billing companies, pharmacies, or other healthcare entities who are Direct-enabled. In fact, some very compelling use cases involve systems who may not have their own EHR, but want to receive digital transitions of care—one such example is skilled nursing facilities.

By the way, patients are also an integral part of the Direct ecosystem.  Several PHRs are already Direct-enabled, and more are on the way.

So, go digital and get your Direct address, and begin interoperating in the modern age!