Redox and The Future Of Integrations

TL:DR 

Redox makes it easy for companies to integrate with hospitals and health systems by creating a standardized API that enables developers to move data in and out of EMRs so they don’t have to have that expertise in-house. 

The company is aiming to build out more “integrations-as-a-service” products in other parts of healthcare. The future of Redox will be dependent on how successfully it can execute in those new product lines and also how Redox interacts with new cloud service providers that are entering the space. 

Read more below.

This is a sponsored post - you can read more about my rules/thoughts on sponsored posts here. If you’re interested in having a sponsored post done, email nikhil@outofpocket.health.

Company Name - Redox

Redox is a company that builds and maintains integrations into the EHRs of hospitals so you can pull-push data, messages, etc. between your third-party application and their workflow. 

The company is named after a reduction-oxidation (redox) reaction. In a redox reaction, there’s a transfer of electrons and I guess that’s sort of like what healthcare data is doing here. Idk I failed chemistry and my imagination doesn’t stretch very far. I sort of think they just found a word with an “x” in it that sounded cool, ran with it with the idea that they’d change the name later, and now it’s been like 7 years and they’re just rolling with it.

The company was founded by Luke Bonney, Niko Skievaski, and James Lloyd and has raised a total of $95M from Adams Street Partners, RRE Ventures, .406 Ventures, and Battery Ventures.

What pain points do they solve?

I’m actually very glad I got to write this post cause when I was first getting into healthcare everyone was like “oh yeah Redox this, Redox that, yada yada yada” and I would just awkwardly nod and smile while saying words like “integration” and “HL7” lots of times so people thought I knew what they were talking about. Now I know a little more and can hopefully explain this seemingly boring but important piece of healthcare to you!

For people selling to hospitals and health systems, you might think that once you’ve closed the sale it’s smooth sailing. Lol. Lmao.

Once the sale is complete, you need to figure out a way to actually get data out of the hospital’s EMR, push data back into their EMR + create rules to govern when that’s done and where the data goes, ensure you’re mapping to their correct data format, create monitoring systems for the data pipeline to alert if things aren’t flowing, etc. This is colloquially called an “integration”, and it colloquially feels like a hemorrhoid.

There are actually two paths to doing this. One is you go to the company that provides EMRs, you go through their version of an application review, and then show up in the EMR app store. This will reduce the time to go live at each hospital by pushing the security review + app test upfront. However the EMRs will charge a sizable take rate, there are still hospital-level specifics you need to deal with (which the EMRs might charge you more for), and some companies find the requirements EMRs impose for their reviews to be egregious. Anecdotally it seems like few companies take this path and the actual efficiency gains from the upfront review are questionable.

The second path is that you go hospital by hospital and do the integration one by one. This means you’re going through a hospital’s review instead of the EMRs. The good news is that there aren’t take rates + you’re beholden to the rules of the hospital, which many health apps find preferable compared to the rules of the EHR vendors since they’re more aligned with the hospital on end goals.

There are several annoying problems with this if you’re a company trying to integrate with a health system:

• Each company now has to have an engineer that knows integrations AND each EMR has its own idiosyncrasies to know, so you might need multiple with niche expertise. Specifically, most hospitals are still on a data standard called HL7v2 if they use popular EMRs like Epic and Cerner. This standard is very customizable but more customization means more site by site variance in how you integrate. On top of that, other popular EMR vendors like Athena, AdvancedMD and Allscripts have their own proprietary APIs that are totally different.
• It takes forever to set up, especially if a company or a health system was new to doing this. This includes getting internal buy-in at hospital IT departments and navigating weird politics within organizations.
• It’s now the job of the company to actually maintain and monitor that integration, when the company is trying to do a million other things instead.
  

At a certain point the question was raised - for all of these companies integrating with the same health systems, why are they each doing one-off integrations?

What does the company do?

Redox makes it much easier for you to integrate with hospitals by doing a much messier integration with hospitals ahead of you and then exposing a cleaner, standard API that you can plug-into. Redox is a combination of the suite of APIs as well as expertise-as-a-service that know integrations and hospital dynamics inside and out to maintain + monitor those integrations. 

For health systems/EHRs that Redox already integrated with, they can basically flip on an existing switch. For new integrations, they’ll go in and map everything to their data model, which might take a bit longer but it’ll still be faster than you integrating yourself because, well, they’ve done it a million times before. They take all the nasty alphabet soup in the back end like HL7v2, FHIR, X12, CDA, etc. and turn it into a JSON-based API, a structure that engineers outside of healthcare would be familiar with. The API is FHIR compliant and the API documentation is public. It’s even readable to someone like me who’s failed 3 coding bootcamps (I’ll get it next time I swear).

Once you’re ready to connect with a health system, you go through a bunch of tests and validations between your application and the health system. Below is an approximate timeline of what you can expect doing it through Redox. 

The extremely dumbed down version (I’m incapable of any other version) is that Redox:

1. Creates a testing environment that’s separate from the actual EHR
2. Redox then maps to the data model that the health system uses. There is a ton of variance here and Redox does a lot of upfront work to do this the first time.
3. Redox then maps the standard JSON-based API to the hospital's data model. This now means figuring out how “messages” (which carry the data) actually get passed between the EHR <> application and configures those messages based on the specifics of both systems. Each hospital works a little differently here.
4. Sends a sample message between the two to make sure it’s all gucci
5. If it works, sets up the live system to make sure it still works when the messages get sent back and forth there
6. Creates monitoring solutions to make sure alerts get sent if something changes (but not if ANYTHING changes, that’s too many notifications)
7. Everyone cries. A lone trumpet plays in the distance and the birds start chirping again. (Actually Redox sent a pizza party to customers for their first integration. RIP offices.)
   

Once you’re fully integrated, here are just some of the things your application can do:

• Locate patient identifiers
• Stay up-to-date on provider info
• Query and receive appointments
• Direct appointment scheduling
• Provide wait time estimates
• Receive patient summary
• Seize the means of production
• Receive real-time patient data
• Share visit documentation
• Complete triage and intake
• Create a new patient
• Initiate billing activities
• Stay up-to-date on patient demographics and insurance
  

The key part here is that this allows the EMR to remain the main interface that a clinician deals with, with the information/data getting ported in and out as necessary via Redox’s pipes. Realistically it’s hard to get people in the hospital to look at a separate interface just for your application, so being able to post data into an interface they’re already looking at (their EMR) reduces friction enormously.

You can see all the places Redox is already integrated with here. In terms of providers, it skews larger since those providers tend to work with many vendors, but if someone isn’t on the list, Redox will let you know if they can do an integration on your behalf or not. General stats on the current network they’re integrated with:

• 1 billion messages (aka. data packets) per quarter. These messages are delivered across 1,700+ organizations that deliver care
• All of the US News and Reports top hospitals
• Carequality and CommonWell Networks 
• 300 independent healthcare product companies 
• 90% of Public Health Departments
• 65% of the top 150 health systems
• And the real integrations, which were the friends we made along the way
  

‍

What is the business model and who is the end user?

The end user is third-party healthcare applications that want to work with hospitals are the target audience.

Redox has lots of case studies about working with everything from patient-reported outcomes companies to concierge services that guide patients through surgeries and how Redox helped connect them to hospitals. If you’re thinking about an integration partner to get into a health system, there’s a good chance Redox has worked with a company like yours.

Their pricing page is public, with four separate tiers that give you increasingly more services the higher you go. There is a flat fee to access the platform and then a fee per connection (there’s bundled pricing if you need lots of connections).

One nifty thing is that their platform is now available through the AWS marketplace. This basically means that developers already using AWS can buy Redox through AWS billing, which is simpler for a lot of orgs that don’t want to manage several separate vendor relationships. You’d be surprised how big of an issue this is.

Job Openings

Redox is hiring for a ton of positions, you should check them out here!

___

Out-Of-Pocket Take

Have you ever tried moving between apartments/houses by yourself? And then you finally hire movers one day and realize they do it 5x as fast as you, have all sorts of crazy tools and techniques to get the job done, and you should have never attempted doing it yourself because it’s 100% worth the money and now your back is permanently f***ed because of your hubris?

Redox is the hospital integration version of that. I’m in the camp that companies should focus on their core competencies, and Redox makes that easier by outsourcing the integration competency to them. 

Some things I like about Redox:

Standardization of process - One of my investing theses is that healthcare has leaned too hard on allowing service providers to build custom solutions, and instead we need to figure out ways to standardize processes to make it easier for small companies to plug-in and get distribution easily. Redox is a great example of that by standardizing the process of integrations and the JSON-based API.

Specialization of expertise + leaning into services - As I said earlier, Redox allows health systems and startups to outsource expertise to Redox instead of building it themselves. One key benefit of this is that Redox can build more “metaservice” products that enhance the integration itself beyond just the bare minimum of “does this integration work”. For example, Redox usually knows when a VPN box is down, or that a health system has introduced new data fields that are now populating the third-party app, etc. and can proactively alert the health system of a change. The outsourcing of expertise also means that Redox can guide health systems thinking about adding new capabilities, and they’re incentivized to try and standardize those workflows across the health systems. For example, here’s Redox’s standardized workflow for a telehealth deployment that goes through how scheduling would work, how post-visit documentation enters the EMR, etc. 

‍

Old school + new school - As I said previously, Redox has specialized in an older data standard called HL7v2 that all hospitals are still currently built on top of. The reality is that many of these hospitals aren’t going anywhere, so Redox has very valuable footing by being the expert in dealing with this standard. As we move into a world of FHIR, a new data standard that’s more flexible to build APIs on top of, Redox is positioning themselves as that bridge between worlds. They also have a product that lets startups ingest patient health records through Carequality and CommonWell, health information exchanges which use FHIR-based APIs. 

In addition to specializing in the old school health system world, Redox has begun working with a new class of virtual care delivery companies. You know, the ones that raise $50M+ every other day.  Many of them are trying to functionally reimagine the EMR, but when they need to get data out of the traditional healthcare data channels for things like patient histories, they can use Redox.

So if you’re a digital health startup, you can theoretically integrate into the workflow of a specific hospital via Redox and also pull in the contextual health records about the patient from other hospitals through their Carequality/CommonWell product. I’ve talked more in-depth about how this works in the past. 

Here are some questions I’d have about a company like Redox.

The market size + new products - The market for HL7v2 based integrations is probably not growing a ton, though it’s still the only way to push data into EHRs (FHIR can’t do that yet). Redox is still not integrated with every provider in this market + has plans to expand internationally, so there’s still room to grow here but the general market is probably not growing as fast. 

Redox is pretty self-aware about this and is releasing new products to get into new markets. 

• They have a product that helps providers using HL7v2 comply with the new interoperability rules and expose their data via a FHIR-based API.
• They’re entering the market to make it easier for startups to integrate with payers. In the near future payers are also going to have to share data to third-parties and to other payers thanks to new interoperability rules targeting payers that go into effect in the next few years. Redox wants to position themselves as the integration partner of choice to make it easy for payers to work with small companies.
• Their long-term goal is to eventually be able to take all these disparate data sets that exist within these different entities in the healthcare system and make it easy for a patient to directly give authorization to transfer data between one and the other.
  

These are big markets with many competitors entering the fray. Redox is in a lot of ways well positioned by having the integration talent in one place and a strong brand name for doing integrations, but I do wonder if the need to maintain and expand their current footprint in the HL7v2 universe will make it more difficult for them to dive headfirst into these other areas. Time will tell!

The entrance of cloud service providers - Companies like Health Catalyst, Google Cloud, Azure, etc. are coming into the integration market a bit orthogonally. These companies help providers move their data from on-premise storage to cloud-based storage so that the providers can do fun stuff with cloud-powered tools like population health analyses, checking to see if they’re using their operating rooms efficiently, and generally making it easier to search through/analyze the data. 

One byproduct of this process is structuring the data and making it easy for third-party cloud-based tools to plug-in and work with that data as well if the hospital approves. Healthcare applications could find it easier to integrate with the cloud service providers instead of using an integration like Redox to integrate with the EMRs directly.

Redox has a pretty big head start here + it presents a more neutral integration option since many of these cloud service providers are also trying to build their own analytics tools on top of it. It’s always dicey to build in someone else’s sandbox if you think they might build a competitive application to yours. 

Plus a lot of the cloud service vendors need to figure out ways to actually transform the data and get it into their cloud in the first place. Redox is actually working with AWS HealthLake to do this. Different cloud vendors will choose different approaches/vendors to do this, but Redox does have the expertise to be a useful partner here.

It’ll be interesting to see where third-party apps flock to as the cloud wars heat up.

---

All in all Redox seems like it’s at a pretty big juncture in its product roadmap and has raised this new funding round to become the start building the integration engine for payers, providers, and digital health startups for any data that needs to pass between them. Creating an easy way for companies to integrate with other older school healthcare entities is critical for having a thriving health startup ecosystem, and Redox has leaned into that specialization. If you need to integrate with someone, I would definitely see if it makes sense to do it through Redox instead of trying to do it yourself.

As a side note, I admire how public Redox is with its documentation, network size, pricing, and more. Most healthcare companies give you a huge run around to figure this out or even worse, charge to be able to access their documentation. It’s refreshing that you can find most of this on Redox’s site.

Thinkboi out,

Nikhil aka. “who’s building the Redox but for my heart?”

Twitter: @nikillinit

IG: @outofpockethealth

---

{{sub-form}}

‍If you’re enjoying the newsletter, do me a solid and shoot this over to a friend or healthcare slack channel and tell them to sign up. The line between unemployment and founder of a startup is traction and whether your parents believe you have a job.‍