Last week, CommonWell hosted our annual Spring Summit with more 120 attendees representing the majority of our 49 members, including representatives from our 11 newest members. One of those members – Redox – participated in the three-date Summit. Niko Skievaski, co-founder and president of Redox, shared his perspective on Tincture about both his vision of tangible interoperability as well as his first month as part of the CommonWell family.
We hope you will take a minute and read about it below.
Drinking from the Commons
By Niko Skievaski, co-founder and president of Redox
Getting to Real-World Interoperability
The “Tragedy of the Commons” describes how farmers sharing common land will over-utilize it until it is useless. It’s an economic fable that illustrates the necessity of property rights and is used as a basis for describing efficiency in capitalism. But this concept breaks down when applied to digital resources. Digital goods are non-rival in that my use of the information does not diminish your ability to use it. This pre-digital relic can help explain the challenges we experience with efficient data availability in healthcare. Some still regard availability of digital clinical information as a viable market barrier, rather than a non-rival commodity.
To me, CommonWell Health Alliance is an attempt to share patient data as a non-rival resource to improve patient care. The Alliance now has 49 members spanning not only EHR vendors, but patient portals, image and lab vendors, government agencies, and even a few API companies. The idea being that we’ll share patient data when it makes sense, and build our businesses regardless. We recently joined CommonWell as a general member, and I had the pleasure of attending the annual summit this week. After getting over the fish-out-of-water feeling any former Epic employee must overcome a major EHR rival, I was taken by the overwhelming amount of opportunity that CommonWell brings.
Networks on Networks
At its core, CommonWell is a network of patients who have opted in to having their data shared between the providers caring for them. The network is enabled by the EHRs used by these providers and powered throw technology developed by CommonWell. Although many of these EHR vendors compete for business every day, at CommonWell they’re collaborating to solve various interoperability use cases. It’s like if Walmart and Target worked to share data about you, because it would improve the consumer experience — competition aside.
In this spirit of collaboration, the topic came up on how to extend this network to other networks to cover more lives. It seems there’s a hundred growing initiatives attempting to unite patient data in the name of i14y: alliances like these, regional HIEs, standards bodies, organizations to standardize the standards, API vendors, the government, etc. I was pleased to see how eager CommonWell members were to find ways to connect these networks. This problem isn’t going to be solved by one organization; we need a cultural shift brought on by our industry’s leaders putting their heads together to figure out what’s right for patients.
I joined the sub-committee tasked with writing this use case. We joined CommonWell to see if and how we could extend it the hundreds of enterprise healthcare software applications connected to our own engine. Could we set up one connection to CommonWell and connect our networks? Similarly, can we write a use case generic enough to enable other networks to do the same? I believe we can.
Consumer Controlled Applications
I’ve written about it before: the patient has to be the broker of her data. That’s not a very controversial statement. However, there’s not currently an efficient way to enable this. We see patients attempt to broker their clinical histories with binders of printouts, macro enabled spreadsheets, and file boxes toted between appointments with their health at stake. We’ve even seen app vendors attempt to resolve this by giving patients databases with an assortment of superior functionality. But the patient health record (PHR) has failed time and time again. The conventional wisdom is that patients aren’t engaged enough for general purpose PHRs. I think that’s crap.
Patients, like every other human being, attempt to avoid data entry at all costs. This is why patient-authorized API access to their clinical data is so important. If a patient could easily authorize the PHR of her choice to access data from all of her providers, we would use them. And we would easily share data logged in that PHR with anyone we want. We would be the broker. Beyond storage and display, applications will be developed with much more engaging and important functionality that will better inform and motivate patients to prevent illness and take better care of themselves.
In a room full of EHR vendors, these thoughts were surprisingly met with smiles. I say this because I’ve talked to many vendors who harbor fears that small apps smell of a best-of-breed world that belittles the monolithic health information system at the core of their business model. But at CommonWell, it seems that these unspoken market forces are replaced with hypotheses of what’s right for patients. We rallied enough support to form yet another sub committee to define the use case.
That makes two. I’m not usually a committee meeting kind of guy as it seems they usually spend an extraordinary amount of time writing verbose recommendations then expect the rest of us to make it happen. My optimism here comes from the fact that, if permitted, entrepreneurs will build it. We have to. The opportunity is too great.