Implementing a design control process is a very resource intensive project. In addition to defining the process add into the mix adopting new technology to support the process. Now the project may seem to be overwhelming but it does not have to be!
The good news is that the FDA does not impose specific rules or conditions in which to implement a design control process. Instead they provide a general framework that helps guide an organization to define a process that meets the FDA regulations as well as meet their own quality standards. All this can be found in the publication: Part 820 – Quality System Regulation (21CFR820.30).
Now where does Team Foundation Server (TFS) 2013 come into the picture? Well TFS is an Application Lifecycle Management (ALM) tool that traditionally has been used for software development projects. Over the last couple of years we are seeing more and more companies adopt TFS to manage complex projects producing more then just software (i.e. medical devices). Effectively we are extending the TFS platform to implement not just an ALM process but the entire design control process. Here is how we can approach this task. . .
Define a plan
The first step would be to come up with a high level plan that defines all the different people, activities, artifacts, inputs, outputs, etc that are involved in the entire process to launch a new device on the market. Most device companies still use a traditional ‘V-Model’
This can vary significantly between organizations. Typically we would start at the top and capture the high level requirements (marketing or customer requirements) and break those down into verifiable design inputs and system requirements. The objective is to document your design inputs in a manner so that they can be verified and later validated by the folks in quality.
In the CMMI process template in TFS the work item type ‘requirements’ is used. We could use this default requirement work item to capture customer requirements. Then we could configure TFS with new work item types: Product Requirements (Design Inputs) and Functional Requirements (System Requirements).
TFS also gives us the capability to relate these work items together so that when the time comes to produce requirements traceability reports the procedure becomes very simple if not completely automatic.
This part is pretty straight forward. Basically we take our design inputs and create build the required components including all packaging labeling and master records. In TFS the Design Input would have a custom workflow with a state that would indicate when the component has been implemented such as ‘Ready for Review’. This way the evolution of the product can be tracked in TFS.
Even for hardware and reagent teams tasks can be leveraged in TFS to track the work being completed against each component.
As the development of the device progresses, design reviews must be conducted to ensure that the design outputs satisfies the needs of the requirements. We would need to think a bit outside the box to implement this functionality in TFS.
One approach would be to add a work item type: Design Review. This work item would contain the results of the design review meeting. Most of the information would simply be added into a description field. However, the important part would be to link the Design Review to the related Design Inputs so that we are able to quickly report on which Design Inputs have been (or not) reviewed. This can be a very powerful tool during an audit.
Verification in TFS simply translates to testing. In TFS we can create test plans, suites and test cases and can associate them to Design Inputs. Once this association is in place we now have the ability to track test execution against the Design Inputs. TFS also has valuable reports that can be used right out of the box to track testing progress.
Custom SSRS reports can also be developed to produce formal trace matrices from customer requirements straight through to verification results. Risk reports (FMEA/Hazards) can also be easily produced from the system.
Once the device has been developed it is also required to validate the end product meets the original requirements. Again by using a specific validation plan that are associated with the Design Inputs we can demonstrate that tests have been performed along with results.
To further configure TFS to support the validation process, the workflow for the Design Inputs can incorporate a state called ‘Validated’. Once the validation process has been completed all the Design Inputs can be moved into this state. We can also add security on the workflow so that only authorized users can certify that validation was satisfactorily completed.
As the development of the device progress (or post launch) changes to the specifications may be required. As a best practice new Design Inputs should be created in TFS and associated with the original ones. They would need to go through the same workflow again, but once completed it will be possible to obtain a list of design changes from a Marketing Requirement or a Design Input. This would greatly facilitate the generation of a design history file (DHF).
As you can see with some work configuring TFS to support your organization business processes coupled with a disciplined team to ensure all the information is captured in the system, TFS can be leveraged as a platform to support the complete design control process.
Thanks for reading!