Show HN: Eligible API for 700+ Health Insurance Companies

I applaud the initiative, but I think the JSON needs to be friendlier.<p>* Use REST.<p>* Use HTTP Basic auth instead of cluttering the URL query string with the API key.<p>* Use ISO 8601 for dates, no exceptions.<p>* Use lower_case or lowerCamelCased keys.<p>* 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.<p>* 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):<p><pre><code> 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", ... } ] </code></pre> * 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.<p>* Same goes for balance, make it a number (use cents to avoid floating points), and provide units like "USD".<p>The JSON example at <a href="https://eligibleapi.com/overview/how-it-works" rel="nofollow">https://eligibleapi.com/overview/how-it-works</a> 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.<p>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.

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?

Just one nit: tell us more about who you are.<p>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.<p>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.

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.<p>I've used it but haven't really gotten any interesting out of it before.

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. <a href="https://eligibleapi.com/restful-json-api/response" rel="nofollow">https://eligibleapi.com/restful-json-api/response</a><p>Also, it's simulating JSON [] lists as objects with fields named <i>"Item #1", "Item #2", ...</i> Seems an odd choice. e.g.<p><pre><code> "Deductible": { "Item #1": { "Calendar Year": "1500" }, "Item #2": { "Remaining": "500" } }, </code></pre> 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.<p><pre><code> "Deductible": [ { "Calendar Year": "1500" }, { "Remaining": "500" } ],</code></pre>

Some questions that immediately came to mind after reading through the docs:<p>1. Does the response contain more than just the 271 EB segments? The demographics segments are important, as are payer contact segments.<p>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?<p>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".<p>4. Do you accept multiple service type codes on a single request?<p>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).<p>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)?

I've been using Eligible API for just over a week and I must say that I'm loving it so far.<p>Kate &#38; Patrice have been extremely responsive and improving incredibly fast.

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.<p>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.

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.

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.

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.<p>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.<p>It's really great to see someone hyper-focused on solving one part of the puzzle.

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.<p><i>Nota Bene: I dislike the malicious sentiment that often pops up in threads like this. My question is driven by pure curiosity.</i>

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.

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: <a href="https://eligibleapi.campfirenow.com/e30aa" rel="nofollow">https://eligibleapi.campfirenow.com/e30aa</a>.

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.<p>I'm excited to see if I can quickly put something together for him.

I don't get this.<p>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.<p>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.<p>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.<p>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?