Best Practices When Developing with NI LabVIEW for FDA-Validated Medical Devices

Medical device development can be a slippery slope to climb. Even in the best cases, when you are dealing with proven treatments, two fundamental and opposing pressures drive the development process. On one hand, quality is the highest concern because failure can lead to patient injury and product recalls. On the other, reducing development time is critical to establishing an early position in a very competitive market. To manage the quality concerns, agencies such as the Food and Drug Administration (FDA) have been established to help guide and enforce best practices for the development of safe and reliable devices. The rest is up to you, the engineer, to work within those constraints and meet all of the requirements in the most timely, safe, and cost-effective manner.

The first step in the development of software for creating or testing a medical device is to understand the regulations. In the end, the FDA is concerned primarily with the safety of the public. It is your job as the device maker to prove to the FDA that you have done your due diligence to ensure that the device you have produced is as safe as it can be. To aid in this process, the FDA has provided a collection of guidelines to document its best practices for quality control in a development process. This guidance is officially called 21 C.F.R. § 820 et seq or Part 820 for short, and it is commonly referred to as QA (quality assurance).

Although Part 820 is specific to the medical device industry, the processes that it outlines can generally be applied across industries to encourage good product development. The following are a few best practices you should follow to help you comply with Part 820.

[+] Enlarge Image

Figure 1. National Instruments provides tools to help you comply with FDA guidelines such as 21 C.F.R. § 820 et seq.

Develop Complete Requirements

It is not enough to develop detailed requirements only for your system. In addition, you must create detailed requirements for the software and even for the components of the software design. Furthermore, it is important that your low-level requirements avoid ambiguity in as many aspects of the behavior as possible. Consider an example where you are developing software for a medical device that detects the skin resistance of a patient, and if the sensor detects a level of more than 1MΩ, a text message is sent to the cell phone of the patient’s physician. The following is an incomplete specification for this feature of the device:

“When a resistance of 1MΩ is detected, a text message is sent to the physician’s cell phone. The cell phone number is stored in a text file called Physician.ini.”

 The following is a more complete requirement specification:

“When a resistance of 1MΩ is detected, a text message is sent to the physician’s cell phone. The cell phone number is stored in a text file called Physician.ini in ASCII format following the form AAA-DDD-DDDD, where AAA is the area code. The text message is delivered by sending a serial message to the cellular chipset of the form XXX. The text message consists of the patient name followed by a colon and the resistance reading. Patient name can be found … ”

You get the idea. By developing extremely specific requirements, you can reduce or eliminate the schedule delays caused by changing and/or incomplete requirements.

Develop Software Tests Early (Before Software Development)

You can develop software tests before you write any actual code. In fact, developing software tests based solely on requirements can help you expose deficiencies in the requirements and address these ambiguities with the scientists and/or the patients before you develop the code.

Clearly Map Requirements to Source Code

Providing a mapping from requirements to source code can help ensure that the documented requirements are implemented. National Instruments offers a tool called NI Requirements Gateway, a requirements traceability solution that links your code to formal requirements stored in documents and databases. By organizing and managing requirements and the documents or applications that cover them, NI Requirements Gateway helps you address FDA quality assurance regulations.

[+] Enlarge Image 

Figure 2. NI Requirements Gateway is a requirements traceability solution that links your code to formal requirements stored in documents.

Use Source Code Control

Source code control provides several safeguards against the common problems introduced by team development. For example, source code control prevents situations where two developers are working on the same source file, and one developer’s changes overwrite those of another.

In addition to managing team-based development, source code control software packages help maintain a historical record of all changes made to all files. This is an important part of the FDA QA audit process.

LabVIEW offers integration with industry-standard source control providers such as Microsoft Visual SourceSafe, Perforce, Rational ClearCase, PVCS Version Manager, MKS Source Integrity, and free, open-source software such as Concurrent Versions Systems (CVS).

Take Advantage of Static Code Analysis Tools

Static code analysis provides a means of checking source code for common mistakes made by developers. For example, C programmers can develop code fairly easily that mismanages memory pointers that may cause an application to gradually degrade in performance or even crash. LabVIEW programmers can make coding errors that can produce memory leaks by opening references without closing them. Static code analysis tools analyze source code for common mistakes such as these so that the errors are caught before the code is run.

For C programmers, there are a number of static code analysis tools on the market such as Coverity Prevent and Klocwork Insight. National Instruments offers a static code analysis for LabVIEW code called the LabVIEW VI Analyzer Toolkit. With this toolkit, you can pinpoint VI improvements to make in the user interface design, block diagram code, documentation, and VI properties and settings to enhance performance, usability, and maintainability. This toolkit provides more than 50 built-in tests that you can run on any VI to quickly learn how to build better applications.

Perform Regular Code Reviews

Code reviews are an essential part of the quality control process. Often, simply walking through your code with a coworker can help expose even the most obscure bugs in software.

Perform Risk Analysis

All testing does not have to be equal. A simple risk analysis can determine which portions of your application are most likely to contain defects. Keep in mind that more complex code is more likely to fail than less complex code. Some factors that contribute to high code complexity are number of functions called, number of branches, and programming structure.

When unit testing, focus on code that is more likely to fail. To learn how to estimate complexity in a LabVIEW application, view this application note.

Conclusion

Although the practices outlined in this tutorial are by no means completely adequate for complying with Part 820 on their own, they are a nice first step. In the end, these tools simply help you document and verify that you have followed correct design procedures. Ultimately, the responsibility still rests with you to create safe and effective medical devices.

For more information on developing medical devices with LabVIEW, visit ni.com/medical.

P. J. Tanzillo is the LabVIEW Embedded Product Manager at National Instruments. He holds a bachelor of science in electrical and computer engineering from the Ohio State University.

The mark LabWindows is used under a license from Microsoft Corporation. Windows is a registered trademark of Microsoft Corporation in the United States and other countries.

7 ratings | 4.43 out of 5

Print | PDF

Reader Comments | Submit a comment »