Technical Documentation for a medical device accessory

Bashaer

Registered
Hello,

I am part of a company that develops a class IIa SamD under MDR and that aims to support decision-making when making a diagnosis or treatment planning in a subject with a neurological disorder.

Now, the company has also developed a separate software, which is a DICOM interface program: it aims to integrate with hospitals' PACS systems installed in a healthcare facility and our SaMD. Its use is totally transparent to the user, and works in the following way:
receive patient images that have been previously acquired by an MRI machine --> anonymize the patient information --> send the images to our software --> retrieve the results provided by our software then de-anonymize them and send them back to the medical practicioner.

Our SaMD can operate without this program interface.

We have to establish the Technical Documentation under the MDR, which leads me to ask several questions about this situation:
1) Is this interface program considered as accessory for the SamD under MDR?
2) If so, will a separate Technical Documentation be required (a new GSPR list, a new Risk Management File, etc)?
3) Will we have to redefine the specification of the device (intended users, medical purpose, operator profile, etc.), the indications/contra-indications/warnings, knowing that its use is transparent to the user?
4) Will we have to assign a UDI to it? Knowing that it is only there to interface and to anonymize patient information, that its use is transparent to the user... so when will the user see the UDI appear?
5) Will we need to establish separate labels/instructions for use than those established for our SaMD?
6) Based on the transparency of this tool towards the user, it seems strange to me to establish for example a separate Clinical evaluation, a PMS Plan... will we have to justify why we don't do it?

Could you please answer me?
Thank you in advance for your help!
 

Junn1992

Quite Involved in Discussions
Hmm.... I don't think it even counts as an accessory since the main device can fulfil it's intended purpose without it. The point of the software is to interface with PACS and anonymize personal identifiers so that your company can avoid liability with personal data.

From a risk management perspective, I would be concerned whether the program will affect the quality of the images in any way whatsoever, and the program also poses new risks from a cybersecurity standpoint.

IMO, I see 2 devices:

Device 1: SaMD that reads images directly

Device 2: SaMD + interface and anonymizer program

I see 2 devices here instead of a device + accessory. Just my 2 cents, I could be wrong.
 

dgrainger

Trusted Information Resource
When you say: "Our SaMD can operate without this program interface", how is the data transferred without it?
 

Bashaer

Registered
Hmm.... I don't think it even counts as an accessory since the main device can fulfil it's intended purpose without it. The point of the software is to interface with PACS and anonymize personal identifiers so that your company can avoid liability with personal data.

From a risk management perspective, I would be concerned whether the program will affect the quality of the images in any way whatsoever, and the program also poses new risks from a cybersecurity standpoint.

IMO, I see 2 devices:

Device 1: SaMD that reads images directly

Device 2: SaMD + interface and anonymizer program

I see 2 devices here instead of a device + accessory. Just my 2 cents, I could be wrong.

Thanks for your answer! No, the interface program does not affect the quality of the images, it is really used just for their transfer to and from our SaMD.
So, in the case that we consider that they are 2 devices instead of a device + accessory, we will probably not have to create a separate Technical Documentation for it, is that correct?

I still find that confusing to decide whether it is another device program or an accessory to the SaMD... I truly don't know on which rationale I can base my decision on. Could you please provide more information?
Thanks again!
 

Bashaer

Registered
When you say: "Our SaMD can operate without this program interface", how is the data transferred without it?

Thanks for your answer!
So by this sentence, I mean that the data transfer can be done using our REST APIs which allow us to retrieve the images sent to our SaMD --> launch the SaMD --> and then return the results to the user. We use our program interface to facilitate the interfacing between the PACS and the server on which our SaMD runs.
Another thing, our SaMD can also be used through a distributor, and on their side, they don't use our program interface.

So is that implying that the program interface is an accessory of the SaMD? Or how should we deal with it?
 

Ronen E

Problem Solver
Moderator
@Bashaer I wonder what you hope to achieve in this discussion. It sounds to me that there are fairly serious liability risks involved in your situation (as well as the obvious regulatory ones). Think GDPR for example. By nature, a public forum won't be able to provide you the assurance you need simply because we don't have access to all (maybe not even most) of the relevant information.
 

Junn1992

Quite Involved in Discussions
I still find that confusing to decide whether it is another device program or an accessory to the SaMD.

‘accessory for a medical device’ means an article which, whilst not being itself a medical device, is intended by its manufacturer to be used together with one or several particular medical device(s) to specifically enable the medical device(s) to be used in accordance with its/their intended purpose(s) or to specifically and directly assist the medical functionality of the medical device(s) in terms of its/their intended purpose(s);

The separate software does not seem to me to qualify as an 'accessory' since the device (software which analyses images) can perform without it. The separate software to anonymise patient information does not in any way help the intended purpose, which is to analyse images and give a certain output.

However, from an IEC 62304 perspective, you cannot separate the "anonymizer software" from the "image analysis software", they are both part of the same overall software architecture. The data first goes to "anonymizer", then to "analysis", then back to "anonymizer" again.

Hence, from a regulatory perspective, there seems to me to be 2 separate IEC 62304 files with 2 separate software architectures. The one with the "anonymizer software" adding an additional layer of risk and cybersecurity risk. This is why I see it as "2 separate devices", instead of just one, because the risk management file will be different, even though eventual performance is most likely the same.
 
Top Bottom