Not Just for Clinician to Clinician Messaging AnymoreI have long maintained that the Direct Protocol, while it is basically email, was not just for physicians to send messages to physicians. Instead, Direct is exactly what it describes itself as a Secure Health Transport. As such, it can and should be used in a variety of use cases whether they are for user to user integrations, system to system integrations, or some other combination.
The Standards & Interoperability Framework projects have long recognized that Direct is a Secure Health Transport for many uses and that many of those are automated system to system communications. Beyond the eReferral model of the initial Direct implementations, the S&I Framework has added projects like Lab Orders Interface and Lab Results Interface that are service organization to provider communications. Also, they added projects like Query Health and now Data Access Framework that are more system integrations to serve population health queries and automate chart pulls from either EMRs or HIEs.
The first of these initiatives were slow to mature but now that Lab Orders are on the radar, Lab Results will pick up. Of course, it will work best when the order comes in with the direct address that need the results and then the results can flow more easily. Query Health will be slow just because it isn’t an existing service that everyone does. So we aren’t making something better, we are making something new. That needs more policy than technology so adoption is going to be slow but steady.Unlike Query Health, I believe Data Access Framework will really jumpstart Direct into use as a mainstream transport protocol for broader HIE than just one to one communication. This is because it is always policy not technology that holds up adoption. In the case of policy for pulling data, many regions already have a policy implemented by their local RHIO and the tie to that policy is the participation agreement with the RHIO. So good news, policy already exists for pulling data. Now we can just implement technology for those EMRs and practices that didn’t do web services but have Direct.
The HIE embedded HISP
The fact that RHIOs will use Direct Protocol both to receive data from practices/EMRs and to accept and respond to queries of the HIE for patient centric history is why I have long been driving the notion that HIEs are an abstraction point between providers for data integration and HIEs need to implement Direct as one of the many protocols they support. Direct is not some other thing that gets implemented on a different stack from the HIE itself and call it the HISP. Direct is just a protocol. It needs to be supported directly inside the HIE protocols. This is not to be the middleman for EMR to EMR communications like eReferral or someday even for Lab or Image Studies. This is for the core services of the patient centric RHIO/HIE. It is for retrieving patient history into the EMR and it is for delivering alerts and notification of patient centric activity to primary care, care managers/coordinators, and patients in support of the emerging ACO models.
Taking the High RoadThe States and RHIOs that have developed or contracted for a HISP that sits outside of their HIE I think have made a huge mistake. Don’t focus on being the HISP. That is a service that sits close to the provider/EMR. Focus on the patient centric data and being your own HISP, just like many EMR vendors and hospitals will be their own HISP, to support your own transactions like patient data access and alerts & notifications. This is what we have done and I believe is the high road so that we aren't competing with EMR vendors or our own participants but complementing them.
Don't Stop, Don't Change Direction, Just Reuse
One last note; don't stop doing IHE web services. The Data Access Framework will still take time to mature the technology. So even with policy out of the way via RHIOs, we still need to move forward. Also, one of the two flavors of Direct (SOAP XDR) is actually the IHE web service XDS.b Provide and Register that is used in the common IHE web service integration to connect with RHIO based HIEs. So any effort completed today is still valuable tomorrow. Again, since the "HIE the noun" is the SOA-based loose coupling (abstraction point) between organizations using multiple standards, one organization may use web services, one may use SMTP, one may still send legacy HL7 message and look up patients using a portal web link. But, they all can communicate seamlessly and not worry about what the other does because the HIE takes care of the translation, transformation, and any changes in transport.