EMC Testing for a US-only, Home-Based Medical Device

[mike8877]

My DUT is a US-only, home-based medical device (embedded CPU, OS, several external peripherals) that will be operated by the patient, for which I am trying to define a test strategy/plan for EMC. I want to understand just what I need to have the test code do and what peripherals should be hooked up, etc., during the test.

I realize this might be a big topic, and I'd bet there are many variables that would take too long to describe, so I just want a basic understanding.

The device will read from its connected peripherals (USB, RS232, or IR) typically once a day and report the findings via a network connection (Ethernet). The peripherals are already qualified medical devices in their own right and are connected/installed by a technician.

1. In normal use, access to the peripherals is relatively rare (a few seconds once a day) and the wireless upload of the data is similarly infrequent (maybe a half-minute, once a day). So, during EMC testing, it would be somewhat unfair to the DUT to have it constantly reading the peripherals and using the Ethernet. However, for the EMC testing they'd have to be accessed more often than once a day (since a scan last only 30-60 minutes or so). What would be a reasonable duty cycle for my test app to be "banging" on these peripherals?

2. Regardless of the answer to 1), the peripherals are not the DUT so it is my understanding they should be "below the floor". Is that true? Others have suggested they be below floor with an extension cable which in turn is clamped with some ferrite near the floor to keep the peripherals' own junk from corrupting the DUT results. Is this reasonable?

3. If I add an intentional radiator (Bluetooth and/or cellular) how do I keep their intentional RF from corrupting the room - pull the SIM card to keep the cell from transmitting for example?

Thanks!

 

[3dBUnderThe Limit]

Yes, this is a big topic.

I think that this needs to be split in Emission and immunity testing and it would be easier to give some input if you stated what standards and versions that you are targeting.

For emission testing I would try to poll the peripherals as often as reasonably possible, in particular with a device with an RTOS that could halt the processor. The reason is that missing a peak associated with accessing a peripheral during the scan will lead to problems later.

Regarding immunity testing I would look at the essential performance and the risk analysis of the DUT and base my test strategy and pass/fail criterias on that. 60601-1-2 Ed4 gives some guidance in the annexes that can be of some help.