Introduction to the Redox FHIR API

FHIR® is a modern, adaptable, and quick way to exchange healthcare data. 

Fun fact

60.2% of health tech vendors share that they are likely to very likely to use the FHIR® industry standard in their own development or infrastructure decision.

Having an effective integration strategy to deliver on the FHIR® promise helps you succeed within FHIR®’s current state of unique limitations while providing interesting opportunities to add even more value to your customers today.

Redox has its own FHIR® API that you can use to communicate with your connections. With our FHIR® API, you can use resources, which are the building blocks for organizing data to exchange. Essentially, they are equivalent to data models, but with a FHIR® REST interface on top of them. You can combine resources to perform a given action to accomplish your unique workflow.

While FHIR® is slowly being adopted by the industry at large, healthcare organizations are required to at least support some read capabilities for clinical data as an option for integration. However, many notifications and writeback capabilities still aren’t typically available via FHIR®. That makes it hard to decide whether to adopt FHIR® fully, right? Redox FHIR® enables you to have the best of both worlds: 

  • Use data already formatted as FHIR®—or let Redox translate to or from FHIR® so you don’t have to figure out how to cohesively use so many different standards; 
  • Use notification and writeback tools with older standards while retaining FHIR® read capabilities.  

As you can see, our FHIR® API gives you consistency while leaving the complex work to us.

We offer a developer-friendly framework to configure your integrations, as well as clear, concise information about how to use our FHIR® API and its tools (but seriously, have you checked out all of our FHIR® articles?).

You may also want the ability to check out your FHIR® traffic and any successes or failures to exchange data. There’s no need to reinvent the wheel by creating your own tools to monitor this—we’ve already done it for you by including FHIR® traffic in the Redox dashboard logs. Learn more about logs.

FHIR® translations

Even if your connections don’t have their own FHIR® APIs, we can help you translate other standards to FHIR® messages:

For HL7 to FHIR®, we're currently working on direct, default translations from HL7 to FHIR® to support additional types of EHR integrations, but today we can still translate between the two styles by translating through our Data Model API.

FHIR® authentication

If you're starting your Redox journey, authentication works the same for either the FHIR® API or Data Model API (hooray!). 

If you’re an existing customer using our legacy authentication, you must develop support for our new JWT authentication. Learn how to authenticate with JWT.

If you want to keep things consistent, you can use the new authentication both for our FHIR® and Data Model APIs. Or, you can keep your existing code and only use the new auth for the FHIR® API. Just a reminder that you can use our FHIR® API with any existing integrations that currently rely on the Redox Data Model API.

Scopes

With FHIR®, API keys have a defined scope, which designates the authorized access for a user with that key. Scopes allow your organization to define security practices around using the platform, meaning that you can safeguard aspects of the platform by restricting or granting access based on the scope that’s assigned to an API key.

For Redox, the available scopes are by environment type: development, staging, and production.   

New API keys are automatically created with the appropriate scopes for the environment flag selected in the dashboard. It's good to know what scopes are, but there's currently no need for you to manually configure any scopes to use the FHIR® API.

FHIR® data on demand

You can use data on demand with our FHIR® API, just like with the Data Model API. But you can also combine it with FHIR® capabilities. Learn more about FHIR® data on demand.