Life's about the Journey, not the Destination(s)

We built Redox under the assumption that our engine would be used to connect applications to health systems. Additionally, that applications prefer JSON through web services, while health systems are stuck with their EHR’s HL7 over TCP. 

While this is true much of the time, we have come to realize that this structure can limit some of the more creative interoperability use cases. We’ve talked with over 500 organizations ranging from startups building an idea to some of the most prestigious academic medical centers. And what we’ve found is that there is a need for more than just HL7 transformation. The true missing piece in integration infrastructure will be far more flexible. It should support multiple data formats, transmission options, and filtering capabilities. 

Redox, Reimagined

We’re excited to share a new version of Redox. Rather than applications and health systems, we saw that what it really boils down to is data sources and destinations. Based on our conversations, we expect most health systems and applications to act as both data sources and destinations. We’ve redesigned our engine around this concept and and can’t wait to see what you come up with. 

Sources

A data Source can be an application, EHR, interface engine, device, lab system, etc. We currently support Sources transmitting JSON messages through Redox data models or HL7v2. Additionally, communication with Redox is supported through our API or an MLLP listener. Sources broadcast messages to one or more subscribed data Destinations. Filters applied on the Source side restrict data to all Destinations. 

Destinations

Similarly, a data Destination can be an application, EHR, interface engine, device, lab system, etc. Destinations consume either HL7v2 or Redox JSON data models. We support communication to Destinations over the Redox API, MLLP, or IHE XDS/XCA for query/response models. Destinations can subscribe to one or more data sources and filters applied to the Destination restrict transmissions to that specific Destination. 

We’ll work with you and your data partner to configure all subscriptions and filters for your Sources and Destinations during the implementation process. 

New Possibilities

There are a number of new use cases through this centralized transformation process. We have over 100 applications building on our APIs. Many of them make up a piece of a patient workflow. For instance, one application may provide direct scheduling services and another may provide the technology to facilitate telemedicine visits. Through this centralized model, the scheduling application (Source) can broadcast an appointment to the health system’s EHR as well as the telemedicine application (Subscribed Destinations). And a filter can be applied to the telemedicine Destination so it only receives telemedicine visit types. 

Additionally, since health systems can be both sources and destinations, this structure allows for better interoperability between two affiliated health systems. With the rampant affiliation going on these days, that’s great news. 

Let us know what you think.

We truly appreciate your feedback, suggestions, and critiques. Send us a note here.