Hacker News new | past | comments | ask | show | jobs | submit login
Show HN: Eligible API for 700+ Health Insurance Companies (eligibleapi.com)
218 points by kategleason on Aug 10, 2012 | hide | past | web | favorite | 92 comments



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.


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.


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.


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


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.


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


An Oauth2 token via http header works very well. Of course, you'll want to send only encrypted requests.


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?


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.


While I think this is awesome (I work in the healthcare space - on the infrastructure side (design, build and implement systems for new hospitals)) though I would LOVE to see the following, if this API allows:

I as a user would like to tell you my insurance info and tell you what procedure I want and you tell me the best/cheapest location to get that done.

Then - here is where the groupon model farking failed: (I have only ever bought one groupon, and I never used it, but the model for groupon should be applied to things people NEED); I want to see coupons for medical, eye, dental procedures - things I dont buy too often and when I do, I want the best deal possible.

So, for example, I want teeth whitening. Or a full eye exam... etc..

Actually - there was a rockhealth company that was doing something similar, that was in the first batch, but they were LA only and hadn't quite built out the right system...

/rant...


I as a user would like to tell you my insurance info and tell you what procedure I want and you tell me the best/cheapest location to get that done.

This is offered by Castlight Health (www.castlighthealth.com), where I used to work. Though it is currently only sold to employers & offered free to their employees.

Re the groupon model: I think you'd need to adjust the model a lot to sell services which are frequently covered by insurance. Teeth whitening generally isn't insured, which is why it is in fact a very frequent groupon offer.


Insurance covers teeth whitening? I thought elective/cosmetic procedures were not covered.


Each insurance is different. And each companies plans within them are different. Anything is possible if someone is willing to pay.


Not all do - but this is why I ask - I would like to see an API that lets me search for procedures I want, and ultimately have a market that makes the providers of that service compete for MY business.

As it stands, the insurance market is inverted that it makes the insured compete for coverage.


Agreed. Castlight health is doing this for employees of certain companies http://www.castlighthealth.com/.


Maybe I'm misunderstanding, but this post makes it sound like you've created an efficient API to find whether or not a person can "afford" treatment.

Again, maybe (hopefully) I've misunderstood. And not to be the the tree-hugging idealist of the post, but as a fellow human, how does this make life better for the rest of us?

Sorry if I seem confrontational about the whole thing; progress usually is a good thing. That said, I hate seeing great intelligence spent wholly on the bottom line.

I'm also aware that I very likely am in the wrong forest barking up the wrong tree...


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 more support people spending their day faxing back EOB's to insurance companies, etc. Those dollars directly affect the cost of Health Care. This is Great.....X12 is arcane, good riddance. There are actually some insurance clearinghouses that will pay you to use them (if you have high enough volume) as they are paid by the insurance companies and/or through government incentive programs.


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 all this potential could achieve if the focus weren't money. As I understand it, the benefits you proclaim would be a side effect of a successful (read: profitable) implementation.

As always, I might be misunderstanding.


(1) No, I am saying that one of the lowest hanging fruits to drive down the cost of Healthcare is ubiquitous/simple two way electronic communication between providers/payers/patients. Today's technology is more than capable of solving this in a very efficient manner. The politics and other reasons standing in the way of progress is a completely different story. (2) This product is actually a solution to this specific issue (complicated and inaccessible data interchange formats). This is not going to solve the healthcare crisis alone, however I think the net effect of services like this is very positive and will result in lower costs and Better and Faster healthcare service. One Note: While a realitime EOB (explanation of benefits) system will benefit patients. Such a system can be abused. Health Providers that are less than ethical (which hopefully is a small minority) that can more easily query for "un-used" benefits that remain on their patients insurance plan can push un-necessary procedures and diagnostics in order to make more claims.


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.


I think it's better for patients to know if they can afford (have coverage) for a treatment before it occurs rather than get a $3000 bill in the mail after it occurs. I know it still sucks ;-/


I think .05 cents per request is too expensive. If generating a response is a computationally intensive task, then I understand. But your current pricing model reminds me of the pay-per-minute phone calls of yester-year.

Pricing has to make sense. Pulling from my experience building and marketing LinkPeek.com, I have found the best results by providing different tiers or plans for different target markets. I try to use the different tiers to show value for different types of customers. It should be a no-brainer for your customers which plan to choose.

I feel you should review your current pricing model so that you don't scare people off when they do the math.


So it sounds like this is not just eligibility to purchase insurance, but also (or instead) coverage by current insurance. Is my understanding correct?


Yes it is to check healthcare eligibility for a patient's current insurance plan. If that plan went inactive we will be able to pass you the plan end date as well.


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


This seems pretty harsh. As someone who is running my own API company in an industry filled with red tape and regulations, I can fully understand a high price, especially when getting started.

Often times (at least in my industry--telephony), it is nearly impossible to negotiate low prices yourself without significant volume to afford better contracts.

I'm certain that everyone running an API company wants their prices to be as low as possible for their consumers, and it seems to me that your comment is really just attacking the guy unnecessarily.


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


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

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


It's one of the cheapest eligibility APIs I've seen. And the clear value add is JSON.

There are some providers that do eligibility checking for free for big payers (I think Availity does) but then you have to process the mess that is X12. Trust me when I say that you want to stay as far as possible from dealing with X12 files.

Other providers charge up to 20 cents per inquiry and still return X12 response. 5 cents and JSON make this highly competitive.


It was the first comment so I was happy and thanked him/her. Sorry to fire off your red flag.

We've been killing ourselves over this data format and connections work for the past 9 months, so to us 5 cents per successful call seems like a steal.


If I as a provider can have software that determines eligibility for $0.05 as opposed to having a clerical worker spend 20 minutes with phone calls or faxes, yeah that's probably not only reasonable, but an insane bargain.


Aimed at a commerical market I'm not sure this doesn't make sense, especially if they are open to bulk discount pricing (which I imagine they are).

So I make an app for some kind of medical pro to use, give it away. A not very busy clinic, say at 50 patients per day currently manually checks and is frustrated. I say, hey, for $100 a month you can check all those patients using my fancy app that will make your life easier. $100 a month to a business for something like this is probably a no brainer. And at that price level there is still profit to be made before any bulk discounts :)

Maybe I should do this...


Please do!


ok then can you give me any reasonable calculation behind why this is 5cents, not 6, or 10, 15 or 1 ?


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.



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 reasons 1) we put a lot of effort into finding cheap/free/redundant real-time connections to payers and 2) we can simply eat the cost as part of the margin for our product. Our philosophy is that you should check eligibility often and always, at every point of the patient's encounter from scheduling to check-in. Per transaction costs scare away customers which is part of why we don't charge per transaction.


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 them now, the Meddata team is still pretty small.


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.


Yep, that was the hard part. Our sales team was three people, including the CEO, and they also had to sell the product to providers. Somehow they managed.

We actually started with referrals. Providers were filling out paper forms and faxing them. Every payer had its own rules, its own identifiers for providers, its own forms. We put everything on a website and reduced a ten-minute process to thirty seconds. We got our first paying customers in 1999.

Trouble was, support was killing us. By 2001 it was starting to look like we wouldn't make it. Then we added eligibility, and it turned out to be insanely profitable. We started by getting payers to give us their entire customer lists, then added edi, plus some proprietary APIs some of them had. At that point, HIPAA hadn't fully kicked in and payers were still implementing X12.

In 2003 we started to break even, and I moved to our parent company to start another project. Meddata bought a couple other companies, then a couple years ago Transunion bought Meddata. I don't know for how much, but Meddata was making a lot of money by then with a team not much bigger, so it had to be a lot.


Very cool Dennis, I'd love to connect with you to hear more about your experience. Please email me k@eligibleapi.com


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.


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


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.


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


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


Three points from Max, lets do it!


We want to make the JSON as simple as possible to parse. I'll be posting full data sets to the documentation shortly. Feel free to email me with how you would prefer to see it handled.


implemented! thanks.


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


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.


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


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.


It looks to be inspired by https://stripe.com/docs


it is :)


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.


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


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.


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


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


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.


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


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


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


You should add a little callout link to that "starter" info dump somewhere on the home page. Best of luck!


Wow -- pleasantly surprised to see that response. Very cool to see you sharing data.


Just curious - how is it that you have claim data? In fact, how is it that you (if I'm not misunderstanding) are storing any actual live data whatsoever?

Just to clarify...you have some data with patient identifiers already "removed"...or are you stripping it yourselves before sharing?

If the latter (which I hope is not true), how would a third-party like you obtain identifiable data? Why would a third-party providing an eligibility API end up storing data (particularly claim data) of any kind to offer to share?


Hey logjam! Let me know what specialty you are and how many insurance companies you currently accept when you have a minute. To answer your question: No, we do not have access now nor plan to have access in the future to claims data. The raw X12 I am referring to is a 271 format only (eligibility) and will be generated by our own sample transformation tool. However; it will be based off data passed (with stripped patient identifiers) through the Eligible API so that it can give shape to the differences between payer (insurance) formats. As of 3:05 8/11 I have not shared any yet, but I hope to push some to production by the end of the day!


So actual patient data is being stored and manipulated, and manually "stripped" so that it can be posted (in effect) to the web? Again, I don't want to misunderstand you, but you feel comfortable doing this? I wouldn't.

Please provide your backup, retention, deletion, access logging, etc., policies on that data you are manipulating.

Am I understanding that an audit two months from now (you log your access and use of this data as required by HIPAA, right?) will indicate that this data was "stripped" and shared?

I would be very very cautious about thinking that "stripping" data like this isn't very prone to error, and to not realizing that storing and sharing this kind of data without a lot of care and thought could create huge problems.


You're twisting my words. I'll let you refer to our terms, security and privacy for the rest of your questions.


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.


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.


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.


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.


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


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.


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.


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


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?


What's your specialty?


Also, how many insurance companies do you currently accept?


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?


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?


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.


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.


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.


[deleted]


Gotcha, primary care is what I assumed. Most of the insurance company websites will give you back a basic active/inactive response along with the patient's copayment. For primary care docs this is enough (although its still annoying to go to 100+ websites if you accept a lot of insurance plans). However; for surgeons, chiropractors, massage therapists, dentists, diagnostic labs, genetic testing facilities, MRI facilities -- this basic information is not even close to enough. That's where the Eligible API comes in.


Uh, no.

I and all physicians and our office staffs get back complete eligibility information for ALL possible care from a single query from existing insurance co queries: eligibility for all surgical, laboratory, radiological, inpatient hospitalization, partial hospitalization, psychiatric care, etc etc; along with deductible, copay, balance, etc etc.

Doctors have to refer patients around - we need to know which specialists accept what insurance and can see our patients. The insurance companies want us to know that. It's in their interest to let us know that. They let us know that. Already.

Could you explain how your query of the insurance company's information would be more complete than the insurance company's query of its own information?

On second thought, go have a nice day. I realize I am asking for technical information and getting sales spiel in return.


No need to get rude here. My replys are sticking to facts not insults. Yes, my experience is in sales and I'm proud of it. Here's the data most interesting to our existing user base: 1) limitations (ie if the patient only has certain amount of visits per year) 2) deductible remaining 3) co-insurance responsibility 4) health spending balances 5) Coverage for specific tests/equipment/procedures: infertility, blood draws, wigs, durable medical equipment, dental crowns, etc.

Two of our largest api users built the system for: diagnostic lab order entry service and genetic testing service.




Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: