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.
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.
firstname.lastname@example.org 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.
email@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 firstname.lastname@example.org 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!