Putting healthcare in hackers' hands(blog.eligibleapi.com) |
Putting healthcare in hackers' hands(blog.eligibleapi.com) |
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?
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.
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...
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.
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'm a health care informatics professional (mostly clinical, not billing) and I can't seem to divine it.
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!
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.
I wonder about other parts of the chain (e.g. payer <-> provider) could benefit from this kind of tech-enabling?
Edit: edited n of free requests per t in eg
Good work. :D
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!
[1] = https://en.wikipedia.org/wiki/Emergency_Medical_Treatment_an...
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.
It does look very useful :)
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.
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.
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.
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.
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...
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.
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.
Insurance pre-dates Christianity by a considerable margin.
"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).
Nice try moving the goalposts from health insurance (you know, the topic at hand), but still wrong...try more googling.
Real property protection vs. Financial asset (contemporary legal constructs) loss allocation
Get it?