Article 10, 4. Obliges Manufacturers to prepare and keep up to date technical documentation for their devices. The content of the technical documentation being prescribed in Annexes II and III.
To implement a process for compiling and maintaining the technical documentation, one should start by considering the desired outcome. The desired outcome is documentation that fulfils the requirements of Annexes II and III. That means a binder (paper or electronic) organised in seven chapters; six containing the records of the development or pre-market phase, one containing the plans for the commercial or post market phase. As the content is defined by the regulation, one can easily create a contents page based on Annexes II and III and use it as a checklist. However, the real challenge is producing all the required documentation at the right time and to the necessary quality.
Most critical is ensuring that the design and development process produces the required technical documentation. To achieve this, the contents page should be used as a project deliverables tracker. Identify the likely sources/suppliers of the various items and hold a kick-off. Agree the supplier (author) of each of the documents and the dates when the documentation is planned to be available. There is a natural sequence to their availability and also dependencies; reports are only available after tests have been performed, tests are only possible after prototypes are available etc. The technical documentation process is primarily one of monitoring: Identifying those items that are on the critical path, those tasks that require prioritisation etc.
In all likelihood, for the majority of people involved in the development of the device, producing records and reports will be the least interesting aspect of their work. Constant monitoring of the progress of developing the technical documentation is key. Everyone involved should be acutely aware that it doesn’t matter how beneficial the inventors think their new device is, without the technical documentation there is no device and there won’t be an approval.
Keep in mind that in the end, people from the outside the developer’s organisation (i.e. from a Notified Body or Health Authority) will be the ones who assess the technical documentation. Consistency is therefore a critically important consideration. Different disciplines often use different vocabularies. Different organisational units often use different formats of documents. In a complex organisation, consistency in documentation will be very difficult to achieve at the end of the project if it hasn’t been considered from the beginning. This doesn’t only apply to tables, charts, vocabulary and report formats. The technical documentation has to make a persuasive argument for the device to be approved. That it has been demonstrated the device can be used as intended by the intended users in the intended use environment, where it will perform as intended and achieve the claimed medical benefits. That the solution also represents the state of the art in medical practice, while at the same time posing the lowest possible risk to patients, users and others. From the beginning of the development process, the entire team should be aligned on the key messages the technical documentation needs to convey. The team should identify those critical content elements which need to be aligned and consistent to make the case for the device. The technical documentation process should therefore include a final consistency check. Not only checking that those critical content elements are aligned and consistent in the finally complied documentation, but also the key messages are clearly conveyed and supported by the finally complied documentation.
The technical documentation process doesn’t end at the submission to the notified body. There will be changes. Some changes may even require prior approval of the Notified Body (See Annex IX, 4.10 and Annex X, 5.2). The technical documentation will need to be maintained so that it is representative of the currently manufactured device. For this reason it’s worth considering performing an periodic review of the technical documentation. Certainly a change history (log) will be expected by the Notified Body to be available at surveillance assessments. Therefore, the technical documentation process must include procedures for managing changes to the approved technical documentation, including those changes that require prior approval by the Notified Body.