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