Introduction of EN 62304 - Life Cycle Requirements for Medical Device Software.

W

wrodnigg

#11
Hmmm... 62304 gives more guidance, but leaves less "room to move".

I think the AAMI standards on medical device software lifecycle management and risk management are better than the en iso ones...

I hope, we will do a better job with the 2932x standards as well...
 
Elsmar Forum Sponsor
S

SligoRover

#13
Off-The Shelf Software..and Life Cycle Requirements for Medical Device Software.

Hi Folks,

I'm working with a company who are developing a medical device incorporating software. I've recently developed a series of design development procedures including procedures covering their internal software development environment However one of the areas that they want procedurised is a systematic approach to the qualification and approval of everything that might incorporate some software, and which is bought in from external sources. This could range from software tools such as compilers and debuggers which have could affect the quality of the software developed to code or firmware that actually gets embedded in the product, incl. operating systems, and hardware as well e.g. PIC's, microprocessors & comm's libraries, 3rd Party networking software, Vista, etc..

My thinking on this is to adopt a similar methodology to that I recommended for the development of their software development process -this is a multi- step phase review process starting off with a Quality Plan and Preliminary Risks Analysis, the risks analysis should focus attention to the aspects of the OTS (off the shelf software) which are of most concern and the Quality Plan plans out the steps needed to qualify that software so that it can be used. The Quality Plan of course would rationalise why its not necessary to go thru every phase at the level of detail you would for a full-blown coded development project. This approach is being balked at from two perspectives; a) the number of Quality Plans that will need to be generated and b) the "over-the-top" level of scrutiny on OTS e.g. a standard compiler/buchecker or PIC that have is going to ultimately have a relatively minor impact on final perf. of device. (Sledgehammer and walnut have been mentioned.)

So I'm rethinking my initial approach and thinking at the moment that the solution is to use the risk management structure to influence the appropriate course of action. (How I frame all of that in a simple 3 or 4 page procedure that is generic enough to cover all the above is a problem I still have to sort out -but I will.) I am also familiar with the fact that FDA have some useful guidances on OTS one of which I'm currently reading. (I can't post weblinks yet but if someone else is familiar with them maybe it might help others who are interested in this branch.)


this is a long winded way of eventually getting to ask the question I want to ask............

1. If this scenario is familiar to anybody out there, what approach have you used in your situation?

2. BTW anybody know of Linux code being used in any medical device applications?


If anyone can help I'd really appreciate it,

Cheers,

SR
 
Last edited by a moderator:
D

danpa

#14
SR,

I don't have a good solution to your first question. I have problems in that area myself.

We do use Linux as the OS that our Medical Device runs on. We configure the OS specific to our application and as such do not allow customers to use their own version. Our medical device is not a real-time, life sustaining system.
 
S

SligoRover

#15
Hi Danpa,

thanks for you're response.

Its interesting that you're experiencing similar difficulties, perhaps the start of a self-help group?

Even though the device is not real-time or life sustaining can I ask you does it gather information on which healthcare decisions are ultimately based?

(I'm not experienced at posting so maybe someone could indicate whether my posting is appropriately located to get the necessary response. I wasn't sure whether I should open it as a new topic rather than a thread to the current topic.)

Thanks again,

SR
 

burovoy

Starting to get Involved
#16
The second question is the hazard software risk analysis approach. For example I studied FMEA and FTA, though I don’t know to what extent they are appropriate for software. Please point me to where “dig out”.

Thanks a lot.
Alexander,

This guidance could help you to integrate the software risk management into ISO 14971 :

AAMI TIR32:2004 Medical device software risk management

Below is the preview link:
http://marketplace.aami.org/eseries/scriptcontent/docs/Preview Files/TIR320412 preview.pdf
 
D

danpa

#17
Even though the device is not real-time or life sustaining can I ask you does it gather information on which healthcare decisions are ultimately based?
Yes, some of our software devices are FDA class II medical devices. As such we validate the hardware, OS and software as a single package.

I think you are right to be looking to use risk management to drive the level of review/testing that needs to be done on the 3rd party software. But the development process used should be significant part of the risk study, but you probably will not have access to the information you need.
In my view, there is a danger here: if it is easier to qualify 3rd party developed software then to build your own under a controlled development process, then why would a company not have a 3rd party develop all their software and then just qualify it in-house? Some of the guidance seems to imply the scrutiny that software built for general use must undergo is different somehow from software built to your specifications. I don't see why there should be a difference.
It would seem that software developed internally under a quality system, should be less effort to incorporate and use than software developed externally under an unknown quality system, but I find the opposite to often be the case.
 
S

SligoRover

#18
I think thats a very interesting comment. In my experience it reflects two realities;
1. Many companies (and not just of medical device companies), would rather work with a contract software developer when they experience internal software project management as a struggle.
2. If there's something similar already out there (OTS software), there's an expectation that that indicates a level of inherent robustness, so grab it! The good thing about this is that it reduces the amount of risk management work needed compared with an internal software project. The bad thing is that it can influence the development of the project as the risk management process may be biased to the characteristics of that software module rather than the intended solution, i.e. lets not go looking to hard for reasons to knock it over.
:2cents:
 
D

danpa

#19
My experience points toward your second point as being the more common reason. I am not sure where the "level of inherent robustness" idea comes from, but I see it all the time. (A very similar phenomenon to the outside consultant having more credibility than a long time internal employee.)

There is another factor I see: Third party software and libraries make product development easier (even if you don't have project mgmt issues) if you ignore the fact that you generally have no idea what is happening within that software. Many people like the speed of development, but with software critical to safety, maybe we should be concerned with more than just how fast we can get new functionality out.

I disagree with “The good thing about this is that it reduces the amount of risk management work needed compared with an internal software project.”. It would seem to me that third party software should increase the amount of risk management work since we know less about the software and the way it was developed.
 
S

SligoRover

#20
Just to clarify, what I was implying is that in an internal software project there are high level and low level risk management activities. Low level risk management engages in stuff like code reviews etc.. unit testing and is documented in fault tree's etc.. With 3rd Party software only the high level risk management is performed i.e. risk assessment of the 3rd Party software outputs that are going to be implemented. So because there is less low level risk management activities there is less work.

And the reason this is so in many cases is because in many cases it is difficult for small companies to get access to the development documentation of 3rd Party software developers.

However I agree with you that in critical applications review of software validation is crucial. So that may mean doing detailed 3rd Party software development audits and critically appraising the software validation process for certain critical functional outputs and getting the necessary reassurance. However in my opinion this is still less labour intensive than actually doing the low-level risk mgmt fault tree analysis work in the first place as the 3rd Party developer should have...of course its another matter if there is no low level risk management work done and you have go back and recreate/redocument that, and revalidate the software again.


:2cents:
 
Thread starter Similar threads Forum Replies Date
G Question about Non-conformances during New Product Introduction Nonconformance and Corrective Action 14
S MDR & IVDR Introduction in late May 2017 EU Medical Device Regulations 1
S New Product Introduction Procedure - NPI Document Control Systems, Procedures, Forms and Templates 1
V Design Transfer to production = New product introduction ?? 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 4
E Does introduction of a new brochure require a 510K? US Food and Drug Administration (FDA) 7
K Auditing New Product Introduction Process General Auditing Discussions 21
K NPI (New Product Introduction) Quality Plan Outsourced Manufacturer/Supplier APQP and PPAP 3
A What should be the contents of the New Gage Introduction Form ? General Measurement Device and Calibration Topics 3
T Raw Parts Inspections for NPI (New Product Introduction) Phase Supplier Quality Assurance and other Supplier Issues 1
A Food Warehouse ISO 9001 Audit and Newbie Introduction ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 3
A Changes required to procedures after introduction of SAP Document Control Systems, Procedures, Forms and Templates 3
J EC Certificate and European Market Introduction CE Marking (Conformité Européene) / CB Scheme 8
AnaMariaVR2 Pharma ?Quality by Design? (QbD): An Introduction, Process Development & Applications Pharmaceuticals (21 CFR Part 210, 21 CFR Part 211 and related Regulations) 1
M Introduction to the Medical IT, Medical software and Health Informatics forum Medical Information Technology, Medical Software and Health Informatics 4
P Introduction of SPC to the Supply Chain Statistical Analysis Tools, Techniques and SPC 18
M NPDI (New Product Development & Introduction) Examples needed Excel .xls Spreadsheet Templates and Tools 3
S Monozukuri Rules for NPI (New product Introduction) - Help to get Lean in Manufacturing and Service Industries 3
D Introduction Coffee Break and Water Cooler Discussions 4
V Introduction Imported Legacy Blogs 6
E FDA New Product Introduction Regulations help needed 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 3
M TPM Announcement Letter for TPM introduction in a organisation Lean in Manufacturing and Service Industries 3
U Introduction of SPC - Embarking on my first implementation for precision machining Statistical Analysis Tools, Techniques and SPC 11
A QMS Introduction - I have been asked to give a brief introduction of our QMS ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 7
B New Product Development and Introduction Manual Manufacturing and Related Processes 5
P Introduction & Latest version of AIAG Control Plan request IATF 16949 - Automotive Quality Systems Standard 3
Hershal Introduction to ANS/ISO/IEC 17025 and Z540 ISO 17025 related Discussions 2
Q Procedure for New Product Introduction (NPI) - Build to print shop Various Other Specifications, Standards, and related Requirements 6
S NPI (New Product Introduction) in Electronics Industries Document Control Systems, Procedures, Forms and Templates 10
L Introduction of Compulsory Bar Coding of Medical Devices in the US? ISO 13485:2016 - Medical Device Quality Management Systems 19
Y NPI (New Product Introduction) Process Qualification System Required Document Control Systems, Procedures, Forms and Templates 8
G Introduction to TS 16949 - Excel Partnership Course Training - Internal, External, Online and Distance Learning 4
Manix TS16949 Training Requirements - Basic introduction to the standard vs. Lead Auditor Training - Internal, External, Online and Distance Learning 8
J Free Introduction Course - VBA (Visual Basic for Application) in Excel to make forms Excel .xls Spreadsheet Templates and Tools 10
C Definition NPI (New Product Introduction) Readiness - Definition Definitions, Acronyms, Abbreviations and Interpretations Listed Alphabetically 9
B Educating Employees - Introduction to what quality is all about ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 5
M Six Sigma .ppt or .doc Presentations - Awareness session or introduction wanted Training - Internal, External, Online and Distance Learning 17
A Design document - Seeking "New Product Introduction" manual example Design and Development of Products and Processes 7
K Games for training - Introduction to ISO 9001 for Upper Management Quality Manager and Management Related Issues 9
R Where can I get ISO 13485:2003 Introduction Training Videos Training - Internal, External, Online and Distance Learning 3
G Introduction of ISO/IEC17024:2003 in Australia General Auditing Discussions 3
D ISO 9001 Introduction and Training for Employees Training - Internal, External, Online and Distance Learning 36
D Fresh Coffee - An Introduction Coffee Break and Water Cooler Discussions 65
G When Do I Start FMEA? During project introduction? FMEA and Control Plans 5
E Test report to certify compliance with IEC 62304 IEC 62304 - Medical Device Software Life Cycle Processes 1
E Any sample of a full software life cycle IEC 62304 report ( any class )? IEC 62304 - Medical Device Software Life Cycle Processes 1
G Adopting old product - compliance with IEC 62304 IEC 62304 - Medical Device Software Life Cycle Processes 9
A IEC 62304 safety classification, External Controls and off-label use related risks IEC 62304 - Medical Device Software Life Cycle Processes 5
S IEC 62304 software costs and time Medical Device and FDA Regulations and Standards News 3
S IEC 62304 - Software verification cost IEC 62304 - Medical Device Software Life Cycle Processes 3
Sravan Manchikanti Software Risk Management & probability of occurrence as per IEC 62304 IEC 62304 - Medical Device Software Life Cycle Processes 8

Similar threads

Top Bottom