Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Eligible API for 700+ Health Insurance Companies

eligibleapi.com

Post reply on HN
Print view View original

61–70 of 95 posts

Re: Show HN: Eligible API for 700+ Health Insurance Companies

#61

Post by sriramk »

kategleason wrote: post #49
ammmir wrote: post #47

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 o…

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.

Actually, as someone who has designed/run a high scale REST API, I have a slightly blasphemous view on this - that the RESTful-ness of the API doesn't matter.

You're better off trying to control how the various language bindings look like and focusing on making core scenarios be as clean as possible code-wise. That's what the developers building on top of your API will actually see and deal with on a day-to-day basis.

Re: Show HN: Eligible API for 700+ Health Insurance Companies

#62

Post by tylermenezes »

ammmir wrote: post #47

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 o…

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

Most APIs I've seen have moved off of HTTP basic auth, usually into including it as a separate header. Doesn't necessarily mean much, but it does mean it's not standard practice by any means.

Re: Show HN: Eligible API for 700+ Health Insurance Companies

#63

Post by babel »

ammmir wrote: post #47

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 o…

Thanks for your feedback ;-)

* I'm not sure what you mean with being REST...

* I thought that a secret key part of the query string (together with the usage of HTTPS) is simpler. But, I might be more a question of personal preference, meaning that we should provide different way to authenticate ;-) I will put this on our to-do list.

* I fully agree, my mistake, I will check this!

* That makes sense... I personally have a preference for the underscores, we will discuss that at Eligible.

* Idem.

* 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 ;-)

* That makes sense... we will discuss that at Eligible.

* Usually, when I design a grammar, I always want to have the UOM next to any number! BUT, in this case, I did not pay enough attention to it... This Eligibility story is - according to my current knowledge - a US and only a US story.

* You are right! Following other comments, 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 ;-)

* I can tell you that our JSON structure is already quite different from the flat raw X12 271 format. But, we might have lost a bit our track to make it as simple as possible to consume... Any suggestion is welcome ;-)

Thanks again for your feedback, please wait to get a full JSON instance - via updated documentation and/or the test API key - and carry on with such constructive feedback.

Re: Show HN: Eligible API for 700+ Health Insurance Companies

#64

Post by babel »

6ren wrote: post #45

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 cho…

As already said in a previous comment: >

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

Re: Show HN: Eligible API for 700+ Health Insurance Companies

#65

Post by babel »

edd_dumbill wrote: post #30

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 giv…

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

Re: Show HN: Eligible API for 700+ Health Insurance Companies

#66

Post by babel »

cllns wrote: post #35

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.

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

Re: Show HN: Eligible API for 700+ Health Insurance Companies

#67

Post by daigoba66 »

DennisP wrote: post #60
daigoba66 wrote: post #56

Earlier quoted context omitted.

The big companies all charge crazy expensive transaction fees: Emdeon, ENS (now Ingenix), ACS (now Xerox), Ability, Relay Health (formally HTP), and Meddata/Transunion. They all charge upwards for 25-35 cents per eligibility transaction. The software company I work for sells a healthcare product which includes automatic real-time eligibility verification. We don't charge per transaction. We can afford to do for two r…

Wow. It's so weird seeing Meddata mentioned and described as one of the "big companies." I was Meddata's second programmer, and built their eligibility system. I wrote their edi parser in five pages of C# code. Two of us built an entire eligibility and referral system, and took the company from nothing to profitability in five years. Then I moved on. I still visit them from time to time, and although Transunion owns…

That's pretty crazy. I think I consider Meddata to be such a big player because of their extensive payer list. Also, we use Meddata as a "backup" route for when our more direct (and free) connections are unavailable.

I'm curious to learn more about the history of the company. From my experience the software isn't necessarily the hard part. The hard part is setting up all of the trading partner relationships with payers and other clearinghouses/vendors.

Re: Show HN: Eligible API for 700+ Health Insurance Companies

#68

Post by kategleason »

babel wrote: post #64
6ren wrote: post #45

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 cho…

As already said in a previous comment: > @Kat, this is the 2nd point for using array ;-)

Three points from Max, lets do it!

Re: Show HN: Eligible API for 700+ Health Insurance Companies

#69

Post by Retric »

obituary_latte wrote: post #39
briguy wrote: post #34

Earlier quoted context omitted.

API's and services like this are Key in making it so that more people will be able to afford medical care. Solving the current cluster F * of paperwork and time involved in establishing eligibility is one of the lowest hanging fruits in cutting medical costs (....NOTE: As opposed to more complicated cost cutting concepts such as preventative care) A typical Doctors office of 2 or 3 practitioners may have 2 or 3 or mo…

So if I'm understanding correctly, the lowest hanging fruit to providing medical care to those in need is...paperwork? Sounds like we're working on a band-aide, not a solution. Again, progress is progress. I guess I wonder whether or not these efforts could be focused on the root. I'm probably sounding like a pretentious douche with all the answers...it's not intentional. On a very base level, I cant help but wonder…

What your missing is Doctors don't actually cost that much directly. Talking with a doctor for 10 minutes often involves the doctor doing 5 minutes of paperwork, and medical billing people doing 2 hours of work at the doctors office and at your insurance company. The billing people may make 1/3 what the doctor does but if there working 6 times as long there still 2/3's of the costs.

Re: Show HN: Eligible API for 700+ Health Insurance Companies

#70

Post by jh3 »

joering2 wrote: post #33
jdangu wrote: post #31

Earlier quoted context omitted.

Software is priced on perceived value, not reasonable calculations. You seem to imply that setting high prices is a dishonest practice. If you don't find enough value to justify the high cost, just move on, that might not be true for others.

no, I am implying that there must be a reason behind setting the price of your product X and not Y. Even greed is a reason, but that's why I asked that question to Kate without making any assumptions.

http://www.joelonsoftware.com/articles/CamelsandRubberDuckie...
Post reply on HN