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.
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.
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.
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.
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.