Putting healthcare in hackers' hands(blog.eligibleapi.com)
blog.eligibleapi.com
Putting healthcare in hackers' hands
http://blog.eligibleapi.com/?p=155
47 comments
Good point. Will add this to website now: 419 Fulton Street Suite F San Francisco, CA 94102.
Sidenote: this is the reason why great hackers stay out of healthcare. you're scaring people away with this comment. I understand privacy needs to be taken seriously, but I do not think it should stifle innovation.
Sidenote: this is the reason why great hackers stay out of healthcare. you're scaring people away with this comment. I understand privacy needs to be taken seriously, but I do not think it should stifle innovation.
Well, you have a great team of investors, but you should be aware of that risk. HIPAA violations are extremely painful.
I'm not in the field yet, but I do have a business plan that deals with US healthcare, and lawsuits and the FDA are pretty scary :)
Edit: example HIPAA fines
http://www.ama-assn.org/ama/pub/physician-resources/solution...
I'm not in the field yet, but I do have a business plan that deals with US healthcare, and lawsuits and the FDA are pretty scary :)
Edit: example HIPAA fines
http://www.ama-assn.org/ama/pub/physician-resources/solution...
At the same time, I'm sure you've looked into the HIPAA regulations, and talked to folks about them...
As another founder of a company working in a healthcare field, having done these two things, I find that much of what's in HIPAA is stuff that a good engineer would do anyway. Stuff like putting passwords on things, using encryption, having backups, not sharing data. Yes, there are some arcane things, but on the whole its a manageable affair.
What I find frustrating (echoing the concerns of the Eligible poster), is that a 5-letter acronym is enough to scare away so many people from touching entire swaths of the healthcare landscape. Yes, there are laws, but it's clear that most people haven't even tried to read them; they wouldn't stop most projects getting off the ground.
As another founder of a company working in a healthcare field, having done these two things, I find that much of what's in HIPAA is stuff that a good engineer would do anyway. Stuff like putting passwords on things, using encryption, having backups, not sharing data. Yes, there are some arcane things, but on the whole its a manageable affair.
What I find frustrating (echoing the concerns of the Eligible poster), is that a 5-letter acronym is enough to scare away so many people from touching entire swaths of the healthcare landscape. Yes, there are laws, but it's clear that most people haven't even tried to read them; they wouldn't stop most projects getting off the ground.
Actually, in my case, we wanted to build a healthcare app (yet another medication manager).
The FDA recently passed some guidelines (as you say, they're entirely reasonable, same as the HIPAA stuff), which we want to stay clear of.
As for HIPAA, I live in Uruguay and I couldn't bear the cost of even a single fine or lawsuit (however remote the possibility) before getting critical mass or funding. A funded U.S. startup, OTOH, can do that. It's just not for the lone coder or small bootstrapped team.
http://www.fda.gov/MedicalDevices/DeviceRegulationandGuidanc...
The FDA recently passed some guidelines (as you say, they're entirely reasonable, same as the HIPAA stuff), which we want to stay clear of.
As for HIPAA, I live in Uruguay and I couldn't bear the cost of even a single fine or lawsuit (however remote the possibility) before getting critical mass or funding. A funded U.S. startup, OTOH, can do that. It's just not for the lone coder or small bootstrapped team.
http://www.fda.gov/MedicalDevices/DeviceRegulationandGuidanc...
I can understand the fear of a lawsuit or fine; these things seem wholly beyond your control. What I don't like is paralysis that comes with that.
Now, some amount of pragmatism is important, and I'm sure you've made your decision in a way that's best for you. I just hope that the entire community doesn't fall into the trap of "there's this [regulatory/bureaucratic] risk, so forget it. I won't even try."
My take on these types of hurdles is that they are surmountable with a good helping of resourcefulness. Example?
In our case, there's actually not FDA approval for primary clinical use of a technique we depend on, so there would be quite a bit of legwork between us and getting to market, not to mention the hospital bureaucracy.
What we figured out, however, is that technicians in the pharmaceutical industry (and biotech) use this same technique, in similarly high volume. The barriers to them adopting new technologies are much lower, and better still, they actively demand and pay for new technologies that boost efficiency. So we're starting with them as a target market, and we'll chip away at the barriers to direct clinical adoption in parallel to revenue generation.
This is only one trick of many we're bringing to bear in fielding our technology, and some patience is required before we can realize the impact we dream of.
Handling the risk associated with being involved in medical or scientific decision-making presents its own set of challenges, as well. Briefly, our take on this is to work hard and validate the scientific merit of what we ship before we ship it. This does take a bunch of time, but having doctors and papers to vouch for what we do means that we've built trust and support in the community. Sometimes this means we ship a smaller set of features than "what is possible", but we're patient and see these products as stepping stones.
Finally, I'll note that we're a small team that's not venture -backed (at present, intentionally so). We're fortunate to have enough grant money to prevent starvation, but that's it. Really, lots of things are possible, even in the healthcare space.
Now, some amount of pragmatism is important, and I'm sure you've made your decision in a way that's best for you. I just hope that the entire community doesn't fall into the trap of "there's this [regulatory/bureaucratic] risk, so forget it. I won't even try."
My take on these types of hurdles is that they are surmountable with a good helping of resourcefulness. Example?
In our case, there's actually not FDA approval for primary clinical use of a technique we depend on, so there would be quite a bit of legwork between us and getting to market, not to mention the hospital bureaucracy.
What we figured out, however, is that technicians in the pharmaceutical industry (and biotech) use this same technique, in similarly high volume. The barriers to them adopting new technologies are much lower, and better still, they actively demand and pay for new technologies that boost efficiency. So we're starting with them as a target market, and we'll chip away at the barriers to direct clinical adoption in parallel to revenue generation.
This is only one trick of many we're bringing to bear in fielding our technology, and some patience is required before we can realize the impact we dream of.
Handling the risk associated with being involved in medical or scientific decision-making presents its own set of challenges, as well. Briefly, our take on this is to work hard and validate the scientific merit of what we ship before we ship it. This does take a bunch of time, but having doctors and papers to vouch for what we do means that we've built trust and support in the community. Sometimes this means we ship a smaller set of features than "what is possible", but we're patient and see these products as stepping stones.
Finally, I'll note that we're a small team that's not venture -backed (at present, intentionally so). We're fortunate to have enough grant money to prevent starvation, but that's it. Really, lots of things are possible, even in the healthcare space.
I believe that was his point, no?
That is one of the major issues preventing innovation in healthcare- the potential to lose a huge lawsuit. This article:
http://www.nytimes.com/2013/02/24/business/overcoming-obstac...
illustrated one of the main problems: the legal framework surrounding malpractice is completely screwed up. In the article, it is claimed that
"As it is now, a doctor or hospital can be sued if the plaintiff can show that “normal standards of care” were not followed, even if those normal standards of care are inappropriate."
Assuming that this is correct (I am neither a physician nor a lawyer), this basically freezes innovation, and makes it nigh impossible for innovation to occur.
That is one of the major issues preventing innovation in healthcare- the potential to lose a huge lawsuit. This article:
http://www.nytimes.com/2013/02/24/business/overcoming-obstac...
illustrated one of the main problems: the legal framework surrounding malpractice is completely screwed up. In the article, it is claimed that
"As it is now, a doctor or hospital can be sued if the plaintiff can show that “normal standards of care” were not followed, even if those normal standards of care are inappropriate."
Assuming that this is correct (I am neither a physician nor a lawyer), this basically freezes innovation, and makes it nigh impossible for innovation to occur.
You mean that I'm scaring people away and stifling innovation by asking what's your address and company data?
In other words, just in case I don't understand - a random poster on HN can stifle innovation in the healthcare industry by posting a half serious (missing address) half joke (suing anyone) comment ? I'm so happy I live in Europe :)
In other words, just in case I don't understand - a random poster on HN can stifle innovation in the healthcare industry by posting a half serious (missing address) half joke (suing anyone) comment ? I'm so happy I live in Europe :)
I believe the commenter was referring to your tongue-in-cheek second part of your comment: "just to know who to sue in case of a leak."
And there are places other than the US to sell products too. I'm not advocating insecure data, but some systems are different to the US, less litigious etc.
And the systems I'd most like to see improved are not accessible remotely (or rarely are), or are comparatively easy to secure (or seem to be to a layman at least), or are basic and loss of the info wouldn't get anyone anything they couldn't find out already (proper hospital rosters is what I have in mind. Wow hospital rostering systems are crap).
Does anyone know if a similar API exists for patient billing records? I see the OP API provides information on claims, but those are not necessarily detailed bills. I would assume that the answer is no, due to the many forms such bills could take. I am hoping they are required to have/provide an electronic bill in a set format, perhaps for medicare reimbursement purposes? Thanks......
[deleted]
This looks amazing, and puts a lot of patient-focused data out in a much more usable format.
I wonder about other parts of the chain (e.g. payer <-> provider) could benefit from this kind of tech-enabling?
I wonder about other parts of the chain (e.g. payer <-> provider) could benefit from this kind of tech-enabling?
Well... this certainly beats parsing HL7, especially v2.x (http://en.wikipedia.org/wiki/Health_Level_7#HL7_version_2.x for those not familiar with it.)
Good work. :D
Good work. :D
This is pretty amazing, not sure why it's not getting more attention.
The patient records (MRI, CT scan images, doctor writeups) are probably a lot harder to standardize I'm assuming?
That seems to be the missing piece from this API. Otherwise, great job you guys.. Open up the industry!
The patient records (MRI, CT scan images, doctor writeups) are probably a lot harder to standardize I'm assuming?
That seems to be the missing piece from this API. Otherwise, great job you guys.. Open up the industry!
It's true that the patient records use disparate standards, and that it's not trivial to convert them. But even when you have systems that adhere to the various existing data exchange standards, there are deeper structural reasons that organizations are hesitant to exchange data.
Their existing software often does a bad job of identifying the provenance of information or filtering out noisy irrelevant information, so unless they can be assured that everyone else is following the same policies around how things are documented and categorized, they're unwilling to mix a bunch of "outside" data with their own.
They also see little incentive to invest effort in opening up their own data to others, because it costs real money and doesn't really benefit them. This is where a good startup business could make a difference -- by doing the data exporting work "for free" in exchange for the ability to sell access to it.
Their existing software often does a bad job of identifying the provenance of information or filtering out noisy irrelevant information, so unless they can be assured that everyone else is following the same policies around how things are documented and categorized, they're unwilling to mix a bunch of "outside" data with their own.
They also see little incentive to invest effort in opening up their own data to others, because it costs real money and doesn't really benefit them. This is where a good startup business could make a difference -- by doing the data exporting work "for free" in exchange for the ability to sell access to it.
Thank you. One step at a time. We're focused on winning as the platform where all US healthcare eligibility information is passed to prove that it can be normalized and done fast. Then we will move on to help hackers take over the whole healthcare transactional world including clinical, imaging, and pharma data :) Less talk, more do!
What does this company actually do? Seems like you need to know a million buzz words, then take a leap, in order to figure out what problems this solves.
I'm a health care informatics professional (mostly clinical, not billing) and I can't seem to divine it.
I'm a health care informatics professional (mostly clinical, not billing) and I can't seem to divine it.
Healthcare providers in the US are paid by insurance companies. It is incredibly useful for providers to know if the patient that just walked-in for service actually has eligibile insurance benefits for the services about to be delivered. Historically this is done via phone calls and fax, if done at all.
There are ANSI standard EDI transactions designed specifically for healthcare insurance eligibility inquiries (there also exists transactions for claims, but that's the other side of the puzzle). The standards themselves are pretty simple. But unfortunately, from a business development and integration perspective, the effort required to become trading partners with healthcare insurance companies is extremely high. There are plenty of vendors and clearinghouses out there which make the process easier. But this company is trying to make the setup and integration even easier with self-service sign-up and credit card billing. It's a novel idea.
Edit: I have no affiliation with Eligible but I've been working with the underlying technology for many years.
There are ANSI standard EDI transactions designed specifically for healthcare insurance eligibility inquiries (there also exists transactions for claims, but that's the other side of the puzzle). The standards themselves are pretty simple. But unfortunately, from a business development and integration perspective, the effort required to become trading partners with healthcare insurance companies is extremely high. There are plenty of vendors and clearinghouses out there which make the process easier. But this company is trying to make the setup and integration even easier with self-service sign-up and credit card billing. It's a novel idea.
Edit: I have no affiliation with Eligible but I've been working with the underlying technology for many years.
Thanks. You answered what Eligible does much clearer than the Eligible guys (and gals :) ) themselves.
It does look very useful :)
It does look very useful :)
thanks for the gals!
I can only speak of physician's offices but I would imagine the process is much the same in hospitals, if more bureaucratic.
Before a test or lab is ordered, or before a specialist visit is scheduled, one of the assistants needs to verify that your insurance will actually cover the procedure. Typically this means the assistant needs to call the insurance provider, give them your information and what procedure(s) they are checking on.
Insurers provide this data but there are close to a dozen disparate standards and formats. Eligible consolidates all that into a REST API that developers can build applications on top of. From what I can tell this is definitely not for the healthcare industry, but for our industry to build healthcare applications.
I have no affiliation with Eligible, but I've been working in healthcare IT for several years, although not at the startup level.
Before a test or lab is ordered, or before a specialist visit is scheduled, one of the assistants needs to verify that your insurance will actually cover the procedure. Typically this means the assistant needs to call the insurance provider, give them your information and what procedure(s) they are checking on.
Insurers provide this data but there are close to a dozen disparate standards and formats. Eligible consolidates all that into a REST API that developers can build applications on top of. From what I can tell this is definitely not for the healthcare industry, but for our industry to build healthcare applications.
I have no affiliation with Eligible, but I've been working in healthcare IT for several years, although not at the startup level.
Traditionally health information technology has been run by non-technical bureaucracies sitting around a table creating "specs" that hackers then need to mud through (usually 300+ page pdf) in order to integrate/implement. The bureaucracies intentions are good: free up the data to build from, but the result is just the same old legacy vendors end up using it.
I appreciate your efforts, but this response doesn't really answer my question. It's too granular (and a bit biased). When I go to your web site, I need some context. I need business problems that this software solves. Based on the name I would say it's Medicare/insurance eligibility checking, but the web site should guide me through what needs the product addresses and why it's better than the alternatives.
Also, I'd advise you not to jump straight to messages about "non-technical bureaucracies." It's certainly true in some cases, but it sounds derogatory. Better to address the objectives these people are trying to meet.
Also, I'd advise you not to jump straight to messages about "non-technical bureaucracies." It's certainly true in some cases, but it sounds derogatory. Better to address the objectives these people are trying to meet.
She's answering the question well, I think, if you've got a basic knowledge of the problem Eligible is dealing with. Frankly, they're not selling to you if you don't understand what they do from their website.
They provide a RESTful API to insurance eligibility data, which is useful because the current (required-by-law) APIs are horrendously complicated and difficult to work worth, AND they're disparate, varying by vendor.
They provide a RESTful API to insurance eligibility data, which is useful because the current (required-by-law) APIs are horrendously complicated and difficult to work worth, AND they're disparate, varying by vendor.
So... hospitals can reject the uninsured even more quickly...?
Your insinuation, that hospitals reject the uninsured, is incorrect. Please read about the Emergency Medical Treatment and Active Labor Act [1].
[1] = https://en.wikipedia.org/wiki/Emergency_Medical_Treatment_an...
[1] = https://en.wikipedia.org/wiki/Emergency_Medical_Treatment_an...
Maybe you should try actually providing constructive criticism for the submitted link instead of this hurr USA insurance is dumb meme garbage.
How does develop an app with this without paying .05 for every api call? Seems like there is a need for some sort of testing sandbox where development can be done.
When you sign up you get $30 free credit (600 free test transactions to start).
Just a suggestion, but it seems like n requests in t for free would be a good model too. eg: Free 60 requests free per hour. 600 free test transactions is great, but for ongoing development the sandbox idea or rate limiting for a free plan seems preferable to us 'hackers'
Edit: edited n of free requests per t in eg
Edit: edited n of free requests per t in eg
Cool, thanks for the suggestion. The sandbox should be rolled out by the end of the week. Any reason why you put 'hackers' in quotations? Does it bother you that we use the word?
Unless the title changed, I don't see quotes anywhere. There is an apostrophe after the word in the HN title, but that's there to show possession (it's their hands).
This looks incredibly powerful. If there were no edge cases of unsupported insurance companies, I think you'd be able to build tools around this service (as it currently is, not what it promises to be) to replace an entire class of office jobs already.
The problem is insurance companies and the gordian knot of legislation they've erected to block wise reform. You can't have real reform that includes them.
Nah - not true. I'm bored with the argument that insurance companies are the bad guys. Gotta give me something more original :)
Boredom is hardly an argument for what is a large part of the problem. The history of contemporary insurance dates to the catholic church and the prohibition of usury. To get around the ban on lending money at interest, loans could be insured.
Default risk was priced and risk was conserved!
Fast-forward to the present day, the insurance concept was applied to healthcare as a way to smooth out one's healthcare costs over a lifetime and eliminate tail-risk to the individual. Since the 1930s, the insurance industry has evolved into a system to avoid paying for your healthcare costs. First, the growing expenses were thrown onto the employer (think auto manufacturers) and when the employers can't support the cost, onto the healthy by passing cost increases on to employees through increased premiums.
The fact is that if you consume something, you or someone(s) else will have to fund your consumption. The second law of thermodynamics applies to healthcare as well. There is no free lunch here either.
Insurance companies end up as an additional layer of administration expense. In the case of financialization of health care, the administration is extraordinarily expensive!
Risk is conserved!
Default risk was priced and risk was conserved!
Fast-forward to the present day, the insurance concept was applied to healthcare as a way to smooth out one's healthcare costs over a lifetime and eliminate tail-risk to the individual. Since the 1930s, the insurance industry has evolved into a system to avoid paying for your healthcare costs. First, the growing expenses were thrown onto the employer (think auto manufacturers) and when the employers can't support the cost, onto the healthy by passing cost increases on to employees through increased premiums.
The fact is that if you consume something, you or someone(s) else will have to fund your consumption. The second law of thermodynamics applies to healthcare as well. There is no free lunch here either.
Insurance companies end up as an additional layer of administration expense. In the case of financialization of health care, the administration is extraordinarily expensive!
Risk is conserved!
http://en.wikipedia.org/wiki/Contractum_trinius
A contractum trinius was a set of contracts devised by European bankers and merchants in the Middle Ages as a method of circumventing canon law edicts prohibiting usury. At the time, most Christian nations heavily incorporated scripture into their laws, and as such it was illegal for any person to charge interest on a loan of money.
To get around this, a set of three separate contracts were presented to someone seeking a loan: an investment, a sale of profit and an insurance contract. Each of these contracts were permissible under Church law, but together replicated the effect of an interest-bearing loan.
The way this procedure worked was as follows: The lender would invest a sum equal to the amount of financing required by the borrower for one year. The lender would then purchase insurance for the investment from the borrower, and finally sell to the borrower the right to any profit made over a pre-arranged percentage of the investment. This system replicated the effects of a loan with any interest rate agreed between the two, yet provided protection to the lender against default, while the borrower remained under the protection of the law when it came to collection of the money by threats or force (loan sharking).
And...
http://en.wikipedia.org/wiki/Vix_Pervenit
Vix Pervenit: On Usury and Other Dishonest Profit was an encyclical, promulgated by Pope Benedict XIV on November 1, 1745, which condemned the practice of charging interest on loans as usury.
A contractum trinius was a set of contracts devised by European bankers and merchants in the Middle Ages as a method of circumventing canon law edicts prohibiting usury. At the time, most Christian nations heavily incorporated scripture into their laws, and as such it was illegal for any person to charge interest on a loan of money.
To get around this, a set of three separate contracts were presented to someone seeking a loan: an investment, a sale of profit and an insurance contract. Each of these contracts were permissible under Church law, but together replicated the effect of an interest-bearing loan.
The way this procedure worked was as follows: The lender would invest a sum equal to the amount of financing required by the borrower for one year. The lender would then purchase insurance for the investment from the borrower, and finally sell to the borrower the right to any profit made over a pre-arranged percentage of the investment. This system replicated the effects of a loan with any interest rate agreed between the two, yet provided protection to the lender against default, while the borrower remained under the protection of the law when it came to collection of the money by threats or force (loan sharking).
And...
http://en.wikipedia.org/wiki/Vix_Pervenit
Vix Pervenit: On Usury and Other Dishonest Profit was an encyclical, promulgated by Pope Benedict XIV on November 1, 1745, which condemned the practice of charging interest on loans as usury.
Quite astonishing that in your search for the history of insurance, you managed to look up "Contractum_trinius" and "Vix_Pervenit" on Wikipedia, and yet failed to look up "Insurance" and look in the History section.
Insurance pre-dates Christianity by a considerable margin.
Insurance pre-dates Christianity by a considerable margin.
Perhaps it's possible I didn't google "history of insurance." Thorough reader you are, McWiki!
"history of contemporary insurance"
Merchant insurance was to protect against real property losses. Contemporary insurance is designed to allocate financial losses for financial products (non-real).
"history of contemporary insurance"
Merchant insurance was to protect against real property losses. Contemporary insurance is designed to allocate financial losses for financial products (non-real).
Perhaps you should have googled it before telling us that it was invented by the Catholic church.
Nice try moving the goalposts from health insurance (you know, the topic at hand), but still wrong...try more googling.
Nice try moving the goalposts from health insurance (you know, the topic at hand), but still wrong...try more googling.
[deleted]
I will put it in layman's terms for you.
Real property protection vs. Financial asset (contemporary legal constructs) loss allocation
Get it?
Real property protection vs. Financial asset (contemporary legal constructs) loss allocation
Get it?
Have no fear! America is a Christian nation and would never do something explicitly banned by the Holy Bible like usury.
Anything that allows us to treat the insurance companies as a relatively homogenous, interchangeable set of entities reduces their power to impede progress. This is true whether you believe that they impede progress intentionally (i.e., are malicious actors), or just incidentally.
https://www.eligibleapi.com/about-us - nothing https://www.eligibleapi.com/privacy - nothing https://www.eligibleapi.com/security - nothing https://www.eligibleapi.com/faq - yay, there's an email address :)
Seriously, what am I missing?