Spouse of a medical practice manager at a mid-sized practice here. Provider data is wildly variable in quality, to be sure. But if the insurance companies are trying to clean the data, they're not using the 'result' to make the system more efficient (except maybe for them at the expense of everyone else), because "we get bad data" gives them another reason to deny the claim. My wife and all of her peers spend inordinate amounts of their time responding to valid insurance denials, quoting chapter and verse of IDC10. Some insurers are so notorious (as in 'deny every claim up front...make them work for it hoping they'll give up') my wife drafts the response to the denial along with the initial request, because she knows it's automatically coming. This makes the automation possibilities that electronic patient management systems offer less effective, because to get paid the practitioner still has to manually intercede in way too many claims.
Another bit of collateral damage is the increasing number of providers who no longer take insurance of any kind and put the onus on the patient to file (and fight) with the insurance companies.
Absolutely. But it happens on the opposite side as well. I can say that major insurance companies have to deal with major hospitals (in addition to individual practices) miscoding stuff.
Not even because they want more money! It's more wrong vs correct. And is done just because "that's the way they've always done it" (and they're used to the insurance company fixing it on their side).
The biggest benefit of the move to automated processing and electronic records is it doesn't leave room for Dr. Sue and Mr. Green to have a non-policy understanding on how to handle claims.
It got things done, but it made it impossible to scale when you were trying to untangle 1,000,000 "special cases."
If you don't mind, why exactly? You're worried the care will get screwed up? Or you worry that someone will steal that data and charge more for insurance?
I'm just wondering about why exactly the paradigm doesn't totally work here. I get that we don't want medical devices failing, but that's different than charting. And I get it that we don't want everyone to have your data. But risking that someone does a data copy vs. reducing healthcare costs seems perhaps a risk worth taking (and it's not like the insurance companies who actually charge us money don't already have it).
Move fast and break things is a really unfortunate name. In my experience, the process of continous deployment, and the automation and defintion of processes to do it well bring more stability than the "move slow and keep things stable" environments. When you deploy once a month (or less!) you view deployment as a one off thing. When you deploy every day or every week. You view releases as a regular part of development. That change in mentality is critical to stable releases.
"move fast and break things" was Facebook's internal engineering motto when I started working there, but it was later (~2016) changed to "move fast and be bold"). The new motto is really just saying what the old motto meant but in a less hyperbolic way.
