If you would like to participate in this SWG, please e-mail Gayathri Jayawardena at Gayathri.Jayawardena@esacinc.com with your contact information and reference the DAF over Direct SWG.
Business Reasons you should commit to the “DAF over Direct” Workgroup
ProvidersYou should commit to this workgroup, or have your EMR vendor commit, because implementing DAF over Direct allows you to work the way you work. It replicates the phone/fax/mail process by which you don’t necessarily have to collect any additional releases from the patient unless you really need the sensitive data protected by specific release. In this one-to-one push model, you can request and receive PHI as you do today on a patient you are treating as allowed under HIPAA.
ACOs and Health PlansYou should commit to this workgroup, or have your HIE vendor commit, because implementing DAF over Direct allows you to work the way you work. It replicates the phone/fax/mail process by which you already can collect patient data for the programs you offer based on the relationships in place between you and your provider network and/or between you and your subscribers. You don’t have to jump through another consent hoop that doesn’t exist today.
EMR VendorsYou should commit to this workgroup because it removes the more cumbersome and mixed HIE standards that are occurring today.
You should commit to this workgroup if you are in a state that believes in reducing costs of health care and government.
Problems Solved by Targeted DAF over Direct
Problem – Too Complex for the Client EHR
Basically, for an EHR to be part of an XDS affinity domain and pull information from an HIE or from another EHR peer to peer as part of the same domain, they have to do as many as 6 web service calls to look-up and maintain the patient identity cross-reference (PIX – up to 3 calls), provide consent, find the document, and retrieve the document.
In the ideal world EHRs and HIEs would connect using late binding that allows for acceptable differences in their implementations. This is done using a Service Directory (e.g. UDDI) such as that offered by HealtheWay. However, this isn’t really occurring. EHRs are for the most part tightly coupled to HIEs or other EHRs and HIEs are tightly coupled to each other even if they participate in a service directory.
Due to the complexity and tight coupling, the number of implementations is limited. In fact, many EHRs don’t have support for XDS web services today. But, most do have Direct protocol support.
Solution – Simplification to a Single Transaction
DAF as proposed has the potential to remove the complexity of multiple transactions and simplify this to a single request for either documents or data (multiple rows in a data document).
Problem – Limited Control in Host (HIE or responding EHR)
Even when EHRs integrate with HIEs, there is a major problem in the way IHE web services work. They put all the responsibility on the client EHR. The client adds, updates, or finds the patient. The client separately posts consent declarations. Then the client finds the document. Finally, the client pulls the document it wants.
Solution – More Control for the Host (HIE or responding EHR)
The Targeted DAF method would reduce this to a single transaction sending a declaration of what I want on what patient or patients and why you should give it to me. The HIE or responding EHR contains the orchestration and business rules to determine who to automatically respond to from a whitelist of known providers by Direct address and what requests do not meet those rules then can be looked at manually.
Problem – XDS Implementations are splintered
Today, due to limited implementations of XDS by EHR vendors but support for Direct and XDR, presumably to connect to a HISP for Direct, by EHR vendors; multiple HIEs have implemented Direct and XDR and methods to supply data to an XDS affinity domain. Those HIEs orchestrate the PIX transactions behind the scenes.
In this model you have EHR vendors implementing with HIEs in many different ways for XML documents. The first is pure XDS as we do in New York. The second is over Direct as they do in Rhode Island. And the third, is a Hybrid using XDR (XDS.b provide and register) with the requisite PIX transactions being performed by the HIE and the content being posted to the HIE repository instead of referred to another as they do in some IDN based HIEs. These are just the more common standards based ways. Beyond this your have people sending Base64 encoded documents in legacy HL7 2.x messages and who knows what else.
The problem beyond the lack of using a single method due to lack of support in EHRs is that these are all about sending data in and in many cases using Direct to do it. There is no solution to use Direct to get data from the HIE or another EHR. Thus, users of one-way methods to post documents to HIEs over Direct, need a way to get data over Direct back into their EHR.
Solution – Harmonize a solution to request data via Direct
This completes the Direct integrations between EHRs and HIEs that already exist by giving them a means to get data from the HIE community back into the EHR rather than having to use an HIE portal and not be able to digest the structured data.
Problem – Privacy restrictions when Pulling data
In the real world, you request data from another provider, you don’t take/pull it. The IHE web services and audit is based on taking data with permission of a user. While this may reflect the reality that provider has an existing user account at the local hospital to access records; that is not the real world. That is a world doctors were forced into by the limitations of 1990s technology. In the 1990s, organizations gave people passwords to their systems via simple portals and VPNs because they had no real interoperability to solve for the problem of routine record access by those within close trust. To see the natural relationship, we need to remove that forced world and look at how they get data with no systems in place. In that world, the provider wanting the information asks for it and the other decides and responds. This process of, I’ll just open the whole system and let you find what you want, probably wasn’t what should have been replicated. This is the client-side focus of the IHE.
Solution – Change from client taking data to host sending data.
Problem – Security Concerns with Synchronous query using web services
XDS registry/repository web services based HIEs are protected by a fabric of trust that ties to a public key infrastructure and the protection of a private key identifying a trusted endpoint (Other HIE, SaaS EHR implementation, hospital, etc). If a private key identifying such a trading partner is stolen, the person who stole it can essentially pretend to be the organization that uses it. In a synchronous query environment, this is hard to detect. After all, the query is coming from what you identified as a proper trusted endpoint. The results of the query are returned on the same transaction as the request.
Solution – Direct Transport Protocol
In an asynchronous implementation of XDS, such as by using Direct as the transport, this is improved because the information would be sent back to the known address of the endpoint, not just encrypted to the key of the endpoint. So, someone would have to steal the endpoint address (domain name most likely). This would be more readily noticed by the endpoint as they would not be able to communicate with anyone over this transport any longer.
Another benefit of Direct as transport is that it is far more prevalent than IHE web services as it is the required transport for Meaningful Use (MU) stage 2 that began on April 1, 2014.
Summary of Benefits
I believe Targeted DAF can produce a superior form of HIE by which not only are records accessible from all whom have data based on a signed consent form that overcomes specific release requirements, but also serves other business relationships between organizations, such a population health management between ACOs and their network of providers. It represents the real world of exchange and provides greater security protection. When combined with Data Segmentation for Privacy (DS4P), it can provide a privacy-limited exchange when specific release and business relationships are lacking but the provider requesting the data is treating the patient and supplying information in such case is allowed by HIPAA. This real-world-view of “push me a request”; “I’ll evaluate it and push you a response”; has fewer limitations than true PULL from my records systems that impose greater restrictions for that reason – they are a take not a request. It can even work across state boundaries as it does in the phone/paper/fax world today with the responder evaluating the request under applicable law.
On the March 19th DAF “All Hands” call, Direct was discussed as a choice for transport for targeted DAF. ONC committed to sending out an interest letter to all committed members of DAF to launch an implementations workgroup for Direct based DAF on the March 26th “All Hands” call. My organization, HIXNY, is already planning to take part in this implementation workgroup.
On March 31st ONC announced that the DAF/IHE White Paper Now Available for Public Comment and it is available for download at http://www.ihe.net/Public_Comment/#pcc. Comments can be submitted through the online form located here http://www.ihe.net/PCC_Public_Comments/.
The IHE white paper is not necessarily all encompassing of DAF at this point as IHE doesn’t have a single transaction that will support requesting a document on a patient by describing the document and describing the patient rather than doing multiple transactions to identify the patient and the document and then finally requesting it. This is work that is still required to simplify the service and any comments supporting simplification could drive more resources towards that goal.
Call to Action
I encourage any EHR, HIE, or other party that is interested to join us in the implementation workgroup for Direct protocol for Targeted Data Access. Together we will overcome the artificial boundaries of HIE. If you would like to participate in this SWG, please e-mail Gayathri Jayawardena at Gayathri.Jayawardena@esacinc.com with your contact information.