1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.
Dismiss Notice
You must be a registered member in order to post messages and view/download attached files in this forum.
Click here to register.

Is Expected Service Life applied to Software ?

Discussion in 'IEC 60601 - Medical Electrical Equipment Safety' started by nikolaos, Nov 18, 2015.

  1. nikolaos

    nikolaos Member

    Joined:
    Aug 11, 2015
    Messages:
    9
    Likes Received:
    4
    Trophy Points:
    2
    Location:
    Italy
    Is the ESL as defined in 60601-1 3rd Ed. applied also for the Software?
    Thanks
     
  2. Atul Khandekar

    Atul Khandekar Administrator Staff Member

    Joined:
    Jul 24, 2015
    Messages:
    376
    Likes Received:
    266
    Trophy Points:
    62
    Location:
    Pune, India
    Can someone please help with this question?
    Thanks.
     
  3. yodon

    yodon Well-Known Member

    Joined:
    Aug 3, 2015
    Messages:
    198
    Likes Received:
    115
    Trophy Points:
    42
    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.
     
    Atul Khandekar likes this.
  4. MarkMeer

    MarkMeer Well-Known Member

    Joined:
    Dec 3, 2015
    Messages:
    138
    Likes Received:
    62
    Trophy Points:
    27
    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...
     
  5. pdzip

    pdzip New Member

    Joined:
    Jan 21, 2016
    Messages:
    4
    Likes Received:
    1
    Trophy Points:
    2
    Location:
    Pacific Northwest, USA
    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).
     
  6. MarkMeer

    MarkMeer Well-Known Member

    Joined:
    Dec 3, 2015
    Messages:
    138
    Likes Received:
    62
    Trophy Points:
    27
    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.
     
  7. Peter Selvey

    Peter Selvey Member

    Joined:
    Nov 9, 2015
    Messages:
    13
    Likes Received:
    8
    Trophy Points:
    2
    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).