Imagine you are an FDA reviewer in the Digital Health division of CDRH. You review a large number of software submissions each year and need to quickly understand how the software fits together.
One way to slow down the reviewer would be to not include any diagrams. Just text, and lots of it. Of course, the FDA Guidance requires that you provide at least a "System and Software Architecture Diagram". (The latest Cybersecurity Guidance requires several more.)
Here are some additional ways to slow down the FDA reviewer:
- Don't distinguish hardware, software items, or external systems
- Don't include a legend
- Don't provide any context about the meaning of the arrows
- Don't provide IDs to trace items back to your other documentation (or, even better, use different names, e.g., "Auth Server" -> "Authentication Backend" just to make it interesting)
- Auto-generate the diagrams and make them very large with small print and a lot of superfluous information
If you don't make it easy on the FDA reviewers to understand your device, you're going to get a lot of requests for additional information which will slow down your timeline. Keep in mind the reviewers have a lot of other devices they're reviewing, and they haven't been working on your software for several years; they won't have all the context you will.
Some of this is common sense, but the FDA Guidance has additional suggestions. See the FDA Guidance on the System and Software Architecture Diagram and the Examples in Appendix B.
The Cybersecurity Guidance describes four Security Architecture Views and also includes a long list of specific information to include. We generally have a table with a row for each “communication pathways” and a unique identifier. We then will reference these interface IDs in the table.
