How to record Regulations and Standards as Design Inputs?

[ga2qa23]

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.

 

[Jen Kirley]

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?

 

[ga2qa23]

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]

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]

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]

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.

 

[ga2qa23]

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]

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.

 

[ga2qa23]

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.

 

[ga2qa23]

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.