Because the development process requires Functional Safety and most regular programmers will struggle with the glacial progress that occurs under such regimes.

While IEC 61508 is the parent of all Functional Safety, medical devices are a little divorced form 61508 and have their own primary standard IEC 60601.

Some good explanation occurs here https://blog.johner-institute.com/systems-engineering/functi....

But this is the sort of engineering where you know everything about what your functionality will be, and what code and what type of code will be used to achieve it, well before you even think about starting to code.

The testing requirements can include things like testing every possible combination of inputs, for every possible combination of states (often just not practical, but there are some techniques to say, we will ignore these combinations etc). Every part of the final code shall be traceable back to a requirement so on and so on.

In industrial Functional Safety you might very easily work on requirements and definition for 2 years before you even think about what you might code, or even the device or platform you might be coding on.

I know of a mine winder job (Could kill 100 people in one go, so sort of like a passenger jet in risk profile) where the defining aspect of the design/build/commissioning critical path was Functional Safety, and it ran 10 years from very beginning to in service.

Imagine the most painful and anal waterfall process you could possibly dream of, and it is more onerous than this, plus you are exposed to being kicked backed to an earlier phase if certain problems are discovered.

If you are a move fast and break things, Mondays is pivot day and we like to actually roll some dice to decide what this weeks pivot will be, type of guy/gal, you are likely totally mentally not ready for how this needs to work, and probably don't want to be.

Plus if you come from a world where everything is a listener, and various other event driven paradigms, most of these people real struggle with real time highly deterministic systems.

This is because these invariably end up needing to be scanned logic, which looks stupid coming from this background. But, it is the best way that you can assure repeatable defined behavior, because event driven code is almost always of the type that ends up with an arbitrary order of execution, and this is not suitable for systems that have expectations of a highly deterministic nature.

There are zero cases for such devices where the answer to a problem is "just send that email again", to show the wagon wheel and/or drop a few frames or show some at lower resolution, or tell the user "just reboot at intervals of no more than 23 days and hold down the reset button while you boot", and so on.

And, some of these devices can do firmware upgrades OTA (not actually very common for somewhat obvious reasons), some need a special programming device within very close proximity and/or wired, and some are made with code in factory silicon and if you get it too wrong you recall them all for binning, at great expense.

I see another comment says that time to market for medical devices averages 12 years, and 75% of companies formed to make these devices fail - yeah I can totally see that, especially if it is a device that might roll out in the thousands to hundreds of thousands, the potential for harm, and for that harm to arise from software that either is specified poorly, or implemented poorly, is very large, extremely large.

I am a functional safety engineer, for well over ten years now, mostly industrial process and machinery, I hold certs from TUV Rhineland SIS and Certified Machinery Safety Expert TUV Nord.

But these are like one week courses, almost anyone that can pay attention could usually pass, though you need grades like 80% or 65% etc depending who runs the course you do.

More importantly (and written quite heavily into the standards) is you need to be competent, in the formal sense, which only comes from working with, or under, other engineers with suitable experience and background, and this might realistically be minimum 5 years, certainly no less than 3.

So moving into real time, embedded often, limited memory and CPU resources, need to know RF maybe as well, on it goes, do you as a well paid dev engineer want to go back to close to square 1 for x years, working in a way that will probably at best seem very antiquated to you, though most requirements are for good reasons when you understand them.

And ultimately, similar to other Fields of Functional Safety, the coding and all the computer stuff is probably easier learned by someone with extensive domain experience,

This is opposed to being an experienced coder (in most likely a different kind of code) and acquiring anywhere near the same domain experience in any reasonable time. eg in this case you are probably much more likely to to find medical people with training and experience that fell into dev roles to service the need, and it might be very difficult to compete with them, for what might be both real and perceived/cultural/"club" reasons.

There is more, but I am sure that is enough in the immediate context - not trying to be discouraging, just realistic.