How to Record Informal Testing (Not Verification/Validation)

[ga2qa23]

Hello all, I'm a medical device startup and we're trying to understanding if we need to (or even should) record informal testing of our R&D prototypes. I have an electrical medical device with a circuit board inside and its own software. It's a simple Class 2 device on the low-risk side. We coded the software ourselves. We're not building anything in-house. I'm purchasing everything (custom-made circuit board, hardware, a plastic shell, etc.) from third-party contract manufacturers, and it'll be send to a separate vendor for final assembly, packaging, and sterilization.

Basically, we already did a bunch of quick/informal testing with low-fidelity mockups of our medical device. But now we're getting into high-fidelity (near-perfect) prototypes. We're starting to do the same testing as we'd do for our final verification/validation testing. We're basically testing the high-fidelity prototypes against our "Design Input" requirements, electrical safety tests (IEC 60601-1), electromagnetic tests (IEC 60601-1-2), and low-level software coding tests. It's not going to serve as our official verification/validation reports. This is just "preliminary" testing to make sure that our final parts will be able to pass the real verification/validation tests successfully the first time.

The big question is: do we need to record this informal "preliminary" testing? Should we even try?

There's really zero regulations/guidances about this subject. I understand that the intention of our Design History File (DHF) is to record the conception/evolution/approval of our medical device design, but technically we can just do all the work and only do a design review/approval of our final prototype version (used for final verification/validation testing). I also understand that FDA expects human factors / usability testing to be conducted as part of the medical device development, but that's mostly separate from everything I mentioned above.

I guess I could record the "preliminary" testing on some special kind of test report, but be clear that there's no real "acceptance criteria"???

And for low-level software testing, I guess I could also record the test results on informal test reports?

Or should I just do the "preliminary" testing, not write anything down formally nor informally, and just roll with it?

 

[Zero_yield]

Hello ga2qa23,

The term that gets thrown around at my workplace for this kind of activity is "skunk work" (which a Google search suggests came from Lockheed, but I digress). You often have to do a lot of tinkering before you even understand a concept well enough to design a good experiment.

I would only document these activities as much as is useful to the development process and good project management. If you're not even at the point where you have acceptance criteria, I would keep making iterations with only internal documentation until you get to your actual validation and verification testing.

Development of medical devices can be glacial at times. Take advantage of being able to move nimbly in this phase of development.

 

[ga2qa23]

Hello ga2qa23,
If you're not even at the point where you have acceptance criteria, I would keep making iterations with only internal documentation until you get to your actual validation and verification testing.

Thanks for your help! We already have acceptance criteria already. The requirements that we're testing against are very straightforward. We're also going to do some "preliminary" testing of our hardware with the vendor we selected to certify our future/final medical device against IEC 60601-1 and IEC 60601-1-2.

But what do you personally mean by "internal documentation"? Is that a document that's not technically version-controlled / approved by test personnel & Quality Assurance personnel? Like if we put a prototype in the oven to see if it still worked after being exposed to high temperatures, would you just write it down on an 'uncontrolled' Word file and keep it outside of the Design History File (DHF)?

Could you please give a general example from your experience?

 

[William55401]

Your QMS design control procedures are important. When does Design Control begin for this project? Mature organizations establish a bright line between research / skunk works and put in formal controls (read as documentation with approvals and all the fun the comes with it). This is your company. Establish compliant procedures that make sense for how you want to operate. To me, declaring when the project is in scope of the QMS procedures is a key step,

 

[ga2qa23]

When does Design Control begin for this project?

The Design Controls are already in-place. We've written our product requirements (Design Inputs), we've done supplier evaluations, and we've done circuit board diagrams / hardware diagrams / software source code. But they're not the "final" versions yet yet. We already had prototypes manufactured with them but they're still not considered ready for final verification/validation testing. They're not the actual "Design Outputs" just yet. We wanted to conduct a bunch of "preliminary" testing with our high-fidelity prototypes, so we know it's good before we can make final changes to become the "finished" design.

In the future, we "finish" our drawings/software. We would arrive at our "final" versions for each "Design Output" that can be used for the final verification/validation testing.

 

[indubioush]

You should absolutely record the preliminary testing. This is known as feasibility testing. The information gained from the feasibility testing may result in design changes. You should be capturing the justification for changes even in the early stages. I would document feasibility testing in your controlled laboratory notebooks. (I hope you have these.)

 

[ga2qa23]

I would document feasibility testing in your controlled laboratory notebooks. (I hope you have these.)

We don't have paper binders of "controlled laboratory notebooks" but we use Microsoft Word and we basically have a formal template for a "Verification/Validation Test Plan" as well as the resulting "Verification/Validation Test Report". So we have that. Isn't that satisfactory for an FDA-regulated medical device?

 

[indubioush]

It is pretty much industry standard to have laboratory notebooks. They can be paper or electronic, but they need to be controlled and the content protected. The purpose is to document organizational knowledge for the future benefit of the company. Have you ever wanted to go back and figure out the justifications for design decisions, and then you realize this information was never documented? I have experienced that, and it is not fun.

 

[ga2qa23]

It is pretty much industry standard to have laboratory notebooks. They can be paper or electronic, but they need to be controlled and the content protected.

I would greatly appreciate if you could help me understand: so it's not technically required then right? My team has a bunch of uncontrolled Microsoft Word files being used for that purpose. But in my understanding, it's not actually required to have controlled laboratory notebooks (paper or electronic) in order to get FDA 510(k) approval for our medical device.

 

[indubioush]

https://www.fda.gov/media/116573/download
Download the guidance and read page 44.