How exciting it is to think about all the solutions being developed for the healthcare industry! The use of technology for measuring patients’ health, setting appointments, setting medication and improving patient’s overall experience are just a few examples of that.

However, to make all these improvements come true, healthcare vendors (technology developers) and healthcare providers have to overcome one significant barrier: to integrate their systems so patient data may be securely accessed and processed by these new applications.

Redox is a startup from United States that is focusing exactly on facilitating this integration, through a platform that serves as an effective interface, providing accurate data transfer between different systems in an easier and faster way.

In this 15th episode, Niko Skievaski told me about the development of Redox and how it evolved from just an idea into a platform that connects more than 450 health systems

SHOW NOTES

CONNECTING TWO WORLDS

Tell us what is the problem that you are solving for healthcare vendors and healthcare providers?

It is a kind of deep systemic problem. For sure, in the United States—as well as I imagine around the world—one of the main barriers to technology adoption within the healthcare space is the inability for new software being built in the cloud for consumers on their phones to actually exchange data with the health systems that they work with.

Because for the most part, healthcare organizations who are treating patients, have electronic medical records that were really never designed to talk to the internet.

What Redox does is connect these two worlds by taking data out of health systems and standardizing it in the cloud, and then making it available over an API for software developers to use.

On the software developer side, they can connect to us once and work with any of the health systems that are on our network—or that they bring into the network.

And on the health system side, they can connect to Redox and work with any of the applications that they might want to utilize into. These are all sorts of different types of digital health applications—things like telehealth solutions, remote patient monitoring.

Because for the most part, healthcare organizations who are treating patients, have electronic medical records that were really never designed to talk to the internet.

How did the idea come to your mind?

My background was coming out of the electronic health record world. I worked at a company called Epic—which is a very large electronic health record vendor—and really started to learn and understand the way that the software was being used across the industry.

It was there where I also met my co-founders who worked in various parts of the organization and understood both the business and technical aspects of working with electronic health records.

After leaving Epic—in 2013—I actually started a different healthcare IT Company, and started to see first-hand the challenges of being an entrepreneur developing a digital health solution for health systems.

Through that experience, we went through a number of pivots between that company and then eventually started a co-working space and an incubator focused on health tech.

We saw over and over again, how digital health companies were running into this barrier of willing to connect up to the health systems and their electronic health records.

Redox ecosystem. — Source: https://www.redoxengine.com/company/

It was through that process where I and my co-founder started to realize: “Hey, the biggest problem here is not the development of new innovation in the space, it’s the adoption of it. If we can actually break down this integration barrier, then it can really accelerate the technology adoption across the industry.” […]

THE MINIMUM VIABLE PRODUCT

Right after we realized that this is a problem we’re solving, we said: “We have to go out and get initial traction because we are running out of money.” We were using our own savings and we knew that we would need to raise money to start a network business like this. So, we said: “Okay. We need to raise money pretty quickly, but we don’t think that we can actually get live with our product to get real traction.”

So, essentially, we designed a minimum viable product that would allow us to test the market demand and see if there’s demand out there. We literally called up startups in the health tech space, we went on to accelerators, websites like Ycombinator, TechStars, Dreamit, Blueprint Health, Rock Health and a bunch of these kinds of healthcare-specific accelerators.

So, essentially, we designed a minimum viable product that would allow us to test the market demand and see if there’s demand out there.

We just started calling those companies and saying: “Hey, we came out of electronic health record world, we want to figure out a way to help you integrate more easily with an API, would you be interested?”

And we got amazing hit rates. We had CTOs calling us back had a product type folks reaching out to us and saying: “Yeah, we would love to use that solution. What does it look like? How do I use it? How much do I pay?”

THE BOTTOM RUNG

At that time, did you have anything?

No, we had nothing. We had a PowerPoint deck. But we did have specialized knowledge of the way that it works from our background coming out of Epic.

So, that was the bottom rung of the traction ladder—just understanding that this was a problem worth solving. And very busy people, technical co-founders of companies were willing to call us and talk about it.

So, that was the bottom rung of the traction ladder—just understanding that this was a problem worth solving.

Through those conversations, we started to understand the specifics of the use cases here—what data needs to be exchanged, how the workflows need to work—and that’s what helped us start to design our API.

The next stage that we moved on to was going deeper: “Can we monetize simply one side of the network? We know we can’t get both sides simultaneously because the product isn’t there yet. But can we get the vendors, the software developers to pay for something?”

We created an API and we put a pay-wall around the documentation of how it would work. So, we essentially charged people—it was something like $50 a month—just to look at the documentation of how the API would work. And that told us that it was such a problem that people were willing to pay just a little good documentation, which is kind of a head-scratcher, right?

Because the only value that they were getting was confidence that they could go to the health system they...