Software in Medical Devices, by MD101 Consulting - Tag - RecallBlog about software medical devices and their regulatory compliance. Main subjects are software validation, IEC 62304, ISO 13485, ISO 14971, CE mark 93/42 directive and 21 CFR part 820.2024-03-27T15:32:28+01:00Cyrille Michaudurn:md5:9c06172e7cd5ed0f5b192883b657eabbDotclearSaMD decommissioning, recall, removal and withdrawalurn:md5:4108ef511635793e8f0b82de191883292022-04-15T14:26:00+02:002022-04-15T14:26:00+02:00MitchRegulationsCE MarkRecallSaMD<p>We saw <a href="https://blog.cm-dm.com/post/2022/02/25/Medical-Device-lifetime-and-SaMD">in the previous post</a> how the lifetime of a SaMD can be defined. Let's continue with the operations that can affect this lifetime.</p> <h4>Decommissioning</h4>
<p>Decommissioning software can happen at the expected end of life of the SaMD, or earlier. In both cases, the end-user or a technician in charge of the device have to be informed. Users are supposed to cease using the SaMD. If no provision is taken by the legal manufacturer, end-users will continue to use it, for sure!<br /></p>
<h5>Case 1: Warning the user</h5>
<p>The bare minimum is to send a mail (either paper or electronic) to the end-users to warn them that the device has reached its end-of-life. Doing this is what is required from a legal point of view, the responsibility of the legal manufacturer ends with this letter. It will work with professional users like health care providers. But, from a risk-based approach or a usability engineering approach, that won't work with the general public or lay persons.</p>
<h5>Case 2: Software Licence</h5>
<p>A more strigent solution is to have a license manager included in the SaMD. When the SaMD is installed, a license is allocated to the software instance or several software instances, depending on the license scheme. The license is valid until one of the following two terms is reached: either the end of license contract, or the SaMD end-of-life (which will also be part of the contract anyway).It means that that the licenses are managed by some operations department of the manufacturer, with a license generator and a registry of all licenses.<br />
The way the software behaves when the license expires can be assessed with risk management. Having a stubborn SaMD refusing to open when the license expires can be a hazardous situation in some clinical contexts. Then, it will be preferable to display a warning to let the user continue use the SaMD anyway. Patient safety is one thing, legal matters are another.<br />
Some licensing librairies don't require an internet connection. This is something better within a HCP network. But it requires to have periodic maintenance of the SaMD, with updates of the licenses when the contract is renewed.</p>
<h5>Case 3: User account</h5>
<p>A third solution, suitable with the general public, with lay persons, but also with mobile apps, is to manage user accounts. When the software starts, it sends a request to a server managed by the SaMD manufacturer, to verify whether the user can use the SaMD or not.<br />
The server will answer "no" when the user account license expires or when the SaMD reaches its end of life. Then a warning can be displayed to the user with, if appropriate, an invite to update the SaMD version.<br />
It means that the manufacturer has to implement and maintain such server. It means also that this server is subject to an exciting and joyful QMS software validation.</p>
<h4>Recall</h4>
<p>Recall of hardware devices is easy to understand. The manufacturer takes actions to either ship back the devices to their premises to decommission them (removal) or to fix the problem by maintenance operations (correction).<br />
With SaMD, correction is the preferred way. The manufacturer makes the users or technicians install a bug fix, a new version. Users are informed that this new version exists, either by mail (cases 1 and 2), or by server notification (case 3).<br />
In some rare cases, a removal is required. Then, case 3 is a lot easier than cases 1 or 2, which require manual interventions. In case 2, if the license manager isn't connected to the internet, it cannot be informed of the removal. Taking <a href="https://www.fda.gov/medical-devices/postmarket-requirements-devices/recalls-corrections-and-removals-devices">FDA wording</a>, an effectiveness check will surely give better results in case 3.<br />
<br />
Remark: in all cases, a recall requires some paperwork, and at least a recall letter of the manufacturer to the users. A fully automated solution like case 3 isn't enough, unless a function to display such letter and manage user's acknowledgment exists in the SaMD. Remark in the remark: Such function will be interesting to validate, at the border of QMS SW and SaMD, with electronic records management and probably some other traps.</p>
<h4>Removal or Withdrawal</h4>
<p>This is the decision of the SaMD manufacturer or the regulatory authority to remove a device from the market. The regulatory difference between the two:</p>
<ul>
<li>Removal the device is defective,</li>
<li>Withdrawal the device is not necessarily defective.</li>
</ul>
<p>Technically speaking, both are equivalent. Case 3 will be more effective than cases 1 and 2.<br />
In all cases, the manufacturer has to send letters to the users to inform them of the withdrawal. In case 1, they cannot do anything else. In case 2, if the license manager is not connected to the internet, they cannot do anything else either. In case 2 with internet connection and in case 3, it is possible to inform the software of its status.</p>
<h4>SaMD product specifications</h4>
<p>If we are in cases 2 or 3, we can draft the following product specifications about lifecycle management:</p>
<ul>
<li>Case 2:
<ul>
<li>Lifecycle requirement 1: A license manager is present in the SaMD,</li>
<li>Lifecycle requirement 2: If an internet connection is present, the SaMD requests the license server about license status,</li>
<li>Lifecycle requirement 3: At startup the SaMD checks the license. When the license expires, the SaMD displays a warning to the user (or something else, choose your behaviour).</li>
</ul></li>
<li>Case 3:
<ul>
<li>Lifecycle requirement 1: At startup, the SaMD send a request to a server to know the current user account status and software status: valid license, expired licence, expired version, software update required, device recall,</li>
<li>Lifecycle requirement 2: When a software update is required, the user has to download and update the version prior to using it,</li>
<li>Lifecycle requirement 3: if the device is in recall, then a recall letter is displayed to the user. it is possible to send the letter to another device (mail, BT...) to let the user store it elsewhere or print it,</li>
<li>Lifecycle requirement 4: if the software version has expired, a message is displayed to the user with the reason of the expiration (enf-of-life, withdrawal...)</li>
<li>Lifecycle requirement 5: if the user account is not valid, a message is displayed to the user with an invite to renew it.</li>
</ul></li>
</ul>
<p>These kinds of product specifications are mostly suitable for mobile apps connected to the internet. But we could imagine that a SaMD manufacturer installs such server on the HCP network, with control on the server.<br />
Then we have to consider whether this server is a SaMD or not. If yes, it is quite a good option to reorganize its architecture to isolate the license server software items from other software functions qualified as medical device.<br />
We end with the requirement to validate that server as a QMS software, installed in the client premises (beware of IQ!). Such a valdilation is worth the effort, only if allows to ease all the processes described above.<br />
<br />
<br />
Anyway, SaMD decommissioning, recall, removal and withdrawal can be performed like any other devices. This article proposed some other solutions taking the opportunity to use communication capabilities of software. They ease the process, once validated but they’re not mandatory.</p>https://blog.cm-dm.com/post/2022/04/15/SaMD-decommissioning%2C-recall%2C-removal-and-withdrawal#comment-formhttps://blog.cm-dm.com/feed/atom/comments/256Miscellaneous of Augusturn:md5:06490dd7b0664df487009cf9e2e923392012-08-10T15:36:00+02:002012-08-26T13:16:39+02:00MitchMiscRecall <p>Hi everybody,</p>
<p>I was out of the office, I didn'it have time to write anything relevant about our favorite subjects.<br />
Here is an interresting article of The Economist (link will be dead after a while) about <a href="http://www.economist.com/node/21556098">open-source software</a>.
<br />
<br />
Seen on the newsletters I receive for vigilance, the recall of a defibrillator due to software failure: <a href="http://www.mhra.gov.uk/home/groups/fsn/documents/fieldsafetynotice/con152682.pdf">here on MHRA website</a> and <a href="http://ansm.sante.fr/S-informer/Points-d-information-Points-d-information/Defibrillateurs-cardiaques-externes-Fred-Easy-automatiques-et-semi-automatiques-commercialises-par-Schiller-Medical-SAS-Point-d-information/%28language%29/fre-FR">here on ANSM Website (in french)</a>.
<br />
<br />
For those who spent their vacation on Mars and haven't heard about Proteus ingestible biomedical sensor yet, have a look at <a href="http://mobihealthnews.com/18075/proteus-gains-de-novo-fda-clearance-for-ingestible-biomedical-sensor/">this article</a>. This is a double performance: technical with an ingestible sensor, and regulatory with clearance through the new "de novo" FDA process.
<br />
<br />
And to end with a bit of futurology, this new article of EMDT about <a href="http://www.emdt.co.uk/article/re-engineering-medical-technology-top-bottom-line?goback=.gde_2852098_member_141588087">the future of medtech</a>.
<br />
<br />
Bye.</p>https://blog.cm-dm.com/post/2012/08/10/Miscellaneous-of-August#comment-formhttps://blog.cm-dm.com/feed/atom/comments/57Pfizer recalls Rheumatology Calculator smartphone Appurn:md5:df3a36bd641d0ad83d3775527d7165002012-01-05T19:45:00+01:002012-01-05T19:57:30+01:00MitchMiscmHealthmobile medical appRecall<p>Dozens of companies recall their medical devices every month. A recall
happens when something wrong happened with the device, like a bad labeling or a
bad sterilization. It's the responsibility of the manufacturer to warn ALL
their customers and the government agencies that a given lot or batch of
products has a defect. The batches shall be destroyed or sent back to the
manufacturer for further analysis.<br />
That's what happened to Pfizer with its Rheumatology Calculator, a smartphone
app used to compute a score to assess the desease of patients according to
complex algorithms. There is a bug in the app and it gives wrong results.</p> <p>Pfizer had to remove it from Android market and Apple Store. At the time I
publish this post, if you search for this App, you won't find it in either
stores. Pfizer had also to warn government agencies. See <a href="http://www.swissmedic.ch/rueckrufe_medizinprodukte/archiv/index.html?lang=fr&l__=&RlArchiv=2011-07">
swissmedic recall here</a>, the agency of Swizterland, and <a href="http://www.mhra.gov.uk/Safetyinformation/Safetywarningsalertsandrecalls/fieldsafetynotices/CON135051">
MRHA recall here</a>, the agency of the UK (scroll down or search Pizer in both
web pages).</p>
<p><em>Disclamer: what I write below is not linked to the way Pfizer manages
the lifecycle of the Rheumatology Calculator App. I don't have any further
information than what I wrote above.</em><br /></p>
<h4>How to recall a smarphone App?</h4>
<p>In the case of a smartphone app, it is not possible to recall it eventually.
Once the app has been downloaded by the user, there is no possibility to erase
it from the phone. Or if there is a possibility, I haven't seen the case yet.
In the case of Apple, I trust them to apply coercitive measures on banned Apps!
For Android, I don't know if they can ban apps. On top of that, the user is the
weak link, who has to synchronize his smartphone with the store to get the
latest evolutions. Many users, like me, synchronize only once a month. So a
buggey app can be used a long time by a user before he is warned about the
situation.<br />
A software medical device manufacturer shall certainly send a mail to every
user to request him to remove the app. Maybe he shall ask the Apple and Android
markets to give him the list of users who downloaded the app. App Markets are
highly controled places. Everything is logged. So it shouldn't be a problem to
warn the users to remove an App and to get an acknowledgement that it was
actually removed.</p>
<h4>How to prevent a recall?</h4>
<p>A recall shall happen when a critical bug is found in software. In the field
of medical devices, a critical bug is something, which gives a bad result or
does a bad action, leading to a bad decision of the pratician or the patient.
Such bug can be hidden a long time, until a user does something which was never
encountered and tested, like an unexpected combination of parameters and
actions.<br />
The only way to prevent this kind of situation is to have a good software
development process. Software on smartphones, which gives information about
diagnosis, may be class IIa according to the EU regulations and class II
according to the FDA regulations. According to the IEC 62304 standard, which
deals with software development, this kind of software may be in class B.<br />
When software falls into this class, a software development process shall be
implemended with the majority of the requirements found in the IEC 62304. This
definitely is the best way to avoid a recall.</p>https://blog.cm-dm.com/post/2012/01/04/Pfizer-recalls-Rheumatology-Calculator-smarphone-app#comment-formhttps://blog.cm-dm.com/feed/atom/comments/49