Getting Your 510K Medical Software Ready

This post was previously on the Pathfinder Software site. Pathfinder Software changed its name to Orthogonal in 2016. Read more.

Medical devices have become so indispensable to modern healthcare that practically no major diagnosis or treatment can be done without them. According to the WHO, an estimated 1.5 million medical devices are currently available, ranging from the humble digital thermometer to the highly sophisticated MRI machine. An increasing number of these devices are being driven by software external to the device, for example, a companion mobile app.

The growing popularity of software-driven medical devices has made it necessary for manufacturers to be aware of the 510K medical software development process, especially in the case of regulated class II and III devices. Since even a small flaw in such devices can directly or indirectly result in the injury, or even death of a patient, every new device must be approved by the Food and Drug Administration (FDA) before it can be made available to the public.

There are two processes through which the FDA grants clearance to medical devices. The first is called Premarket Notification, or the 510(K) process. The second is Premarket Approval, or PMA. Contrary to what many people believe, the 510(K) is not a form. It is a section of the Federal Food, Drug and Cosmetic Act (FD&CA), which lays down the conditions that a new medical device or software must fulfill before it can get market clearance.

The 510(K) process is based on the generic drug concept, which requires that a new device roughly meet the safety and effectiveness equivalent of a standard recognized by the FDA, or the standard of another lawfully marketed device. However, this does not shut the door to innovation or advancement, as the proposed device doesn’t need to be built with the same materials and/or software as those to which it is being compared.

Because the 510(K) process covers a myriad of different medical devices, it is intentionally vague, in order to accommodate all of them. Therefore, when applying for 510(K), the burden of ensuring that the product meets the FDA standards falls on the manufacturer. While developers may find this arrangement favorable to them, it also leaves a lot of room for errors arising from misconceptions and misinterpretations. Such errors can be costly, especially if the software needs to be patched, reworked or completely rewritten.

The success of 510(K) submission for any medical device with software depends on the manufacturer’s ability to demonstrate that the software performs as required. But, all too often, new and inexperienced manufacturers focus more on the device than on the software, resulting in software that is substandard, or even buggy. Therefore, it is important to develop a rigorous 510(k) medical software development methodology and choose the appropriate software development life cycle.

Developing software differs from developing devices in that every copy of the finished software is exactly the same as the original copy, so every copy will carry all of its flaws (if there are any) to the device that it operates. The matter is further complicated by the fact that many of today’s medical software apps are device-independent. Also, the binary nature of computing means that software either works or doesn’t; there are no degrees of conformance. Therefore, elimination of errors before 510(K) submission is of utmost importance. This requires extensive verification and validation (V&V).

V&V is a time-consuming and labor-intensive process. In order to ensure a proper V&V, the developer must identify the three levels of concern defined by the FDA: major, moderate and minor. Major concern involves failure or flaws that could result in serious injury or death. Moderate concern involves failure or flaws that could result in minor injury to the patient. Minor concern involves failure or flaws that are unlikely to cause any injury.

If you’re part of a medical device and diagnostic firm, it is likely that you are seeking to accelerate your software development product timeline to take advantage of the rapid innovation in sensors, mobile technology and cloud computing. Our Agile Product Development Service is a medical software product design and development service that provides accelerated product timelines, improved user experience and reduced risk to patients.

Unlike services offered by traditional software development partners, ours integrates human-centered design, rapid prototyping and feedback, and a deep knowledge of the application of risk analysis and mitigation to new technologies. We are configured to operate in an FDA regulated environment within a rigorous Agile-enabled quality system. Our 510(K) medical software development methodology is designed to catch errors and problems, and to eliminate waste earlier in the development life cycle. Our approach decreases development risk and empowers you to create the next generation of great products before the competition does.