Well you said it couldn’t be done, but here we are two and half years later and are a profitable, rapidly growing, successful corporation.
We’ve cut out nearly all of the old healthcare middle men and have built direct integrations with over 90% of the insurers in the United States of America. We’ve normalized all their painstakingly detailed variations on eligibility, claim edits, authorizations, referrals, claim rejections, report generations, claim status, remittance filings and offered that up in the cloud, as a service, to our customers.
Eligible can now confidently call itself a next generation healthcare clearinghouse with a suite of simple, unified APIS built specifically for rapid implementation. Financial services for the healthcare industry, if you will.
Collectively our customer bases’ market capitalization is over 78 Billion Dollars. We’re only two and half years old.
In 2012 we made a promise to our customers that we would never become distracted by the quick cash that building an application would inevitably bring us. We’ve kept that promise to our customers, ourselves, and to the healthcare industry at large by focusing solely on building an aggregated, clean, pipeline between provider vendor systems and health insurance companies.
As we continue to grow we will remain dedicated to this promise and will focus every last bit of our energy on building the core infrastructure needed in order to create a more unified health care delivery and payment system, aka the pipes. And for this reason, and because of this promise, we will win.
Eligible is an integrations partner which offers connectivity and processing to every health insurance company in the country. Eligible's simple API network enables disparate systems to instantly send and receive transactions required for the processing of healthcare payments and reimbursements.
One such transaction is a real time health insurance eligibility and benefit query. This endpoint is used by provider systems to retrieve the latest health insurance benefit and policy details of a patient.
The transaction occurs in “real time” by healthcare industry standards with the average transaction taking about six seconds. However; on peak volume days such as Monday - Wednesday from the hours of 9am-5pm EST the transaction can sometimes result in a ten to twenty second transmission.
Federal law and regulation require the transactions to be processed in under 20 seconds. When Eligible sees a transaction running over the allowed 20 seconds we automatically cut the connection to the insurance company and do a retry for you at no additional cost. Since we see a high success rate in the second attempt of the free automatic retry we recommend setting your time out window to stay open for at least 40 seconds.
We know this is pretty pathetic for a “real time transaction” and we make sure to alert all of our health insurance partners of this and we constantly provide them with logs on how they might be able to improve their response times. However; at this point it is better to just accept the reality that the health insurance companies might not get faster for a while and you can make sure to set that expectation for your user and set your time out windows accordingly. For example, you can quickly render the Eligible connectivity status within your application or you can sign up for webhook notifications to display in your own styles.
Healthcare companies across the country have been scrambling to add the official healthcare eligibility transaction (mandated by HIPAA as of 1996) into their new and existing systems for over a decade.
Most companies come to the eligibility transaction looking to build out a cost estimator tool. Here is the data they are expecting to be returned:
- Does the patient’s health insurance plan cover this specific health care service?
- How much will this specific service cost the patient out of pocket?
- Does this specific service require a preauthorization?
- Active coverage or inactive coverage for a service type. Not a specific health care service. Example: Information returned for diagnostic lab will be for the service “type: diagnostic lab”, not for the specific blood sugar lab you are looking to receive for some diabetes testing.
- Information needed to calculate patients financial responsibility (coinsurance, copayment, deductible, etc) will be returned on the service type level not for the specific service.
- I think you get my drift here but in case you didn’t the preauthorization information is only returned on the service type level not the specific service as well.
Back to telephone calls. It is actually not the phone call encounter itself which keeps the insurance call centers bumping (I know everyone thinks people just want to hear a kind voice, but research shows that’s not the case). It is the data content which the phone call can provide that the eligibility transaction can not. It is the fact that when you call, you can get patient’s health coverage information for specific services and are not stuck with a “guess” based off that service’s general “type”.
Everyone who talks to providers (doctors, nurses, labs, radiology centers, therapists, etc) about their experiences using the eligibility transaction for over the past ten years will tell you it is great and reliable for things they did not expect. Such as:
- Validating that a patient’s insurance policy is still active
- Handling coordination of benefits (patient has more than one insurance policy with primary, secondary, and so forth)
- Data entry scrubbing for demographic matching/validation
- Verifying of a group/employer identification along with plan names.
- Understanding plan type benefits (PPO, HMO, POS, etc)
- Retrieval plan deductibles remaining, stop loss maximums, and visit maximum information.
In the next breath they will then tell you that when it comes down to checking if a patient has coverage for a very specific service they have no choice but to turn to the telephone.
This same existing transaction (270/271 spec for eligibility/coverage/benefits) actually allows for the passing of a specific service or procedure code. Obviously absolutely no health insurance companies supports it yet, but the “mandated” spec supports it. So, we’re closer to truly killing phone calls sooner than you think. *Actually, Medicare supports this for a select few preventative care HCPCS codes. You can see the Eligible Medicare endpoint documentation for it here: https://eligibleapi.com/rest#medicare.
Lets start telling the insurance companies that this is what most people are looking for when processing an eligibility transaction. The insurance companies are not the bad guys, they are just misinformed. No one ever just talks to them about the problem. They are always trying to force them into some solution. If you would like to join us in making sure they understand the problem ping us at email@example.com.
Add a classic Healthcare Eligibility & Benefit Report to your system in one hour.
All health insurance plans were not created equally :)
You can use the Eligible Coverage API to identify what type of health plan the patient is enrolled in including HMO, PPO, POS, etc.
It is important to know that there are very specific differences between an HMO and a PPO plan. A HMO Plan (Health Maintenance Organization) usually designates a specific set of doctors which the patient is able to visit and has a set primary care provider which the patient will need to see for other speciality referrals. HMO plans tend to have more preauthorizations requirements and usually offer little to no coverage for procedures that are administered by out of network health professionals.
A PPO (Preferred Provider Organization) plan is more flexible, allowing the patient to receive some health coverage even when being serviced by an “out of network provider”. However; if the patient wants to receive the most financial coverage possible and is enrolled in a PPO the patient should see a doctor who has contracted in network with their health insurance company.
Are certain patients covered by more than one health insurance company?
When trying to determine which health insurance company of the patient’s is responsible for paying for the patient’s procedure or services this is often referred to as “coordination of benefits”.
For example if Ben Franklin has two health plan policies one for Medical and one for Dental that is pretty easy to coordinate. Obviously all of Ben’s Medical services will be paid by his Medical insurance company. But what happens when Ben has two Medical insurance policies? Aetna and BCBS Alabama? Well, that is where the payment logistics can get messy.
You can now use Eligible API to identify if a patient has multiple health insurance plans and confirm which one is considered the “primary” health insurance plan and which one is considered the “secondary health insurance plan”. This will help avoid denial of your claim if you send to the secondary before the primary.
No information should be keyed into any health care system unless validated.
Data entry is a seemingly small, but very real problem in health care technology.
Most clinics and hospital systems are comprised of many different enterprise solutions and when data needs to be shared between one to the other it is likely keyed in manually.
In one location a hospital may use one solution for payments and billing, another for health records, another for diagnostic imaging, so on and so forth. In the same hospital network but different location they may use an entirely different set of solutions.
If the two locations need to share information such as a patient’s health insurance information they most likely fax it over or call it in.
The problem here is if the fax or phone call results in a data entry mistake, even a very minor one such as the spelling of the patient’s first name, all medical claims for that patient are going to be denied by their insurance company.
This is the easiest and most proactive use of an “eligibility transaction”. We call it a data entry scrub. Every time a patient is keyed into a new health system a query should be triggered to verify that the patients DOB, Zip code, full name, and active status match what the insurance company has on file for that patient. If the patient can not be validated then that information most likely has an error.
You can use the Eligible demographics API to validate that the information entered matches what is on file at the insurance company.
Use Eligible’s Medicare API to avoid claim and payment denials.
First thing is first start by validating that the information provided by a patient matches what Medicare has on file for that patient.
Without using any Network Service Vendor (no middle man!) Eligible has built a direct connection to the CMS Medicare pipelines for real time eligibility and benefit coverage information.
With a simple GET request made for a healthcare professional:
curl "https://gds.eligibleapi.com/v1.1/medicare/coverage.json" -X "GET" -d "test=true" -d "api_key=aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee" -d "provider_last_name=Doe" -d "provider_first_name=John" -d "provider_npi=0123456789" -d "member_id=ZZZ445554301" -d "member_first_name=IDA" -d "member_last_name=FRANKLIN" -d "member_dob=1701-12-12"
You’ll be able to retrieve the following information:
- Medicare Part A & B Active/Inactive coverage and date status.
- Coordination of benefits of multiple health plans for vision or primary care will be listed as well.
- Full Medicare advantage information for routing of claims to commercial advantage plans.
- Full names as the MUST appear on claims.
- Hospice information
- End Stage Renal information
- Recertification dates for home healthcare
- Preventative care services by code
- Hospital copayment information based upon number of days per spell including what day of the spell the patient has reached.
- Skilled nursing facility information
- Deductible and deductible remaining information.
- Coordination of Medicare Part D information and Medicare advantage.
For more examples of the types of data that can be retrieved review our documentation here: https://eligibleapi.com/rest#retrieve-medicare.
You can now use the Eligible API to retrieve the payment status of claims submitted to all health insurance companies in the US except CMS Medicare.
Find line item information including all procedure codes billed, the original charge amount, the assigned payment amount along with payment trace number and finalization date.
Check out the documentation here: https://eligibleapi.com/rest#payment-status