Why on earth is medical equipment running standard Windows? This is the ideal location for some basic RTOS or even just an embedded Linux. Seems like a huge cost and risk for no gain.
It's cheap to find Windows programmers and even cheaper to find ones that are not hindered by knowledge about software quality and safety. That's not their fault; no-one ever told them something like that exists.
That was my first thought too. And why there is an anti-virus running? This equipment should not be connected to the internet nor some staff should plug-in a flash drive on the first place.
Could communicate with a gateway bridging a private medical devices network and a public network. That seems a reasonable way to provide control and access.
I believe that it's strongly related to the dashboard software being targeted towards "familiarity" by the doctors / customers and having old GUI-centric software from back in the mid-90s ported to run on Windows over the decades prettied up back when there was nothing really viable for end-user accessible embedded systems besides even more grotesquely expensive custom software with even less capabilities and far worse SDKs than anything under Windows back in, say, 1994. This isn't that different to me than banking software with a COBOL backend with Java middleware and a PHP frontend that's extremely common for retail banking sector.
Given the sheer amount of overhead in enterprise BS medical hardware has (read: sales people likely get the biggest chunk of the absorbed costs) it wouldn't be a surprise to me that the engineering teams amount to a skeleton crew while 70%+ of the personnel involved are non-engineers that override the professional decisions of the engineers.
I feel there are two very contradictory views on HN. The first of these, is that anything safety critical needs to land on an RTOS.
The second of these, is to avoid C.
Both of these have reasons behind them and appear to make sense. Leaders in the RTOS space appear to be QNX and vxworks. Suitable languages people raise are Rust and Go.
Based on some Google time, neither of these platforms support either of these OS's. Multiple "Introduction to vxworks" documents are all exclusively in C.
In terms of accessibility, safe languages are far easier for someone to get their hands on, test to death, than some of the OS's recommended.
I never realized just how lucky I was to have been born when I was. I can't imagine building embed devices which aren't running a very simply super loop or an ARM RTOS.