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.
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...
As it stands, the insurance market is inverted that it makes the insured compete for coverage.
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.
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...
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.
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).
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.
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.
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.
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...
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.
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.)
Is it very specific to a certain type of business contract?
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.
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.
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.
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.
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.