A few years ago, I wrote a post titled Why the world needs a new kind of interface engine. My message was about developer empowerment, over what I saw (and still see) in the interface engine world: bloated, hard to use, overpriced products that have long been "good enough" at solving the problems they are purchased for.

Niko recently wrote a great article about Redox's vision Supporting the Human Connection in Healthcare.

This post is from an on-going series from our engineering blog, Shift6, which features developer-focused content. For the first part of the Redox Microservices Journey series, click here; for the second, click here. 

At Redox, we're taking a pragmatic approach to building microservices, especially in how we handle cross-cutting concerns. Most refer to this part of a microservice ecosystem as the chassis—things that every microservice needs to have in order for us to be confident that it's a quality product. The chassis includes:

At Redox, we rely on Slack to communicate every single day, and while it's core value lies in it's sheer utility, there are plenty of other reasons we've come to love using it that aren't entirely related to work.

I've spent a lot of valuable time reading and learning how to become a rockstar developer from people like Fred Brooks and Jeff Atwood, but no one has really written a guide about how to be a rockstar healthcare developer. 

This post will be my quick hits on what is different about developing in the healthcare space and what Redox can help with. 

When I worked at Epic, I was asked to do many challenging and exciting things. The most challenging and least exciting thing, though, was being a project manager for integration projects. Since this role exists at Redox as the Customer Success (CustoSucc) team, I feel privileged to be working with people who are excelling in ways I never could.

In this post, I'll explain what an integration project is, why it's a project, and why Redox has a recipe for success.

In a previous post titled “3 Questions to ask your healthcare API vendor”, I  touched on why we don’t use an off-the-shelf interface engine for Redox. In this post, I want to dig deeper into why I’m so passionate about this. 

On the way back from my recent overseas adventures, I was lucky enough to binge watch the entire first season of Mr. Robot. The show is amazing and I highly recommend it!

The thing that healthcare IT and ancient China have most in common? Most people in the United States have no idea about how either work. The second? There is a lot more nuance than even scholars of both fields know.

With all the EHRs that our engine interacts with, it's kind of hard to keep track of what all the connection types and data formats we support are. As always, I try to help clarify things.

Half of the Redox team is remote. This month, I'm extremely remote -barely working from China. In this post I'd like to meditate on what tools you need to be a successful remote worker.

If you're reading this, you likely have a need to integrate your application with EHRs across the country (maybe even the world!). There are a handful of API companies out there, with us at Redox pushing the pack. As you review available solutions, it is important to ask the right questions and get past the marketing. This post overviews some really tough decisions we have had to make in designing our product, and why we made the choices we did.