In the previous FHIR blogpost we announced our commitment to integrate our systems with the FHIR standard. We went over the specifics of what FHIR is and why we consider its adoption a crucial move for us.
In this post we will explain with further detail how exactly our operations are being integrated with FHIR, describing the relevant resources and how we use them to describe our data.
FHIR (Fast Healthcare Interoperability Resources) was conceived by HL7 to answer the industry-wide call for a modern healthcare data standardization system capable of meeting current demands of usability and interoperability. Its core design principle is speed and ease of adoption for developer teams, together with a tight focus on interoperability between systems. It features a robust data model based on differentiated resources, while running on a RESTful API.
At Tucuvi, we firmly believe that interoperability is one of the key tenets of value-based healthcare. It promises to speed up the exchange of information, therefore lowering overall costs. But crucially, it’s also highly beneficial for patients, since treatment effectiveness is highly dependent on the quality and readiness of clinical data and its ability to be shared between medical teams. Integrating our systems with FHIR is a natural step for us as a value-focused healthcare company.
At the core of the FHIR standard lie its resources, which define the information contents and structure for healthcare data management. In essence, resources are packets of information used to exchange or store data that satisfy most use cases in the clinical setting. Importantly, resource contents can be stored as JSON, XML and other base standards commonly used in general application design. In order to integrate Tucuvi’s data structure with FHIR we've first needed to identify our core data elements and fit them within the FHIR resource map.
In a nutshell, Tucuvi provides an automated, phone based follow-up service based on advanced AI technologies that is fully customizable according to the needs and requirements of both healthcare professionals and their patients. Lola, our medical virtual assistant, calls patients on a scheduled basis and routinely collects clinical information through empathic, natural conversations. This information is then summarized and relayed to their doctors through our clinical dashboard.
With this in mind, we can establish the following core data elements:
The first two are easy to fit within FHIR’s paradigm. Patients can be directly mapped to the patient resource and doctors and other medical personnel can be mapped to the practitioner resource when needed (in fact, we have adopted practitioner as the standard term to refer to medical personnel in all our internal communications).
Protocols are a little trickier since there is no one-to-one relation with an existing FHIR resource. In practice, however, the most relevant piece of information from a given protocol in terms of interoperability with our clients is its identifier or ID. This datum is enough to link a patient with their required follow-up plan and establish all the clinical variables that will be recorded. If for any reason we decide that a more detailed registry is required for our protocols, there are available FHIR resources such as the care plan resource, which we can easily adapt.
The clinical data gathered during phone calls with patients can in turn be directly mapped to a diagnostic report resource, with clinical variables corresponding to an observation resource. For compound variables such as blood pressure, we can use the component field within the observation resource.
Finally, we make use of the bundle resource to group our other resources together as needed. This enables us to neatly package whatever information is relevant to any request.
It is important to note that all these resources are compatible with FHIR R4B, the latest release by HL7, and are also backwards compatible with R4, STU3 and DSTU2. This implies a full degree of interoperability with most existing FHIR-based EHRs.
Mapping our data to relevant FHIR resources is only one half of the cake. The other half is building an API that enables us to exchange these resources with other FHIR-compliant systems. We have chosen to rely on Google’s Cloud Healthcare API tools for this task due to its ease of use. As a bonus, it provides direct compatibility with other Google Cloud services we are already making use of. This API operates using the OAUTH2 authorization standard, ensuring security as well as interoperability.
We currently have two operations defined in our API: receiving new patients and sending clinical data collected during a call.
Receiving a new patient:
At this stage, our API receives a FHIR bundle consisting of a patient resource and an observation resource. The only information contained within the observation will be the corresponding protocol ID. This ID, together with the patient’s details, is enough to start scheduling phone calls. This process is fully customizable and adaptive, since we can make use of specific properties within FHIR resources, or by referencing other resources such as the care-plan mentioned above.
Gathering and sending clinical data:
As Lola speaks with our patients on the phone, she gathers key clinical variables. To relay this data in compliance with FHIR, our API can send a bundle containing the patient resource and a diagnostic report. The result property in the diagnostic report links to a corresponding observation resource. This observation in turn contains all the data collected during the phone call. We also offer the possibility of directly sending a bundle containing a patient and an observation, where the observation resource once again contains all the data collected during a call.
With these steps we are ready to integrate with new FHIR based systems immediately. We are also able to translate all our existing data into FHIR resources. As we gain experience through new integrations, our tools are maturing and our capabilities are increasing greatly. Our goal is to always be at the cutting edge of data management, striving to always use the tools that are at the forefront of technology. The adoption of FHIR is a key move for us in this direction.
On your marks, get set, FHIR!!
Here are some good reads to further your knowledge:
Today’s system may be handling data, but tomorrow’s systems will need to exchange data. HL7® FHIR® is a mature standard for global health data interoperability that’s ready to meet the increasing demand.
FHIR validation and testing tools can reduce variations in implementation, thus supporting interoperability and health data exchange.
FHIR is bringing the heat to healthcare analytics and interoperability, offering new capabilities to enable truly patient-centered, data-driven care.