Regulatory Open Forum

This message was posted by a user wishing to remain anonymous

I realize this question is quite specific, but I am wondering if anyone has encountered a similar challenge and might have some advice: 

My company manufactures an electromedical device that is currently regulated as Class I in the United States. In our next major release, we are planning to update the hardware of the device to extend its capabilities.  Some of the new features will introduce new indications that will require a 510(k).  However, to reduce upgrade costs and allow these new features to be sold as add-ons, our plan is to manufacture a "base" unit with all necessary hardware included, and then to control access to the new features/functionality using software licenses. In this case, the main "base" system could continue to be Class I, but the software modules sold as accessories would be subject to a 510(k).

I have identified a 510(k) for the Aesculap DIR 800 (K202391) where they have taken a similar approach. https://www.accessdata.fda.gov/cdrh_docs/pdf20/K202391.pdf

My question is, how should we manage the structure of the DHF and the documentation included in the submission?  Because there is only one hardware configuration, it is difficult to draw a line between the parent system and the accessory.  While it may be possible to sort the risks, requirements, etc. into those that apply to the Class I parent system and those that apply to the Class II accessory, it most cases, describing the two in isolation is not easy, nor would it be desired.

Would it be acceptable to create only one set of documentation to cover both the parent system and the accessory or would this cause problems down the road? My biggest concern would be that the FDA would begin to treat the whole system as Class II, limiting our flexibility to make design changes to the "base" system in the future.

Thanks!

Greetings Anon,

Your assumption unfortunately is correct and can be difficult to navigate: '... the FDA would begin to treat the whole system as Class II ...' as they generally look at the entire device/system.  With that said, the 510(k) submission could be generated in a manner to keep the "base" unit as the Class I entity while the add-ons would be the subject of a 510(k) submission.  This can be successfully done, it just needs to be presented, shown, and any justifications clearly described in the 510(k).  Unfortunately what I often see is companies use the "simplistic" approach (and my own personal opinion really out-dated) providing minimal information to a regulatory authority.  What this creates is the reviewer assuming what companies are trying to do, making their own conclusions, and filling in-between the lines themselves.  This means companies need to divulge information, provide sufficient detail, and clearly describe their approach - I know shocking !

In regards to the DHF, this can also be done as there are many different ways a Design History File (DHF) can be prepared, assembled, and documented.  As an example, you can have the "core" DHF which is associated with the 'base unit' which has all the electrical, hardware, components, materials, etc., described.  For sake call this DHF-010-001 - which is structured in an index format or table of contents showing all the documentation involved with the base unit.  Then you can create DHF-010-002 for Add-on 'X' and DHF-010-003 for Add-on 'Y' and so forth.  Content in DHF-010-002 or -003 does not need to replicate everything from -001, references and linkages can be made.  Again this is only an example method, but there are many different ways to generate DHF or development files.  Also there is no need to create one, big, huge DHF file where everything is kept together.  Certainly from a index, modular, or individual document perspective this is also easy because you can then reference/provide individual documents within the 510(k) submission.

------------------------------
Richard Vincins ASQ-CQA, MTOPRA, RAC
Vice President Global Regulatory Affairs
------------------------------

Original Message:
Sent: 11-Jan-2022 15:35
From: Anonymous Member
Subject: DHF structure for Class II accessory of a Class I device

This message was posted by a user wishing to remain anonymous

I realize this question is quite specific, but I am wondering if anyone has encountered a similar challenge and might have some advice:

My company manufactures an electromedical device that is currently regulated as Class I in the United States. In our next major release, we are planning to update the hardware of the device to extend its capabilities.  Some of the new features will introduce new indications that will require a 510(k).  However, to reduce upgrade costs and allow these new features to be sold as add-ons, our plan is to manufacture a "base" unit with all necessary hardware included, and then to control access to the new features/functionality using software licenses. In this case, the main "base" system could continue to be Class I, but the software modules sold as accessories would be subject to a 510(k).

I have identified a 510(k) for the Aesculap DIR 800 (K202391) where they have taken a similar approach. https://www.accessdata.fda.gov/cdrh_docs/pdf20/K202391.pdf

My question is, how should we manage the structure of the DHF and the documentation included in the submission?  Because there is only one hardware configuration, it is difficult to draw a line between the parent system and the accessory.  While it may be possible to sort the risks, requirements, etc. into those that apply to the Class I parent system and those that apply to the Class II accessory, it most cases, describing the two in isolation is not easy, nor would it be desired.

Would it be acceptable to create only one set of documentation to cover both the parent system and the accessory or would this cause problems down the road? My biggest concern would be that the FDA would begin to treat the whole system as Class II, limiting our flexibility to make design changes to the "base" system in the future.

Thanks!