Payers on FHIR
True to its name, FHIR is hotter than ever right now. We’re seeing widespread adoption of technology by providers and their EHR vendors, large tech companies like Apple and Samsung, and a host of smaller shops entering the market, bringing new tech talent to build FHIR applications for physicians and patients alike.
Yet one party is conspicuously absent in much of the discussion, and I think it’s far past time they threw their hat in the ring. I’m talking about Payers — commercial insurance carriers who pay for the bulk of healthcare, who are arguably best suited to solve some of the biggest challenges facing the FHIR standard today.
It’s been a few years since the first implementations of the new FHIR standards. Since then, most EHRs now support the core clinical resources through FHIR APIs. However, FHIR doesn’t stop there — there are the administrative resources, such as registration and scheduling, and the financial resources, such as insurance policy details and claims management. These resources, for the most part, have not been finalized and are seeing varying levels of support among EHR vendors and provider organizations.
However, there is a conceptual flaw in the current design for financial resources. The entire FHIR workflow centers around pulling data directly from an EHR — effectively, using API to pull records from the provider organization’s database. While this makes sense for clinical resources, such as observations, medications, family history, etc., it fails to address the operational needs regarding financial information.
Under the current flow, the patient-provider, provider-payer, and patient-payer interactions are all achieved through different standards and without much crossover. In a FHIR environment, a patient will interact with a provider’s EHR through a FHIR API. However, the provider-payer interaction will largely take place using the X12 EDI standard, typically through a third-party clearinghouse. Patients will interact with the Payer through an app or web portal, with no standard means of data exchange.
In this environment, a FHIR user only has access to snapshots of data received from the Payer. If a FHIR client retrieves a request/response for eligibility (basically a “status update” on an insurance policy), they will receive an outdated response from the last time the Provider requested that information from the Payer. If a patient wanted to know their current insurance status, they would have to call their Payer directly or login to the Payer’s app/web portal.
This is particularly problematic when it comes to managing claims. Currently, once the Provider has sent a claim over to a Payer, any FHIR clients will be stuck with a claim that simply says “Out to Payer” until the claim is adjudicated and the Payer returns a response.
Additionally, the patient will have to manage claims from different providers separately. For example, if a patient undergoes surgery at a hospital, and the surgeon, anesthesiologist, facility, and subsequent physical therapist are all separate entities, there is a good chance that the patient will need to manage their claims through four separate FHIR APIs (with varying levels of support). The patient would have no real way to know the current status of each until all of them have been adjudicated. Even if there clinical resources were shared with the patient’s PCP, or were consolidated in any of the four EHRs, the claims would likely still all be managed separately.
Ideally, there would be a way for the patient to centralize claims data, and a way for FHIR clients to receive the most up-to-date information directly from the Payer.
I would propose that Payers offer FHIR APIs of their own. Naturally, they would not support all the same resources as EHRs, but would at least have endpoints for any financial resources where the Payer would have the most “up-to-date” data available. This would allow claims to be submitted to payers directly via a FHIR transaction instead of an X12 837 transaction, and any subsequent updates between the two systems would be performed with FHIR requests.
This opens up new avenues for FHIR clients to receive the most relevant data. For example, let’s say a patient requested the status of a claim from an EHR using a FHIR request, and that claim was currently out to the Payer. The EHR could pass the request through to the Payer’s FHIR API, retrieve the updated info from the Payer, update their own record of the claim, and pass the response through to the FHIR client user. On the other hand, the FHIR client could completely skip the EHR at this point, requesting data directly from the Payer. This would allow the patient to review any outstanding claims, check the current status of their insurance policy, compare the Payer’s system with the Provider’s, and much more.
Certain financial resources may be managed entirely within the Provider’s billing system — Namely accounting/payment resources, such as accounts, charges, payments, and adjustments to name a few. However, nearly all of the EDI transactions — policy status, coverage eligibility request, claims, explanation of benefits — would only offer snapshots when pulled from the EHR. Other Payer-dependent information — Referrals, Prior Authorizations, Cost Estimates —must be accessed in real-time to be useful. By-and-large, this data would be better suited to come directly from the Payer.
With Payers supporting FHIR, developers can tackle one of the most important challenges facing FHIR today — Authentication.
When registering a new user, it is difficult to positively identify that the user is a particular patient within a health system with enough confidence to share sensitive PHI, and there are very few trusted partners in the space capable of solving this problem in a user-friendly way. Developers need a way to absolutely tie a user to a medical record, but in such a way that it does not overburden patients or providers.
Enter Payers on FHIR. Payers tend to be more web-savvy than the average physician practice, having built their own consumer-facing portals, with many building additional interfaces for HR systems and brokers.
Payers have a much more centralized view of the patient, with a single member ID, a thorough registration process, and (most importantly for this use case) some validated form of communication — often requiring an email address.
This means that payers could be used as trusted partners when authenticating a patient. Throughout the claims process, providers and payers share their internal IDs for any given patient. Once a patient has signed in to their payers FHIR API, they could pass along their patient identifiers to an EHR API — essentially, another sign in flow.
Payers can also help with account reconciliation. For the most part, Payers are purely transactional, and therefore less plagued by duplicate records. Patients may be added to a provider’s system from multiple points-of-entry, and most EHRs require some means to “combine patients” in case a duplicate is created. Additionally, many patient and provider FHIR apps attempt to create a holistic view of a patient’s medical record — synchronizing records from multiple sources, possibly generating duplicates in the process. For Payers, there is no need to synchronize data from disparate sources — a single login will tie to a single member.
Pathway for Innovation
By connecting payers to the FHIR ecosystem, countless possibilities open up to developers looking to solve industry-wide problems.
From a workflow standpoint, some of the toughest, most time-consuming tasks could be optimized with a simple FHIR endpoint, including Referrals, Prior Authorization, and Cost Estimates. Any place where a Provider or Patient needs and answer from the Payer, a FHIR API could spare someone from waiting on a response or filling out a form or placing a phone call on hold, potentially saving the industry billions in waste.
From a public reporting standpoint, various government agencies would be able to cut costs on gathering and processing data from payers. For example, payers could offer FHIR endpoints to show their various plan designs, allowing the states’ Health Exchanges automate their annual data processes.
Employers and HR software companies would no longer need to stress over the cost of integration when switching to a new health plan, as payers would share common integration standards. Consumer apps would be able to move with the user as they change jobs or health plans, simply by logging in to their new payer’s FHIR API.
From a sheer talent standpoint, more software developers and finance-savvy professionals can engage in the space without learning all the ins-and-outs of EDI and X12 transactions. We’ve already seen FHIR tear down the barriers to entry surrounding clinical resources by HL7v2 — for financial resources, that barrier is built with X12.
I do not believe FHIR is the end-all solution to all the technical problems in the industry. But I do believe it represents real progress, and it enables new players to enter the market and drive change without being slowed by sluggish data integrations.
I believe one of the greatest strengths of the FHIR movement is deeper than simply its technical achievements. FHIR has brought a spirit of cooperation to the industry — where the exchange of data is required to solve real problems, organizations are putting short-term convenience and “how we’ve always done it” aside, and instead moving towards “how we all should do it”.
And I believe that payers, with such an important role in the industry, can close the gaps in the current FHIR spec and spark real progress in the HealthTech industry with just a little cooperation.