Strategy for IEC62304 implementation half way into the software development process

[GillLN]

Hi all,

I'm new to medical device regulatory affairs and recently joined a team developing medical device. During an ISO13485 audit we were told that we have no evidence of software development in compliance with IEC62304. However, we're already half way into the software development process (have alpha version tested). Is there a way to implement IEC62304 into the development at midpoint? or we have start over with a software development plan that's in compliance with IEC62304 from scratch？

Also, is IEC62304 mandatory or de-facto mandatory in order to be ISO13485 certified?

Any advice would greatly appreciated. Thank you!

 

[davishont02]

Hi GillLN,

The short answer is no, IEC62304 is not mandatory to be ISO13485 certified, however, during your certification audit, many registrars are going to be looking for 62304 compliance if you have software elements in your device.

I have worked as a Quality Manager for multiple organizations with software as a medical device and some with software elements, what I have found is it is easier to be compliant with 62304 than not. Since it is a harmonized standard, it ensures you have the appropriate software development processes and documentation for various geographic regions (US, EU, etc) and situations (some auditors and testing bodies look for it specifically).

Your QMS is a living being that should always be improved. Introducing compliance to 62304 would be a positive change that seems to have already come up in an audit. If you are already developing your software to industry standard, you may already have the elements necessary for an easy adoption of 62304.

If you decide to adopt, create a quality plan that evaluates both the impact to the QMS and current documentation/design file. QMS impacts would be changes to design process (addition or modifications of any procedures, WI, or forms). Documentation/Design File impact would consider what modifications to design documentation are necessary, if any, for software that has been developed or in the process of being developed. The software development plan (SDP) is meant to be updated, so yes I would expect modifications to the plan to happen for some things. For example, if there was no configuration management - you can add the section regarding conf. man. to the SDP, then note in the revision history it was added. Just like any new process, you would use configuration management from that day forward.
Note: part of the quality planning process is to decide how changes impact the QMS, in this case to the development process. You have to consider regulatory and business dependencies on when is the right time to adopt 62304.

Hope this helps.

LaDahvia

 

[yodon]

Excellent answer by @davishont02 above.

To build on that a bit, establishing the safety class is critical. Like @davishont02 said, it's not mandatory but it's what regulators are looking at and with everything being risk-based these days, there will be an expectation of a risk-based approach to your software development.

Most of 62304 is just basic software engineering. A few twists, IMO, but you are probably doing most everything already. Get on board. Establish the software safety class, do the gap analysis, then start filling in the missing pieces. Shouldn't be a monumental effort (assuming you're employing good software engineering practices already).

Don't be lured into trying to take the legacy ("we'll fix it after release") path. It will likely be more painful in the long run.

 

[GillLN]

Hi GillLN,

The short answer is no, IEC62304 is not mandatory to be ISO13485 certified, however, during your certification audit, many registrars are going to be looking for 62304 compliance if you have software elements in your device.

I have worked as a Quality Manager for multiple organizations with software as a medical device and some with software elements, what I have found is it is easier to be compliant with 62304 than not. Since it is a harmonized standard, it ensures you have the appropriate software development processes and documentation for various geographic regions (US, EU, etc) and situations (some auditors and testing bodies look for it specifically).

Your QMS is a living being that should always be improved. Introducing compliance to 62304 would be a positive change that seems to have already come up in an audit. If you are already developing your software to industry standard, you may already have the elements necessary for an easy adoption of 62304.

If you decide to adopt, create a quality plan that evaluates both the impact to the QMS and current documentation/design file. QMS impacts would be changes to design process (addition or modifications of any procedures, WI, or forms). Documentation/Design File impact would consider what modifications to design documentation are necessary, if any, for software that has been developed or in the process of being developed. The software development plan (SDP) is meant to be updated, so yes I would expect modifications to the plan to happen for some things. For example, if there was no configuration management - you can add the section regarding conf. man. to the SDP, then note in the revision history it was added. Just like any new process, you would use configuration management from that day forward.
Note: part of the quality planning process is to decide how changes impact the QMS, in this case to the development process. You have to consider regulatory and business dependencies on when is the right time to adopt 62304.

Hope this helps.

LaDahvia

Hi LaDahvia,

Thank you very much for the explanation and advice. Regarding the impact to the Documentation/Design File, we currently don't have any official software development plan but rather pieces of communication (the software development was outsourced). In other words, there is no official documentation of the SDP, requirement analysis, software architectural design, etc. Is it acceptable to start constructing these documents now based on tasks performed in the past?

GillLN

 

[GillLN]

Excellent answer by @davishont02 above.

To build on that a bit, establishing the safety class is critical. Like @davishont02 said, it's not mandatory but it's what regulators are looking at and with everything being risk-based these days, there will be an expectation of a risk-based approach to your software development.

Most of 62304 is just basic software engineering. A few twists, IMO, but you are probably doing most everything already. Get on board. Establish the software safety class, do the gap analysis, then start filling in the missing pieces. Shouldn't be a monumental effort (assuming you're employing good software engineering practices already).

Don't be lured into trying to take the legacy ("we'll fix it after release") path. It will likely be more painful in the long run.

Hi Yodon,

Thank you very much for the advice!

Unfortunately, out contractor didn't employ good software engineering practice nor did we took that into consideration (now we do). So we practically need start from scratch in terms of the documentations. Do you have any suggestions on how to document the activities/tasks happened in the past and make them fit into the software development process that's in compliance with IEC62304.

GillLN

 

[yodon]

As the Nike slogan goes: Just do it!

Without knowing exactly where you are in the process, it's a bit difficult to provide specifics. The first thing, as mentioned, should be to determine the software safety class. If class C, you may end up with considerable rework (especially in architecture).

Risk Management and Requirements will be key documents.

 

[GillLN]

As the Nike slogan goes: Just do it!

Without knowing exactly where you are in the process, it's a bit difficult to provide specifics. The first thing, as mentioned, should be to determine the software safety class. If class C, you may end up with considerable rework (especially in architecture).

Risk Management and Requirements will be key documents.

Thanks again!

 

[davishont02]

Hi LaDahvia,

Thank you very much for the explanation and advice. Regarding the impact to the Documentation/Design File, we currently don't have any official software development plan but rather pieces of communication (the software development was outsourced). In other words, there is no official documentation of the SDP, requirement analysis, software architectural design, etc. Is it acceptable to start constructing these documents now based on tasks performed in the past?

GillLN

Got it!

Just as Yodon said, the earlier the 62304 elements are introduced the better. It is acceptable and expected to construct these documents even though some of the tasks have been performed in the past.
In regulated industry when you find that something has been missed and your system needs to be improved you a) acknowledge that has been work done, b) document how you will be moving forward and c) do it.

From a granular perspective, to acknowledge the work that has been done and how you are moving forward you can explain your efforts in the software development plan (or project plan) to scope the document and put in to context how the processes will apply (Some plan templates have a project overview section - this would be a good place to put it.). Remember the plan is for the activities for this project- every project has its nuances. This approach can be used for other required plans (V&V, etc).
In regards to other design documentation, such as design inputs (i.e. requirements), design outputs (i.e. architectural documents) the construction of these documents are imperative because you can't adequately perform verification, validation, or document design changes without them. Besides 62304, these documents establish your design and would be needed as evidence of compliance to ISO 13485.

It sounds like from a design documentation perspective you may have some of this - in my experience elements of these documents are residing in a development software or wiki of some sort - you can save some time by being creative with how you retrieve the information to establish your document baseline.

Note: Since this was a result of an audit, if this is an audit observation, a CAPA will be expected form a systemic level. This also provides an acknowledgment of this happened in the past and this is how we move forward. A CAPA eliminates the need for a quality plan I mentioned earlier. But hey, it all depends on what your QMS procedures require.

Sorry so wordy - I love remediating!
Hope this helps

 

[GillLN]

Got it!

Just as Yodon said, the earlier the 62304 elements are introduced the better. It is acceptable and expected to construct these documents even though some of the tasks have been performed in the past.
In regulated industry when you find that something has been missed and your system needs to be improved you a) acknowledge that has been work done, b) document how you will be moving forward and c) do it.

From a granular perspective, to acknowledge the work that has been done and how you are moving forward you can explain your efforts in the software development plan (or project plan) to scope the document and put in to context how the processes will apply (Some plan templates have a project overview section - this would be a good place to put it.). Remember the plan is for the activities for this project- every project has its nuances. This approach can be used for other required plans (V&V, etc).
In regards to other design documentation, such as design inputs (i.e. requirements), design outputs (i.e. architectural documents) the construction of these documents are imperative because you can't adequately perform verification, validation, or document design changes without them. Besides 62304, these documents establish your design and would be needed as evidence of compliance to ISO 13485.

It sounds like from a design documentation perspective you may have some of this - in my experience elements of these documents are residing in a development software or wiki of some sort - you can save some time by being creative with how you retrieve the information to establish your document baseline.

Note: Since this was a result of an audit, if this is an audit observation, a CAPA will be expected form a systemic level. This also provides an acknowledgment of this happened in the past and this is how we move forward. A CAPA eliminates the need for a quality plan I mentioned earlier. But hey, it all depends on what your QMS procedures require.

Sorry so wordy - I love remediating!
Hope this helps

Hi LaDahvia,

It's not wordy at all! Thank you so much. Your explanation and suggestion really helped me understanding the situation and develop a plan to address the issues. I really appreciated the time and effort you put into this response

GillLN

 

[davishont02]

You are so very welcome GillLN!