Redox

We’re chatting about Redox and how it’s used at your company. Before we jump into that, could you give a brief overview of the company and your role there?

We are a remote patient monitoring and patient engagement tool. Our main customers are large health systems, and so how we play into their integrations strategy and broader digital health strategies is crucial. Initially, when we were building our product, we realized that building and maintaining HL7 or FHIR integrations on our own would not be feasible. That’s why we turned to Redox for their expertise in this area.

I used to work as the integrations product manager for the company, where my main focus was on integrating with health systems, finding the best ways to integrate our tool with their existing electronic health record (EHR) systems and developing new workflows based on those systems. Additionally, since we didn’t have a dedicated implementations team, I also took on the responsibility of ensuring that the integrations were implemented successfully. Sometimes the technical aspects of the integrations were too complex for our client success team to handle, so our product team stepped in to assist. We worked closely with Redox’s support teams and implementation managers to ensure smooth implementation.

How long have you been using Redox?

Since 2016.

What led you to look into purchasing Redox?

Our target customers were large health systems which have extensive IT teams and use various digital tools. When selling our product, the patient engagement side was always well received. However, integrating with their existing EHR and tools was a challenge. We realized that integrating with health systems had to be a crucial part of our product strategy, but we didn’t want to build a dedicated integration engineering team at that time. So we needed a tool like Redox to help us standardize and streamline the integration process for SIU, ADT, ORU, and MDM across different health systems. Redox’s reputation, customer support, and compatibility with various EHR systems, as well as their existing footprint with health systems we were targeting moved them to the top of our list.

What is Redox, and how does it help you solve the integration challenge?

Redox essentially normalizes HL7 pipelines by converting them into JSON or any other format you prefer. This means that, regardless of the type of EHR being used, Allscripts, Epic, MedEvolve, etc., you can expect the same data model on your end. This allows for the implementation of the same workflows across different EHR systems.

One specific feature we focused on was surgical scheduling. It was crucial for us to track when surgery was scheduled for our patients and when the surgeries were happening. Having a reliable SIU interface was a top priority for our organization. However, implementing SIU feeds can vary greatly depending on the EHR being used, particularly the smaller ambulatory surgery centers that we were expanding into. With Redox, we didn’t have to worry about the specific EHR on the other end, as long as they could support HL7 integration.

When you integrated with Redox, were you then able to immediately plug in to all your customers?

Theoretically, yes, that’s what should happen. However, it does require calls and implementation resources to sort out the details. This is where I feel Redox could have been more helpful. I had to participate in calls with our clients to ensure that they were meeting all the requirements from our end. Redox as the intermediary, could have taken on more of that work, in terms of project management + getting the work across the line.

Since you originally brought Redox on, have you evaluated other competitors? And how did Redox stack up against them?

Yes, there was one competitor that we targeted, but they went out of business during Covid. We were actively trying to switch over to them, mainly because Redox’s pricing became quite high and they changed their pricing model.

However, we did evaluate Xealth as a primary integration solution, even though they aren’t really a direct competitor. Xealth doesn’t offer the exact same services as Redox, but from a business perspective, they helped address many of the reasons why we needed a platform like Redox. They helped us initiate sales conversations, ensure smooth integration with health systems, and bring clinical workflows and data back into the EHR system to avoid switching between different tools. When we started integrating with Xealth at some of our health systems, we actually turned off our Redox feeds. This definitely shifted the way our organization thought about Redox.

Can you elaborate a little about Xealth? It sounds like they weren’t direct competitors, but that you were able to use them instead of Redox.

Yes, so Xealth sits within Epic AppOrchard or Cerner Code. It partners with digital vendors to allow health systems to manage all of their digital tools, in terms of ordering and monitoring, all within the EHR. From a technical perspective, it allows you to embed your application within their Epic or Cerner as an iframe. Xealth handles the heavy lifting of connecting to the EHR’s open APIs and existing SIU/ADT interfaces. The main difference between Xealth and Redox is that Redox translates any HL7 message into JSON (i.e., it’s focused on the data exchange), while Xealth focuses on embedding your application within the clinical workflow. However, with Xealth, you can still place orders directly from Epic, so there is a data exchange aspect as well. That’s why they’re not direct competitors, as Xealth’s primary goal isn’t standardizing the data transformation.

What are the key requirements you used to evaluate Redox and their competitors?

One of the main factors we considered was having really good documentation, especially API documentation. Pricing was also a big consideration, since we didn’t want it to offset the deals we were trying to pursue. Initially, we didn’t put much emphasis on professional services or the level of involvement needed for implementation, as we were okay with handling that ourselves. However, as we started scaling, it became a bit problematic.

The EHR footprint with various healthcare organizations was also crucial to us. We primarily worked with large health systems, but we were expanding into the ASC market, which involved integration with smaller EHRs that many companies didn’t want to deal with. Redox had experience in integrating with those EHRs, which was extremely important for us. In general using Redox helped build rapport with IT teams, as they were familiar with Redox’s name and past history. It was also a significant advantage for us when dealing with buyers, being able to show how many other organizations we’d already integrated with via Redox.

How would you characterize the relative strengths and weaknesses of Redox?

Strengths, well, it works. They do what they need to do very well. I think their documentation is strong. They have a dedicated product manager for documentation, and she’s amazing. Another thing I really appreciate is how collaborative they are. I was constantly invited to give feedback and improve the user experience for different personas, whether it was developers, product managers, or implementers. They always listened and took action on our feedback, which was great.

Their webinars and social media presence were also really helpful. One thing we struggled with was communicating the importance of integrations. We wanted to empower everyone in our company to talk about the value of our product within a larger health system and their digital strategy, and integrations was a big piece of this. It was difficult for me to explain this in detail, as I was focused on the technical aspects like HL7, SIU, and others. However, Redox does a fantastic job of providing knowledge about integrations through their webinars and bringing in experts from different sources. Our customer success and sales teams would watch those webinars, which was really helpful.

Weaknesses? I think the professional services part could definitely use some improvement, especially with the implementation managers. There were a few who were really amazing and knew exactly what we needed right from the start. Maybe we had worked together on previous projects, so they understood our requirements inside out. They knew what was important to us and what wasn’t, making the implementation process much smoother. However, there were also some implementation managers that became a roadblock to getting things done, and I had to escalate the issues to other people at Redox because it was slowing down our progress.

So I think a standardization of the services or keeping detailed notes on clients would be really important. They seemed to have a round-robin system for assigning people to projects, and that’s where they fell short. In the past, some projects could run smoothly without much involvement from me, while others required my constant involvement. Considering the price they charge, I don’t think the level of service they provided always matched.

So what led you to stick with Redox and not switch to another solution?

When we were considering the downsides of using Redox, the implementation issues were a significant factor. However, at that time, we didn’t really worry about the internal resources we were using, so that wasn’t a major issue for us. The only thing we focused on was the pricing, which we were able to negotiate down to a favorable deal. In addition, they were able to integrate with all the healthcare systems we wanted to work with, both on paper and in practice. So there was no reason to go through the hassle of switching to a different vendor and migrating all our existing integrations.

What made you look into Xealth?

We integrated with Redox at one of our existing clients, and Xealth was also being utilized there. The leadership at the client approached us and suggested that we give Xealth a try. I’m not sure about the full history, but they were paying a significant amount for Redox. When we initially signed the contract, Redox was listed at a much higher cost compared to other clients, so the client had an incentive to switch away from Redox. Since they already had Xealth implemented in another department , we decided to test it out there, and it worked well.

With Redox, we had to charge annual implementation fees as there were maintenance/support costs associated with utilizing Redox. Since Xealth had no implementation fees, that was a cost-saving opportunity. If Xealth offered workflow parity, while also being more affordable, it was an obvious choice for us. We also could grow together with Xealth as partners, which wasn’t the case with Redox. Xealth truly saw us as partners, and we had regular calls, shared our sales pipelines, and referred each other to clients. There was a lot of synergy between us.

To the extent you remember the company that went out of business, how did they compare to Redox in the key dimensions that you mentioned before: pricing, footprints, implementation, and ultimate quality of the integration?

The pricing of the other vendor wasn’t significantly lower. However, when it came to the overall experience and capabilities, Redox blew them out of the water. I remember being on calls with the other vendor where they struggled with basic workflows that we had to explain to them. We were trying to set up a proof of concept, specifically for SIU/ADT workflows, and it was clear that they lacked the necessary experience. On the other hand, Redox acted as consultants in terms of integrations and interoperability, taking on the heavy lifting. While I would bring ideas or problems to the table, they truly worked as partners, helping us think through what would work and identifying any downsides. The other vendor not only failed to understand what we wanted but also couldn’t assist us in generating new ideas or expanding into different opportunities like Redox could. I had numerous conversations with Redox’s product managers and engineers, discussing various topics. One instance that stands out is when we were trying to implement a new use case at one of our organizations; it felt like an ideation session bouncing ideas off each other. This level of support and willingness to collaborate was extremely valuable and something not all vendors offer.

And you said the price was the same. Was it a per-integration cost?

They referred to it as a connection, defining a connection as either VPN or API. Let’s say you have SIU, ADT, ORU, and MDM within an organization, which is our classic setup. That would be one connection at $6,000 per year on top of a standard annual platform fee.

Did you have specific use cases that you did with them? Or was it standard across each of the systems or clients that you worked with?

It was pretty standard. However, when it came to implementing newer technologies like FHIR, we decided to handle it ourselves. We were initially considering using AppOrchard and writing directly to FHIR resources because we felt that Redox was a bit behind in that area. Our CEO, the head of product, and I couldn’t really understand the value proposition of Redox for FHIR at that time. Connecting through Redox with HL7 made sense to us, but when it came to FHIR, they couldn’t clearly explain their involvement, since it was a relatively new initiative for them. So, for FHIR-related tasks such as SMART on FHIR launches, we chose not to work with Redox because their value proposition wasn’t clear to us. And when we looked at pricing, we decided to go ahead and try it on our own.

Can you explain a bit about why you didn’t understand the value prop with respect to FHIR?

Yeah, so the whole idea behind FHIR is that you only need to connect to it once, with one version, and it’s implemented in a consistent way. Redox capitalizes on the fact that HL7 doesn’t work that way. We were skeptical about why we even needed a middleman with FHIR. Redox said that FHIR might not actually be implemented consistently, and there could be variations, but we hadn’t gone out and tested that ourselves. We had experienced the challenges of using HL7 in different ways, but when it came to FHIR, we didn’t know enough about it to believe Redox, see their value, and know whether it was worth the price. As for implementing with clients, if we could do it ourselves without involving a third party – not that Redox significantly slowed down the process – we would give it a try.

Did you actually test out FHIR and get a read on whether what Redox was saying was accurate?

Yeah, that was my last project at that company. We focused on implementing FHIR resources for medications. It was quite a challenge for our engineers to grasp the concept. There’s a whole dictionary associated with FHIR, so they had to take a course and educate themselves on it. It was a bit expensive, but it was crucial for us as engineers in a digital health company where FHIR played a fundamental role in our product strategy. I believe there was great value in not having to deal with HL7 ourselves, and FHIR seemed like the way forward, making it easier for tools to connect using this standard, or so they claim. As for understanding if the implementations varied, we only worked on medication implementations for one client. Unfortunately, I didn’t have the opportunity to see how it was done at other clients.

At a fundamental level, was the quality of Redox good and consistent?

Yes, 1,000%. The downtime for their feeds, if any, was minimal, maybe around five seconds or a minute at most. But the great thing was that, even during those brief moments, we still received consistent communication and alerts. So it never caused any major issues for us. I do recall one instance that was a bit longer, around 30 minutes. However, given the nature of our application, it didn’t really affect us much. Our main focus was sending patients education and materials to assist them in preparing for surgery or recovering afterward. It wasn’t as urgent as, for example, lab orders that required constant uptime.

Is there anything that we haven’t covered that’s worth mentioning?

Personally, I really like their documentation. I think they excel in that area. Specifically, I find it to be very user-friendly, especially for product managers. They provide a lot of details on what can be done with the product, the reasons behind it, as well as example workflows and real-life clinical workflows. All of this really helps to give a broader understanding, which I found to be really helpful, alongside the actual API documentation.

In terms of account management or support, how would you characterize that with Redox?

You know what? It’s actually funny. Our account manager changed four times in one year, which was really annoying, because I never knew who my account manager was at any given moment. I had to dig through my emails to figure out who to reach out to. And there was never any explanation for why they were changing so often. I don’t think they were leaving the company, they were just being switched around. So that was pretty frustrating.

As for support, I was there when they switched to Jira Service Desk. Initially, it was just a Gmail email system, which worked fine, honestly. The frustration came with using Jira Service Desk as a tool. But when it came to support response time, level of detail, and issue resolution time, I never really had an issue with that.

It doesn’t sound like you had a lot of other options, but do you think you ultimately made the right decision with Redox?

I believe we did. But when it came to thinking about why we chose Redox, that’s where the thought of Xealth came in. We started considering the specific issues we were trying to address, and we saw the potential of growing with Xealth as a partner, particularly in areas like writing back. If I had stayed longer, I think we would have definitely made some changes in that regard, or at least attempted to.

Between Xealth and the emergence of FHIR as an integration route, do you think Redox will be less necessary in the future?

From my current perspective, I would seriously question why we were still relying on Redox for integration. If I was going through the process now, our first choice would probably be Xealth. If Xealth didn’t work out, we would explore the possibility of using FHIR. And if the EHR system didn’t support FHIR the way Cerner or Epic do (the EHR systems that Xealth integrates with), then we would consider using Redox to avoid dealing with flat files. Redox would become the third option in our decision-making process. It seems like Redox is playing catch-up with FHIR, their second act perhaps.

Do you have any advice for someone who is in the position right now of thinking through their options?

When it comes to integrations, it’s really helpful to use real-life clinical workflows instead of just focusing on hard requirements. When we discussed Xealth, I found myself asking questions about the clinical workflows and the problems we were trying to solve. How can we collaborate with Xealth to address these issues? Otherwise, you might just end up with a long list of requirements.

For example, we might just say we need an SIU feed or an ADT feed without considering the bigger picture. This kind of thinking can lead to short-term decisions that work for the present but not for the future of our product down the road. Unfortunately, we didn’t often engage in this forward-thinking approach when working with Redox for our integration strategy. We fell into a pattern that lacked innovation. It wasn’t until Xealth came along that we started questioning why we were sticking with Redox and why we weren’t investing more in research and development to enhance our integration capabilities with different partners.