How to record Regulations and Standards as Design Inputs?

#1
Hello, could anyone please share strategies for how to establish "design inputs" for a medical device, to satisfy any requirements from government regulations and various international standards?

To develop a Class 2 device for the US market, it must conform to FDA regulatory requirements and FDA-recognized consensus standards for things like biocompatibility, sterilization, etc. It's my understanding that when I'm establishing a document to translate "user needs" into "design inputs", it must include requirements from regulations and standards. So far I can only think of two possible options:
  1. As high-level design inputs, I just write that the device must conform to FDA regulations and each individual standard. Then as a verification method, I write up a lot of long checklists. each stating how my device conforms to FDA regulations and each individual standard. Each checklist would basically be a long list of requirements from the regulation/standard, and would be used to "verify" only a single "design input".
  2. I painstakingly list every FDA requirement and every standard requirement as individual design inputs. This means I would have an extremely long list of specific design inputs! (It would be a design input for every requirement from the FDA regulations and all the standards). Then as a verification method, I would still have a lot of long checklists but now every item on the checklist was recorded a design input. So each checklist would "verify" a lot of "design inputs" simultaneously.
I would much appreciate any help you could please give. I would be grateful for visual examples or explanations. Often I find that guidance documents don't actually help with this. Right now, I'm using an excel table to trace user needs, design inputs, etc. Thank you very much, this is the first time I've posted on this forum.
 
Elsmar Forum Sponsor

Jen Kirley

Quality and Auditing Expert
Staff member
Admin
#2
Welcome ga2qa23!

Can you identify them as Essential Characteristics? EC1, EC2, etc. on drawings with a corresponding Note that spells out the requirement for each: "Must comply with RoHS / UL 94" etc.

In specification documents for parts designed by suppliers, a table can spell out each requirement, and assign them numbers which can then be correspondingly referred to in the text as EC1, EC2 etc.

Does this help?
 
#3
Welcome ga2qa23!

Can you identify them as Essential Characteristics? EC1, EC2, etc. on drawings with a corresponding Note that spells out the requirement for each: "Must comply with RoHS / UL 94" etc.

In specification documents for parts designed by suppliers, a table can spell out each requirement, and assign them numbers which can then be correspondingly referred to in the text as EC1, EC2 etc.

Does this help?
Thank you for replying. Yes, I can identify them as Essential Characteristics (but I haven't heard of that term before) and I can put them on drawings in the same manner (example: Must comply with IEC 60601-1). My apologies if I'm not understanding you correctly, I am new to project design.

So if I understand you correctly, then...
  1. I could have my official user needs document state that a "design input" is just "must comply with IEC 60601-1" (it doesn't need to be any more detailed) and then my "design output" would just be a component drawing that complies with IEC 60601-1?
  2. By that logic, would the "verification" be a checklist (or specification document) that clearly states how the component complies with IEC 60601-1?
  3. Then would the "validation" be a third-party vendor that actually certifies my medical device to IEC 60601-1?
I have some draft hardware designs but I would like to outsource the official final hardware design and component manufacturing to a subcontractor. Then I add my software to the hardware to "manufacture" the finished device. It would make everything much easier if I could just give the subcontractor a high-level "design input" requirement that the hardware must "comply with IEC 60601-1".
 

Gisly

Starting to get Involved
#4
Hi
Without going into too much detail I would recommend to not go in the direction suggested above. The 60601-1 is a broad standard so putting it into the drawing would be ambiguous, hard to maintain, and not make much sense for others than QA/RA (I here assume drawing = technical drawing). You would also have to maintain the correct version(s) of the 60601-1 in ALL drawings rather than as top item(s) in your req. document.

Where I come from we used the external IEC 60601 test as our formal verification reference.
 

Jen Kirley

Quality and Auditing Expert
Staff member
Admin
#5
I agree with Gisly.

I suggest identifying a feature bearing the requirement with EC1/EC2 etc. on the drawing, then describe in the Notes: "EC1: must comply with 60601-1"

In this way you can avoid having to go in and revise all these drawings/specifications if 60601-1 were to be revised. Of course all relevant personnel would need access to the applicable version.

I would also avoid identifying the revision number of the technical specification. I have seen more drawings than I can count which cite the old version ASME Y14.5:2009 or even ASME Y14.5M:1994. This is likely not the best example, as an organization can voluntarily use 2009 instead of updating to 2018, but I hope my point is made.
 

Ed Panek

QA RA Small Med Dev Company
Staff member
Super Moderator
#6
In our trace matrix, we provide evidence on inputs and outputs. For harmonized standards, we call out individual requirements here. The FDA also accepts "bench" testing of other requirements specific to your product. For bench testing, make sure it's easily explained and that you do the bench testing identical during all of the development. FDA may have questions if you change your testing.
 
#7
Thank you to everyone for replying. However, I am still confused. It seems like despite every medical device manufacturer having to adhere to the same standards, there is no typical method for recording the requirements of standards as "design inputs". This is very strange to me because the FDA audits device manufacturers but does not provide specific guidance on the subject. I even reviewed FDA QSIT and nothing there.

Each standard has many many many individual requirements. Would your trace matrix thus have a "design input" for every single section of every single standard?
  • For example, IEC 60601-1 has specific requirements on leakage current which become my "design input", then the "design output" would be a technical drawing and the "verification" would be a leakage current test.
  • But the standard also has really general requirements like Section 8.10.1 "Fixing of components" and Section 8.10.2 "Fixing of wiring". I can't imagine what a "design output" would be for these.
  • And the standard also has a requirement in Section 4.2 "Risk management..." that states you must have a risk management process that complies with ISO 14971. Does that have to be a "design input" too? Would my "design output" just be my own risk management file? What would the "verification" even be?

Another thing that's unclear is while you're writing these "design inputs" in your trace matrix, would the "design input" be written for the whole device or just for the applicable component? For example, the "design input" could either state that "device shall prevent leakage currents" or you could instead write both "component X shall prevent leakage current" and "component Y shall prevent leakage current".

Again I apologize for not understanding. My overall goal is to outsource the final hardware design and manufacturing to a subcontractor. But even then, it seems like, I must still review every single standard first, and write out every single requirement of every standard for every single hardware component as individual "design inputs" in my own trace matrix.
 

Ed Panek

QA RA Small Med Dev Company
Staff member
Super Moderator
#8
Our trace Design input has two levels.

First is the User Needs/Requirements

For that, it might be named (user Requirement) UR001 - User must not experience electrical shocks

A (Design Input) DI001 might be listed right below that referencing a test from 60601 we plan to document
DI002 might be a bench test for leakage current might be listed below that.

As the product develops we may see users want to use our device outside when it rains. A new DI under this UR would list an IP rating we wanted to provide and how we tested we meet it.

For risk controls please read ISO 14971 and if necessary 24971 on how to document this in your QMS. For us it means a risk management file for our device and I conduct annual risk reviews for our device for each design change and at least once a year based on MAUDE FDA data and complaint data to assure our risk controls are adequate. You should have a risk management plan as an output for your device (how will you control risks?)

As with any process, I suggest you engage an outside consultant to audit your QMS with your requirements to see if you meet them. Its the best way to demonstrate conformance.
 
Last edited:
#9
Our trace Design input has two levels.

First is the User Needs/Requirements

For that, it might be named (user Requirement) UR001 - User must not experience electrical shocks

A (Design Input) DI001 might be listed right below that referencing a test from 60601 we plan to document
DI002 might be a bench test for leakage current might be listed below that.
My understanding that a medical device must conform to certain FDA regulations and FDA-recognized standards. However, it seems like with your approach, you are not attempting to list FDA regulations nor standards as your base level "user needs". Instead, you are picking generic "user needs" and you are then folding in the requirements of regulations/standards as "design inputs" where applicable.

However, this brings up an issue. How are you sure that you covered all the requirements from each regulation/standard? For example, for IEC 60601-1, do your employees just know all the individual requirements ahead-of-time and you just write them as individual "design inputs"?

As with any process, I suggest you engage an outside consultant to audit your QMS with your requirements to see if you meet them. Its the best way to demonstrate conformance.
Thank you, I am also in the process of purchasing QMS/SOP templates to create my QMS. I also plan to hire outside consultants to audit me in the future.
 
#10
Hi all, I wanted to thank everyone for replying but I feel like there's still no actual answer. I'm going to hire my own Quality/Regulatory person in the future but at this point we're still in the early EARLY feasibility phase with plenty of pivoting set ahead of us. I want to guarantee that I'm not trying to push something out before it's ready. I just wanted to understand how you typically tackle things like:
  • Electrical safety testing per IEC 60601-1
  • EMC testing per IEC 60601-1-2
  • Mechanical strength testing per IEC 60601-1
  • Labeling requirements per IEC 60601-1
  • Labeling requirements per FDA regulations
  • Biocompatibility standard
  • Sterilization standards (Autoclave vs. Gamma vs. Ethylene Oxide)
I understand that there can be multi-level requirements, with a high-level "design input" and then lower-level "technical requirements" & "software requirements". Would you capture any of these regulatory/standard requirements as a high-level "design input"? Or would some/all of them instead only be covered in your low-level "technical requirements"?

To me, I feel like all these regulatory/standard requirements can be high-level "design inputs" because at the end of the day, your overall "finished" medical device product must be electrically safe, biocompatible, etc. Then I break down each high level "design input" (e.g. System shall be biocompatible) into low-level "technical requirements" (e.g. Component A shall be made of passivated stainless steel).

I'm not asking anyone to do the work for me, I just need an understanding of what the industry expectations are. There's zero government guidance on this. I don't want to attempt to do something and then have someone else come in later and think that everything is poorly done. Thank you.
 
Thread starter Similar threads Forum Replies Date
R Record Retention Requirements per FDA 820 Regulations Records and Data - Quality, Legal and Other Evidence 10
B Acquired Medical Device Product Line - Documentation Requirements for Device Master Record ISO 13485:2016 - Medical Device Quality Management Systems 7
D Device Master Record (DMR) checklist ISO 13485:2016 - Medical Device Quality Management Systems 1
M Record Retention Verbiage Needed for "Lifetime" Retention EU Medical Device Regulations 6
M Sample record for verification performed by importers before placing a device on the market EU Medical Device Regulations 0
S IVD Device History Record ISO 13485:2016 - Medical Device Quality Management Systems 3
E Record Retention - Raw Material (Steel Certs) Records and Data - Quality, Legal and Other Evidence 3
E Procedure ( SOP) for Device Master Record ( DMR ) and for Device History Record (DHR)? 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 2
J Records Control - Does each individual record need to be numbered? Records and Data - Quality, Legal and Other Evidence 2
S Records - Do's and don't' of record entries (FDA - 21 CFR 820) Records and Data - Quality, Legal and Other Evidence 13
N Importer of record - Europe EU Medical Device Regulations 0
M Question for Auditors - "Off the Record" Conversation? General Auditing Discussions 14
C GUDID Device record history Medical Device and FDA Regulations and Standards News 2
D IATF16949 7.5.3.2.1 Record Retention - Our Product or Customer Product? Elsmar Cove Forum Suggestions, Complaints, Problems and Bug Reports 1
S How do you record your Nonconforming product? Batch production of staged processes Nonconformance and Corrective Action 2
I Can a document (form) approval record be separate? ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 6
M Defining and Documenting Record Retention CE Marking (Conformité Européene) / CB Scheme 5
Q Forms Master List versus Record Matrix ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 3
B Record Management - Does the QMS need to control templates of records? Records and Data - Quality, Legal and Other Evidence 17
S Service record requirements for Non-Serviceable Medical Devices CE Marking (Conformité Européene) / CB Scheme 1
R No design history file or device master record ISO 13485:2016 - Medical Device Quality Management Systems 5
Sam Lazzara Medical Device File (MDF per 13485:2016 4.2.3) versus FDA Device Master Record (DMR) ISO 13485:2016 - Medical Device Quality Management Systems 3
I What kind of information needs to be in a calibration record? General Measurement Device and Calibration Topics 25
E ISO 9001:2015 - Record requirements for out of calibration tool ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 28
N ISO 13485 Quality Record Retention Period ISO 13485:2016 - Medical Device Quality Management Systems 4
M Loss of a Quality Record - FDA Inspection Records and Data - Quality, Legal and Other Evidence 4
B MDSAP 8.2.6 CH6 task 17 ANVISA 16/2013 3.2.1 - Label History in Device history record Other Medical Device Regulations World-Wide 3
I Training records and levels - When does training NOT need a record? ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 13
Gman2 Quality Record Retention (Internal Audits, CA's) ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 9
R Are DMR (device master record) and DHR (device history record) inspected by FDA or audited by an NB ISO 13485:2016 - Medical Device Quality Management Systems 9
N When to record values if a spec for a mfg process is set Manufacturing and Related Processes 3
S Mobile app data privacy - Length of record retention in a software app Medical Information Technology, Medical Software and Health Informatics 1
S Foreign Manufacturer and DMR - Who keeps the DMR (Device Master Record)? ISO 13485:2016 - Medical Device Quality Management Systems 2
M Medical Device News Health Canada - Scientific Advisory Panel on Software as a Medical Device (SAP-SaMD) - Record of Proceedings – January 26, 2018 Canada Medical Device Regulations 0
J Training Record Template and tracking Document Control Systems, Procedures, Forms and Templates 1
S DMR (Device Master Record) for Medical Device Software IEC 62304 - Medical Device Software Life Cycle Processes 3
D Design Outputs vs DMR (Design Master Record) 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 2
H In-house device calibration record - Actual values obtained required? General Measurement Device and Calibration Topics 9
M Is referenced content sufficient to meet record content requirements? 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 4
R Reissuing pages of a record 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 4
S Record Retention - How long must a company keep the following records? Records and Data - Quality, Legal and Other Evidence 17
M Batch record supersedes all other instructions 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 2
K Our local sterilizer is closing - Record Retention Question 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 1
qualprod An uncontrolled record is it a non-conformance? ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 12
B Quality Records - Should any record be signed? ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 3
C Record retention for defunct customers? ISO 13485:2016 - Medical Device Quality Management Systems 11
I Engineering Drawing = Record or Document? Document Control Systems, Procedures, Forms and Templates 8
A Requirement to Identify Changes to record in ISO 13485 : 2016 ISO 13485:2016 - Medical Device Quality Management Systems 4
T Record Retention Requirements - IATF 16949 Clause 7.5.3.2.1 Records and Data - Quality, Legal and Other Evidence 15
Q Modifying an old printed record? ISO 9001 ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 10

Similar threads

Top Bottom