The Do’s and Don’ts for Medical Software Development

by | Feb 25, 2021 | Medical Devices, Quality, Quality Systems, Software

For any software development, there is a defined pattern. What I like to do is always start with the identification of the problem statement. The answer to this question forms the major purpose of the software. Then I like to create a blueprint or architecture, and then break it down into modules. Modules are then simplified into atomic software requirements. From this point, I begin my development and keep adding layers of functionality on top of it. Finally, with testing, my software is ready to be installed and deployed. But this pattern changes a bit when we are developing software that is going to provide a service in the healthcare sector. Especially if the software service impacts the patient’s safety or makes important decisions regarding the patient’s health, FDA intervenes and checks if the software follows certain regulatory guidelines. In this regard, we present a blog that discusses what activities developers should incorporate while developing medical software systems and what they should avoid while working on their software tool.

A key part of software development is software validation. For validation, one of the most important entities is design requirements. Therefore, initially, manufacturers should capture all the requirements which collectively form the device’s intended use. When this software design is locked, developers have a clear picture of what lays ahead in medical software development. The second major “Do” would be referring to an existing prototype for development. A good prototype would provide advantages, disadvantages, business model, data flow, and limitations. This would resemble an actual reference point while designing and developing specific modules in the application. The next major practice is starting with quality management activities. An example is when you are designing the system, write it in such a way that it will constitute the testable software requirements, the architecture as well as the detailed design or module documentation. Also, I would recommend that when a program file is written, the next steps to implement would be verification and validation activity such as unit testing, analysis, and inspections. In the end, I would also perform risk assessment activities in parallel with code development. If these activities are performed in parallel with medical software design and development, the final product would be ready with the assurance that the software has been tested, verified, and overall validated in terms of design, functionality, and performance.1

After discussing the Do’s, let us discuss the Don’ts in the medical software development life cycle. The first is always monitoring if the software requirements contribute towards the overall intended use. If there are requirements that shift from the objective of the software, it can shift the overall development of software in the wrong direction. Hence, do not add requirements that shift the focus from the intended goal.2 I think the next Don’t is very important which is considering regulatory strategies too late. What this means is not applying the required quality checks from the design till the deployment phase. For example, if the testing is performed on all files after the entire software is built, bugs such as data leaks or inappropriate comments would not be identified as unit testing was not performed.

As I am working as a software engineer in the medical device industry, I make sure that I follow all the stated “Do’s and Don’ts” principles. Indeed, it helps me streamline the entire development process and helps me organize the design, development, and testing phases of the software tool following the FDA regulatory guidelines. One of the key checks before deploying the software is validating if the software achieves the intended use while maintaining the required levels of safety, quality, and efficiency. This is where EMMA International specializes. Our experienced quality and software experts can guide you through the FDA regulatory process to ensure medical software system is thoroughly validated and is FDA compliant. Contact us at 248-987-4497 or info@emmainternational.com for more information.


1Codrine Arsene (March 2020). The Dos and Don’ts of Medical Device Software. Retrieved on 18th February 2021 from https://lapostexaminer.com/the-dos-and-donts-of-medical-device-software/2020/03/29.

2Milton Yatberry (October 2019). 3 Do’s and Don’ts for Medical Device Software Development. Retrieved on 18th February 2021 from https://www.designnews.com/design-hardware-software/3-dos-and-donts-medical-device-software-development.

Govind Yatnalkar

Govind Yatnalkar

More Resources

FDA Adverse Event Reporting 

FDA Adverse Event Reporting 

When reporting an Adverse Event to the Food and Drug Administration (FDA) the best method is to utilize the FDA Adverse Event Reporting System (FAERS). FAERS is a database that contains adverse event reports, product quality complaints that led to an adverse event, and medication error reports1. All FAERS reports are easily accessible to the public. 
De Novo Classification

De Novo Classification

A device can be registered for the De Novo pathway if there is evidence of the safety and effectiveness of the device and there is not a previously legally marketed predicate device1. When determining if your device can go through the De Novo process there are two pathways available to determine the device classification.
Abbreviated 510k submission

Abbreviated 510k submission

There are three types of 510K, Premarket Notifications, which can be submitted to the Food and Drug Administration (FDA) traditional, abbreviated, and special. Abbreviated and Special 510K submissions can be utilized when the submissions meet the certain factors presented by the FDA. When submitting an abbreviated 510K the submission must include the elements that are identified in 21CFR 807.87 for the information required in a premarket notification submission.

Ready to learn more about working with us?

Pin It on Pinterest

Share This