Adopting old product - compliance with IEC 62304

globatron

Starting to get Involved
Hello everyone,

I am currently dealing with a situation where a product that was not a medical device before might have to be transitioned to the MDR space. We already dealth with most of the requirements (13485, 14971...) but with regards to 62304 it becomes tricky since the product is standalone software.

62304 foresees that old software can be used as legacy software, in case it was placed on the market before 2010. This is the case for the initial version, but it was not placed on the market as a medical device and was updated thereafter regularly. Therefore i guess the clause about legacy software is not applicable.

There is a lot of documentation available on the development including verification&validation, change requests etc., but it is not 62304 compliant. Would we have to re-do everything from scratch (reverse-engineering?) or is there any chance to "transform" old documentation and development to be in compliance with 62304? Treat it as SOUP etc.?

Thanks!
 

Tidge

Trusted Information Resource
In order to claim compliance with 62304, you will need to have evidence of the existence of the specific deliverables required per the software system safety classification. The required deliverables of 62304 are commensurate with the safety classification. If you find you are missing certain necessary deliverables, then you will need to create them, starting with a formal classification of the software system. This will give you an idea of how big the potential gaps could be.

Since the codebase already exists, there may be some elements of the development plan that won't be applicable, but you will still need to establish requirements, traceability from requirements (to controls, etc.), and a lifecycle plan. It sounds as if there is an established process for software management, so the other area to make sure is under control is risk management.
 

globatron

Starting to get Involved
thanks a lot for the explanation!

So it should be ok to conduct a gap analysis? Afterwwards we would set up a plan, document what was already there and which gaps we have identified, based on the requirements, and what we wold plan on closing those gaps. We would then have a part of the documentation according to the old process as well as new documentation to accompany the old documentation, showing that we filled any gaps.

I think it will be easier once we reached product version 1.0, since from there we can fully conduct software maintenance according to 62304.

Regarding the safety classification: is it correct to assume that only hazardous situations caused by the software itself should be assumed here? Therefore topics like "intentional missuse" do not have to be reflected in the safety classification?

Thanks again!
 

yodon

Leader
Super Moderator
62304 does address the concept of Legacy Software and the approach to bring things in line. Indeed, a gap analysis is indicated, but so are the risk management activities. From your gap analysis, you develop a [documented] plan to

"...generate the identified DELIVERABLES. Where available, objective evidence may be used to generate required DELIVERABLES without performing [the indicated] ACTIVITIES"

All changes going forward are to be managed in accordance with 62304. Finally, you need to document a rationale for continued use of the legacy software.

Can the software be intentionally misused such that it would allow harm? I'm thinking, for example, of an infusion pump. The drug being delivered has a max delivery rate. The software should not allow the (intentional misuse) case of allowing the operator to program a delivery rate exceeding the max.
 

globatron

Starting to get Involved
Thanks a lot for further explaining the requirements. Legacy Software would require though, that the software was used as a medical product previously, right? The software was marketed before for years, but not as a medical device but will become a medical device by updating the intended purpose.

The software is quite safe to use, it provides information for diagnosis which can (and must be) fully verified by professional users before utilizing for diagnosis. Therefore the only way harm could be caused is by intentionally ignoring the intended purpose of the product and instructions for use. We covered such aspects through ISO 14971.
 

yodon

Leader
Super Moderator
Legacy Software would require though, that the software was used as a medical product previously, right?

There's nothing in the standard that would lead me to believe this is the case.

Be sure you cover both false positive and false negative cases in your risk analysis, if you haven't already.
 

Tidge

Trusted Information Resource
Legacy software is defined in 62304:

LEGACY SOFTWARE: MEDICAL DEVICE SOFTWARE which was legally placed on the market and is still marketed today but for which there is insufficient objective evidence that it was developed in compliance with the current version of this standard.
 

globatron

Starting to get Involved
Right, but placed on the market would mean "as a medical device" or in general placed on the market? As I said before, the product was not used as a medical device and will only be placed on the market as a medical device in 2021.

Thank you!
 

TomaszPuk

Starting to get Involved
As you are developing medical device software I would treat that "project" as first design and development iteration under ISO13485. One of the design and development inputs to the project would be the requirement to follow IEC62304 standard. During Software Development Life Cycle (SDLC) as you define software safety classification for you software you would be able to assess the gap between what you have on docs / engineering / tools and what you should have.
Then you would start addressing these gaps on the levels such as:
1. Engineering e.g. implementing risk control measures, security measures, etc.
2. Processes like risk management, architecture reviews, installation, maintenance etc.
3. Documentation - adding missing docs and records.
The biggest gap is usually in documentation and then within verification and validation processes. When you approach the release you would collect the documents (old and new once) that are required for e.g. Class B and deliver them as Design Outputs to ISO13485 level. If your system was well implemented, the scope of engineering changes would be still minimal while the documentation / processes would close the gap to IEC62304.
 

Tidge

Trusted Information Resource
Right, but placed on the market would mean "as a medical device" or in general placed on the market? As I said before, the product was not used as a medical device and will only be placed on the market as a medical device in 2021.

If the device was not on the market as a medical device, but you now believe it to be a medical device, I am inclined to be suspicious about claims that it could be treated as legacy software.... but I am more skeptical that it actually is somehow now a medical device, if it was already on the market and was not a medical device. I can imagine that this is the case, but I remain skeptical.

62304 is a standard for the development of medical device software. The activities required as part of 62304 derive from a risk analysis. "Legacy" status doesn't remove the requirements around performing a risk analysis. Are you comfortable telling us where you have landed in the software system safety classification?
 
Top Bottom