

Putting healthcare in hackers' hands - kategleason
http://blog.eligibleapi.com/?p=155

======
TomaszZielinski
So I want to know their address and company registration data, just to know
who to sue in case of a leak :)

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

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

~~~
GFischer
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...](http://www.ama-assn.org/ama/pub/physician-
resources/solutions-managing-your-practice/coding-billing-
insurance/hipaahealth-insurance-portability-accountability-act/hipaa-
violations-enforcement.page)

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

~~~
GFischer
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...](http://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/ucm263280.htm)

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

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

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

~~~
GFischer
Thanks. You answered what Eligible does much clearer than the Eligible guys
(and gals :) ) themselves.

It does look very useful :)

~~~
kategleason
thanks for the gals!

------
aantix
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!

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

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

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

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

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

~~~
kategleason
When you sign up you get $30 free credit (600 free test transactions to
start).

~~~
ncavig
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

~~~
kategleason
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?

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

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

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

~~~
kategleason
Nah - not true. I'm bored with the argument that insurance companies are the
bad guys. Gotta give me something more original :)

~~~
nwzpaperman
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!

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

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

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

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

~~~
nwzpaperman
I will put it in layman's terms for you.

Real property protection vs. Financial asset (contemporary legal constructs)
loss allocation

Get it?

------
craig552uk
So... hospitals can reject the uninsured even more quickly...?

~~~
carbocation
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...](https://en.wikipedia.org/wiki/Emergency_Medical_Treatment_and_Active_Labor_Act)

