Software and software as a medical device may share the key characteristic of being software, but they couldn't be more different in structure. Most software engineers start out with a goal in mind, and create code based on their knowledge gained to achieve basic structures. They test to make sure the code works as intended, review with clients or users and get feedback. They then revise the code for bugs, changes, etc. until the user is happy. Job well done, move on to the next.
In a medical device environment, the key difference is the regulatory and compliance requirements for your software. Since software intended to help with patient care is going to affect lives, stringent rules are in place to prevent any bugs or changing priorities from making it into a cleared device. Each software project needs to start on a white board where an architecture and basic user needs are outlined and a quality system established to capture these steps. Once the end users agree to the needs and sign off on them, risks need to be outlined for each proposed unit of a code that might have problems, or risks. These risks are then pondered over until a good solution that will minimize the risk is determined. Then a strategy to test and prove this mitigation has to be figured out.
Notice how we haven’t touched a computer yet, the key question to ask yourself is, are you reacting to issues, or do you have a plan? The regulated medical device software needs a well laid out plan, or it’s not compliant with the regulations.