If you prefer the reading experience ofMedium you can follow us there as well.
Vicert Takes on a Challenge
When a client asked for a Redox Data Chateau service adapter, a lot of new keywords were thrown my way.
We had to look into every detail of “Redox”, “FHIR format”, “Data Models”, “resources” and “Clinical Summary” concepts in order to quickly create a bigger picture where everything needed for our project made sense.
The gist of our first working theory was as follows:
We would receive a FHIR standard conformant request, translate it to a Redox form of request, receive a response from Redox and then translate it back to a FHIR response.
It sounded simple enough and we assumed our task would consist mostly of repackaging. So we started a deep dive into health care information sharing and that is where we encountered our first real-world interoperability problems.
Breaking it Down
It turns out FHIR is a very carefully thought-out, extensively documented specification with the potential to enter every pore of health care. As an HL7 organization standard, guided by their experience, it uses existing logical and theoretical models to define a basic building block – Resource. This concept encapsulates core information used across many
implementations; e.g. Patient, Practitioner, Encounter, Observation, CarePlan and many more. A lot of effort was and still is being made to make the resources system sufficiently granular so they can better represent real-world concepts. The main purpose of defining resources like this is that combining them can support the majority of use-cases found in health care.
All resources can be divided into groups depending on their main concern. They can serve as FHIR abstract system infrastructure or pure clinical content (AllergyIntollerance, MedicationAdministration), to name one example of division, but they all share common technical characteristics (including XML, JSON and RDF representations). And resources are just the tip of the iceberg, even with the current 145 different resource types defined. FHIR further provides mechanisms – frameworks for working with resources:
- REST API
- Messaging framework
- Services framework
- Documents framework
In this project, Vicert used FHIR-provided REST API specification limited to Create, Read, Search and Transaction interactions.
(More on FHIR REST API can be found here.
Now that we have information sets defined and a way to manipulate them, at least from the FHIR side, we should take a look at the part of our system providing information and communicating with EHR vendors.
Another key player in our big picture is Redox. Clean documentation and their friendly team helped us understand and use this system.
Redox is a modern API for EHR integration making the exchange of health data easy. It is located between organizations willing to communicate. When you integrate with Redox, the first thing you don’t have to think about is what standard your EHR vendor is e.g. hospital, using, as many standards like CDA, X12 and HL7v2 are supported. As every data exchange is routed via them, the fact that they have their own standardized format (and in JSON too) available through REST-inspired API does not come as a surprise.
Redox also defined sets of information they found to fit most workflows. They call these data sets Data Models and differentiate between their Event Types (we worked with Clinical Summary and Notes Data Models). To start manipulating Data Models we had to set up a Destination point for receiving data and a Source in Redox so we could query sample data. The following documented setup guide and using client-provided Redox development environment proved easy and we soon had all elements of our interoperability play.
(More on Redox Data Models here (https://developer.redoxengine.com/introduction/data-models/)
-End of part 1 (part 2 is coming in less than a month – so stay tuned for more… in the
meantime you can read more about our FHIR on Redox Case Study:
and download our FHIR White Paper for a more detailed breakdown of this interoperability