Hi Vikram,
Reading your posts it seems you have a complicated case - I'll try to elaborate below. If my assumptions are incorrect I apologize.
It seems to me, that you have a few separate issues - I recommend to split up your case into as many minor issues as possible, and then manage eat issue individually - while adhering to he whole picture. If you don't split it up you'll get confused.
Regarding design life:Planned design life (expected service life) of 5 years only indicates that each individual device has an in use life-time expectancy of 5 years after being sold.
So no, this does not in any way trigger a need for redesign by itself.
Regarding validity of test results:I'll split this question in two parts below.
a) On validity period:No, there is no time period limiting validity of test results.
What could trigger a need for retesting is redesign of hardware, redesign of software or a change in standards or regulations.
So, if there is no change in the device or its requirements the existing test evidence
should be sufficient (see below).
b) On adequacy of test evidence:If I understand correctly, your existing test evidence is incomplete. It reports the conclusion (pass) bot there is a lack of traceability, description of how things were tested and so on.
As such, I assume that at some point in the past when the device was developed, the evidence was written, evaluated and accepted by the standards of that time.
Secondly I assume that you are re-evaluating the device documentation - perhaps due to MDR transition? Which brings you to re-evaluate documentation that was found to be acceptable in the past in a new light. Yes, the MDR changes how we evaluate documentation for software, and yes interpretation of IEC 62304 has evolved over the years, to some degree reflected in the TRF.
So, your dilemma is that existing documentation does not meet the expectations of current regulations and standards and you are in the process of re-authorizing under the MDR.
If correct, then yes you most likely will have to improve the test evidence documentation to meet the standards of today. And if the existing documentation lacks traceability, evidence and observations, the most effective approach can certainly be to re-test - perhaps with limited scope.
Regarding 'Retesting ...':IEC 62304 defines the life-cycle processes for software development and maintenance.
It requires, that retesting is performed when there is a change in functionality, etc.
It does not say that you can not retest for other reasons.
I would refer you to Figure 2 of IEC 62304 and propose you treat this retest as a 'maintenance request', which triggers that you go through the entire maintenance process and update your documentation as relevant along the way.
------------------------------
Claus Rømer Andersen
Hørsholm, Denmark
claus@roemerconsulting.dk------------------------------
Original Message:
Sent: 03-Jan-2020 18:57
From: vikram u
Subject: TRF File for Compliance - applicability over Design Life
Hi Andreas,
Thank you for covering most parts of my question.
The TRF as you have listed is the Test Report Format for 62304 covering software development and configuration process.
The correction on service life over a design life is duly noted. Does the planned design life of 5 years' mean that there has to be some redesign needed after introduction of the product?
The main question here though was to know and provide rationale for a verdict based on Test results. Is there a validity period for a test evidence(software product) if no redesign is done?. The complexity is that some test evidence does not list version/combination of OS, individual requirement breakup and their Pass/Fail status. It is only possible to say Req#X.Y passed,but there is insufficient evidence and observation details for all steps under Req#X.
Retesting could be justified if there were changes in functionality, feature specific changes are tested on a project basis and this is not as per 62304 acceptance criteria defined for release. How do we map to this acceptance criteria ?
------------------------------
Regards,
Vikram U
Tech Lead, MDD-MDR transition
India
Original Message:
Sent: 03-Jan-2020 09:23
From: Claus Andersen
Subject: TRF File for Compliance - applicability over Design Life
Hi Vikram,
Your question is not entirely clear to me - so you'll get some comments and return questions.
I assume that with 'Product Design Life' you refer to 'expected service life' as defined by clause 3.28 of IEC 60601-1? This term relates to the time period during which the device is expected to remain safe. I.e. from device being taken into use until device is scrapped.
This is different from the time period where the product is placed on the market after having been developed.
As such, you can have several software releases / updates to a device that has been on the market for a time period being longer than the expected service life.
As you are preparing a TRF (presumably a Test Report Form?), I assume you are in the process of performing a safety test according to IEC 60601-1 or a specific product standard?
In this process, you should evaluate if and justify how you test evidence is valid and relevant to support the verdict in the TRF. For any old test evidence, this can be challenge for software which has been subject to multiple updates and indeed retesting could be justified. But the case that the test reports are older than the expected services life does not in and by itself justify / require re-testing.
I would propose, that in the TRF you refer to existing release test evidence and justify that it is valid to document compliance with each of the test requirements. This justification could be a separate engineering rationale.
In cases where existing release test evidence is found to be inadequate or insufficient to demonstrate compliance with a test requirement you retest and refer to the new test evidence.
Does this help at all, or did I misunderstand your question?
------------------------------
Claus Rømer Andersen
Hørsholm, Denmark
claus@roemerconsulting.dk
Original Message:
Sent: 03-Jan-2020 05:30
From: vikram u
Subject: TRF File for Compliance - applicability over Design Life
Hi
I have a lingering doubt regards the applicability of the Test Evidence of a Software driven Medical device. The Product Design Life is for a period of X years. The Software has had intermediate releases through-out this period and Test evidences are available for the releases
In preparing the TRF for the Product, we have to check evidences for covered features and releases and update the Verdict. Would the Test evidence need to be re-run if the resport is older than the intended design life. i.e. the Test reports are older than the stated design life.
How would we map the Product TRF evidence to the Release Test evidence?. Is there a rationale to be listed to say that the Test results/verdict is valid for the last released Software/Product?. Would end of Design life of the product affect validity of Test results?.
The TRF maps to EN/62304:2006 AMD1:2015.
------------------------------
Vikram U
Tech Lead MDD-MDR Transition
India
------------------------------