Combining two products with same GMDN, Same Clinical environment and BUT different connectivity mode under one CE application.

[shabs.moiyed53]

Hello,

We have developed two spirometer devices classified as Class 2a, both of which require CE Marking. These spirometers have the same GMDN number, intended use, indications of use, clinical environment, and operational principle (infrared and turbine technology).

The primary distinction between these devices lies in their connectivity features: one utilizes Bluetooth Low Energy (BLE) technology to interface with mobile phones, while the other uses a USB cable for direct connection to computers to display results.

Given the similarity in all other aspects except connectivity, we would like to know if these two spirometers can be included as a single technical file for submission to the notified body, or if separate technical files are required for each device.

Looking forward to your help and response.

 

[Ed Panek]

Its best to simply ask your NB Industry engagement officer for advice. IF they are similar it might be possible. Does one have a performance delta with the other in any way? Broadcast range, Power used, etc?

 

[shabs.moiyed53]

Broadcast range, Power used, etc

Hi Ed,

Thank you for your time and response.

There is no performance delta ie in terms of biocompatibility, toxicity and accuracy.
In terms of broadcast range there will be some differences. In terms of the power used they are the same.
The BLE device sends data via Bluetooth whereas the other spirometer sends data using a USB cable.
They both have different PCB design and are tested separately for EMI/C.
Please let me know your opinion or if you could refer me to a guidance document.
Thanks and looking forward to your response.

 

[Ed Panek]

A question the NB could ask is what in the market requires a model with Bluetooth and another model with USB? Why not have both on the IO port?

 

[shabs.moiyed53]

Hi Ed,

The USB product and the BLE product are both placed at a different price. For marketing reasons we would like to keep them separate. Thanks.

 

[Ed Panek]

In that case its a marketing sales decision. The performance delta seems small (ish) but Ive not seen performance testing. You might be able to submit as single device with a feature key for both models but with nearly identical spec. Build a case for the system that 100% identical, and tell them you are creating a standard model and a "Super" model with "Which ever system is faster"

A BOM listing will emphasize the common parts. A separate BOM would represent the difference. They approve each system as the same type of device.

The scope of you cert would be "The design and manufacture of a spirometer with a Blue Tooth option" or similar

I don't think regulators are that worried about USB vs BT as completely different devices.

 

[Hendi]

The minimum difference might be UART lines inside either going to a USB bridge like FT232 and connector thru a enclosure opening or to a BLE Chip or chip on module. This causes a lot of difference in risks (Ever tripped over a usb or bluetooth cable? fluid/dust ingress at connector? BLE can be denied by jammer, with cable you need rather a knife) - as so many things, I think this is one of the many decisions which should be risk-based.

 

[ChrisM]

They both have different PCB design and are tested separately for EMI/C.

I suspect that you will have to treat them as different devices but it is best to check with your NB first. There will be things to take into consideration such as how different the PCB's are in layout, track size, components used, how many PCBs in total and how many are common/different etc

 

[CharlieUK]

Aside from the Medical Directives/Regulations, the BT one is also under the Radio Equipment Directive, RED, and the other one isn't.
The RED has a number of additional administrative (and testing) compliance requirements that the USB doesn't have to meet.
Whilst you have the same GMDN number, is there some other model number or other way of differentiating between the 2 devices as you'll need separate DoCs for radio and non-radio variants