Discussion in 'IEC 60601 - Medical Electrical Equipment Safety' started by nikolaos, Nov 18, 2015.
Is the ESL as defined in 60601-1 3rd Ed. applied also for the Software?
Can someone please help with this question?
Sorry for the delay responding... busy, busy, busy.
Since an expected service life for a medical device (even if just software) is required to be defined, why not use that?
There are good reasons (IMO) to define an expected service life for software: helps pick platforms, enables planning for service support & upgrades, etc.
If it can be assumed that the platform/hardware the software is installed on will not change from the time it is put into service (i.e. the system-requirements are clearly specified, and users are expected to abide by them), I really don't see how "expected service life" can apply to software.
Unless there is some upper-limit on the data or iterations of process, then I really don't see how estimation of a service life is even possible...
Service life for medical device software (SaMD) is in my opinion a reality. There is always a chance that a hitherto unknown serious bug creeps out of the woodwork and will need to be fixed. That will get harder as time increases. We also have to face the fact that if the medical SW was designed to run on XP, then you may have a problem when the old reliable XP workhorse gives up the ghost and the SW must be ported to a Windows 10 machine. My guess is that as a SW provider, you don't want to support any longer than regulatory requires (or of course the market).
I still maintain that the concept makes little sense. Sure, you could specify a service-life to the customer to indicate a time-frame after which you no longer support the software. ...but from a regulatory perspective it be hard to justify a service-life unless there is some actual decrease in performance overtime, or some indication that bugs may be introduced as a function of time. As far as changing operating systems, hardware, etc., this should be covered by a clear specification of the system-requirements for the software.
If users abide by the specified system-requirements, and the software is either simple or sufficiently robust, there is no reason to predict that its function would be compromised as a function of time.
Service life is simply a statement in the risk management file which can be referred to when needed, since it can influence risk based decisions. In many (most) cases it is not relevant, but there are special situations where it directly influences the probability calculations, especially for high risk devices. This can then influence decisions such as whether to include, for example, self diagnostic features, which are often software driven. Hence, the device lifetime can influence the software.
As for considering the life of the software itself e.g. stability for upgrades, degradation over time and so on, I don't think this is the intention behind need to declare a lifetime. Sure, it is always possible to construct a scenario, but from a regulatory perspective these are a bit too vague. Re-installing software designed for XP to a Win 10 machine would be misuse if the manufacturer did not define (validate) it is OK for Win 10; bugs are not function of time (bugs might be found as a function of time, but they are not created as a function of time).
Separate names with a comma.