Our FHIR Story: Tales from the healthcare data interoperability revolution.
I asked a Cardiologist if he had any terrible stories about telling patients that a painful test they had just done at a different institute would have to be repeated because the systems didn’t exchange records. “Actually, most patients have come to expect it, unfortunately.” The continuing lack of healthcare data interoperability has become so well known that even patient’s standards have fallen. Patients have become accustomed to their health narrative being fractured, understood only in vignettes.
At Story Health, we focus on understanding each patient’s whole story to help specialists adapt the best virtual care plan for that patient. Health records are a foundational part of that story. We’d like to share our experience working with health records especially given all of the new government rules opening up access to data sharing.
I’ve been working with data systems throughout my entire career. Starting as an engineer in Google’s core Ads and Payments, I joined healthcare eight years ago when I co-founded Alphabet’s Verily, where I was Head of Software.
Blocking healthcare data by various parties has been one of the most significant barriers to healthcare data being used to improve care.
What is information blocking, and how are the new rules breaking down barriers?
Barriers to data sharing are multifactorial, including lack of incentives, technical problems, missing standards, and concerns about privacy, security, and safety. Recently, the Cures act tried to take on some of these issues by releasing new ONC information blocking rules. These rules set technical standards (SMART on FHIR) for exchanging a “core” data set and mandate all parties to work together to solve these problems. These rules are going into effect in the next few months, and the rollout has already begun.
So, now that the implementation phase is beginning, what is the reality?
FHIR (pronounced as “fire”) is a standard that allows for all Electronic Health Records (EHRs) and other computer systems to speak the same language so that they can communicate over the internet about a patient’s record. The standard is built on modern internet concepts that today’s information technology tools understand. As a technologist, FHIR is a breath of fresh air compared to many of the antiquated healthcare systems still in wide use today.
SMART allows us to build apps on this new standard inside EHRs through a common set of interfaces for authenticating and authorizing clinicians to access systems.
Most of the legislation to date has been about patients and ensuring they have access to their own records. The new rules mandate patient’s access to their records. Hurray!
Unfortunately, this still means needing to navigate a plethora of institution-specific systems. There is no one place where all patients can go to get all their data.
Once a patient has access to their data, there isn’t a straightforward way of giving it to another institution. You can walk into your doctor’s office and show them your MRI report in your patient portal, but they will still have to make a separate records request if they want to see for themselves. These records requests can make use of the SMART on FHIR protocol if the institutions have a connection.
So how does FHIR work in reality? The good news is that all of the major EHR vendors are doing their part to be part of this effort; in fact, every certified EHR vendor is required to make this work. FHIR enables one institution to tell another institution everything it knows about a patient: conditions, labs, vitals, notes, documents, and more. FHIR even supports the transmission of progress notes and other clinical narrative documents, where so much meaningful health history lives. I’ve used FHIR from multiple EHR vendors, and I can say that it is possible to build a system to connect things now.
Having a lingua franca to speak across systems doesn’t necessarily mean that systems will understand each other. Just because you speak English in your local neighborhood, that doesn’t mean you will understand someone from halfway around the world that speaks English. Idioms, vocabularies, slang, … so much room for regional dialects.
The same is true in FHIR. Different coding schemes: LOINC, ICD9/10, SNOMED CT, CPT, RxNorm, and more mean there are many ways of saying the same things, even in the same coding scheme! Add on even more billing-based idiosyncrasies onto these schemes, and you start to see where this is going. For example, kidney function (eGFR) can be encoded with many different codes, some based on whether the patient is African American, some independent. Diagnosis codes are notorious for being obtuse because there is reimbursement from some codes while not for other similar codes.
ONC has tried to remove some of the ambiguity here by mandating a subset of the language called US Core. These rules substantially cut down on the language’s ambiguity, but there is still much to do. For example, there are still multiple ways of coding blood pressure in LOINC, and the way your institution does it may be different from mine, and we may need a translator or have our institutions expand their grasp of the language.
The trick to getting compatibility is to see the actual data. Unfortunately, there is no way to know how an institution or even an individual practice creates data without shadowing genuine clinical care and running systems in practice mode and seeing how they work. Many institutions and EHR vendors employ clinical ontologists whose job is to ensure that real-world data works with new applications.
What about implementation at institutions? I mentioned that all of the EHR vendors are well down the path of supporting FHIR. These vendors are actively engaged. Each has test sites where you can try their APIs and ensure that you are interpreting things correctly.
There is an added barrier which is institutional rollout. Even though the EHR vendors support the new standards, getting the upgraded systems installed at all of the many clinical institutions will take many years.
Then there is the problem of each of the connections between each institution. EHR vendors have been working hard to unlock this as much as they can. Institutions running Epic, for example, can see the records from all other institutions running Epic about a specific patient. Unfortunately, communication between systems with different vendors has not been as forthcoming. Working across systems requires alliances and exchanges and significant technical work that exchanges typically don’t have the resources to implement. Efforts such as Carequality are working to standardize and support these clinician-to-clinician exchange scenarios.
What about interaction? Imagine if all the apps on your phone could only read data already on your phone but didn’t allow you to create anything. Pretty limiting, right?! Most use cases for interoperability in healthcare IT have focused on just reading the data out. After all, there is a burning clinical use case to know what happened with a given patient. The exciting next step is where all of the apps can start asking the EHR systems to do things. We can have apps that allow new ways of creating clinical orders, sending messages, adding home measurements, and more.
There are certainly safety concerns here. Do we trust home measurements? Many EHR vendors are thinking about this and proposing clever ways of expressing the provenance of data so that clinicians can assess different levels of certainty in various data sources. ONC explicitly laid out safety concerns as a place where we should be thoughtful and carved out an exception to the data blocking rules.
CDSHooks is another API that lets apps interact with the existing EHR workflow. Clinical Decision Support (CDS) in the EHR has become the best example of apps built on top of the EHR. These CDS systems alert clinicians about drug interactions when prescribing a new medication, showing relevant guideline-based recommendations, and generally assisting clinicians.
In conclusion, this is an exciting time in healthcare to use longitudinal data to build new healthcare applications that assist clinicians.
We’ve made considerable progress getting our first product integrated into the EHR. A few weeks ago, we received our Cerner Code validation, indicating that our system has been tested with Cerner and ready for integration and distribution. More news to come on implementation with health systems soon!
