Not too much actually. You need to have a design history file (DHF) and a Failure-Mode Engineering Assesment (FMEA) document as part of your "Quality" system for FDA submission, usually at the time the project starts. Defining and using agile methodologies forces those documents/proceedures to be more in-sync with the software system and any unit/system/e2e testing and CI. It also formalizes the testing process - bringing some structure to the agility of your chosen methodology.
AAMI TIR-45 ("Guidance on the use of agile practices in the development of medical device software") offers guidance by mapping agile practices to regulatory requirements, and there are many other good examples for implementing agile (small "a") methods in other highly-regulated industries.
Agile itself is perfectly fine for this sort of software. It's a philosophy and approach, not a set of dogmatic rules.
We applied agile methods to developing safety systems for aircraft (something of a pilot project within the company, looking for a "better way"). It was quite effective, focusing on iterative development, small changes integrated frequently, frequent delivery to the customer for verification/validation, etc.
Well, a lot could, of course. But the word agile is used rather loosely these days, and I think good advice can come from a blog with (almost) an arbitrary name.
There's a balance. Slow and heavy development might create unadequate systems that cause more harm than good to doctors and patients. Proper iteration time might avoid this.