In July 2019 Fabric successfully integrated with a Health System’s patient portal using SMART on FHIR for single-sign on, pulling in externally sourced electronic medical record information.
What does this collection of acronyms actually mean? And what does this have to do with the future of virtual care? So glad you asked. My hope is you walk away from this blog knowing exactly what FHIR is, what it achieves, and the potential it creates for the future of virtual care integrations.
What is FHIR exactly?
Fast Healthcare Interoperability Resources or ‘FHIR’ is a common language for describing healthcare resources. Developers of medical records and healthcare IT vendors use it to structure communications on patients, clinicians, and other healthcare data. These standard resources can be read or updated using FHIR APIs (application programming interface, for those not familiar), released by the systems containing the data.
For Fabric, the move to consuming FHIR services reflects a shift in the electronic medical record environment allowing for greater integration and interoperability. It helps us connect securely to healthcare data with minimal set up from the health systems. With a released FHIR API, we know exactly what we’re going to get and how to process it.
How has the FHIR standard changed things for patient, developers and health systems?
This isn’t the first time the Healthcare IT industry has been promised transparency and secure access to patient data. Couldn’t we just develop secured access to this health information? Why was this so hard?
The answer is interoperability. There are three parties to this integration problem:
- External healthcare developers (like Fabric)
- Individual health systems (like your local hospital system)
- EMR (electronic medical record) companies
Before FHIR the only option for an external healthcare developer (like Fabric) to do detailed integrations was to use the APIs released by EMR companies in whatever standards they saw fit. Unfortunately, these were often antiquated implementations with insufficient documentation, making them challenging for external developers to use. In practice, this meant a large investment of time and resources was needed by both the external developers AND the health system teams to decipher and develop around each EMR system’s API and data model.
Historically the core problem of interoperability was a knowledge gap: your local hospital systems pay for an electronic medical record system, but were then being asked to grant access and manage APIs they didn’t write themselves or understand from a technical standpoint. With FHIR, that burden has been appropriately shifted from hospital systems to EMR companies to standardize their APIs and provide the means to grant access to APIs and relevant documentation. With FHIR, productive technical conversations can start directly between Fabric and the EMR companies themselves.
So what exactly is Fabric doing with FHIR?
The initial use case was to perform single-sign on using existing patient credentials. Just like Spotify allows you to log in with your Facebook account or the New York Times lets you use your Google account, Fabric now allows the use of specific EMR systems’ patient logins to grant access to virtual care. We’ll automatically pull in existing demographic information in a single click to aid registration. Then upon future logins, we’ll automatically check for updated medications and allergies.
A future use case could involve embedding Fabric directly in the EMR, so clinical staff are not jumping between multiple screens and windows. The potential for workflow integration does not stop there, we could also aid clinical staff by pulling previous diagnosis or visit information directly into Fabric for more informed diagnoses. To drive patient satisfaction when virtual care is not appropriate for conditions, we could schedule in-person visits while the virtual care visit information automatically files to their chart.
Today FHIR is allowing patients to jump directly into the Fabric virtual care platform to and from their health system’s patient portal. Tomorrow, it could mean improving the user experience for patients and healthcare providers alike. Especially since current medical records and patient-accessed portals still solve for billing documentation rather than optimizing around patient care.
Ultimately our goal with FHIR, or any interoperability work, is to provide clinical staff and patients with a streamlined user interface of Fabric while powering it with data from medical records. The only thing tempering progress is the timeline medical record companies keep releasing the appropriate FHIR APIs. For now our application is on FHIR – ready and waiting.
