Today we are very excited to announce the launch of R^FHIR – our solution for developers that want to use FHIR® but still enjoy the standardization, normalization, and deployment efficiencies provided by the Redox Network.
As with most things, it is important to start with the “why”. In the case of R^FHIR, there were two motivating factors.
We believe in open standards
Standards organizations are incredibly important and their authors should be commended for their meaningful work. As an industry, we’re lucky to have Health Level Seven International authoring standards like HL7v2®, CDA®, and now FHIR®. While the optionality and implementation inconsistencies can be frustrating, there is at least a common framework that can be used to communicate and resolve differences.
That being said, Redox is not a standards body (although groups have designed their internal schema around our Data Models). We exist to serve our customers. If a standard can’t be leveraged to meet the needs of our customers, we will find a way to do so on our own.
When we started Redox, FHIR was little more than a glint in Grahame Grieve’s eye. Building a business on something that was about to change dramatically would have been a bad idea. Even today, we’re realistic about FHIR’s maturity model and the speed at which it will evolve.
We authored our own API and Data Models because it was necessary for us to deliver a delightful developer experience and react to our customers in an agile way. That’s why, even with this announcement, we’ll never retire our Data Models. They will always be a simpler, more responsive standard we can leverage to meet the needs of our customers.
Standards exist for a reason and the work that goes into defining them shouldn’t be dismissed. They should be assessed and leveraged in the appropriate scenarios. That’s why we’ve chosen to devote resources to extend our platform to provide our partners with the option to interact with FHIR.
Healthcare needs an EHR vendor agnostic abstraction layer
Redox already uses FHIR. We have numerous integrations where the healthcare organization’s EHR makes certain FHIR functionality available that we leverage to support our customers’ workflow needs.
It is important to note that the work we do to standardize and normalize various HL7v2 feeds/ web services to allow our vendor partners to interact with our API is also required where FHIR is available today. Due to the way EHR vendors like Epic and Cerner are adopting and implementing FHIR, there is no consistency in the market across vendors.
An inconsistently implemented FHIR standard is incapable of delivering on its enormous promise. So now that we know it is being implemented inconsistently, what do we do about it? The same thing we do every day–continue building the only vendor-agnostic interoperable network in healthcare.
The problems of vendor discrepancy and implementation inconsistency are exactly what we solve today for our partners. The beauty of the Redox Network is our ability to abstract away variance from one node and expose a consistent way to interact with that entity by any other member.
With R^FHIR, we have the ability to expose a single, consistent FHIR implementation complete with clearly defined extensions that can be used to interact with any other member of our Network – regardless of EHR or individual implementation.
Every new standard needs a parallel private entity that supports and extends it into the real world. We believe we’re uniquely positioned to show the world how FHIR can be leveraged to power relevant integration workflows in a truly consistent manner and we relish the opportunity to help direct its utilization in real-world environments.
What is R^FHIR today?
Our initial support will include functionality traditionally provided by our PatientAdmin and Scheduling data models. We are effectively translating the contents of these venerable Data Models into FHIR bundles that can be exchanged using Redox.
There are a few important details that should be noted.
FHIR Messaging
The FHIR specification describes a set of resources and several different frameworks for exchanging resources between different systems.
Applications claim conformance to one (or more) of the following exchange frameworks:
- “RESTful FHIR”: the RESTful API
- “FHIR messaging”: Message based exchange
- “FHIR documents”: Document based exchange
R^FHIR is in conformance with FHIR messaging making it the first production implementation to support bidirectional push and write workflows. This design enables integration workflows to be triggered based on clinically relevant events like an appointment being scheduled or patient admission.
With both R^FHIR PatientAdmin and R^FHIR Scheduling, you will be able to “subscribe for updates” and receive messages when a patient event occurs instead of querying on an ad hoc basis. Each message will include a bundle of resources that provide the necessary information and context to trigger a workflow. For example, a R^FHIR-PatientAdmin_NewPatient message will include a “Patient”, “Practitioner”, “Coverage”, and “Organization” resource. For more examples, please review our developer documentation.
If you’ve used the Redox API before, your experience will basically be the same. The only difference with R^FHIR is the message contents will follow FHIR syntax instead of Redox JSON. If you’re more familiar with FHIR, keep in mind that each R^FHIR-DataModel_EventType combination will be populated by some bundle of FHIR resources and exchange will be message based (push or write).
Bidirectional FHIR
At this time, the major EHR implementations of FHIR have only made available queries. Primarily for information we’ve supported since the beginning of Redox with our ClinicalSummary Data Model.
R^FHIR will be the first production use of FHIR that supports writing into a system. An example would be a vendor that helps streamline registration using R^FHIR-PateintAdmin_PatientUpdate to update a patient’s demographics (address, phone number, etc).
Not RESTful FHIR (for now)
We are not currently supporting requests for individual FHIR resources.
After speaking with customers and looking at the majority of integration workflows we power today, it became clear that FHIR messaging was the right exchange framework to support first. The ability to query for granular pieces of information is great, but pre-packaged, clearly defined bundles of information are more relevant to the needs of our customers today.
We’re out to simplify and standardize the way healthcare shares data. The initial scope of R^FHIR supports integrations that have been executed across our network and are proven to support in demand workflows. Moving forward we will extend our FHIR support to include more data models and queries relevant to the needs of our customers.
Learn more
If you’re a developer interested in leveraging R^FHIR or a healthcare organization that wants to accelerate what aspects of FHIR are enabled for your organization, please watch our product launch webinar where our very own Niko Skievaski and Nick Hatt break down “everything you need to know about R^FHIR”.
For everything else, please contact our Solutions Team.
Stay in the know! Subscribe to our newsletter.
CDA®, HL7v2®, and FHIR® are the registered trademarks of HL7 and are used with the permission of HL7.