What we don't do
Flexpa is the simplest and easiest way to connect your patients' claims data, which can power a number of use cases across healthcare, benefits, and fintech. However, claims data is not always what you're looking for. Rather than try and square peg a round hole, we want to make sure you're equipped with the right tools to solve the right problems from the wide range of interoperability and API products on the market today.
Below are some other common interoperability problems that organizations in healthcare face and some of the solutions available today to help you.
We'd love to discuss more about how claims and other payer data can fit alongside and supplement these other solutions, so contact us to chat!
#Provider Directory Data
A clean list of providers and organizations is actually surprisingly hard to come by. Providers switch organizations, change addresses, and change names. Organizations are merged, acquired, and closed.
For your use cases and problems, you may need to know the provider's name, address, phone number, taxonomy code, and NPI. You may also need to know the organization's name, address, phone number, and taxonomy code. While Flexpa includes some provider data in our claims data, such as a patient's prescribing provider for a MedicationRequest resource or a patient's attending provider for an Encounter resource, a full foundational list of providers and organizations may be beneficial.
The CMS has the National Plan & Provider Enumeration System (NPPES), which is a free data set, but it is not always up to date. They offer a bulk download, an API, and a user interface to interact with provider data.
There are also a number of commercial solutions that provide provider data:
Flexpa claims data is a powerful tool alongside provider directory data in that they form two of the main three factors (a correct list of providers, a list of available services and costs, and prior healthcare usage) to help patients properly plan and navigate their care.
#Price Transparency and Cost Data
Understanding providers and organizations is only the first piece of the puzzle. Patients and vendors also need to know what services these providers offer and how much they cost. Thus, we stumble upon the raison d'être of price transparency.
Between the trifecta of legislation and regulation of the CMS Hospital Price Transparency, the CMS Transparency in Coverage Rule, and the No Surprises Act, price transparency is a hot topic in healthcare. For further detail, we recommend this summary here.
These rules mean that all hospitals and payers must publish their price transparency data in a machine-readable format. This data includes a list of services and their costs. This data is available for free and can be used to power a number of use cases.
However, these are large files and often difficult to track down. This open-source initiative is a great resource for processing price transparency data.
There are also a number of commercial solutions that aggregate, normalize, and provide value-add services on top of this data:
Flexpa claims data is a powerful tool alongside price transparency data in that they form two of the main three factors (a correct list of providers, a list of available services and costs, and prior healthcare usage) to help patients properly plan and navigate their care.
#Eligibility
Understanding if a patient is eligible for a given service or benefit is the first step on the critical path to providing care and later receiving reimbursement. Claims clearinghouses and eligibility verification services are the most common solutions for this problem.
Flexpa claims data can be powerful to augment eligibility data, as it can provide a more complete picture of a patient's benefits and coverage. For example, Flexpa claims data can help you understand a patient's spend towards their deductible or improve your success rate of predicting the actual cost, reducing backend administrative time for corrections to bills.
#Networks
Claims clearinghouses act as hubs that allow healthcare practices to transmit electronic transactions to insurance carriers in a secure way that protects patient health information, or protected health information. These networks are some of the oldest and most ubiquitous in the healthcare industry and are used by all types of healthcare providers, including hospitals, clinics, and individual practitioners. At this point, they have broad coverage to almost all payers, as many clearinghouses have data exchange agreements with one another.
As a result of the HIPAA transaction rule, clearinghouses are required to use the X12 standard, which can be challenging to implement and maintain. As a result, today eligibility requests are primarily serviced through clearinghouses using that standard.
Some examples:
#On-ramps
X12 is an old and difficult standard, so a number of companies have built on-ramps to make it easier to use. These on-ramps are often built on top of the X12 standard and are used to translate X12 into a more modern format, like JSON. This makes it easier for developers to build applications that can consume eligibility data.
These on-ramps have an additional cost on top of any clearinghouse network fees. However, they can be a good option for developers who are looking to build applications that consume eligibility data that are looking to move more quickly.
Some examples:
#Coverage Discovery
Understanding a patient's benefits and coverage is a critical step in providing care. This is especially true for patients who have complex medical histories and are seeing multiple providers. In order to provide the best care, providers need to be able to access a patient's full benefits and coverage information.
Coverage discovery is similar to eligibility, but instead of using a member identifier, you use a patient's name, date of birth, and address to discover their benefits and coverage.
Flexpa claims data can be powerful to augment coverage data from payers, as it can provide a more complete picture of a patient's benefits and coverage. For example, Flexpa claims data can help you understand a patient's spend towards their deductible or improve your success rate of predicting the actual cost, reducing backend administrative time for corrections to bills.
Some examples:
#Summary of Benefits and Plan Design
Understanding a patient's benefits and coverage is the second step on the critical path to providing care and later receiving reimbursement.
Flexpa's API provides nominal details about a patient's benefits & coverage via the Coverage resource.
This pairs well with other vendors that do offer summary of benefits and plan design information, allowing developers to ascertain the specific plan a patient is on and link it to the detailed plan structure.
This can be useful for a number of use cases, including determining whether a patient is eligible for a given service or benefit.
#Vendors
#Clinical Data
Aggregating a patient's clinical history from other providers is a critical step in providing care. This is especially true for patients who have complex medical histories and are seeing multiple providers. For example, a patient with diabetes may be seeing a primary care physician, an endocrinologist, and a nutritionist. In order to provide the best care, these providers need to be able to access the patient's full medical history.
Flexpa claims data from payers can be powerful to augment clinical data from providers, as it can provide a more complete picture of a patient's care. For example, Flexpa claims data can help you understand whether care was provided in-network or out-of-network, which can help you understand the patient's total cost of care.
There are three main paths for clinical data - patient authorized access, direct integrations, and health information networks.
#Patient Authorized Access
Just as Flexpa offers access to payer data via patient authorization, there are a number of companies that offer access to clinical data via patient authorization.
With these companies, a patient inputs their portal credentials to access their clinical data from their provider's EHR system.
This data can be used to provide a more complete picture of a patient's care, which can be useful for a number of use cases, including care coordination and population health management.
The data is typically provided in a FHIR format, which is a modern, standardized format for exchanging clinical data.
Some examples:
#Direct Integrations
Direct integrations with provider EHR systems are another way to access clinical data.
While these integrations can better facilitate full push and pull workflows and provide a more detailed picture of a patient's care, they can be complex and time-consuming to set up.
They are typically only available to provider organizations or business associates of provider organizations involved in the treatment process, such as EHRs.
These integrations are typically completed through a variety of formats, such as HL7, FHIR, custom APIs, or flat files.
Some examples:
#Networks
Health information exchanges (HIEs) and health information networks now exist at both regional and national levels. These networks are designed to allow providers to securely exchange clinical data with one another.
These networks are often built on top of the C-CDA standard, an XML format, and use a query (search and retrieve) model for pulling data. Given that they are most useful with a treatment purpose of use, they are really only usable today for provider organizations or business associates of provider organizations involved in the treatment process, such as EHRs. They also typically require reciprocity - that is, providers must respond to queries from other providers with their unique clinical data in order to retrieve data from others.
Some examples:
#On-ramps
C-CDA is a complex standard, so a number of companies have built on-ramps to make it easier to use. These on-ramps are often built on top of the CDA standard and are used to translate CDA into a more modern format, like FHIR or JSON. This makes it easier for developers to build applications that can consume providers' clinical data.
These on-ramps have an additional cost on top of any HIE or HIN fees. However, they can be a good option for developers who are looking to build applications that consume provider clinical data that are looking to move more quickly.
Some examples:
#Wearables Data
As the healthcare industry continues to evolve, the role of wearables and connected health devices has become increasingly significant. These devices can offer continuous monitoring, alerting, and insights that traditional healthcare cannot match in frequency or convenience.
Devices such as Fitbits, Apple Watches, and Oura Rings are becoming increasingly popular, and the data they collect can be used to improve patient care and outcomes.
#Data sources
Wearables and connected health devices collect a wide range of health data, from basic metrics like steps taken, heart rate, and sleep patterns to more advanced metrics like ECG, blood oxygen levels, and stress indicators.
This data can be instrumental in providing a more comprehensive view of a patient's health, especially when combined with clinical and claims data.
Some examples:
- Fitness Trackers: Devices like Fitbit, Garmin, and Xiaomi Mi Band.
- Smartwatches: Apple Watch, Samsung Galaxy Watch, and Wear OS devices.
- Specialized Wearables: Devices like the Oura Ring (for sleep tracking) and Whoop Strap (for recovery and strain).
- Connected Health Devices: Glucometers, blood pressure monitors, and smart scales that can connect to apps or the cloud for data storage and analysis.
#On-ramps
Given the wide variety of devices and proprietary data formats, accessing wearable data can be a challenge.
On-ramps or middleware solutions can facilitate the integration of this data into healthcare applications, translating proprietary data formats into more universal or standardized formats, making it easier for developers to work with.
Some examples:
#Deidentified Data
Understanding healthcare trends, health system performance, research, and policy decisions often requires analysis at a larger scale, where individual patient identities are not necessary. This is where deidentified claims data comes into play.
Deidentified claims data is information derived from individual health insurance claims that have been stripped of any personal health information (PHI) to maintain patient privacy. This includes removing or altering details like patient names, addresses, social security numbers, and any other information that could be used to identify a particular individual.
The deidentification process is governed by the Health Insurance Portability and Accountability Act (HIPAA) Privacy Rule, which provides two methods to achieve deidentification: the Safe Harbor Method and the Expert Determination Method.
The Safe Harbor method involves removing 18 types of identifiers, while the Expert Determination method involves a statistical risk assessment performed by a qualified expert to determine that the risk of re-identification is very small.
#Networks
Deidentified information networks and aggregators now exist at both regional and national levels. These networks are designed to allow data holders such as payers (for claims data) and providers (for clinical data) to securely exchange deidentified information on relevant populations.
The formats for this exchange are typically custom, as there is no standard for de-identified data. However, the most common formats are CSV and JSON.
Some examples:
#FHIR Data Store
A FHIR (Fast Healthcare Interoperability Resources) Data Store is a repository that allows you to store, retrieve, and manage FHIR-formatted clinical data efficiently.
Using a FHIR Data Store allows healthcare organizations and software developers to make the data from payers, electronic health records (EHRs), and other systems interoperable and easily accessible for various health IT applications.
Given that Flexpa provides access to FHIR formatted data from external FHIR servers, customers often set up their own FHIR data store to store and manage the data they retrieve from Flexpa.
While you can store data to any database, a FHIR data store is a great option for developers who want to store and manage FHIR data in a way that is native to and compliant with the FHIR standard.
Transforming data from one format to another is a common problem in healthcare. For example, you may need to transform a FHIR resource you receive from Flexpa's API into a different format to store it in your database.
#ETLs
Extract, Transform, Load (ETL) tools are commonly used to transform data from one format to another. These tools allow you to extract data from a source, transform it using a set of rules, and load it into a destination. There are some healthcare-specific ETL tools that can help you transform data from Flexpa's API into a format that is more useful for your application.
Some examples: