Yes, for very good reason network medical device vendors are specific as to what client software modifications can be made. This includes client-side security measures such as service packs, security patches, and antivirus. This is primarily due to FDA regulations which require full software qualification, validation, testing, and documentation. The full scope and diligent execution of an FDA-compliant quality safety process takes time and costs money. This is not like IT operations patching a web server; a patient on the table in a procedure requires all device imaging and monitoring systems to work flawlessly, exactly as designed. Any issues that arise will require an FDA adverse event report from the manufacturer and if the device has been modified from its FDA approved baseline then responsibility may fall on the hospital; then watch as the lawyers pull out all the stops, especially if patient treatment was affected.

I work directly in this field. Once hospital IT get their head around these facts, it's time to think outside of using traditional client-side security mitigation techniques. It's routine for me to find hospital IT networks with no mitigating network security controls controls, no VLAN segmentation, no ACL entries, no routing chokepoints, firewall rulesets with ANY/ANY permitted, and the inevitable infected medical devices. It's a shame for patient safety.

I just went through a similar experience. I bought a new car with a nice sound system, activated the satellite radio trial and was utterly repulsed by the poor fidelity. Similar to this story, however, when I mentioned this to other people that have satellite radio in their vehicles they responded with confusion, not comprehending what I was complaining about.