Redox

April 2017 Redox Development Updates

Posted May 1, 2017
By Nijay Patel

At Redox we strive to provide a solution to all of your integration needs. Our team is constantly improving our product and rolling out new features for you to use. You’ll find some of our most recent updates below, along with a highlight of some of the problems we are currently working to solve. If anything piques your interest or if you have any feedback, we are always listening on Slack.

Recent Updates

Clinical Summary Updates

We have a new addition to the ever-popular Clinical Summary to support encounter level documents with the addition of the Clinical Summary VisitSummary event types. This new event type allows you to consume or send an encounter level document with progress notes and other visit-specific information.

Synchronous Error Responses

For synchronous integrations (queries and non-HL7 based integrations), we have introduced discretely mapped and normalized error responses. The HTTP Status Code article explains the error response structure.

Claim Data Model

With the Claim Data Model, we are building support for 835 and 837 ANSI X12 messages. We are currently implementing this feature in its initial pilot, focused on the integration of these message types with health systems.

Filtering Message Logs

You will now find a number of helpful filters on the logs page. This will help you quickly identify specific messages based on a time range, data model, filtered status, etc. You can expect to see a number of additional filters for these tables shortly.

Two-Factor Authentication

We have been using two-factor authentication to login to the Redox dashboard since our initial release. This functionality is now available for all users. We encourage you to enable two-factor authentication for your account. In the future, you will have the ability to require this for all members of your team (check out the User Roles feature below).

Postman Package for EHR Sandboxes

We previously connected Redox to three EHR sandboxes – and they have been an instrumental tool for us as we build Redox. As part of the Redox implementation, we’d like to make these tools available to you as well. So far, we’ve built support for a handful of common integration scenarios. For those working on an integration with a healthcare system, your Redox implementation lead can help you get started with one of our sandbox environments.

Important Changes

API Request Updates

Previously RedoxEngine would default in the destinations you are subscribed to if a destination was not explicitly defined in the request. We have introduced a requirement to populate Meta.Destinations[] in all API requests moving forward. We implemented this change in preparation for an upcoming update that simplifies the Source and Destination workflow. Existing integrations will continue to function as normal; no changes are necessary at this time.

Retirement of Redox ID

Patient identifiers can often prove to be one of the trickiest parts of integrating with healthcare data. We initially introduced the Redox ID to simplify the need to handle multiple patient identifiers that may be used within healthcare. After using it for some time, we have decided to phase this functionality out over the coming weeks. We still care very much about this problem and look forward to providing a more helpful and robust solution in the future. Our new design goes in a different direction, and we look forward to sharing it with you soon.

Coming Up

Here are a couple of the projects our engineering team is building right now.

SFTP Communication Method – while we greatly prefer any number of alternate communication methods, there are specific scenarios (such as ANSI X12 Claims) that will require Redox to communicate via SFTP.

Support Large Payloads – we introduced the Redox BLOB to allow applications to send large files (such as PDFs) efficiently. There is a growing need in the opposite direction, as receiving large files from a health system can become complicated and applications will benefit from the use of our BLOB.

User Roles and Access Restriction – we understand that teams often have a need to restrict specific functions to team members. For example, a consultant may not require access to sensitive information (such as PHI). We will be introducing user roles to manage access to specific features of the Redox dashboard.