Rather than go into the details of our discussion, let's work with another example more relevant to you:
Is it realistic to believe that a provider would be able to connect his or her system to any other provider in the US, and be able to query that system for patient data, get it back in a semantically interoperable way, and then be able to use it? Would you like to work on that use case?
I wouldn't. Not in a one year project, or even a two year project. This is more like a three to five year effort, and you have to develop it in stages that bring significant value in each stage. Here is one way to break it down:
- Agree on an interoperable data format for exchange of data.
- Agree on a common transport of that same data.
- Enable some mechanism that allows you to securely identify healthcare providers and find them.
- Enable individuals to authorize applications they control to access the data that they have a right to access. To simplify in this step, you might ignore the distinction between proxies for an individual and the individual, treating them as the "same case" for most intents and purposes.
- Add to the previous step the ability to deal with distinctions, and support also the concept of limited rights.
- Be able at some point to have an individual give to some other person or organization something that grants them some sort of limited right.
- Let that other person or organization be another healthcare provider.
These step together will take a lot of time. Let's go back and identify the activities associated with these various stages:
- CCD and then C-CDA, eventually moving to something better (e.g., FHIR)
- NwHIN Exchange, NwHIN Direct, ABBI Pull
- Direct Certificates
- OAuth 2.0/IHE IUA and HL7 FHIR XDS Entry w/ IHE MHD using CCD/C-CDA
- More on OAuth 2.0/IUA, possibly with IHE BPPC or HL7 Consent Documents or their successors
- IHE BPPC or HL7 Consent Documents or successors, possibly including Digital Signatures (e.g., IHE DSG)
- Done
The impact can be great, but you have to allow for the proper staging. Nobody every planned on using connections originally designed to support teletypes and terminals to handle web traffic, but eventually we got there. If we had started with the idea that we were going to build the web, we'd probably still be working on it.
Would it be better to try for a laser like approach? I don't think so. I cannot think of a single example where that ever worked.
Having a way to do something, and actually doing it, are two entirely different things.
ReplyDeleteWhile I don't disagree that it is definitely possible for us to eventually enable such "drive-by interoperability", at the end of the day it will still only happen if vendors let it happen.
TJL
I assume this ties to the Data Access Framework (DAF). On a pure peer to peer basis for both technology and policy, you are right, it will take a while. However, we can iterate to that. The best initial integration of DAF will be as a means to query a centralized RHIO HIE. And, Direct for Transition of Care will be the way to trigger sending data to the RHIO HIE for others to query for. The RHIO has the largest problem, policy, at least mostly solved. DAF then starts as a way to lift vendors who do not have other means of integrating (e.g. web services) to integrate. The RHIO also solves the problem of finding who to query, just query the RHIO, they have or will get the data from all sources for the reply.
ReplyDeleteMaybe peer to peer will take off in markets where the RHIO HIE is less established. But the best place for this to start is with Practice to RHIO for EMR vendors that will have Direct for MU2 but nothing else. See my posts on the same.
http://www.directhisp.com/2013/06/data-access-framework-seamless.html
Joel