The instinctive answer is checking. Review the submission before it goes out. Verify the document before it reaches the investigator. Audit the file before the monitor arrives. And there is nothing wrong with checking -- it catches errors. But checking is a downstream activity. By the time you are reviewing a continuing review package and finding that the coordinator used an outdated protocol version, the error has already happened. Your review caught it before it reached the IRB, which is better than not catching it at all. But the process that produced the error is still running. It will produce the same error again, in the same study or in another one, the next time conditions align the same way.

ICH E6(R3) draws a deliberate distinction between these two orientations. Section 3.11 addresses quality assurance and quality control -- the activities that verify compliance after work is performed. Section 3.10 addresses quality management -- the system that designs quality into the process itself, before errors occur. The difference is not merely semantic. Quality control asks: "Did we do this correctly?" Quality management asks: "Is this process designed so that doing it correctly is the default outcome?" The first question leads to inspection. The second leads to architecture.

This lesson applies Section 3.10 to the specific domain of site-level regulatory operations. We are not revisiting quality by design as a general concept -- the CRC track covered that territory. What we are doing here is taking the formal QMS framework that E6(R3) assigns to sponsors and applying it, with appropriate adaptation, to the regulatory infrastructure that the RC builds and operates. It is, in essence, a systems-engineering perspective on a regulatory operations problem.

The instinctive answer is checking. Review the submission before it goes out. Verify the document before it reaches the investigator. Audit the file before the monitor arrives. And there is nothing wrong with checking -- it catches errors. But checking is a downstream activity. By the time you are reviewing a continuing review package and finding that the coordinator used an outdated protocol version, the error has already happened. Your review caught it before it reached the IRB, which is better than not catching it at all. But the process that produced the error is still running. It will produce the same error again, in the same study or in another one, the next time conditions align the same way.

ICH E6(R3) draws a deliberate distinction between these two orientations. Section 3.11 addresses quality assurance and quality control -- the activities that verify compliance after work is performed. Section 3.10 addresses quality management -- the system that designs quality into the process itself, before errors occur. The difference is not merely semantic. Quality control asks: "Did we do this correctly?" Quality management asks: "Is this process designed so that doing it correctly is the default outcome?" The first question leads to inspection. The second leads to architecture.

This lesson applies Section 3.10 to the specific domain of site-level regulatory operations. We are not revisiting quality by design as a general concept -- the CRC track covered that territory. What we are doing here is taking the formal QMS framework that E6(R3) assigns to sponsors and applying it, with appropriate adaptation, to the regulatory infrastructure that the RC builds and operates. It is, in essence, a systems-engineering perspective on a regulatory operations problem.