For the list, I think an example works best. Consider a Class IIb implantable device and the area of interest is post-market surveillance.
Plan – This is the PMS Plan in Article 84 and Annex III
Plan's execution – This is conducting the plan for the first time
Initial Report – This is the report produced using the information from the plan's first execution. This is the PSUR in Article 86 and Annex III
Report Update – Article 86(1) includes the update frequency based on the device class. For a Class IIb device it is annually. Prepare the initial report, continue to execute the plan, and write an update to the report once each year using the new information obtained.
Report transmission to regulators – Article 86(2) and (3) include transmitting the report to the Notified Body, NB. For an implantable device the transmission method in Article 86(2) is "the electronic system referred to in Article 92", i.e., Eudamed. (If the device were not implantable, the transmission would be availability for an Article IX surveillance audit's sampling plan under Article 86(3).)
Linkage to other systems – Typically, the various systems interact. Identify all of the interactions. In this case (Class IIb implantable device), the PSUR interacts with the Clinical Evaluation System, the Risk Management System, and the SSCP System.
Documentation location – Where does the documentation live. In this case it is in both the Annex II and the Annex III technical documentation. Notice that one of interaction systems, Risk Management, has a separate file, the Risk Management File; you may choose to include the PSUR.
In moving from the EU to the US, I'll offer the same advice I offer in moving from the MDD to the MDR. Start fresh, do not try to convert. When addressing a requirement determine if you already have information that satisfies it. In the case of the Annex I GS&PR be especially careful because there could be one-word changes from the similar requirement in the Annex I ER.
In many cases, you will have documents in common between the EU and the US. For example, if you a standard, then the results will equally apply in both instances. Put them into a master document as a hyperlink. Similarity, with documents that apply in one place but not the other.
When you make the submission (510(k) in the US and Annex II in the EU) pull in all the hyperlinked documents. For the US, the 510(k) file is static once approved. For the EU, the Annex II file changes. In each case, you need to identify the trigger for a new submission.
------------------------------
Dan O'Leary CQA, CQE
Swanzey NH
United States
------------------------------
Original Message:
Sent: 27-May-2020 08:32
From: Anonymous Member
Subject: DHF content
This message was posted by a user wishing to remain anonymous
Thanks Richard and Dan for your explanations.
Dan, in your list:
Initial Report is the very original report (i.e., iteration 0 of the device)
Report Update is the delta report when there is a change in the device that triggers a new test
Report transmission to regulators is the selection of information from initial report and report update to be transmitted to the regulator.
Is my understanding correct?
Also, your framework triggers another question. We are already in the European market and we had already several projects and several iterations of the device. We are now planning to go for the first time in USA. Some tests will be repeated, some other no.
Any suggestion on how to avoid fragmentation of the documentation for the FDA (e.g., some reports - or parts of reports - taken from previous European iterations and some others from the latest project) and have a cohesive information?
Original Message:
Sent: 23-May-2020 10:35
From: Dan O'Leary
Subject: DHF content
You need to be very careful to separate some concepts. They are the design history, the current device production documentation, and the current device technical description.
I infer you have a QMS that meets Part 820, ISO 13485:2016, and the EU-MDR Article 10(9).
The design history is the documentation of the design project. Because it is history, it can never change. When the design project closes, the required documentation goes into the 820.30(j) Design History File and the ISO 13485:2016, 7.3.10. A design change may add information, but should not modify existing information with preserving the complete history.
The current production documentation includes all the information required to manufacture the device. Update as necessary and maintain it under document control. The required documentation goes into the 820.181 Device Master Record, DMR, and the ISO 13485:2016, 4.2.3 Medical Device File, MDF. Note that the contents are not the same so your implementation needs to satisfy the union of the requirements.
The current technical description is a mixed affair. In the US, for a 510(k) device, the current technical description is the most recently cleared 510(k) submission. The manufacturer does not update it unless there is a change that triggers a new 510(k). There could be many changes over time that do not trigger a new 510(k). When there is a new 510(k), it is cumulative since the prior approval.
In the EU-MDR this documentation is in Annex II and Annex III. The manufacturer updates so it stays current. The manufacturer evaluates the changes to determine if they trigger a new Declaration of Conformity or, for most devices, an evaluation by the Notified Body.
In addition, there are a number of systems that operate such the Risk Management system, the Post Market Surveillance system, the Usability Engineering system, etc. They typically start with a plan, the plan's execution resulting in a report, and report updates. These systems communicate with each other. They also update the current technical description. For example, the PMS system produces a PSUR (for some devices) and periodic updates. The current PSUR becomes part of the Annex II and the Annex III documentation.
I believe the best practice identifies each requirement. Cast each requirement into the general framework of:
Plan
Plan's execution
Initial Report
Report Update
Report transmission to regulators
Linkage to other systems
Documentation location
------------------------------
Dan O'Leary CQA, CQE
Swanzey NH
United States
Original Message:
Sent: 21-May-2020 06:15
From: Anonymous Member
Subject: DHF content
This message was posted by a user wishing to remain anonymous
Hi forum,
What would be the best practice to create a DHF that facilitates the compilation of technical documentation for both EU and USA (e.g., 510k)?
I see that the FDA has a well defined format to report information (e.g., guidances on bench testing, EMC, usability, clinical, etc.) and sometimes this format does not correspond exactly to documents that are used in Europe. Examples of these documents are System Architecture, Clinical Evaluation Plan and Report, Usability Engineering File, among others.
Is there an efficient way to write/format these European documents to be ready for USA without too much re-assembling and re-writing?
Thanks