For those of you following our journey these past few years, you might be wondering how the recently announced partnership with Brigham Health fits into our developer-first approach to interoperability. I want to spend a few minutes to share where this journey has taken us and how this developing strategy fits into our vision for the future of health tech.
We started Redox to help software developers get their products into the hands of patients and providers faster. As such, we spend our time focusing on building a platform we hope healthcare developers love. And in return, the healthcare developer community has built inspiring (and dare I say) life-saving products utilizing the platform. You’ve sold and deployed at hundreds of health systems while dragging us along for the ride. The innovation you’re bringing to market is what gets us up in the morning. It’s why we do what we do.
For the most part, I see this current wave of adoption as the second coming of technology solutions in healthcare (the first wave being what we affectionately refer to as legacy HIT systems, the tools in the data center managed by IT). The first wave ended with Meaningful Use and was really responsible for moving workflows off clipboards and into databases.
In contrast, the second wave is in the cloud. It’s SaaS. Solutions here assume the information is digital and ask “So what? What’s next?” Applications are lightweight and don’t require implementation projects or IT support. We’ve taken a look at how these apps are adopted by the health systems they were made for and have learned a few things that I believe further describe this second wave:
Selling to health systems is really difficult. As such…
- We’ve seen entrepreneurs with huge vision shrink into product offerings that can slide in under a budget or under the radar. Most don’t get the opportunity to climb back up to that big vision and end up selling a product that only brings incremental change for a specific department or disease state. In health tech, disruption too often takes a back seat to a little bit of traction.
- Technology adoption is driven by strategy. Most of the tools we see being deployed fit into some strategic initiative put forth by health system leadership. Sales cycles play out with a clinical champion who needs to become an internal advocate, putting her social capital on the line to help the software solution navigate bureaucratic landmines while building a business case under one of these strategies.
- Software is too expensive because of long sales cycles. If it’s going to take two years of relationship building to get the contract signed, that contract better be worth it. CAC>LTV. As customer acquisition costs rise, the lifetime value better cover it. So deals are in the six figures. (And, even if this is dwarfed by the price of the first wave, it’s still outrageous.) Higher price tags mean more risk aversion and even longer sales cycles.
The good news here is that we’ve seen some health systems recognize these challenges and start to do something about it. They know they won’t be able to move the needle if they can’t figure out how to efficiently adopt technology that will bring transformative change. The shift to value-based care is applying further pressure to innovate. Taking on risk means efficiency is the name of the game. And as patients shop, differentiating by creating delightful (and often tech-enabled) experiences is becoming key to keeping patients engaged and within the network.
So what does wave three look like? I think that’s what we’re seeing the beginning of right now. Many health systems have launched innovation teams whose charter isn’t necessarily to seek tech to fit under a known top-down strategic initiative. Rather, they seek technology that will help move the needle, regardless. They’re figuring out how to rapidly adopt these solutions, while measuring outcomes and scaling when it makes sense. The RFP is being thrown out the window. They’re imagining how to move these decisions down from the centralize gauntlet of committees to the end user, or—better yet—the patient.
I’ve spent a lot of time in the past months talking to health systems about how they’re looking at these wave-two challenges. We’ve talked with groups who have two-year backlogs of interface projects holding back new solutions from being deployed. While this might be an edge case, it’s representative of the integration status quo at many health systems. We think it’s an unacceptable barrier holding our industry back from the gains we know technology will bring.
Brigham inspired us from day one. They’re on a mission to transform the patient experience while leveraging the best tools on the market to drive efficiency. What does the partnership mean for you? If you’re an application working with Brigham, you should expect a streamlined process complete with the modern Redox API experience you’re already comfortable with. And it won’t cost you a dime.
For us, this is a fundamental shift in the interoperability landscape. Applications already leverage Redox to connect to any health system and any EHR. As our network has grown, we’ve seen this process accelerate as apps deploy at health systems we’re already plugged into. Brigham took this a step further from the other side of our network. It isn’t enough for an EHR or a health system to have an API. That’s only incremental improvement. The API needs to be ubiquitous across health systems and EHRs while connecting a network of applications. That’s where we come in.
This is how interoperability can and should be used to scale digital transformation in healthcare.