5. Delivery -- Via the directory, we know to whom (or to what location) we want to send a notification, message, fetch request, or record, but how will it get there? With literally hundreds of different EHR products in use and as many interoperability challenges, it is clear that a disruptive national solution must accommodate multiple technologies depending on sender and recipient capabilities. Until now, the only delivery "technology" that has ensured reliable delivery rates is the mighty fax machine.
With the potential of a large hospital at one end and a remote single-doctor practice at the other, it would be unreasonable to take a one size fits all approach. The system should also serve as a useful "middleman" to help different parties move to the model (in much the same way that ripping CDs or iTunes gave a helping hand to new MP3 owners). Such a delivery "middleman" should automatically adapt communications to each end of the communication's technology capabilities, needs, and preferences..
6. Embracing Push -- To be honest, I think we got complacent in healthcare about how we designed our technologies. Most interoperability attempts are "fetch" oriented, relying on someone pulling data from a big repository such as an EHR portal or an HIE. Then we set up triggers (such as ADTs) to tell someone to get it. These have not worked at scale in 30+ years of trying. Among other reasons, it has been common for even hospitals to be reluctant to participate fully, fearing a competitive disadvantage if they make data available for all of their patients.
My vision for a disruptive and innovative interoperability system reduces the current reliance on fetch. Why not enable reliable, proactive pushing of the right information in a timely fashion on a patient-by-patient basis? The ideal system would be driven by push, but include fetch when needed. Leverage the excellent deployment of the Direct Trust protocol already in place, supplement it with a directory and delivery service, add new digital "middleman," and complement it with an excellent fetch capability to fill in any gaps and enable bi-directional flows.
7. Patient Records and Messages -- We need both data sharing and messaging in the same system, so we can embrace and effortlessly enable both clinical summaries and notes. There must be no practical limits on the size or types of files that can easily be shared. We need to help people solve problems together and drive everyday workflows. These are all variations of the same problem, and the disruptor needs to solve it all.
