Design file for pre-existing products - Inputs and Outputs

James

Involved In Discussions
#1
Hi all

Just have a few questions that I'm mulling over:

1. Is there a sensible way that I can specify a design file for pre-existing products that have been in use for many years? Some products don’t have any historic design and manufacturing files but have been incrementally developed over a number of years. There have been very few incidents relating to products, with a good level of surveillance in place.

2. How do we best reflect in our design inputs and outputs that although there are approximately 20 groups of product that we make, all of these are 'custom made' to individual client requirements? For example, we make a wheelchair back support and have a technical file for this product. However, the specification for this item when we take an order is written for an individual patient as a prescription. So, the design input is the product information in the technical file, regulatory requirements, etc; its added to the patient specification and this complete set of information is the design output?

There are 2 steps in the design: Firstly the base product, which we have device file documentation for; and then secondly the client specification, which is unique / specified to the patient.

3. Is there any reason why design and development file information can’t be merged and kept within the 'medical device file'? 13485 specifies that one 'shall be maintained' for each device?

Thanks

James
 
Elsmar Forum Sponsor

Ed Panek

QA RA Small Med Dev Company
Trusted Information Resource
#2
For #2, I once worked for a company that made medical film printers. All of the printers connected to various workstations; Some CT, Some X-RAY, DR/CR, Mammo, etc. Each modality had their own special tweaks to the final design. The printer had some items in common among all the models we sold. This was our base model. The modality tweak occurred just prior to shipping and was a final configurator design. Our auditor felt the base model had a complete DHF and for final config we would need a DMR for each modality and a DHR for how each printer went through final configuration.
 

yodon

Staff member
Super Moderator
#3
I'm curious what the motivation is? Presumably a relevant authority has cleared your devices for distribution and your current situation is not considered nonconforming. (Not to endorse not doing things or that you will still be cleared in the future, just seriously curious.)

A couple of standards, like IEC 62304 (software) and ANSI 62366 (usability) have addressed the "legacy" aspect, enabling a path forward if those standards weren't followed originally. In essence, do a gap analysis then do a risk assessment on the gaps. As the risk indicates, either close the gap or provide rationale why unnecessary (based on risk).

Do note that 13485 has the concept of a medical device family and this is reflected in the 'files.'

If not considered nonconforming, sure sounds like a good opportunity for improvement!
 

James

Involved In Discussions
#4
I'm curious what the motivation is? Presumably a relevant authority has cleared your devices for distribution and your current situation is not considered nonconforming. (Not to endorse not doing things or that you will still be cleared in the future, just seriously curious.)

A couple of standards, like IEC 62304 (software) and ANSI 62366 (usability) have addressed the "legacy" aspect, enabling a path forward if those standards weren't followed originally. In essence, do a gap analysis then do a risk assessment on the gaps. As the risk indicates, either close the gap or provide rationale why unnecessary (based on risk).

Do note that 13485 has the concept of a medical device family and this is reflected in the 'files.'

If not considered nonconforming, sure sounds like a good opportunity for improvement!
Apologies - I misunderstand your question - motivation for which bit? I've given a general response.

For added context, we manufacture low risk accessories, mainly for wheelchairs to help patients with posture. We do very small volumes of custom made devices and will apply a Health Institution Exemption to our system. This will be the division's first implementation of ISO 13485. My motivation for combining and reducing documentation where possible is to have a system that is lean, meaningful, adds value for staff doing the work so it shouldn't be overly complex, and that meets regulatory requirements.

thanks

James
 

James

Involved In Discussions
#5
For #2, I once worked for a company that made medical film printers. All of the printers connected to various workstations; Some CT, Some X-RAY, DR/CR, Mammo, etc. Each modality had their own special tweaks to the final design. The printer had some items in common among all the models we sold. This was our base model. The modality tweak occurred just prior to shipping and was a final configurator design. Our auditor felt the base model had a complete DHF and for final config we would need a DMR for each modality and a DHR for how each printer went through final configuration.
Thanks Ed, that's a useful perspective. I think my application will go much further in that the base product will be much more basic and closer to raw components, and the customisation will give much more specificity of the actual device.

For example, we make postural support cushions for wheelchairs. The device file (and partly the design file?) will include the specifics of materials that can be used, safety information about components and combinations, evidence of tests, available literature to support why we do it and use what we use, all of the GSPR, etc). The actual custom made item design will be specified by a clinician (the size, materials used, clinical justifications for why we are making the custom device, etc).

I have been trying to think of different ways of satisfying Section 7 of 13485 to optimise the utility of our system. The design inputs will include national and regional service specifications, the MDR and design history.

Regards

James
 

yodon

Staff member
Super Moderator
#6
No apologies necessary; I wasn't clear.

So NOW you're going for 13485 certification. I presume you're looking at the pre-existing design to establish the foundation for going forward with new units which would be compliant to 13485? Sounds like the "family" organization that @Ed Panek mentions would be a good approach for you. I still say that a gap analysis is probably a good way to get your baseline set up.

Oh, and your goal of a lean, value-adding, meaningful, simple (not complex) system is spot on - it's what they're supposed to be! Kudos. :)
 
Thread starter Similar threads Forum Replies Date
A Design History File - Not ready to share the design drawings or Bill of Material US Food and Drug Administration (FDA) 2
R No design history file or device master record ISO 13485:2016 - Medical Device Quality Management Systems 5
R Suggestions for putting together a DHF (Design History File) ISO 13485:2016 - Medical Device Quality Management Systems 3
D Questions about the contents of a Design History File 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 3
T Design Changes - Updating the Design and Development File EU Medical Device Regulations 5
E Updating DHF (Design History File) to include Alternative Component 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 2
V Template / format for Device History File & Design Verification of transdermal patch 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 1
JoCam Ownership of Design History File EU Medical Device Regulations 6
K ISO 13485 and DHF (Design History File) requirements ISO 13485:2016 - Medical Device Quality Management Systems 9
M Design History File (DHF) for New Generation of Product 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 3
N 510k without DHF (Design History File) that we bought a 3 years ago US Food and Drug Administration (FDA) 4
A DHF (Design History File) for a Legacy Product (Class iii Medical Device) 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 6
B When To Share Your DHF (Design History File) With A Customer US Food and Drug Administration (FDA) 1
R Need help on defining scope for Design Verification File for Class III IVD 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 8
S Cost Targets as Design Inputs in your DHF (Design History File) US Food and Drug Administration (FDA) 7
C Should Research Findings be in the Design History File? 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 1
renenatasha Usage of web articles in DHF (Design History File) 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 10
A Medical Device DHF (Design History File) - One per Design Change? 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 17
R Dealing with Device/Design changes by a "Letter to File" vs. 60601 Retesting IEC 60601 - Medical Electrical Equipment Safety Standards Series 10
L Creating DHF (Design History File) for Medical Device Systems Design and Development of Products and Processes 8
O ISO Standards For Intramedullary Pin Design History File Other Medical Device Related Standards 2
K How to start a Design History File (DHF) for Medical devices Company 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 2
R Design History File DHF Practices and Contract Manufacturer 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 2
R FDA Requirements for a Design Technical File US Food and Drug Administration (FDA) 11
D Design History File (DHF) - Buy-For-Resell Products 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 7
A Design History File Maintenance - Who is responsible for the Design History File 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 5
M What are typical Roles & Responsibilities of DHF (Design History File) Librarian? US Food and Drug Administration (FDA) 6
H Paper based DHF (Design History File) updates for Software Updates 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 4
R Who should document the Design Review Meeting and Design History File? 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 8
Q DMR-Device Master Record vs DHF-Design History File vs DHR-Device History Record 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 50
C Remediating a Design History File (DHF) for an IVD developed prior to 1997 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 4
S Design History File (DHF) Maintenance Information wanted 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 6
O DHF (Design History File) Template Other US Medical Device Regulations 13
C How to establish a Design History file (DHF)? 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 15
J What are the differences between a design dossier and a regular technical file? EU Medical Device Regulations 1
J Technical File vs. Design Dossier - Class II and Class III Medical Devices ISO 13485:2016 - Medical Device Quality Management Systems 12
W Design History File (DHF) Template Example for Consideration. Design and Development of Products and Processes 12
S Which documents in the DHF (Design History File) should be controlled? ISO 13485:2016 - Medical Device Quality Management Systems 2
Q DHF (Design History File) on New Medical Device Product ISO 13485:2016 - Medical Device Quality Management Systems 9
M Design History File - Medical Device Quality Systems Manual Section 3, Design Control Design and Development of Products and Processes 1
Q PPT used as Design Review ISO 13485:2016 - Medical Device Quality Management Systems 3
D Design Verification Sample Size vs Repeats Statistical Analysis Tools, Techniques and SPC 9
A Design and development procedure for API Spec Q2 Oil and Gas Industry Standards and Regulations 2
D Design controls - Inputs, outputs, V&V, DHF, DMR ISO 13485:2016 - Medical Device Quality Management Systems 10
LostLouie Manufacturer divorced from Design process, is he justified in design process deficiencies? ISO 13485:2016 - Medical Device Quality Management Systems 8
R DFA & DFM - Examples for Design for assembly and design for manufacturability Lean in Manufacturing and Service Industries 2
D Using Laboratory Notebooks in R&D and Design and Development ISO 13485:2016 - Medical Device Quality Management Systems 3
D ISO 13485 - 7.3.6 Design and development verification - Do most folks create a separate SOP? ISO 13485:2016 - Medical Device Quality Management Systems 4
K Joint approval between OEM and Manufacturer on Design Documents ISO 13485:2016 - Medical Device Quality Management Systems 4
M API 4F/7K/8C Design Package Validation Oil and Gas Industry Standards and Regulations 2

Similar threads

Top Bottom