|
Certainly appears possible. See my other post that states "1 in 7".
|
|
|
|
|
not quite. The article said that 90% of UHC denials were overturned due to faulty logic, not following Medicare coverage laws, not following doctor's specific instructions and endangering the health and welfare of the patient. (Mainly seniors who were in hospice or nursing care to treat long term recoveries for injuries or sickness)
However, the denials were generating hundreds of millions of dollars in claims not paid. So there was no incentive to correct the faulty denials of payment. The upper management of UHC went as far as to threaten, demote and fire employees who were going against the AI generated denials and approving the payments.
In the 1970's and 80's it was the green bar computer printout that overrode people's good sense. "The computer said so." Today it is being replaced by "The AI said so."
|
|
|
|
|
Gary Stachelski 2021 wrote: The article said that 90% of UHC denials were overturned due to faulty logic,...
The article I posted specifically said the following
"But data from state and federal regulators shows that insurers reject about 1 in 7 claims for treatment."
1 in 7 is a higher rejection rate.
And that is based on the non AI process.
modified 21-Nov-23 11:24am.
|
|
|
|
|
Which like a lot of this stuff is just not really relevant.
The fact that an algorithm was doing it doesn't change that they were doing it before that.
Following article would suggest that the above is actually an improvement.
Inside UnitedHealth’s Effort to Deny Coverage for a Patient’s Care — ProPublica[^]
"But data from state and federal regulators shows that insurers reject about 1 in 7 claims for treatment."
|
|
|
|
|
I would beg to differ. The article you linked to is a single case where a claim was in question. The article I originally linked to was describing an entire class of senior patients that had coverage, had a valid claim but payments were being denied and questioned by the AI. These patients were recovering from hip fractures, ankle fractures, Pneumonia, Covid. The claim was accepted and the rules said they could have up to 100 days of care to recover. After 7 to 14 days UHC began denial of payments. It would dispute treatments, refuse to talk to doctors, argue with the diagnosis and treatment. This was done not at the start of the claim, which all parties agreed was correct and valid. Families were forced to either pay out of pocket to continue with care or see the senior sent home to make it on their own. The law suit was the result of several patients dying.
While it might be true that management at UHC would have pressured their people to cut care early. It appears that they now point to an AI which is supposed to be infallible and challenge you, your lawyers and doctors to prove otherwise. Meanwhile, no payment and the patient suffers.
|
|
|
|
|
Gary Stachelski 2021 wrote: I would beg to differ.
From my link and what I already posted...
"More than 200 million Americans are covered by private health insurance. But data from state and federal regulators shows that insurers reject about 1 in 7 claims for treatment."
Please explain how I misread that.
|
|
|
|
|
#Worldle #664 2/6 (100%)
🟩🟩🟨⬜⬜↖️
🟩🟩🟩🟩🟩🎉
https://worldle.teuteuf.fr
easy
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
...hence why I used Server 2022 when I built my latest dev VM. I got tired of finding out my previous Windows 10 dev VM had rebooted right after Patch Tuesday.
But no, my dev machine rebooted last night at 00:45am. Lost an awful lot of context.
Meanwhile, the VM host, running Server 2012 R2, back when it was still supported and getting updates, would patiently wait for months if I just let it.
Surely server admins aren't putting up with this. Surely MS hasn't changed the default behavior so a server OS can now reboot if it just feels like it.
|
|
|
|
|
Dunno. My Win 10 desktop system keeps chugging along waiting patiently for me to apply updates when I'm good and ready.
|
|
|
|
|
I've never managed to stop the MS bologna. I can hold it off, but if I say take a weekend off and don't notice a pending "update", I'll find a clean screen the next morning. I'm actually surprised there hasn't been a class action lawsuit to stop this crap.
I'm assuming deep in the bowels of MS, they have servers running their software. I cannot remotely imagine they tolerate server reboots in their own facility.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
Microsoft makes a point to dogfood their own products. They even came up with the verb "dogfood"
That tells me there's probably a way to turn the "feature" off, even if it's on by default (which it shouldn't be, but that's MS for you)
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
honey the codewitch wrote: That tells me there's probably a way to turn the "feature" off, even if it's on by default (which it shouldn't be, but that's MS for you)
That was my primary point. As mentioned, I can have Server 2012 R2 wait for months with the reboot prompt waiting for me to click it - it'll never initiate the actual reboot on its own. But something has changed somewhere along the way so nowadays the Server releases are now as dumb as the consumer ones.
If I try to manually reboot Server 2022, I'll get the prompt that's asking for the reason to reboot (unless I disable it). But even that, apparently, is not enough to prevent the OS from waiting indefinitely.
Or Notepad waiting with a "Save Changes Y/N" prompt. That used to be enough to prevent a reboot. Not anymore. It used to kill every other process until it reached that one, but it never forced it to be killed.
|
|
|
|
|
Which version? Win10 Enterprise can have policies set to allow updates only on the owner's schedule, cutting Microsoft out.
I run Win10 Professional at home, and AFAIK I can't easily shut off the updates, but I can snooze them for roughly 5 weeks. My practice is to snooze the updates, then every 3 to 4 weeks, when it's convenient for me, I unsnooze and let it do its thing. Then I snooze it again.
UPDATE: I found a group policy setting that shuts off automatic updates and allows manual check. I'm going to try that.
|
|
|
|
|
If that works, can you please post a followup comment about it?
Time is the differentiation of eternity devised by man to measure the passage of human events.
- Manly P. Hall
Mark
Just another cog in the wheel
|
|
|
|
|
Mark Starr wrote: If that works, can you please post a followup comment about it? Will do. The process I used is:
1. Launch the Run command (Win + R). Type in "gpedit.msc" and hit Enter to open the group policy editor.
2. Drill down through Computer Configuration | Administrative Templates | Windows Components | Windows Update
3. In the right pane, select Configure Automatic Updates [I had to sort by name, as there are many options in no obvious sort order]
4. Click Disabled to select it, then click Apply and then OK
The descriptions in the Configure Automatic Updates dialog talk about Windows XP, so this is old. I did this on my laptop, but not my desktop. I'm going to watch on a daily basis to see what happens.
Note 1:
When I go into Windows Update in red it reads "*Some settings are managed by your organization"
Below the Check for Updates button it reads "*Your organization has turned off automatic updates"
I have hopes it will work, but fear it just can't be this easy. We are dealing with MS, after all.
Note 2:
If Enabled is clicked, options can be set to "3 - Auto download and notify for install". If the above works, I may try this, as I have no problem with updates being downloaded. My objection is automatic updates and especially being forced to reboot.
|
|
|
|
|
. 2. Drill down through Computer Configuration | Administrative Templates | Windows Components | Windows Update
. 3. In the right pane, select Configure Automatic Updates [I had to sort by name, as there are many options in no obvious sort order]
That’s the piece I needed. You’re right: there are so many flags and switches now it’s mind numbing to go through them.
Thanks!
Time is the differentiation of eternity devised by man to measure the passage of human events.
- Manly P. Hall
Mark
Just another cog in the wheel
|
|
|
|
|
Yes, my update dialog also said something about the organization and updates.
Win 10.
I left mine as auto-download but not to update.
Time is the differentiation of eternity devised by man to measure the passage of human events.
- Manly P. Hall
Mark
Just another cog in the wheel
|
|
|
|
|
I had to wait until there was a Windows update on my desktop to test if the policy change works. The laptop, which I used the policy change on, said it was up-to-date, but when I clicked the "Check" button it found 2 updates and is installing them.
So the change works on Win10.
Since posting in this thread I replaced my aged Lenovo laptop with a Surface running Win11 Home. I am girding myself to replace Win11 Home with Pro ...
|
|
|
|
|
PIEBALDconsult wrote: waiting patiently for me to apply updates
Probably an important distinction:
I'm not talking about waiting for me to install updates; I do have it install them (since that's something that can take a while, but can run in the background while I keep working).
I just want it to wait for me after that to give the okay to reboot. That's how I've always done it. But in this particular case, I imagine, the prompt comes up while I'm away, it gets no response, then reboots on its own overnight. Server 2012 R2 (and probably others) waited indefinitely. 2022 won't even wait for 24 hours, whether you've seen the prompt or not.
|
|
|
|
|
dandy72 wrote: Surely server admins aren't putting up with this.
Not sure what you mean.
Standard large distributed system architecture design would be to expect servers to reboot, fail, and even just disappear (taken down and not restored.)
As an example AWS SLA is 99.99% per month. So it will fail. You only get back (money) for the time it was down if it was down for more than that. And it is generally up to you to figure it out and prove it.
dandy72 wrote: so a server OS can now reboot if it just feels like it.
I believe one can turn patching off entirely.
That however only prevents reboots due to a patch. Restarts for other reasons are possible. Some that I can think of
- Manual reboot request
- Perhaps detected error. So OS and/or hardware detected problem and restarted.
- Power problem.
dandy72 wrote: a server OS can now reboot if it just feels like it.
Perhaps not applicable to you but at least AWS will force updates for certain cases. They give notice but if the user has not updated the system by the specified date they will just do it.
|
|
|
|
|
dude, some of us may run "server" OS, but I suspect we're talking about a machine almost certainly used in development. I do expect interruptions, it's why I have a UPS in my office. The context is MS forcibly rebooting machines because they are just stupid and have their heads where the sun doesn't shine. I'm being polite. Ask me how I really feel. There is not another OS in the world that forces updates/reboots like this. It's just stupid.
Customers I work with have some sort of enterprise version where the forced reboot is clearly disabled. I've logged into these machines for months and seen "you need to reboot" popups. I'm not the sysadmin, so it's not up to me to reboot things.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
charlieg wrote: The context is MS forcibly rebooting machines
The OP does not state that they found the cause of the reboot. As I noted in my response there are a number of possible causes.
charlieg wrote: where the forced reboot is clearly disabled.
Which applies to one situation.
|
|
|
|
|
jschell wrote: Standard large distributed system architecture design would be to expect servers to reboot, fail, and even just disappear (taken down and not restored.) We are not talking about a unforeseen failure that crashes a server.
We are talking about an outside third party intentionally rebooting a server at its whim, completely ignoring the needs of the owner of that server.
For former is an "act of god". The latter is an "act of Microsoft".
jschell wrote: Perhaps not applicable to you but at least AWS will force updates for certain cases. They give notice but if the user has not updated the system by the specified date they will just do it. Emphasis mine.
This is a totally different scenario, as the owner of the servers (AWS) gives notice to the tenants that maintenance is required, and acts when a deadline has been reached.
Similarly, all computers and major systems at my employer undergo periodic maintenance. The respective owners give users (tenants) sufficient warning ahead of time, and any who fail to heed the warning, get what they get.
|
|
|
|
|
BryanFazekas wrote: We are not talking about a unforeseen failure that crashes a server.
We are talking about an outside third party intentionally rebooting a server at its whim, completely ignoring the needs of the owner of that server.
This. So much this.
BryanFazekas wrote: For former is an "act of god". The latter is an "act of Microsoft".
I think the fundamental problem here is that according to Microsoft, there is no difference between the two.
|
|
|
|
|
BryanFazekas wrote: We are talking about an outside third party intentionally rebooting a server at its whim
The OP did not state that.
BryanFazekas wrote: (AWS) gives notice to the tenants that maintenance is required, and acts when a deadline has been reached.
And yet in my experience people are still surprised when it happens. The notice was given but they did not see it so they do not understand why it happened.
BryanFazekas wrote: Similarly, all computers and major systems at my employer undergo periodic maintenance.
In my experience I have had to debug production server problems because someone did an update without telling anyone. Sometimes without even documenting it. Even when documented often without documenting what the exact update did.
And then when I am tasked with determining the problem, no one on the call is even aware that an update happened.
|
|
|
|