Mapping of IEC 62304 artefacts (SRS, SAD, etc) to the 820.30 phases

[andypatkinson]

Hi,

Can anyone provide a mapping of IEC 62304 artefacts (SRS, SAD, etc) to the 820.30 phases: Planning, Design Input, Device Design, Design Output, Verification, Validation, Design Review.

(As a side note, I cannot even find a good definition of what 'Design' means when considering 820.30 Design Controls and medical device software development - any thoughts, interpretations, suggestions?)

I have seen so many contradictory and incorrect answers,
the favourite being:

Planning: SDP
Design Input: System Requirements, Medical Device Risk Assessment, SRS
Device Design: SAD, SDD, Code
Design Output: Release Notes, Binary
Verification: Verification Report

What say you learned folk?

TIA

Andy

 

[yodon]

First off, here are a couple of links that may be helpful:

http://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/ucm085281.htm

http://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/ucm089543.htm

The last one provides a fairly good mapping.

As far as your list goes, it's not bad. I would move 'code' to a design output (it's implementation of the design). It can go along with the binaries since those are outputs, too. I would add verification protocols and results along with the report.

A lot depends on the classification and the way you guys do business. I personally recommend (when applicable) a design artifact be an Interface Control Document. Other things you may need to consider / do based on class would be unit test documentation (procedures, results), integration test documentation, change records, etc. Procedurally, you may want to have a Configuration Management / Release Management Plan, a Risk Management Plan, and a V&V Plan. If you have risk controls implemented in software, you'll need verification of those (if not included in your verification documentation already). You may want to include review records.

If you have SOUP / COTS in the system, you'll want to do some additional analysis / documentation / testing.

Those jump to mind - may not be complete.

 

[andypatkinson]

Hi Yodon,

Thanks for the reply. A few questions if I may:

1) what specifically is of interest in the linked docs? I had a skim read and couldn't immediately see the correlation?

2) What does the FDA mean when they say 'Design'? It seems to be anything and everything prior to Transfer and therefore Design Outputs are the artefacts transferred into Production which does not include Source Code - it's the binary + release notes + installation / programming instructions.

3) Quote "As far as your list goes, it's not bad. I would move 'code' to a design output (it's implementation of the design)." - and herein lies some of my 'confusion'. If I look at this as a software engineer, I know what design is - it's where I turn 'what' (reqs) into 'how' (designs) and I then implement my design as code (as you suggest). I don't think this use of 'design' is synonymous with the FDA use of the term 'design' - Design Output is what I put into production. Do you agree?

Either I am making heavy weather of this or it's not as clear as hoped it would be.....

Any further help appreciated - anyone else feel free to chime in. Showing how (as software folk) we satisfy 820.30 must be a pretty universal thing (if you're headed into the US market).

TIA

Andy

 

[yodon]

The first link talks a little about how the FDA views the software life cycle (with a focus on validation). The second talks about the artifacts expected for submission based on the level of concern.

Design is, as you suggest, everything up to production but it certainly includes the software source code since that's what's touched when you have to make changes. That's why validation talks so much about the life cycle and control.

So design outputs are ALL the results of the process of translating the design inputs into the final product. Not just the things that go into production (i.e., binaries).

 

[mihzago]

I think you shouldn't be looking at Design Controls described in 820.30 as "phases", but rather as required elements that drive activities and deliverables within your own development process.

Your mapping is mostly correct, but as Yodon mentioned, your "device design" artefacts should be under "Design Outputs". There is no design control called "Device Design"; loosely "design" applies to everything that makes up your product, including the code. I've noticed this concept is confusing to software folks, they think "design" applies to the process of creating the software or the UI; I sometimes for example hear "this is not a design change, we only changed one line of middleware code".
Also, I think that the "Design History File" provides suggestion what is considered "design" - which is everything that happened before you transferred your to production (deployed, for many stand-alone software transfer to production equates to a few mouse clicks).

I created a table with mapping of FDA design control elements, IEC62304, my company's development phases, typical deliverables, and brief description. I try to attach it, but I'm not sure if I have enough privileges to be able to post files. (if not, I'll be happy to share via email)
I hope this is helpful. Feel free to share any feedback; I'm sure what i have is not perfect and needs more work.

 

[andypatkinson]

Hi Guys,

Thanks for your feedback.

Yes, for SW folk it's a shift in their thinking - overloaded terms with very different meanings and implications.

I think I am OK with this now.

Thank you for your time and attention.

Regards

Andy