
Show HN: Eligible API for 700+ Health Insurance Companies - kategleason
https://eligibleapi.com/
======
ammmir
I applaud the initiative, but I think the JSON needs to be friendlier.

* Use REST.

* Use HTTP Basic auth instead of cluttering the URL query string with the API key.

* Use ISO 8601 for dates, no exceptions.

* Use lower_case or lowerCamelCased keys.

* Don't use spaces or other non-alphanumeric/underscore characters in keys, otherwise you can't easily index child objects with dot notation in many languages.

* Instead of liberally using dictionaries, use arrays with a type field. For example (I couldn't finish the example because the example JSON on your site is indented too poorly to comprehend):
    
    
        active_coverage: [
          {
            title: "Item #1",
            description: "Choice Fund HRA Open Access Plus",
            free_text: "Member is in network based on NPI ID provided in request",
            ...
          }
        ]
    

* Why are percentages expressed as a string? Instead of ".1" which will need to be parsed again by the consuming app, use a raw number, or to avoid floating points, multiply by 100 to ensure whole numbers.

* Same goes for balance, make it a number (use cents to avoid floating points), and provide units like "USD".

The JSON example at <https://eligibleapi.com/overview/how-it-works> is
incomplete and invalid. I'd be interested in seeing the entire JSON envelope
to see how to actually get at the data and what other metadata is exposed.

This looks like a straight up EDI translation into JSON, and thus not natural
at all. I'd try to abstract it out a bit more into what people might use it
for, and build a truly consumable REST API.

~~~
kategleason
can we hire you?

I love your feedback, we know this is still raw (early beta) but its great
hearing constructive suggestions. Please email when you have a chance
k@eligibleapi.com so that I can provide you with a full data set of JSON
response.

~~~
gvnonor
In case ammmir decides takes you up on your offer, I'd advise him to ensure
that a contract is in place before committing to do any work.

~~~
kategleason
Waiting for that bad boy. In case anyone is curious of what gman is referring
to you can read my response here katgleason.tumblr.com

------
chime
If I understand it correctly, this is an EDI to JSON API? At 5c/call, it seems
like one of the most expensive APIs out there but I'm guessing it does
something that is very difficult to setup on your own. Reading the front-page,
did not make it clear what is it that it really simplifies. And how can I as a
developer (who might want to make a mobile app for the medical industry) make
use of this service?

~~~
kategleason
Thanks for your comment. We handle the connections to the insurance companies
and the EDI to JSON transformation. I respect your point about 5 cents being
high. We, of course, will evaluate that as time goes on.

To start, you as a developer can make an app for the medical industry that
checks patient's health insurance eligibility. Details you can call include:
health spending accounts, deductibles remaining, coinsurance/copayment,
whether or not they have coverage for MRI, etc.

~~~
joering2
> Thanks for your comment.

Perhaps I am having a bad day, but is it really necessary to thank someone for
their question? Seriously, this makes me feel like I am dumb for asking a
question.

I understand you trying to be extra polite, but I am sure you won't start a
conversation with "thank you" every time your wife, son, daughter, lover or
employee ask you a question. So while many will appreciate your "politeness
throw-up" attitude, personally you just caused my red flag to pop up, because
I honestly feel your politeness is fake.

> I respect your point about 5 cents being high. We, of course, will evaluate
> that as time goes on.

His, and everyone else who ever paid for API and knows what is reasonable
price what's not. To me this "We, of course, will evaluate that as time goes
on." stripped out of bullshit means this "We will try to make fortune (or
something like 100,000% profit margin on those simple text requests to our
server) and will benchmark traffic, and if we don't get enough suckers to sign
up, then we, of course will lower our price".

I can bet you $50 that after the initial wave of HN interest, your value
versus cost ratio will scare 99% of those who need to use service similar to
yours. Please don't forget to post a news where you go down to a reasonable
rates, like 1,000 hits for 1 cent (Sendgrid, MailChimp, etc, etc).

~~~
rlucas
Terrible, shortsighted comment. You're really judging the value of an
informational API on absolute price per dip??

I know of a guy who has a database for which he charges $5000 per lookup. Is
that not a "reasonable price?" Well, turns out it contains contract details,
including expiration and re-bidding dates, for multi $-MM corporate contracts.
If you're a sales team angling for a $500k commission, paying $5k to look up a
single record suddenly makes sense.

(I agree that ideally the info that Eligible is selling should be available
for free, in real-time, from insurance companies. Guess what; it's not. But
redirect your anger, buddy: Eligible is part of the solution, not part of the
problem.)

~~~
tehwebguy
I am insanely interested in knowing more about this guy and his database.

Is it very specific to a certain type of business contract?

------
edd_dumbill
Just one nit: tell us more about who you are.

When dealing with something like health insurance data (or really any service,
to be honest) I like to know there's a human or corporation behind it. Your
contact page just lists an anonymous email address.

Knowing who the team are that built this thing would give some assurance —
particularly because your signup page asks quite a lot of information, way
more than you give away about yourselves.

~~~
babel
You are right, we will update our Contact page ;-)

As a sneak preview, please find below our respective LinkedIn profiles:

* <http://www.linkedin.com/in/katelyngleason>

* <http://be.linkedin.com/in/patricekrakow>

------
seltzered_
Just fyi, there's a "mint for healthcare" startup called simplee.com that's
been around for a year or two. You link the site up to your various health
insurance plans.

I've used it but haven't really gotten any interesting out of it before.

------
6ren
The deeply nested JSON (9 levels) seems difficult to understand without some
kind of schema/detailed docs - though maybe domain users are already familiar
with the underlying data's schema? Part of the problem is intrinsic data
complexity, aside from EDI format. <https://eligibleapi.com/restful-json-
api/response>

Also, it's simulating JSON [] lists as objects with fields named _"Item #1",
"Item #2", ..._ Seems an odd choice. e.g.

    
    
      "Deductible": {
        "Item #1": {
          "Calendar Year": "1500"
        },
        "Item #2": {
          "Remaining": "500"
        }
      },
    

EDIT: To clarify, below is the same snippet using JSON lists. The list syntax
gives schema information (i.e. that it is a list), and is standard, readable
and concise. Most parsers will map it to a list in the destination language,
making it more natural to address and loop over; i.e. easier to process in
general.

    
    
      "Deductible": [
        {
          "Calendar Year": "1500"
        },
        {
          "Remaining": "500"
        }
      ],

~~~
babel
As already said in a previous comment: << To be fully honest, it has been an
internal debate: "use or not use array" ;-) I personally wanted to use them...
so, thanks for your feedback ;-) >>

@Kat, this is the 2nd point for using array ;-)

~~~
kategleason
Three points from Max, lets do it!

------
daigoba66
Some questions that immediately came to mind after reading through the docs:

1\. Does the response contain more than just the 271 EB segments? The
demographics segments are important, as are payer contact segments.

2\. How do you deal with payers that require provider registration? Do you
have a standard registration form that can be used to expedite the process. Do
you, can you, register on behalf of the provider?

3\. JSON is web service friendly and stuff, but your output sure is verbose.
Is there any reason you choose to print entire descriptions of codes instead
of just returning the code? (for example "Diagnostic Lab" instead of simply
"5"). Personally I think sticking to the standard X12 codes would make the
data easier for software to consume. In my honest opinion it's hard to beat
X12 for EDI transactions given its well defined structure. Though it's very
unfortunate that it's not "open".

4\. Do you accept multiple service type codes on a single request?

5\. Can you accept a Service Date in the request? Often times it is useful to
retroactively check for coverage. A good example is Medicaid: providers often
batch eligibility requests for their self-pay patients at the end of the
calendar month to see if they now have coverage (new Medicaid coverage can be
retroactive in some cases).

6\. How reliable are your connections? Have you setup your own direct payer
connections, or is mostly hopping through other EDI vendors (Emdeon, ENS,
Meddata, etc)?

------
buss
I've been using Eligible API for just over a week and I must say that I'm
loving it so far.

Kate & Patrice have been extremely responsive and improving incredibly fast.

~~~
kategleason
Your team has helped us improve 100% over past week alone. Thanks again.

------
Danieru
I am impressed by this site's use of Bootstrap. Most Bootstrap sites look like
exact clones of the example templates with some colors swapped. The Bootstrap
origin on this site is obvious yet not tired.

All they did was add a background and position one element yet it looks
unique. I think the key thing was that they avoided the Bootstrap's black
navigation bar.

~~~
citricsquid
IMO what matters most is Bootstrap was used _well_. They took the purpose of
Bootstrap (CSS/HTML Framework and well designed common elements) and then used
that alongside their own understanding of how their site should be fit for the
purpose.

So many people take Bootstrap as an excuse to not give a single thought to the
usability of their site. It's a shame really, Bootstrap is a great tool but
inevitably the people that rely on it are relying on it because they have no
clue, so they butcher it.

~~~
kategleason
thanks :) we put a lot of thought into how best to use it. glad that comes
through.

------
technotony
Anything involving health data is interesting and has the potential to improve
lives, however there isn't enough information on the landing page here to
indicate what this data is or why I might want to use it. Could do with a
better landing page.

~~~
kategleason
Great feedback, we will do that and include samples from some companies
currently using the API.

~~~
thowar2
Maybe also put up a comparison with your competitors and/or highlight the
features that make you a better choice.

------
jasonkolb
I wish the raw data was available (is it, somewhere?). I'd love to do some
statistical analysis on this and get some real insight about how different
insurance companies treat claims.

~~~
kategleason
absolutely. I'll send you over as much raw X12, with removed patient info of
course, as you want! Please email support@eligibleapi.com

~~~
felideon
You mean you also have claim data (837)? Or do you just have enrollment data
(834)?

If the former, I wonder if some statistical analysis could be done in order to
detect possible fraud, waste, and abuse. (I'm not a data geek or anything, but
have I always wanted to learn.)

~~~
kategleason
Nope, sorry we do not handle 837 or 834 EDI transactions at this time.

------
mikecuesta
Healthcare and Health IT are plagued with an insurmountable amount of
complexity, administrative burden and draconian policies which hinder a lot of
the potential for innovation.

Solutions like this are absolutely vital in getting the next generation of
startups, developers, and healthcare providers the kind of infrastructure that
can otherwise be cost-prohibitive.

It's really great to see someone hyper-focused on solving one part of the
puzzle.

~~~
kategleason
Thanks Mike. We are starting at the source and will not leave it until there
is a genuine shift in how eligibility for healthcare is handled.

------
dfc
I was surprised by the read-only aspect of the API. How do doctors/medical
providers/employers submit records and or update billing information? I guess
I am under the impression that when I visit the doctors office that they
transmit data to my insurance provider.

 _Nota Bene: I dislike the malicious sentiment that often pops up in threads
like this. My question is driven by pure curiosity._

~~~
buss
Eligibility is a different beast from filing insurance claims.

Eligibility checking is performed prior to filing a claim. It tells the
provider if the patient's insurance covers the requested procedure at the
requested facility.

Filing claims is typically done through an EMR system that submits claims to a
clearinghouse.

------
cllns
It would be cool to provide a sample API with test data. You could either
require sign-up (as individual or organization, but not necessarily a
registered company) or don't. This would enable someone to hack something
together before they establish a company.

~~~
babel
Thanks for your feedback! Following your comment, we might soon provide a
public test API key that will return a predefined anonymized JSON answer so
developers can hack the API straight away ;-)

------
kategleason
We've had a lot of people sign up and start building already :). If you have
any questions please jump into our campfire chat room:
<https://eligibleapi.campfirenow.com/e30aa>.

------
colinsidoti
My father's a chiropractor and I just asked him about this. Apparently
checking insurance eligibility is a "pain in the ass" and involves a phone
call with wait times.

I'm excited to see if I can quickly put something together for him.

~~~
kategleason
we'd love that. email me k@eligibleapi.com

------
logjam
I don't get this.

I'm a physician, and every insurance company to which I submit claims already
has a web service in place to check eligibility...at no charge. Already.

There aren't many interface differences between insurance companies: you
typically enter two identifiers, usually either an id number or last name, and
birth date. You get full eligibility info immediately.

There's nothing difficult about it. We almost never call insurance companies
to get eligibility info - web querying is already in place, and has been for a
while.

What problem, at 5 cents for each API CALL (c'mon, really?) is this solving?
Why would I want to pay to pass my patient's protected health information
through yet another layer (and store? see my comment below about this
company's offer of a data "sample") of potential privacy loss?

~~~
kategleason
What's your specialty?

~~~
kategleason
Also, how many insurance companies do you currently accept?

~~~
logjam
Many many. I just discussed this with our office manger - checking eligibility
is not a problem for us (nor would it be for most practices in my opinion)
using web services already in place....and especially not free vs a dollar per
20 queries.

I'm not actually a fan of insurance companies, but please explain why I would
want to pay for the hassle of dealing with Yet Another third-party and at the
same time expose my patient's protected health info to Yet Another layer of
risk?

~~~
kategleason
I see. We certainly would not expose your patient's data. My reply at bottom
should help clear that up for you. You forgot to mention what specialty you
are?

~~~
logjam
No, actually your reply doesn't describe your security practices at all. Why
are you retaining live data at all?

Forgive me, but just claiming "we certainly would not expose your patient's
data" is hollow at best - I take the responsibility for protecting my
patient's health information very seriously, as do most physicians, and it is
ultimately our responsibility to do no harm in that regard.

Not saying this is true of you guys, but there are a lot of incentives out
there for "mining" and even selling health info. At the very least, storing
health data on multiple, geographically disparate servers, logging access,
retention policy, etc is a nightmare waiting to happen.

~~~
kategleason
You forgot to mention what specialty you are? Take a look at our privacy,
terms of service, and security pages to answer the rest of your questions
above. If you do not think the service is useful then you don't need to use
it. That's the beauty of the free market. One man's junk is another man's
treasure.

~~~
logjam
I'm a family medicine doc in a practice with several other docs. Why do you
ask?

I already read your site's security pages, which in large measure do NOT
address the questions I've asked here.

However, I believe you're right - neither I nor the software folks I consult
with here in Bay Area will be interested in using your tool. Good luck to you.

