Search the Elsmar Cove!
**Search ALL of Elsmar.com** with DuckDuckGo including content not in the forum - Search results with No ads.

Medical Device Software - Design Outputs? ISO 90003 and ISO 62304

K

koes0030

#1
Hi all! I'm currently struggling with trying to overhaul a company's design control procedure. The company is trying to follow ISO 90003 and 62304, but must also be compliant with 21CFR820 and ISO 13485. Currently, the company is using a Software Requirements Specification document for design inputs... they have not defined what serves as their design outputs. They have a Software Design Specification document that could be part of the ouput... but it seems that the actual source code is going to be the primary output.

This is the first time I've ever worked with a software device... when working with inputs/outputs at other device companies, I've always seen them presented in some sort of matrix format, clearly showing which outputs satisfy which inputs (drawings, specifications, IFU's, etc.) I can't seem to figure out how it should work in this case with the software device. How can we put the outputs in a form that enables verification against the inputs? Any thoughts would be greatly appreciated!!!
 
R

rclanzillotto

#2
Re: Medical Device Software - Design Outputs?

Develop a software customer requirements document that will serve as your design input. This contains functional descriptions. Link it to your specification and V&V tests.

Good Luck
 

yodon

Staff member
Super Moderator
#3
Re: Medical Device Software - Design Outputs?

Several things could be candidates for software design outputs. These include, depending on the project size / levels of documentation you have, Architecture documents (e.g., block diagrams, state diagrams, etc.); Top-Level Design docs, Detailed Design docs, Database Design docs; Interface docs (one level could be requirements <inputs> and another level could be design <outputs>); Software Build reports (more of a CM accounting but can show architecture); & Software Version Description Documents.

Reviews of each should confirm some aspect of a parent doc; e.g., an architecture doc could confirm that required functionality is addressed (at a high level), design docs (immediately traced to requirements) would be reviewed to confirm the design both adequately addresses the requirements and that the requirements are fully 'consumed.'
 
#4
Re: Medical Device Software - Design Outputs?

The way you´re presenting this semms a little weird to me. You should be defining "verifiable" design inputs (which will lead to verifiable design outputs, not forcing the output to be verifiable.

Also, a requirements engineering proccess could help.
 
Top Bottom