"I would like to insist on the "incentives" topic with a quick example: I previously developed production analysis software to find and exploit the cases where an hospital could be more efficient and thus make more money (long story short, see one of my previous posts on http://news.ycombinator.com/item?id=4826314 for more details)
As I like to say, this is as good as printing money - I can say precisely what should be changed in a billing statement, why, how much it will gain, and the probability to find matching evidence in the patient file."
There are entire companies devoted to nothing more than this - taking a ICD9/10 diagnosis, some procedure codes and massaging the bill to get the biggest possible bill (and vice versa, as an insurer, minimizing the same).
Yes, that's the easy part - massaging the bill, testing.
Providing an accurate estimation of the expected gains however require both domain knowledge and statistical analysis.
Ie if your hypothesis is to add "morbid obesity", and you know how much it will gain in the bill, how likely are you to find that in the patient file, given the patient history and (hopefully) some text from the release letter?
Enough to send an unqualified worker who does not understand medical speech?
(you won't get paid for ideas, but for actual results - and too many false positives cost money, because humans have to do the fact checking)
Do you believe it's worth putting a MD on the case? It will cost more in fixed costs, and thus reduce potential gains.
Can you automate that for one patient file consisting of multiple inputs? Can you still do that for 100'000 files? How long does it take for your software to produce its result? Can it still work when it is missing some critical information you believed in your early development would never be missing - like the release letter?
Textual analysis, datamining, Bayes, even sentiment mining (see http://news.ycombinator.com/item?id=4908056) etc - everything is fair game (ex: "the patient did not seem morbidly obese, but upon calculating BMI score, was")
Then you have to convert the lead to a sale. I'm talking about having money in the bank. This requires more than a nod and a signature for hospitals. I know firsthand - in the end, only one hospital paid.
Interest and traction are irrelevant. What matters is how much money you get in the end, and how satisfied the customer is to recommend you to others (it's a small world, especially in the health-IT field)
Very true - on a slightly different note, my company cleans up in the insurance / claims management side by implementing a system of policy management not based on table lookups but by allowing our providers to build rules and flows of their own. You wouldn't (well, perhaps you would) believe how many claims processors rely on database tables hundreds of columns wide to cover every permutation for a policy possible, and how (relatively) easy it is to convert those into boolean logic and simple rules along the lines of "IF AmountPaid > Deductible THEN" etc.
We achieve auto-adjudication of claim rates into the low-mid 90th percent, whereas most of our competitors are in the 60s to 80s (and some clients, inefficiently using those competitors, are as low as 30% auto-adjudication when they come to us).
But working on the insurance side of things increasingly tweaks my moral compass the wrong way...
Indeed, there are many things that can be done simply at first, then you have to reach for the higher hanging fruits.
However I would not call that "the wrong way" - for me, it's moral and logical. Maybe I'm too zen about that, but for me it's about increasing efficiency.
Generally speaking, if somethings feels wrong to you, you shouldn't do it. Works for every topic - because we each have our own morals, and it's soul damaging to go against it.
There are entire companies devoted to nothing more than this - taking a ICD9/10 diagnosis, some procedure codes and massaging the bill to get the biggest possible bill (and vice versa, as an insurer, minimizing the same).