Developing Successful FDA Compliant Medical Devices

Software and Firmware for Safety-Critical Systems

Today, medical devices rely on an increasing amount of software running on embedded microprocessors, PCs, smartphones, and the cloud. Whether you are designing and developing standalone Software as a medical device (SaMD), networked medical devices, a component of an IoT system, or a cloud based solution, it is likely that the software and firmware will be using a combination of multiple connections. There are several phases to medical device development before it can be brought to market.

Unfortunately, many great medical machines and equipment are not approved by the FDA and fail to make it to market.  Others hit the market years late and many more devices are way over budget. Understanding the complexity of FDA regulations and classifications, as well as the associated costs of each development phase, is critical when planning a successful medical development project.

What’s Different about Medical Device Software Design & Development?

When designing and engineering medical device software, there are many safety and security issues that must be considered. Medical device designs should consider how the device will run in each possible type of environment, with all users in mind, including clinicians, patients, and manufacturing personnel.

In the United States, the Food and Drug Administration (FDA) has several regulations for medical devices. Medical devices must adhere to different regulatory requirements to pass the 510(k) clearance process and/or De Novo process. FDA guidelines also determine device classification (i.e. Class I, II, or III). With changes coming to the 510(k) pathway and additional FDA regulations, it is critical that medical device manufacturers fully understand what such regulations entail.

At a high level, preparation for FDA submissions should include the proper documentation and plans, including Standard Operating Procedures (SOPs) and the Quality Management System (QMS).
Additional FDA standards for medical devices may include, but are not be limited to:

• ISO 13485 – Medical devices – Quality Management Systems
• IEC 14971 – Application of risk management to medical devices
• IEC 60601-1 Chapter 14 – Programmable Electrical Medical Systems (PEMS)
• IEC 62304 – Medical Device Software – Software Life Cycle
• Title 21 CFR Part 11 – Electronic Records; Electronic Signatures
• Title 21 CFR Part 820 – Medical Devices, Part 820 Quality System Regulation
• EU-MDR – European Union Medical Device Regulation
• FDA Unique Device Identification Rule (UDI)

Regulations may vary depending on device type and intended use, for example, In Vitro Diagnostic (IVD) devices should consider adhering to IEC 61010-2: Safety Requirements for Electrical Equipment for Measurement, Control and Laboratory Use – Part 2-101: Particular Requirements for In Vitro Diagnostic (IVD) Medical Equipment. In the EU-MDR medical devices are classified as A, B, and C matching up fairly well with the FDA I, II and III with some minor exceptions. The major exception is IVD medical devices which are now classified as D.

Why is medical device software development so expensive?

The design and development of safety-critical medical device software must go through a number of development stages to significantly reduce risks and hazards, including

1. Requirements Specification: Before any work on a medical device begins, its purpose must be defined.
2. Design of Fault Tolerant Life Critical Systems: Software developers must design fault tolerant systems. Software design involves problem solving and solution planning. Everything from normal operations to software failures, hardware failures, user errors, external failures, intrusions, risks, hazards, or any security risks. Once failures are detected, the medical software should capture these events for analysis. In addition, it should provide a time-stamped history of process activities, operator actions and any other events deemed important. The original data captured by the medical device should be secure from any manipulations or alterations. Post market surveillance should include any information gathered and should be analyzed by the manufacturer for improvements to the device. Medical device software audit trails should perform the following functions:
   • Detect failures
   • Prevent injuries or confusion
   • Capture a history of events
   • Providing methods for analysis
3. Medical Device Prototyping & Clinical Trials: Building medical device prototypes and throwing them away in a trial and error manner will cost you time and money. Instead, build prototypes that can be used later. To do this, the software engineers must understand the clinicians’ needs from the beginning. Knowing what a is expected from a medical device’s performance – data, statistics, processes, or what would be needed to get through clinical trial – is necessary in order to reduce costs. Do your research upfront. Testing and clinical trials are expensive and if you need to fix and upgrade a medical device mid-trial you’ll waste time and budget. Ensure your medical device has a sound design from the start. With specific, sound requirements, there are no questions as to how the device shall be developed and what technology is required, keeping your project on track to satisfy the intended scope.
4. FDA Regulatory Approvals: The ISO, IEC, FDA and EU-MDR standards and regulations will require any software used in a medical device to perform its necessary operations and protect the patient and/or users.

While you may feel that a large chunk of your development budget is spent on medical device software engineering, this is a critical part of the product development journey. Medical device embedded systems cannot fail because its end user depends on the technology to make life changing diagnoses and potentially sustain life.

PSI possesses the expertise and capabilities for your custom medical device development and software testing. We’ll get the job done right, the first time and keep your budget in mind.

Why are medical devices so difficult to design and build?

Medical devices are difficult to design and develop because of the risks associated with them. Building a medical device requires specific knowledge from consultants and individuals familiar with FDA standards and regulations.

Do you have the right people and partners in place to ensure your device is successful? When you are evaluating potential software and firmware engineering partners, start by asking the right questions.

• Will you have enough funding to accomplish what you desire?
• Has your software design team successfully built a medical device in the past?
• Is your software engineers team intimately familiar with and proficient in the strict regulations that medical devices are held to?
• Which design standards does your software engineering company follow?
• Is your software developer ISO certified and does their Quality Management System (QMS) support FDA regulations?

Choosing the right software engineering team is critical to developing and designing successful FDA compliant medical software and firmware. Too often, the right software development team is not selected, leaving more room for error. PSI is an experienced team of software and firmware developers that has successfully designed a variety of medical devices.

If you are stuck or do not know where to begin your medical device development project, call PSI at 215-672-1860 or contact our medical device software consultants.

In need of software engineering or regulatory assistance?