The Fast Healthcare Interoperability Resources (HL7/FHIR) is probably the most widely adopted standard for healthcare data. In the USA it meets data sharing requirements that will become law sometime in 2023 and other countries like Scotland, where FHIR is the chosen standard. Already, FHIR data is two thirds of the way standardised. Where it isn't already a standard, FHIR will surely soon be. At the same time, data analytics in healthcare is plagued by lack of standardisation and disconnectedness. In other words, before healthcare data can be used in analytics, it needs to be standardised and aggregated. It may seem straightforward to use FHIR for analytic applications. Dozens of failed projects attempted to run analytics on FHIR data. A recent review in the Journal of the American Medical Informatics Association found that in more than 90% of FHIR analytics projects, FHIR is only used as infrastructure to exchange data between systems.
Before more attempts to use FHIR for analytics result in expensive failures, we provide two reasons that should be enough to make you think of other solutions:
1. FHIR is not a Data Model
The purpose of FHIR is to exchange information in real-time so that different software systems even from different vendors, can exchange information. For example, a clinical decision support system can get information from a pathology system that show a patient is at high risk of a stroke, and cross that information with a patient administration system that shows the patient is about to be discharged and alert staff quickly to avoid an error. To achieve such a level of interoperability between systems means that messages sent from one system are understood by another and this doesn't require a data model.
To understand this better, consider diagnostic codes. Some systems use ICD-10, and some systems use SNOMED-CT. Other systems don't use diagnostic codes at all. As long as a FHIR message with a diagnosis is explicit about which of the options is used in the message, it can be "understandable" by any receiving systems. FHIR provides the flexibility for the sending system to use whatever diagnosis representation works best for it.
Analytic application require not only that all diagnoses be understandable, but also that all systems use the same coding system. The most commonly used data standard for analytics is OMOP which dictates that all diagnoses be converted to SNOMED-CT. To do so efficiently, all diagnoses are usually converted to SNOMED during the transformation of the data from the source format to OMOP and Evidentli Piano does that almost entirely automatically.
2. FHIR is not Relational
When exchanging information as quickly as possible and with the fewest dependencies on other systems, a single FHIR message should contain all the information needed to interpret the data. That means that a lot of information is duplicated many times in multiple messages. For example, the patient name might appears in every message that describes a procedure, diagnosis, medication order etc. for that patient. Messages are also encoded inefficiently as text. Research conducted by Evidentli shows that OMOP require 70 times less storage than FHIR. This means a lot of storage is required which is reasonable when analyzing a handful of messages, but poses serious scalability limitations when dealing with, trillions of messages. Networks speeds not withstanding, loading 15Gb of relational data instead of a 1Tb of FHIR messages, would often make the difference between success and failure for an analytics system. Further issues exist with analyzing that much more data etc.
Using FHIR for analytics is like using an iPhone to open a jar: it is a very good tool for its intended use but unsuitable for the task. These two reasons alone should suffice to dissway anyone from trying to use FHIR for analytics, but this is not a comprehensive list. If you want to run analytics on real-world healthcare data, you need OMOP. The easiest, quickest and least expensive way to get OMOP is with Evidentli.
Leave a Reply
Comments, questions or queries? Let us know!"