
Ask HN: Glassdoor for Medical Bills? - brundolf
I had an idea earlier after receiving an unreasonable medical bill.<p>As most here probably know, medical bills in the U.S. - in addition to being high - are almost never advertised, often erroneous, often inflated via agreements with insurers, and can often be talked down as soon as the recipient points out issues with them.<p>What if there were a website where people could report their invoices from different providers, tagging them by state, by insurance provider, by insurance plan, itemizing the charges for each piece of care, and including both the base charge and the amount covered by insurance, and then the site could a) aggregate this data to help people understand how their costs compare to others for similar treatments, and b) raise general awareness of the prices. If prices won&#x27;t be transparent up-front, we can make them transparent after the fact for the next person. Beyond just helping individuals, if this got big enough it could conceivably push down prices as providers are forced to compete.<p>A journalist at Vox did something similar (for a one-off investigation) at one point: https:&#x2F;&#x2F;www.vox.com&#x2F;2018&#x2F;2&#x2F;27&#x2F;16936638&#x2F;er-bills-emergency-room-hospital-fees-health-care-costs<p>But of course what I&#x27;m talking about would be an ongoing, ever-growing, self-reported dataset.<p>Does this exist? Could it exist? Anybody want to collaborate on it?
======
applecrazy
I've had this exact idea. I made it as a hackathon project but haven't worked
on it ever since. One of the things I wanted to do was to use publicly-
available treatment cost data (I think states like California require
reporting of this) and aggregate it by type of treatment to allow users to
comparison-shop between medical providers in their area.

The issue I was facing (and the reason I stopped working on this project) was
the lack of standard, openly-available medical codes, since most hospitals
mark treatments with CPT codes, which are proprietary and require a license to
use in software. If anyone has any solutions to translate these codes to
human-readable names without licensing the entire set of codes from the
American Medical Association, I'd be open to hearing those ideas.

~~~
brundolf
My (possibly naive) thinking was to have people just enter the human-friendly
name for each item from their invoice as-is. A data-cleanup stage would then
be necessary to reconcile these names across entries, but:

\- The same provider will presumably use the exact same name for the same item
across invoices, reducing the subsets of values that will need to be matched
up (similar to the way services like Mint make sense of transaction names)

\- Some automated "fuzzy matching" could be applied; keywords, off-by-one-
letter checks, etc

\- Human curation, amplified by the above two factors, might be feasible

\- Maybe someone could even do something fancy with a neural-net, who knows
¯\\_(ツ)_/¯

But yeah, data reconciliation is definitely one of the main challenges here.

If you want to brainstorm/discuss more directly, you can email me at
mail[at]brandonsmith[dot]ninja

~~~
adventured
It's a good idea overall.

My suggestion is to absolutely under no circumstances attempt to cover all (or
a large number) possible medical codes in the first few years. Do not spend
any mental energy on that, it will bury you, it will rob your motivation, it
will waste your time and make you wish you never considered the service.

Do the opposite, start very stupid simple, knock down one bowling pin. Pick a
small selection of the most common medical codes or those most in need of this
service (the treatments that can benefit most from this). Roll the complexity
gradually from there. You will be aided by resources as you scale, in many
ways, which you will lack in the beginning. Your expanding userbase can also
assist you immensely as you go along (in the beginning they won't exist); but
you first need to have a very useful service to get those users, and to do
that you have to be good at something; narrow, narrow, narrow; you'll expand
outward later.

And frankly if you can't make it work for a small group of medical codes, you
are not going to make it work for a much larger & complex context.

Again, whatever you do, do not attempt to run before you crawl with this. You
don't need to do that. Just offering this for small selection of medical codes
could be hugely valuable, then slowly expand it. Make it work super well for
that small group first.

Make it clear what your service focuses on, and keep that list short. Reject
any attempts by users to expand the system to cover all medical codes in the
beginning.

It's no different than going from Harvard.edu, to Stanford.edu as in the
Facebook bowling pin strategy, and then building up some demand from users to
see you add more medical codes (the userbase will help inform you which to do
next). Do not try to go wide in the beginning, it's a guaranteed path to
failure.

Plus, if you start with a small selection of medical codes, you can better
focus on your outreach / marketing to just those people and their
circumstances. It will drastically simplify your attempts to find the first
100 / 1000 / 10000 users, and those early users will all be able to coordinate
on the same narrow medical code/s, which will build the initial community
foundation you require. If you try to go wide initially, covering a lot of
medical codes, you'll get stray users that won't be able to coordinate with
the other users who all have different medical codes (ie it's better to have
1,000 users with the same single medical code, than 1,000 medical codes each
with one user).

~~~
brundolf
Thanks for the feedback. I think you're right; my thinking was to eagerly
gather as much data as possible even if not all of it is useful immediately,
but it's true that it might dilute the experience when the person _entering_
the info doesn't yet benefit from most of what they've entered.

~~~
adventured
Absolutely. You risk an endless cycle of the ghost town effect in that
scenario (people floating on an island by themselves, to zero benefit). I'd
wager it's better to have only 100 users with one medical code, than 10,000
users all with different codes. Those 100 users ignite the function of the
system, its desired feedback mechanism. I suspect there are some large, very
common targets you can choose from to get started. Your challenge is probably
deciding whether to target a more common medical code, or one with greater
user intensity (people that are more frustrated; a higher intensity factor
might be ideal for starting the system around; it's an interesting trade-off).

------
codegeek
Funny I have thought of doing exactly the same. Would love to brainstorm
ideas. Sick and tired of medical billing crap.

------
schemescape
My employer used to provide access to a service (it might have been Castlight
Health) that would show typical prices for providers/facilities, so you could
at least attempt to shop around. I don’t think it is open to individuals,
unfortunately.

------
giantg2
Many insurance providers actually have a portal where you can search for a
procedure and they will list the providers and their prices.

------
greenyoda
What do you envision as the business model for this site? Pay to subscribe?
Ad-supported? Free, supported by donations?

~~~
brundolf
I was thinking open-source/nonprofit. Server costs should be trivial until it
started to take off for real (and I'd personally be open to covering them out
of pocket), at which point a proper nonprofit/donation model could be set up.
Ideally the data itself would also be open, for use by others (analysts,
journalists, etc).

