Healthcare has been historically behind the times when adopting new technology. That’s not news. It is seriously frustrating, though.
We have all waited for test results to be faxed to our doctor, taking days to get much-needed answers. Prescriptions are still manually called into our pharmacists, with the potential of getting the dosing and even the medication wrong. Claims are emailed in spreadsheets from providers to payers, creating a high potential for inaccuracies, incorrect billing, additional manual work, and poor member experience.
This all occurs in the same world where products are bought, procured, and shipped seamlessly to your doorstep with a click of a button. And these all represent challenges around integration, which is how data and information are transferred between disparate systems.
Picking up the pace
The healthcare industry and regulators have embarked on a vast project to address these shortcomings. One of the main tools in their arsenal is a new integration standard advocated by both government and industry called FHIR (Fast Healthcare Interoperability Resources). This standard outlines the language and protocols that systems should use to communicate and understand each other.
Agreeing on a common standard represents a huge potential to address these aforementioned challenges. In addition to providers, payers stand to gain a large benefit from adopting FHIR in a variety of ways. It enables better sharing of data between payers and providers, presenting a large opportunity to improve billing and claims accuracy. Member experience and outcomes can be improved by creating a better overall view of member health and associated provider interventions. Consistent modern integration protocols allow standard software development technology and tools to be used to easily transfer data securely and efficiently between providers and payers.
All of these present a potential material benefit to payers. FHIR is also becoming a regulatory requirement where governments are mandating these organizations adopt the standard by specific deadlines.
While many organizations are on the journey to implement FHIR, it has been slower than many would like. To support this change, both on-premise and cloud vendors are deploying out-of-the-box FHIR services and servers, providing a standard technical framework to deploy FHIR capabilities and creating a jump-start so organizations don’t have to roll their own.
Not the tightest standard
Payers have special considerations and challenges as they adopt the FHIR standard. Some of these are a function of the FHIR standard itself, and some are indicative of the complexity of healthcare data integration in general. To solve these challenges, payers need to understand and address all these issues to realize the potential benefits that have been advertised.
Healthcare data is complex, as there are lots of types of data entities (which FHIR calls “resources”) that represent all the types of data that need to be communicated between healthcare systems. FHIR, in trying to achieve the goal of covering the “breadth” of resources necessary, has created gaps in defining these resources “in depth.”
In other words, the standard is somewhat loose and highly open to interpretation.
The “appointment” resource is a good example of this. Appointments represent the information required to schedule an appointment. This would seem to be pretty simple, capturing basic information like date, provider, patient, and location. The appointment resource has an element named Actor. But the Actor is defined in the FHIR standard as “A Person, Location/Healthcare Service or Device that is participating in the appointment.”
Based on this definition, what should you put in there? Is it the nurse, the physician, or some other supporting healthcare provider or device? It’s not clear, so the consuming system may assume it means something very different from the data-producing system’s original intent. This requires the producing and consuming systems to agree on what “actor” means in advance. If there is ambiguity in something as simple as an appointment, think about how difficult it is to align on more complex entities like “Claim” and much less-structured clinical resources such as “Problem” or diagnostic resources like “Report” (representing those test results you are waiting on).
Considerations to ponder
Just conforming to the standard does not mean you are done. You must go through a process in which you agree on what each field actually means in detail, increasing the up-front analysis and requiring teams to go back and forth to hash out what the ultimate meaning is, which greatly increases the time and complexity associated with any FHIR integration.
Different resources have different levels of maturity and clarity. Payers can take advantage of a higher level of maturity around resources like “Patient,” “Practitioner,” and “Healthcare Service,” but to build truly deeper member insights, they need entities like “Clinical” and “Diagnostics” (which are much less mature and much more open to interpretation). This type of EHR clinical data is highly variable and unstructured in many instances, creating a big lift for the providers to transform it to the FHIR standard — and, in turn, provide to a payer to ingest and understand so they may drive member insights. This unstructured clinical data may only represent 30% of your data, but it will require a large majority of the effort to translate and interpret.
When implementing FHIR, you also need to think about more technical considerations in addition to the looseness of the standard. When you create or process FHIR data, you essentially have to create a copy of that data. Those who understand data architecture and the nature of data understand that creating copies has a lot of adverse knock-on effects. When there is a copy, it is important to ensure that the two copies do not get out of sync.
In dynamic systems — particularly with resources that change like patient or provider — replicating changes to each copy can present large technical and operational challenges. How often does the provider send updates? Do these updates represent a new set of data that overwrites existing data, or should you just track deltas (changes)? If I can’t find the existing “Patient” or “Practitioner,” is there a risk that I will create duplicates to where I don’t know what the actual master record is?
From a Payer perspective, these data issues can fundamentally impact your ability to get a full 360-degree, historical view of your members.
A good first step
You need to decide how much to copy and maintain in FHIR. Healthcare data (and particularly EHR data) can have a large amount of historical data. When this data is loaded into an FHIR server or service, you need to determine how much history you want to maintain. Do you create just a short time horizon — meaning you go back to the source data often — or do you create a large amount of data (which causes synchronization issues and challenges where to store it all)?
When thinking about new FHIR services from cloud providers, these considerations are even more important, as they can be real drivers of the overall cost of the platform. If you decide to transform in real-time and not maintain a copy, you can pay considerable processing fees and have potential performance issues where you need to go back to the master every time you access data. If you load a large amount of historical data, you pay to store that data and process and manipulate it on the cloud platform. If you want to pull data from your cloud service to on-premises or another cloud provider, you also pay egress fees that charge you for data when it moves off the platform.
It’s a lot to consider. These are not new challenges and have been considerations around data-intensive systems from their inception, but the FHIR standard provides very limited guidance around how to address these deeper functional and architectural challenges and has the very real potential to exacerbate them.
Many of these issues may be addressed over time. The standard will become more concrete and less open to interpretation. Key line-of-business systems will be migrating to the cloud, and all systems may start to use the FHIR standard — natively becoming the “lingua franca” of how systems persist and communicate across a healthcare data ecosystem (and reducing the need for copies).
However, all these solutions are years away, and your members, regulators, and other stakeholders are not going to wait. For many of these near-term considerations, there is not one answer. It requires people that have both strong functional and technical knowledge to weigh the pros and cons, understand the implications, and devise an approach that best reflects your strategic priorities.
Being prepared, starting small, and getting initial wins is a good first step.
