The regulatory lead builds the side-by-side comparison of the subject device and the predicate, row by row, and marks each difference. The same work sets the software documentation level, writes the human factors rationale, and reviews the requirement wording so the SRS matches the intended use and the labeling.
On the map: Predicate comparison. Documentation level. Human factors rationale. Review SRS wording.
Rows are disciplines, columns are stages 1 to 8. Select a square to open that task.
Back to the full map
Read the requirements with engineering for regulatory language. Settle the documentation level and human factors rationale with quality before the Phase 1 design review.
Include intended use, users, population, anatomy, modality, inputs, outputs, report content, algorithm type and platform. Reviewers ask for outputs and technical detail, so a table limited to the indications and platform is too thin.
For each difference, state whether it raises a different question of safety or effectiveness and name the test that answers it. Keep the other rows as close to the predicate as the design allows.
Answer the guidance questions on the software functions before risk controls are applied. A foreseeable failure that could lead to death or serious injury means Enhanced.
Walk through the user tasks and the labeling for use errors that could cause harm. If no critical task exists, write a rationale and handle usability risks in the risk file.
See the open positions and apply.