Whoever develops software for medical devices without having code reviews carried out, should be asking whether he/she is in the correct industry and if software development is right for him/her. Renouncing code reviews has nothing to do with professional programming.

Tips for practical implementation

General rules for code reviews

One of the most important ways to have a significant breakdown in the error rate within my team was with code reviews. In fact, it was consistent with all code. But that only works if you do it properly and comply to a few rules:

1. A code review should not take longer than 30 minutes.
2. A code review should examine the code based on predetermined and possibly programming-specific criteria, including compliance with previously (automatically) determined metrics and coding guidelines.
3. A code review should take into account the test code (including code coverage).
4. A code review should be documented. More on that in a moment.
5. A code review can also be performed in reverse. More on that in a moment.

During the reverse code review, the author does not explain his code to his reviewer, but vice versa. The reviewer explains what he believes he understands. This has great advantages:

1. The reviewer is focussed, because he has to explain the code to the author. 
2. The author is soon tired of the alleged slowness of the reviewer and writes code in the future, that even the reviewer will understand. This leads to understandable and thus maintainable code. 
3. The boss can be sure that there is a second person who also understands the code. This reduces dependence on a developer.

Four eyes see more than two. You should also do code reviews. It’s best to do them in reverse!

Documentation of code reviews

Document all code reviews, but make it very lightweight! Either use a tool like TFS or MedPack or if you have a form (a sheet with front and back-side), which is included on every desk or in a drawer of every developer. During the review, the reviewer fills out the form. Once a week the developer throws the completed forms in the tray of the quality manager. Done. The overhead for the formalities should be in the range of a few seconds!

Checklists for code reviews

For premium members in the auditgarant, a proven code review checklist is available for download. All auditgarant members can view the associated training videos.

Code Reviews: Does the FDA require a signature? From whom? 

"Who needs to sign a code review, according to the FDA? Only one person, for example, the reviewer, or the moderator, or everyone involved, so the developer, reviewer and moderator? 

To answer this question, we must briefly highlight the concept of code review: There is no such thing as "the" code review, but a lot of different methods of static testing of the source code. For example 

• the walkthrough, 
• the technical review, 
• informal review and 
• the inspection.

The FDA notes these processes partially in the software validation guide, without explicitly demanding one of them. The methods also differ by the people who are to be involved. A moderator does not exist, for example, at an informal review.

The statutory requirement for reviews can be found in 21 CFR part 820. Here, too, no specific method is named.

This, then, gives us the answer: You describe, as a manufacturer, in your 820-compliant quality management system, what kind of reviews you will make. And according to that, you need to document what people are involved - by signature.