Risk Analysis : 2 devices used in combination (hazard in device A, but harm using device B)

TomQA

Involved In Discussions
Hello,

I have a question concerning the attribution of a risk in a device used in combination with a another device. Here's the context:
We have an SaMD (call it DEVICE A ) that is used by the Healthcare professional to plan various therapy sessions for his patient. The patient does the therapy session by using another medical device software (call it DEVICE B), which contains therapeutic activities using parameters defined in the plan created in DEVICE A.

One of the risks is that the therapy plan created, using DEVICE A, is not correct (due to usability issues of the interface, not understanding it, etc.) and therefore the patient follows a therapy session using the DEVICE B that is not adapted and may result in a harm (risk of falling, risk of injury..).
So basically the Hazard starts in Device A but the actually harm to the patient only occurs using DEVICE B.
How can we document this ? As Both devices have distinct Technical files.
Because, using the DEVICE A alone will not hurt anyone, but as it impacts the use of another medical device, it may harm the patient indirectly.
Hopefully I am clear..
Thanks for your help.
 

Tidge

Trusted Information Resource
So basically the Hazard starts in Device A but the actually harm to the patient only occurs using DEVICE B.
How can we document this ? As Both devices have distinct Technical files.
Because, using the DEVICE A alone will not hurt anyone, but as it impacts the use of another medical device, it may harm the patient indirectly.
I would recalibrate the thinking relating to Hazards. Hazards are sources of Harm. The Hazard is something elemental that must be physically present in the device that could cause the Harm.

My instincts are to being with trying to explore the circumstances generated by DEVICE A in one-or-more use scenarios for DEVICE B. If the two devices don't always "go together" as a system, it doesn't make much sense to me to have (potentially) unacceptable risks in the technical file of one device that are addressed in the technical file of another device. Is DEVICE B is safe without DEVICE A even existing?

I feel like the Risk Management for DEVICE A (on this particular point) is going to end up as something like IFU, with no real reduction in risk.
 

Enternationalist

Involved In Discussions
Abstract your harms. Think of them as totally separate products.

Device A has one job; correctly capture and communicate a therapeutic plan developed by a doctor. What is an unacceptable risk for this job, assuming that what happens after the plan is sent is totally out of your hands?

Remember, risk acceptability criteria are decided by you - you just need to substantiate them. If you can't predict the level of harm (given the wide variety of things that may be communicated), then base your acceptability on the probability of making a mistake. This makes sense - you get around this by doing things like forcing the clinician to double check what they are sending to the client and that it is what they expect.

Device B has one job - correctly receive, display (and possible interpret) those clinical instructions. Depending on the activities, you may be able to figure out a worst-case harm, but otherwise it is quite similar. What is an unacceptable risk for doing that job?
 

Vetty007

Involved In Discussions
As acc. to Annex I MDR (14/ 14.5) you need to make sure, that your product is also safe, when used in a (foreseen) combination and then you should evaluate the combination in both files. Also there would be different Risks (Device A sending and Device B receiving wrong information) and mitigation measures (e.g. Device A: Confirmation of the detailed Plan before releasing it; Device B: Note to not follow the plan and talk to the plan creator, if something seems inappropriate) to give in the Risk analysis as Enternationalist already wrote. Even if Device A doesn't cause a direct harm, you need to analyse the risk of sending wrong information to another device, that you also need to specify to make sure that it is a safe combination. Due to this you will also know, what the other device can cause and take this into account as harm. This is esp. due, when the Device A main intention is to give information to Device B (or also other devices), which seems to be the case her and as only creating a plan (= documentation) wouldn't require the software to be a medical device. But possibly there is something else despite planing, that qualifies the software as MD itself and which is not due to the combination (Its often thought, that if you combine a device, the other part also needs to be a device). But for medical Apps, just parts of the App can be MD, requiring to check all interfaces carefully.
 
Top Bottom