Most mandatory documents can only be finalized at the end of the development project. However, it is not wise to draw up all documents at the end of the development project. As a result, not only is a lot of time lost – after all, the product is ready, but cannot yet be sent to the Notified Body for assessment – the development process has also not demonstrably proceeded according to a development plan. Writing a (software) development plan, after the test reports (Validation and Verification) are already available, can cause problems with product certification, especially when dates are overlapping, and signatures are missing. In addition, a lot of ready knowledge is lost when planned and unplanned events are not immediately recorded.
It is wise to start drawing up a technical documentation (TD) from development phase 0, how this is possible and which documents must be drawn up per phase, depends on the product that is being made, but should include the Quality and Regulatory plan (including the regulatory requirements), the soft- and hardware design plan, a general product description and the validation and verification plan. The checklist should include, for each phase, which documents must be present before the decision can be made to proceed to the next phase. These are documents that must all be added to the TD and are of such quality that they can be offered to a Notified Body (so no drafts).
In product development phase 4, the product, including the device master record, will be offered to the Notified Body.
What to expect from maintaining and auditing the QMS?
Maintaining product development and the QMS requires a high time/resource investment. To keep this manageable, it is advisable to carefully check which documents/processes are required and which documents are ‘nice to have’. The fact that documents are not necessary does not mean that it has no added value to draw them up. An example of this is the IEC62304:2006 standard. This standard applies to software used in or as a medical device. The standard describes how to classify the software. The software class then determines which documents need to be drawn up. E.g., for software that has been categorized as class A then it is not required to create a document that describes the architectural design. Creating such a document could be beneficial (nice to have) for customers, technical support or to be reused in other products.
The work processes within the QMS must be audited according to an audit calendar. It is impossible to audit all protocol processes individually. This can also be done with conducting department audits. The department manager is audited on part of the work processes and one audit report is written. The following year you select other work processes for the audit, so all processes are covered, without a department having to do several audits per year.
The management review can be used to audit the management processes. During the management review, the risk mitigating measures, the status of the QMS and the possibilities for improvement are discussed. Where the members of the management can indicate which processes need to be adjusted. If it turns out that a process is not going correctly, a non-conformity can be created.
In addition to checking whether production documents are created, the workflow processes have been followed, and key performance Indicators are achieved, department audits provide a (reasonably) conclusive picture of the quality and compliance of the work processes and the audits are carried out efficiently and effectively.
