Software in Medical Devices, by MD101 Consulting

SaMD PMS data

Types data that can be gathered with a SaMD contain data common to all medical devices, not covered by this blog, such as:

• Customer feedback,
• Customer claims,
• Vigilance events,
• Trend reports,
• Usability data and usage statistics,
• Clinical data...

They also contain data specific to SaMD, managed through the software maintenance plan and the problem resolution process, required by clauses 6.1 and 9 of IEC 62304:

• Software issues, coming from the field or found internally,
• SOUP issues, new SOUP versions, SOUP obsolescence,
• Cybersecurity issues, from software items developed by the manufacturer or from SOUP.

Of course, customer claims or customer feedback can give rise to software issues. Thus, these data categories aren't separated.

The advantage with software is to be able to partially automate the data collection and analysis. The functions described below are not specific to SaMD and can be present in non-regulated software. What makes them specific to SaMD is the regulatory requirements behind these functions.

Customer satisfaction questionnaire

You've already seen these questionnaires popping out, while you're using a website (the FDA does that) or a mobile app, trying to grab some stars from you. This is some PMS; a proactive task, according to article 2.60 of the MDR.
It is possible for SaMD applications to request end-user feedback inside the application. This function should be subject to a risk-based approach. Popping out a questionnaire while a doctor is with their patients is probably not a good idea.
This kind of function is probably more suitable to software used by the general public. Usually, manufacturers prefer meeting with medical professionals to get their feedback. They also prefer sending them questionnaires by mail or by e-mail.

Issue reporting

Another option is to have a function allowing end-users to report issues directly from the SaMD application. It allows the user to file the issue in the context of use. This offers the advantage of avoiding changing of context, like having to send a mail, retrieve the mail address and copy-paste data or images.
It could also automatically allow to send log files or dump files with the issue. Provided that theses files don't contain confidential data.

Use statistics

Use statistics are required by the Periodic Safety Update Report (PSUR). They can also be used by usability and trend reporting.
Use statistics can be easily generated by software, to monitor its use. Software can report the number of user accounts, the frequency of use by accounts, the access to some specific functions. Almost all kind of use statistics can be reported.

End-user clinical data

A more specific function is the ability to send user's clinical data to the manufacturer. Then, the manufacturer shall obtain the user's consent to send and process such information for PMS purposes or other purposes. The consent form may be displayed by the SaMD as well, provided that the legal department considers this is enough for an informed consent, and provided that the electronic signature in the consent form is validated (GDPR, HIPAA and 21 CFR part 11 are haunting this small bit of software!).

Event though this function looks like a validation nightmare, use statistics and clinical data can be source of highly valuable information for the manufacturer:

• Data to better train their ML pipelines and models,
• Data for future ML pipelines and models,
• Usability data to monitor end user's way of using the application,
• Data used for trend reports,
• Clinical data during a clinical investigation,
• Clinical data for PMCF,
• And some other data specific to the SaMD intended use.

PMS software functions

These functions won't be qualified as medical devices, as they don't give results for the benefit of a single person. We can split them into two categories: generating data and analysing data.

Functions generating data

These functions generate aggregates of data, that can be anonymized, if possible.
However, it may be difficult to separate these non-MD functions from MD functions. Is it possible to isolate logging functions from other components? Probably not for the logging points disseminated through the software. Probably yes for the logging system, like a logging server.
Thus, validating these functions can be partially part of the SaMD validation, when data generation is inside the SaMD.

Functions analysing data

Data analysis consists in processing data aggregates coming from several patients. The computers performing these analyses are managed by the manufacturer and are software used in the PMS process. Thus, they are QMS software, subject to a passionate and exciting QMS software validation, like IQ/OQ/PQ.

Architectural separation

As we've seen in the previous article, separating non-MD functions from MD functions is a good option. When feasible, it allows to reduce the burden of validation on the SaMD, and leave it to the less stringent QMS SW validation process.

Conclusion

A complete PMS process requires user data and clinical data from the field. Automating this data collection with some PMS functions in a SaMD is a good option. It will result in a validation covering the requirements, when applicable, of SaMD, of GDPR or HIPAA and 21 CFR part 11. That validation can be a burdensome task when all these regulations are simultaneously applicable. But it can be worth the effort, when manual data collection is a too burdensome task on its own.