Redox has been on this interoperability journey for a few years now. Today, we announced that we closed our Series B round led by our new partners at RRE Ventures. Raising outside capital forces an organization to convey a vision for the way the world should be and show considerable progress towards making that vision a reality. I’d like to share a bit of that vision and progress here today.
(If you’re more of a visual learner, view the webinar from 2/2. I talked through this stuff and answered questions live with James.)
Here: The status quo
How did we arrive here? It’s estimated that as much as a third of expenditures in healthcare are waste, and we spend nearly 20% of GDP on healthcare. This is a huge bullseye for efficiency gains that computers and the internet have brought to nearly every other industry. But our status quo is in the early technology adopted—it’s in the pagers, fax machines, dumb clients, and servers cooled in the basement. It’s in the habits of entrenched providers picked up decades earlier in medical school before the adoption of technology-enabled healthcare. This is the canvas innovation has to work with.
The new technology is out there, but our industry has an adoption problem. Redox exists to accelerate technology adoption in healthcare. Here’s how we’ve seen healthcare organizations evolve over the past few years.
Step 1: Strategic technology adoption
Healthcare administrators are feeling pressured as their costs of delivering care rise while revenues drop. As such, leadership is actively looking for technology solutions to empower strategic initiatives within their organization:
- Deliver care more efficiently – use telehealth, improve care coordination across teams, allow providers to deliver care at the top of their licenses, utilize skilled nursing facilities, etc.
- Replace high-cost events with low-cost intervention – reduction of hospital acquired infection, prevent readmissions, monitor patients remotely, identify opportunities for prevention, divert emergency care to outpatient or urgent care, etc.
Today, there are hundreds of technology solutions on the market attempting to solve these problems. The current class of interoperability solutions attempt to connect these software solutions directly to the health system’s legacy electronic health record.
This is where we’ve built our current business model. The applications we connect are chosen strategically by healthcare leadership. The goal for the apps and health systems we connect are to transmit data from A to B. They don’t care that we do this through a centralized network.
In fact, we’ve been asked by both to tear down the network in exchange for a silo of control:
We’ve been asked to put the engine within the walls of the health system where it will only work as an endpoint for the subset of applications that health system has chosen to work with. It’s then that we’re compared to legacy interface engines or API management companies because, if we did this, that’s what we’d be.
We’ve been asked to silo the engine for the application side, where it will only work for health systems the application can sell to. This is when we’re compared to startups on the market who service these vendors through managed point-to-point solutions. This only solves the problem for A and B and A to C, not C to B—not for an industry. In fact, it exacerbates the interoperability problem by rebuilding the wheel each time. This is inefficient and unacceptable.
Each time we’ve said “no.”
Networked interoperability
All applications and health systems connected to Redox are on the same network using the same data models. As such, all apps and health systems are technically interoperable. As our network has grown we’ve seen tremendous efficiency gains as one health system turns on multiple applications, and as one application integrates with multiple health systems through the exact same infrastructure. This is what we call networked interoperability.
Our network is growing. Around 2k digital health applications have Redox developer accounts to build integrations on the network. We’re exchanging production data with health systems from coast to coast and in the EU, using three dozen different EHR vendors. Our production message volume is nearing a million clinical messages per day.
Step 2: Innovation as a strategy
We’re inspired by the health systems who have begun looking beyond their known opportunities to the innovation space as a whole. They’re asking what technology is being developed that they’re not looking for yet? What should we try? How can we move beyond efficiency to efficacy through controlled experimentation?
Typically, these organizations were early adopters of the EHR and have already had numerous successes with strategic technology adoption. They’ve begun to understand that a standardized application integration layer on top of their existing infrastructure is necessary to rapidly pilot and deploy solutions.
The earliest adopters of this built their own API layers on top of data warehouses or their EHR directly. Some companies have sprouted up to provide the API management tools for IT teams to do this more efficiently. But these solutions only reduce the effort for the IT team. The innovations still need to integrate with that specific health system’s API specs. This only brings incremental improvement to technology adoption.
Redox has been pulled into working with many of these innovative healthcare organizations. We describe how a single connection to Redox can be used to deploy applications on the network with increasing efficiency. And hundreds of applications are already connected, ready for production.
In fact, most of these innovative health systems are identified by our application partners who believe in this vision. These applications are being adopted strategically, but are dragging us along. I think this says something about health tech entrepreneurs: beyond growing our own enterprises, we believe in the bigger mission here. Technology can enable healthcare delivery in ways we’ve yet to conceive. These are the seeds of cultural change planted by the efforts of the pioneers in health tech.
Step 3: Distributed technology adoption
Innovation teams must be collaborators. They might be the top of the funnel, but they necessarily have to work with departments, providers, and patients to bring new technology into the healthcare delivery organization. In a steady state, technology adoption decisions should be as close to the end user as possible.
As long as the data securely syncs up to the organizational source-of-truth, it only makes sense that an end user chooses the technology appropriate to support her unique workflow, preferences, and style. Akin to the bring-your-own-device movement, in some circumstances a bring-your-own-app model will start to take shape. In a simplified example, I choose to use a specific email and calendar app on my phone. But I’m still accessing the same managed email account as my peers who may use whatever apps they please to interact with it.
A family practice might feel that Orb Health makes sense to check in with patients remotely. An orthopedic surgeon, might choose to deploy CODE Technology to gather outcomes of her joint replacement patients. A PT department might deploy Breg’s point-of-sale system to help streamline DME inventory. Oncology might use Carevive’s survivorship plans on certain patients. The point here is, the choice to adopt technology doesn’t have to be centralized at the executive level. Once a secure application layer is in place, apps can more freely be used, or not.
Step 4: Patient-centered interoperability
The common thread in any interoperability use case is the patient. She is the one moving between specialists, being admitted to the hospital, and attempting to engage in her care. As such, true interoperability will not be achieved until her clinical data follows her effortlessly. This is patient-centered interoperability and it’s sadly missing from the typical discussion in our industry.
It requires seamless connectivity of source and destination systems. Moreover, the patient will need to be able to authorize access to her data for whomever she deems necessary. Because of the way EHRs were deployed, this is currently impossible. Things need to be networked. Patients, and the applications they’ll use, need a single network to plug into retrieve and utilize clinical data. Redox will become this network.
We can’t start here—with patient centered interoperability. There’s a bit of chicken or egg problem. These applications can’t survive without the network and the network can’t be built on the backs of these patient-controlled apps. It takes the first three stages discussed above to drag the platform along that will eventually be used to let the patient—the rightful owners of these data—actually control it.
So that’s what we’re up to.