Agile Compliance - Bridging the Process Gap between Agile and Regulation in Medical Devices
Often in medical device companies there’s one Design Control SOP which contains the "big picture" software development activities.
For each software product the project manager is responsible for creating a Software development plan based on the SOP. Besides the basic software development activities there’s more things which need to be planned upfront, e.g. how to deal with risks (usually in the risk management plan, based on the risk management SOP), document management plan (which documents need to be created, where are they stored, how are they versioned reviewed and approved), software configuration management plan etc.
Usually the SOPs are owned by QA/RA personnel, the software plans by the software engineers.
This raised the first issue that is the communication between these parties is often difficult, e.g. for a regulatory person a “unit test” is a signed test protocol of a small part of the software, for an engineer a piece of automatic running test, which is executed upon every code change.
The second issue comes from the fact that the agile process strives for a continuous improvement of the process, learning on the way what works and what doesn’t. This can happen every 2 to 4 weeks depending on the length of one cycle.
The combination of these both issues make the situation really painful, updating the software development or other plans or the Design Control SOP often takes months. As it requires input and reviews from different stakeholders with only a limited knowledge (either regulatory or software), and actually the better the initial planning is the more difficult it gets to improve the documentation as there’s just more of them. The solution will be:
Step 1: Replace large word document by units of information
Breaking down big regulatory documents into smaller independent entities describing the regulatory requirements for each needed process so that software developers can understand and relate to it. These smaller entities can then link to the individual development activities replacing the big development, risk, document,… plans.
Three levels of process documentation
Step 2: use an eQMS with fine grained traceability and flexible change control
An electronic quality management system should be put in place which allows a rapid update, review and approval of these entities. If a regulatory person wants to modify one "his/her" boxes, he can see through traceability exactly which software activities will be affected, that makes the discussion with the software developer much easier and faster.
Same is true if a product manager wants to change one of the processes it’s immediately clear what the regulatory input is and it will be a matter of minutes to update a process and get it approved, rather than months if multiple big documents have to be reviewed and approved independently.
In this screenshot, taken from Matrix Requirements, you can see the regulatory requirements which define as input for the product Verification Process (SOP) defined by QA/RA. You can also see the links to the processes defined for the software development plan written by the software development team.