What is Redox?
Redox is the healthcare cloud API service that connects products to providers, HIEs, and trusted networks like Carequality and Commonwell. Redox standardizes all source and destination organizations to a common use-case focused syntax on a service with compliance to the most demanding data security standards.
Make development easy
The landscape for provider connectivity is stratified across standards and digital maturity and connecting to each individually means development teams need dedicated resources, significant knowledge of legacy standards and an operational program to monitor and maintain each connection. Redox provides an enhanced ability for product teams to use EHR integration as a competitive advantage rather than a resource drain. See how Redox supports simplifies connection and speeds your time to delivering customer value:
Redox will work with the healthcare organizations and other healthcare data Sources that you want to connect with to make sure that they’re connected to the network through their preferred method, such as a VPN or authenticating to EHR APIs. This allows healthcare organizations integrating with Redox customers to use the connectivity methods natively supported by their systems while allowing Redox customers to maintain their single, standardized connection to our platform.
Redox uses a library of configurations for various integration methods and EHRs in order to translate whatever we’re receiving from your clients into a standardized API that you work with. So regardless of whether Redox is receiving FHIR from Cerner, HL7 from Epic, C-CDAs from Allscripts, or using any of the myriad of (and disparate) EHR vendor APIs out there, you will always receive data in the same standardized JSON format through the Redox API.
For software vendors connecting to Redox, we provide integration infrastructure that is built to scale, helps reduce tech debt, and addresses scaling database challenges. For any vendor that works with integrated data, there are four jobs your product needs to do:
- Ingest Data: the ability to receive data in a compatible format
- Process Data: completion of data processing steps while retaining FIFO order on large quantities of incoming data
- Maintain Data: application of business logic to define how data should be handled when it’s received
- Recall Data: reference maintained data at the correct point in product workflows
Redox lightens this load by making sure that you’re working with the integrated data you need when you need it, all in a predictable manner through our API. Through our Data on Demand infrastructure, Redox can receive large volumes of pushed data from connecting healthcare organizations and persist that data while making a queryable endpoint available to Redox customers leveraging our API. This means your application can move closer to being a stateless system, where you are ingesting, processing, maintaining, and recalling a much smaller amount of patient data than if you were receiving a full firehose of data over an event-based interface.
Alerts and Monitoring
Redox monitors live connections for errors, handles retries against both your system and your client’s system, and will send alerts to notify your team of any errors we receive when posting data to your system. Our team will work with the appropriate team or resources to resolve any issue that does arise across a live connection.
Now that you have an understanding of the role of the Redox platform as a whole, let’s take a closer look at its different components.
Due to the decentralized nature of healthcare integration support, a health system may want or need to send data to an integration partner using any number of methods, formats, and value sets. To reduce the development efforts required to support the integration variances, the Redox API standardizes the data we receive from EHR systems and other healthcare data Sources into our JSON models as well as normalizing many of the incoming value sets. This means you can connect to the Redox engine and exchange data through the Network with major EHR vendors, CRMs, Health Information Exchanges (HIEs), and more—all over a single HTTPS connection and consistent data format. The Redox API supports exchange of a wide variety of (mostly) patient-centric data through our standard JSON data models, and within these models the Redox API performs the two core functions of format standardization and data normalization.
Messages transmitted over the Redox API will always be formatted according to the JSON specifications of our data models during three core stages of real-time processing. This allows your team to develop against a predictable set of data models instead of creating customized translations for every format in addition to accommodating differences between healthcare organizations. First, messages are parsed according to type (HL7 v2, CCD, Custom API, etc.). Secondly, they are configured for vendor-specific specifications based on the Source system, such as an EHR, HIE, CRM, or ERP. Finally, they are configured against any site-specific customizations that are needed—e.g. one ADT HL7v2 message from one Cerner site will still not be identical to an ADT message from another Cerner site and this variation will always be accounted for within the Redox API.
This diagram shows how data consumed from an external Source is transformed into our data models. Though this shows an HL7v2 message transformed into JSON, please note that a variety of other standards such as CDA, FHIR, X12, and Web Services can be both consumed and produced by Redox in order to exchange data with your connection partners.
Data normalization is applied to data fields where there is a set list of possible values within the EHR—think a drop-down list or a predetermined category list a user can choose from. These fields include patient race, ethnicity, marital status, and language among many others, and you can see the specific fields along with the specific value sets we support by visiting our data model documentation and within a given event clicking the Show Translation Fields toggle.
When working with healthcare organizations, we analyze the values in these fields coming from the health system and make sure they are mapped to new or existing values in our standard tables of values. As a specific example of this, we make sure that all of the values we receive indicating a contact’s relationship to a patient look the same. If the contact is the patient’s brother, that data could come across as “Brother”, “BRO”, “B”, etc., but we will always map those values to “Brother”.
Note that we do not yet normalize coded values. This is largely due to the amount of maintenance that would be required to maintain mappings between such large code sets, which include ICD, SNOMED, NDC, RxNORM, LOINC, CPT, and HCPCS codes. Translating codes and mapping them between code sets can also have significant clinical implications, as there isn’t always a perfect mapping alignment between sets. If you are interested in coded value normalization please let us know as we are always interested in hearing about particular use cases and needs.
Our network approach
Redox takes a networked approach to interoperability where the connections we establish to healthcare organizations and other data sources are “nodes” on the network and built to be reusable. In order to enable the healthcare industry to be more interoperable, we think it is important to do more than to be an outsourced method of creating customized connections. Our approach allows us to create reusable nodes that are then available to be leveraged by other Redox customers who have the necessary legal agreements in place with those organizations connected to the Redox. Establishing integrations within this networked paradigm allows for significantly expedited implementations (up to 30 days faster) for both you and the healthcare organizations you’re working with, especially when Redox is already receiving the specific data set that is looking to be exchanged.
Redox message processing
Redox handles all core message processing, routing, and storage for the millions of messages exchanged across the platform daily. Our engine was built with flexibility in mind with the goal of minimizing the effort required for integration, not just for Redox customers but the healthcare organizations they partner and integrate with as well. Redox is able to ingest data from different healthcare data Sources, such as EHRs, HIEs, CRMs, and ERPs, using the format that their system already natively supports (eg: HL7, vendor API, FHIR, etc). Through our experience working with hundreds of healthcare data Sources, we already have the necessary mechanisms in place to map messages from the most common healthcare-industry accepted integration standards (as defined by the ONC’s Interoperability Standards Advisory) to the Redox API.
The bottom line here is that we handle the mapping and configuration of messages to and from our API in the engine, making it easy and lightweight for you and your partners’ IT teams to work with us.
In addition to the standardization the Redox API offers, a core value of leveraging Redox is the workflow normalization our engine offers across many of our data models and events.
Workflow normalization is the ability to enable the same set of integration points and calls for Redox customers regardless of how the system on the other end is exchanging data with Redox. This means that whether Redox is synchronously querying for data over an EHR’s proprietary API or receiving pushed, event-based HL7 messages, you can still receive the data through the same Redox data model event type.
For customers who prefer to query for data and the connecting organization can only support pushing data to Redox, our engine can persist data and still provide a queryable endpoint over our API for data models that are enabled within our Data on Demand feature. You’ll learn more about this feature in the Data on Demand post in the Onboarding section of this guide. For instances where a customer prefers to receive data through pushed event notifications where their partner organizations only natively support synchronous queries over an API, the Redox engine can employ standard polling capabilities to enable a data push between Redox and our customers over the Redox API.
Subscriptions, Sources, & Destinations
Redox uses a proprietary subscription infrastructure to route the millions of messages we process on a daily basis. Subscriptions are the juncture point between two network participants that enables them to exchange the appropriate data. We prefer to filter data at the Subscription level to ensure that Network Participants receive only the minimum necessary data. Redox subscriptions are configured between you and your connection partners and have specified data models, ensuring that you not only exchange data with the right organizations but that you exchange the right type of data.
Redox’s subscription infrastructure is centered around the concept of sources and destinations, where each node on the Redox network has its own configured source and destination records. Each subscription is between one entity’s source record and another’s destination that allows them to exchange data over the platform. Source records either send data over a pushed model or initiate queries to retrieve data; destinations either receive data over a push model or synchronously respond to queries with the requested data. A single source can have subscriptions to multiple destinations and across multiple data models; conversely, a single destination can receive events for multiple data models for many different Sources.
We’ll go into more detail about Redox subscriptions and how to set up sources and destinations in the Onboarding section of this guide.
In order to ensure that the nodes we establish across our network are as reusable as possible, Redox engine has extensive filtering capabilities, which enables us to process full interface feeds and handle necessary filtering within our platform. Our engine has the ability to filter on any discrete piece of data within the body of the message that is being processed; most commonly Redox places filters on specific locations of care, such as a particular hospital or outpatient department. Filters can be applied on the Source-side—meaning the filter applies across all of the Sources subscribed Destinations—or applied to specific Destinations subscribed to a given Source. Source-side filtering is helpful when there are specific messages that the connecting entity doesn’t want sent to any downstream system through Redox; destination-side filtering allows the engine to have filters specific to the receiving entity and means that healthcare organizations source connections can remain reusable across multiple subscribed destinations. The Redox implementation and support teams currently set up and maintain all filtering through the Redox dashboard.
Partner Connection Management
In order for Redox to ingest data from your connection partners, we need to be able to set up and maintain connectivity with your healthcare organization partners. Our integration experts work with your partners to identify the most efficient integration strategy for their unique system implementation, all while leveraging pre-built adapters that allow us to connect quickly with all major EHR vendors. For HL7 integrations, Redox most commonly maintains a secure VPN tunnel for MLLP traffic. HL7 messages originating in the organization are normally routed through an already established on-premise interface engine before being pushed to the Redox VPN. Conversely, Redox can generate and push HL7 messages back to the EHR through this infrastructure as well.
Redox can also work with your healthcare organization partners to leverage other standards and connection mechanisms beyond HL7 messages over a VPN. Redox can connect to FHIR resources, EHR-vendor-custom APIs, FTP servers, and other standard web services, all over a range of connection mechanisms and all while managing the required authentication, whether that be credential or certificate-based. During the early stages of an implementation, the Redox implementation team will work with the networking team or other appropriate contacts at your partner organization to obtain and configure the necessary information for the given authentication and connection strategy. And once configured, the VPN setup or other type of authentication credential will be fully managed by Redox in our engine.
Connections are configured and managed through the centralized Redox dashboard. The Redox dashboard will be your team’s integration hub to view all message logs as well as live Subscriptions to your partner organizations and the associated credentials. You will also use your dashboard to manage your Sources, Destinations, and team access. You can create your own organization by signing up and creating a free user account, after which you’ll have access to developer tools that will allow you to kick the tires with our API. We’ll cover those developer tools, source and destination Setup, Subscriptions, and message logs in much more detail in the Onboarding section of this guide.
Once you’re ready to connect to a healthcare organization, you will need to contact us to upgrade to a paid account. After your project kicks off, the Redox team will manage the creation and setup of the organizations you partner and connect with across Redox.
Connecting to Redox
One of the main tenets of how Redox introduces efficiencies to a complex integration landscape is the ease of which developers can connect to the Redox platform. In this section we cover an overview of how customers build against our API and connect to us once over a standard HTTPS connection. Further on in the Onboarding section of this guide we’ll get into more details around how to most effectively code against our API and models.
When you create a free user account, you’ll be asked for your name, email, and the name of your organization as part of the registration process. Once you set your password and create your Redox account an invitation to log into your organization’s new dashboard will be sent to your email.
The organization name you specify during registration will be the initial name of your organization record in the Dashboard but it can be modified by clicking the Edit Profile button on the Overview tab. You’ll also be able to add general information about your organization, such as an overview of your product, your organization’s website, logo, etc.
One of the critical fields in the profile is the Alert Email field, which is where you should specify the email where Redox can send alerts and notifications about errors, critical incidents and scheduled maintenance. You’ll read more about our error alerting functionality in the Onboarding section of this guide.
User Management & PHI Access
Once you have established your organization, you can send invites to other users from your team to grant access to the dashboard by clicking the green caret menu in the top right-hand corner of the dashboard and selecting Manage Users*. You’ll be able to send your team invitations by entering their email addresses under the ADD NEW USER field at the top of the page.
Once users have accepted and gained access their permissions are centered around two things: organization owner and PHI access, both of which are displayed as check boxes next to each user that has access to the dashboard. The first person who creates the organization will automatically be granted the organization owner, which simply means they have access to modify permissions for other users once they join and themselves, either granting or removing organization ownership and PHI access.
Removing a user’s PHI access within the Redox dashboard means that the user will only be able to see message and transmission log metadata for production connections as opposed to the full message contents they’ll have access to for development and staging connections. We’ll talk more about message and transmission logs and the different types of connections in the Onboarding section of this guide.
*Note: some users may have access to multiple organizations within Redox, in which case you should make sure you are within the organization you want to modify users for when you select the Manage Users menu option.
All requests to Redox over our API are sent to endpoints that live under https://api.redoxengine.com/ and there are two primary Redox endpoints that customers connecting to the platform will leverage to either send data to Redox or initiate queries against Redox as a Source.
All data pushed from a Source to Redox over our webhook events should be sent as POSTs to https://api.redoxengine.com/endpoint.
To query Redox for data, you should POST to https://api.redoxengine.com/query from your Source and include the relevant parameters of the query in the body of the request, as indicated in our data model documentation. Our API requires POST events for these queries so that Protected Health Information (PHI), such as the patient’s Medical Reference Number (MRN), is transmitted in the body of the request, which is TLS encrypted. With GET requests, query parameters and resource identifiers must go in the URL, which could be logged in plain text in network and server logs before the request gets to Redox.
What about applications receiving data from Redox through their Destination? When you establish your Destination record in your organization’s dashboard you will be able to specify the public endpoint where you want Redox to send HTTP requests over our API.
Applications sending data to Redox over our API need to first authenticate against Redox by sending a POST to https://api.redoxengine.com/auth/authenticate with the API Key and Source Secret configured in their Source record. Redox will synchronously return an Access Token that will then need to be included in the header of messages sent to Redox.
Conversely, applications receiving requests from Redox over our API should specify a Verification Token in their Destination record that Redox will then include in the header of messages sent to the customer’s endpoint.
The Redox API leverages standard JSON data models that represent a wide variety of patient-centric data that can be exchanged across our Network. Redox customers connecting to Redox over our API need to be able to process messages according to these models, whether that be receiving pushed data, initiating queries, or pushing data back to Redox as a writeback. Each data model has supported event types, some of which correspond to pushed, event-based notifications which are typically based on an action a user takes within an EHR or other system. Scheduling – New is an example of this, where messages are created and pushed to the connecting system as new appointments are scheduled. Other event types are query-based; Scheduling – AvailableSlots and ClinicalSummary – PatientQuery are examples of this, where the requested data is synchronously returned to the application that initiated the query rather than being pushed based on some real-time event in the EHR.
As we mentioned in our post on Workflow Normalization, Redox can employ API polling or leveraging Data on Demand so that the data model events that vendors need to use to get data are consistent regardless of how Redox is obtaining the data from the connecting partner. We will cover additional details around this and how it affects integration scoping in our Onboarding section.
Security and privacy are two areas that have always remained at the core of everything Redox does. We are privileged to be entrusted with the incredibly personal information needed to provide quality healthcare and take our responsibility in keeping our platform secure very seriously. By using Redox, you are able to reduce many of the risks associated with data exchange by leveraging the work we do to maintain and exceed industry security standards. Here’s how we ensure a high level of security through every step of the integration process and throughout our company and platform.
Securing the Engine
Redox is HITRUST certified (with no findings or CAPs) and SOC2 Type 2 compliant. We utilize industry standard, HIPAA-compliant, and National Institute of Standards and Technology (NIST) recommended encryption standards to protect client information.
- Databases are 256 bit AES encrypted. Database filesystems are encrypted using AWS managed keys and encrypted backups are taken nightly and stored in a separate geographic location.
- The Redox API scales to balance traffic across available application instances. Our endpoints receive automatic security updates, and we force HTTPS at the endpoint layer.
- Application code runs in Docker containers in the app layer. We deploy code changes without any interruption to traffic.
- Redox applications and databases are redundant across AWS Availability zones, so if an outage occurs in one AZ, we failover with minimal interruption to traffic.
- App and database containers run in a private subnet, inaccessible from the outside internet. Access is restricted to the app and bastion layers. Internal database traffic that contains any confidential information is encrypted.
- Database filesystems are encrypted using AWS managed keys. Encrypted backups are taken nightly, or more often if you require, and stored in a separate geographic location.
Redox is hosted on AWS in the Eastern Region within our dedicated Virtual Private Cloud (VPC). We have a business associate agreement (BAA) in place with Amazon and all other tools authorized for use with protected data and all sensitive third party tools undergo a yearly security evaluation. Our robust disaster recovery plans are documented, reviewed regularly, and tested yearly and we have a trained security incident response team on call 24/7/365 to investigate and mitigate the impact of security issues.
Redox contracts with a number of independent auditing organizations to maintain security. Penetration Testing is done at least yearly to identify potential system vulnerabilities, which ensures any security issues are resolved before they have a chance to arise, and that data is properly guarded. Code audits are also regularly done to scan our code base and find and address any security vulnerabilities. We also have independent third parties monitoring system-level events for intrusion detection and reporting any incongruent activity, like a user promoting their privileges or modifying files.
Staff access to protected data is limited to business need and adheres to least privilege principles. Redox additionally enforces multi-factor authentication for staff access to any sensitive infrastructure or tools and access control is centrally managed using SSO. All staff undergo background checks prior to employment and are given security awareness training and specialized role-based training for roles with sensitive access or authority. Redox also logs all user activity to a separate, non-reputable SIEM.
TCP traffic from Health Systems is encrypted via a secure VPN connection. We use the IPsec protocol to ensure all traffic within the VPN is encrypted and authenticated. The VPN is consistently monitored with a heartbeat to ensure the connection is healthy.
Between Redox customers leveraging our API and Redox, end-to-end encryption is done to secure all data transmitted over an HTTPS connection. Within the Redox application, we support modern industry OAuth and SAML standards to authenticate applications that send to Redox and to authenticate with applications that receive information from Redox. We store sensitive credentials as salted hashed values for an additional layer of security.
For dashboard access, we offer Two Factor Authentication as an optional security feature to further protect data logs. The first factor is a user’s password; the second is a code sent to the user’s phone. With both, access to the dashboard is easy. If you’re a hacker who has someone’s password, but not their phone, access is prevented.
Similar to other Redox platform access, we audit all web events, meaning every query or access through the dashboard is documented. This tells us what was accessed, when, and by whom.
Redox customers can grant or remove access to PHI data for the users on their team who have dashboard access. We maintain logs of every message that moves through our system, but removing PHI access means those users will only see meta-data related to message and transmission processing.
Data Retention Policy
We make a commitment to our customers that we provide a consistent data exchange experience that allows you to design once and connect to any system using ONC-certified technology. In order to provide this and to continue to evolve our offering to meet the needs of our customers, Redox will store all data we receive during the length of contracted services. This will allow us to enhance the integration infrastructure we provide to our customers.
We’ve created a Redox Data Retention Philosophy that is designed to articulate our intentions and commitments to make sure the data we retain is done for the purpose of enabling frictionless adoption of technology in healthcare and making healthcare data useful.
Redox Data Retention Philosophy:
- Redox collects data for the purpose of facilitating normalized data exchange in the healthcare sector.
- Redox does not receive or retain data without appropriate business associate agreements in place.
- Redox will not sell or share data for uses outside of contracted healthcare data needs.
- Any data collected by Redox will only be used for purposes related to improving healthcare data exchange.
- Redox will destroy data in accordance with contractual and regulatory obligations.
Our full data retention policy can be made available at customer request. For customers that have thoughts or questions to share, please reach out to any of the Redox team members you work with to discuss our policy further.