We understand the term code review as the checking of the non-compiled source code by other people, for example in the context of inspections or walkthroughs.
The IEC 62304 does not require explicit code reviews. But it does see code reviews as a way to test software units. However, written test criteria for code reviews must be available and the code review should be documented in writing as well.
The FDA does not require code reviews, but writes the following in the Software Validation Guidance Document:
Source code should also be evaluated to verify its compliance with the corresponding detailed design specification. […] Source code evaluations are often implemented as code inspections and code walkthroughs. Such static analyses provide a very effective means to detect errors before execution of the code. They allow for examination of each error in isolation and can also help in focusing later dynamic testing of the software. […] Source code evaluations should be extended to verification of internal linkages between modules and layers (horizontal and vertical interfaces), and compliance with their design specifications. Documentation of the procedures used and the results of source code evaluations should be maintained as part of design verification.
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.
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 the code. But that only works if you do it properly and comply to a few rules:
Reverse Code Review
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:
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 concise. 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!
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 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.