Building technology that has anything to do with healthcare can be a daunting task for developers—every system you connect to might have a different way of sending data (TCP, MLLP, HTTP, SFTP, etc) and a different format for the data itself (HL7v2, FHIR, JSON, XML, PDF, etc).
You might connect to Hospital A that sends HL7 messages over MLLP. Naturally, you build your technology to be able to exchange data with Hospital A. Soon, your company grows and wants to connect with Hospital B… but they use XML over HTTP. What do you do?
The unfortunate reality is that you’re faced with rebuilding part of your system to handle the connection to Hospital B. Even if Hospital B uses HL7 over MLLP, they might have customizations in their system that creates differences in the HL7 standard that Hospital A uses. This creates a big problem: you’re now spending time building your system to be interoperable with both hospitals, when your time could be better spent improving your core product.
Tech-debt is a phrase most commonly used in software development to describe the negative impact of crudely written code—it impacts performance, makes future changes more difficult, and is something high-functioning development teams seek to eradicate in general. In our scenario, tech debt applies not to computer code, but to integration infrastructure. Each new connection that is built in this highly customized, non-reusable integration model is an additional piece of infrastructure that needs to be maintained and updated.
Over time, the more of these connections organizations have, the more of their team’s man hours must transition to maintenance. This means they aren’t able to work on net new projects because resources are devoted entirely to monitoring and maintaining existing connections. This becomes extremely troublesome when something new comes along that represents a drastic improvement on what’s in use today, because with traditional integrations, implementing one new tool requires building a multitude of new connections.
The good news? Redox solves this problem, and many others developers encounter when working in healthcare. Here’s why developers enjoy working with us:
1. A modern API experience
Rather than building to each system’s specifications as outlined above, developers using the Redox Platform develop using our standardized API, which means that no matter how many systems you connect to, the Redox API stays the same.
You’ll be using a modern API to send and receive JSON using HTTP rather than dealing with multiple protocols and message formats, so you don’t have to worry about (or spend time figuring out) MLLP, XML, HL7 or any of those other things.
A developer that wants to add an appointment for a patient in a connected system would simply make a POST request, sending a JSON message that adheres to our Scheduling data model.
Want to connect to another system, or another 500? Developing with the Redox API makes that possible.
2. Redox sets up and monitors connections (so you can sleep better)
Want to connect to 50 different health systems? Without Redox, you’ll need a specialist to setup those 50 VPN’s and monitor those connections 24/7.
By working with Redox, developers rest easy knowing that all VPN’s are set up, maintained, and constantly monitored by Redox. If a connection to a health system goes down at 3:15am, we’re working on it by 3:16am. This takes not only monitoring connections off your plate, but building out monitoring functionality, too.
3. Redox can handle it
Redox was built from the ground up with reliability, scalability, and security in mind. Our message processing is horizontally scalable and we separate message queues to avoid the noisy neighbor problem. We’ve integrated with over three dozen leading EHR vendors at over 150 health systems. No matter how much you grow, Redox can scale with you.
4. You gain teammates
Working with Redox is like hiring a team of over 50 healthcare experts to handle the tricky parts of developing in the healthcare industry. Developers love us because all we do is integration, and we know what needs to get done, when, and by whom.
Best yet, we allow teams to focus on building value into their software, rather than spending time dealing with the headaches of connecting and interacting with other systems.
Developing healthcare technology can be daunting, but it doesn’t have to be—Redox knows the ins and outs of healthcare data exchange and built our platform to be easy to understand and build against. Check out our API docs to start building with us today.