Why Gartner named us a Cool Vendor

Gartner just released their 2018 list of Cool Vendors, which are companies doing innovative, impactful, and pioneering work across industries. Redox received the designation in the Healthcare Providers category, and needless to say, we’re pretty pumped--not only because being selected out of literally hundreds of vendors is such an honor, but also because it reaffirms that the way we’re tackling the interoperability problem in healthcare really is different. I hosted a webinar on June 20th, 2018 to talk through why we think that we're cool that you can watch.

When I talk to folks about what we do, many healthcare IT professionals follow up with, “so, you’re basically an interface engine, right?” or “are you an API management solution?” The short answer to both of those questions is kind of, but not really. The simple description of Redox is that we’re a full-service integration platform designed for the tech-enabled provider organization. Our unique combination of centralized architecture, managed service, and a truly standards-agnostic approach eliminates the need for the point-to-point interfaces that dominate the health IT landscape today, simplifying the way healthcare organizations exchange data and in turn accelerating the development and deployment of new technology across those organizations.

There’s a lot to unpack here, so let’s break this down and get at the core of how Redox is different.

How is Redox different from Interface Engines?

Interface engines enable healthcare IT systems to exchange data by providing a tool for interface development. Popular vendors include Corepoint, InterSystems (Ensemble), Infor (Cloverleaf) and Mirth, among others. Widely adopted alongside EHRs, these solutions offer interface teams the ability to filter, transform, route, and troubleshoot messages, using common standards like HL7, CDA, and X12. Some also support web services.

Like interface engines, Redox facilitates data exchange between IT systems and can accommodate a wide range of standards (including FHIR). But we take that a step further with a completely vendor and standards agnostic platform, meaning we don’t give interface teams specs to build to. Instead, we conform to the healthcare organization’s preferred method of data exchange.

Unlike interface engines, which are typically on-premise systems that must be managed by the healthcare organization’s IT team, we deliver our solution as a cloud-based, fully managed service. That means that we take on the work of building, mapping, configuring, and monitoring connections to the Redox platform, reducing the burden on IT teams. Moreover, our modern cloud-based infrastructure and API-first approach are optimized for connecting legacy EHRs and other systems to applications that live outside the four walls of the data center--all via a single connection to Redox vs. unique connections to every vendor.

How is Redox different than traditional API management solutions?

API management solutions are becoming increasingly common in healthcare. Mulesoft and Apigee (owned by Google) are some of the better-known vendors in the space. These platforms allow organizations to design, create, and publish proprietary APIs, and include tools for controlling access, collecting and analyzing usage, and monitoring performance.

Like API management solutions, we enable healthcare organizations to stand-up a suite of reusable APIs for third-party developers to consume, simplifying the integration process by eliminating the need for custom interface builds for every new vendor. The Redox platform essentially acts as an abstraction layer above source systems like EHRs, providing a standardized way to send and receive data with any authorized vendor or internally-developed application.

What’s unique about Redox relative to API management solutions is that every organization using our platform leverages the same shared infrastructure and API. Unlike traditional API management platforms, which build custom APIs from the inside-out (i.e., from the perspective of those that have the data), the Redox API is built and expanded from the outside-in based on the needs of application developers (i.e., those that consume the data). The result is a set of data models based on real-world use cases vs. hypothetical or academic ones. As an example, our bi-directional R^FHIR implementation was built with the developer experience and usability in mind, resulting in the bundling of FHIR resources to support the most commonly requested use cases.

Why Gartner thinks we're "Cool"

While the simplification, centralization, and reusability that Redox brings to the table differentiate our platform from other solutions in the market, the real secret sauce is our network. All of the data we process from the hundreds of software applications and healthcare organizations we work with is standardized and communicated through the same API and canonical model. This means that once connected to the Redox network, every node is technically interoperable with every other node, whether they speak the same language or not. In the way that HIEs serve as an interoperable network of healthcare organizations in a given geography, Redox essentially serves as the real-time HIE for third-party applications.

The beauty of this model is that, with every new node, the entire network gets more efficient. Integration projects get faster and faster each time as the network infrastructure is reused, enabling healthcare organizations to be increasingly agile in their adoption of new technology. We call this approach “networked interoperability,” and we believe it’s networks like this that will ultimately solve healthcare’s interoperability problem. We’re excited to be part of that solution.