Show HN: Eligible API for 700+ Health Insurance Companies

* 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",
        ...
      }
    ]

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

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.

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

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"
    }
  },

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

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)?

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

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.

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.

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

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

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?