Service Tool application for Medical Device

[medical_electronic]

Hello,
Let's imagine a situation where there is a medical device with some firmware documented under IEC62304. I would like to create a PC application/Mobile application for service purposes (reading error codes, changing settings, reading software versions etc.). Does this kind of application meet some requirements from medical standards, or can it be treated as an auxiliary tool for authorised service?
Am I right that the only requirement that such an application should meet is to include it in the software system architecture and integration tests?

 

[yodon]

End users need to be able to read the software version (or get it through the UDI somehow).

Regardless, I think you're saying that end users would never be given access to this auxiliary application, right?

It does concern me that the software can change settings. That may push it into the accessory area. That's definitely getting into gray space. The risk of that software changing the settings to something that could expose a hazardous situation should be considered.

Assuming, though, that it's completely outside the scope of medical devices, no, there are no requirements for complying with any standard or providing any deliverables. Now, I wouldn't recommend that; 62304 defines a fairly standard software development life cycle. You still want that auxiliary software to work properly and be able to maintain it, so good software engineering practices would certainly be recommended.

To beat on the dead horse even more, the auxiliary software would be an attack vector for cybersecurity.

It does tend to snowball, doesn't it!?!

 

[medical_electronic]

End users need to be able to read the software version (or get it through the UDI somehow).

Is it a standard requirement? Does that mean that the device with a small PCB and firmware "inside" (no displays, no UDI etc.) should have "SW ver." described somewhere eg. on the device label?

Yes, the application will not be available for the end user (patient/caregiver). The main purpose of the application is to provide a tool for authorised service (for example, to check the number of device uses).
It will be possible to get/set some parameters, reset counters or, for example, calibrate the internal sensor after service.

Now, I wouldn't recommend that; 62304 defines a fairly standard software development life cycle. You still want that auxiliary software to work properly and be able to maintain it, so good software engineering practices would certainly be recommended.

agree. Of course, each software should be properly documented for future support.

 

[Tidge]

If this tool is only going to be used by service personnel (who are presumably NOT the end users) I believe that the tool's software would NOT fall under 62304; i.e. it is Non-Product Software (NPS). From the limited presentation of information here, I would say that the device would have a high enough risk profile (because it is to be used to service medical devices) that there needs to be a high-level of assurance that the software is meeting its (fully documented) requirements.

Some of the deliverables necessary to have that assurance will almost certainly look like deliverables described in 62304, but don't call this effort a 62304-driven one.