SBS - The Best Value in QMS software

Strategy for IEC62304 implementation half way into the software development process

#1
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!
 
Elsmar Forum Sponsor

davishont02

Starting to get Involved
#2
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

Staff member
Super Moderator
#3
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.
 
#4
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
 
#5
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

Staff member
Super Moderator
#6
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.
 
#7
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

Starting to get Involved
#8
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
 
#9
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 (y)

GillLN
 
Thread starter Similar threads Forum Replies Date
J Strategy for MDR Regulatory Compliance Procedure ISO 13485:2016 - Medical Device Quality Management Systems 4
D MSA strategy Gage R&R (GR&R) and MSA (Measurement Systems Analysis) 4
K IEC 62304 compliance - Code reviews as part of verification strategy IEC 62304 - Medical Device Software Life Cycle Processes 5
W Seeking Guidance Verification Test Strategy for Class B Medical Devices IEC 62304 - Medical Device Software Life Cycle Processes 1
H Post-market surveillance strategy EU Medical Device Regulations 2
S Regulatory strategy for Third party plugin in a PACS EU Medical Device Regulations 1
O New MDR 2017/745 Transition Strategy - 2019 Manufacturing and Related Processes 3
T CE Certification Strategy - Expanding the validity of certificate EU Medical Device Regulations 1
J CER - Literature search strategy and PMV data Timeline - MEDDEV 2.7.1/ Rev 4 CE Marking (Conformité Européene) / CB Scheme 2
M Strategy for Foreign Regulatory Compliance Other Medical Device Regulations World-Wide 6
O Supply chain strategy or commodity strategy reading recommendations Supplier Quality Assurance and other Supplier Issues 6
D Production Strategy in Construction & Heavy Industries Manufacturing and Related Processes 0
Q How to align a Business Strategy to Operative KPIs ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 10
M Chrysler is requesting a "Torque Strategy" for all Fastener Joints FMEA and Control Plans 7
Q IATF 16949 Strategy - Audit Team Requirement IATF 16949 - Automotive Quality Systems Standard 4
B Strategy for Registration a Medical Device in China China Medical Device Regulations 2
G How to develop a strategy to eliminate an indicator who has been 0 forever? Preventive Action and Continuous Improvement 1
A Quality Management System Strategy Misc. Quality Assurance and Business Systems Related Topics 15
M Strategy to allow for OTS computer use as part of a Medical Equipment System EU Medical Device Regulations 14
D GHG Emissions - Can a Prevention is better than Cure strategy help Imported Legacy Blogs 4
N Scouting Potential Suppliers - Strategy and Tactics Supplier Quality Assurance and other Supplier Issues 7
D What is your Post-Market Surveillance Strategy 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 1
A Assessing a Preventive Maintenance Strategy - Reliability or Maintenance Statistics Reliability Analysis - Predictions, Testing and Standards 2
AnaMariaVR2 Communicating Strategy with the Balanced Scorecard Business Continuity & Resiliency Planning (BCRP) 0
J What is Exposure Assessment Strategy - Annex D of OHSAS 18002? Occupational Health & Safety Management Standards 6
F Is every activity required to be mentioned in BSC strategy map ? Quality Tools, Improvement and Analysis 1
B Strategy Document to deploy a new eDHR system ISO 13485:2016 - Medical Device Quality Management Systems 1
I Quality Assurance Business Plan & Strategy Quality Tools, Improvement and Analysis 3
A Presentation on Training and Development Strategy on Skill Crisis wanted Training - Internal, External, Online and Distance Learning 2
A What should be strategy plan to develop R&D and what we should do to certified that IATF 16949 - Automotive Quality Systems Standard 5
Sidney Vianna Reasons for the Decline of ISO 9001 Registrations Worldwide and ISO Strategy 2030 - Why can't they learn? ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 154
D BS 25999 - BCM (Business Continuity Management) Strategy Business Continuity & Resiliency Planning (BCRP) 2
H Getting Things Started ? QM, Tactics, Strategy, Acceptance vs. Gridlock, Enthusiasm Quality Manager and Management Related Issues 3
pbojsen Regulatory Plan / Strategy Template? Other US Medical Device Regulations 10
J Sampling Strategy for Process Control - How to develop a Sampling Plan Inspection, Prints (Drawings), Testing, Sampling and Related Topics 6
C Supplier Quality Development Strategy - How can we convince the supplier? Supplier Quality Assurance and other Supplier Issues 10
P Services (Management Systems Strategy) that we can offer to other companies Misc. Quality Assurance and Business Systems Related Topics 1
bio_subbu GHTF - Guidance on QMS Audits at Multiple Sites / Regulatory Auditing Strategy Other Medical Device Related Standards 1
H Supplier Quality Strategy - Class 1 Medical Device manufacturer Supplier Quality Assurance and other Supplier Issues 10
M Electronic Medical Records (EMR) strategy Software Quality Assurance 1
S Strategy for implementation Lean Six Sigma - What kind of research? Six Sigma 4
P 3 Year Strategy Sourcing Plan - Supplier Quality Manual IATF 16949 - Automotive Quality Systems Standard 5
Wes Bucey Exit (Escape?) Strategy (Employment FMEA) - Good and Bad Experiences Career and Occupation Discussions 23
J Training Strategy for Primary ISO 9001 Implementation ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 7
A A Step by Step TS 16949 Implimentation Plan and Strategy - New Company IATF 16949 - Automotive Quality Systems Standard 17
L Strategy Plan for Systems Thinking Career and Occupation Discussions 6
W What is difference between the company policy & company vision or strategy Misc. Quality Assurance and Business Systems Related Topics 9
J Automotive makers strategy and benchmarking on supplier quality management Supplier Quality Assurance and other Supplier Issues 2
C Strategy for preparing CQE exam and can any one suggest some good books? Professional Certifications and Degrees 1
Wes Bucey ASQ "Living Strategy" ASQ, ANAB, UKAS, IAF, IRCA, Exemplar Global and Related Organizations 21

Similar threads

Top Bottom