Posts Tagged ‘FDA requirements’

Systems Engineering In Medical Device Design – Preproduction, Part 3

Monday, February 18th, 2013
     We’ve been discussing the Preproduction aspect of the Development stage of our systems engineering approach to medical device design.  Last week we learned that once the medical devices produced during Preproduction are assembled, they’re subjected to rigorous testing, first in the lab, then in the real world.

     Once devices produced in Preproduction pass the test in a controlled laboratory environment, it’s time to place them into field testing.  The objective is to place Preproduction devices within actual working environments, such as healthcare facilities.  These facilities must be willing to cooperate with design engineers during testing on a number of items, including but not limited to evaluation of product performance and clarity of instructions.

     In order for this to happen, design engineers must coordinate their efforts with their company’s sales and marketing departments to locate, qualify, and enlist suitable facilities.  To qualify, a facility must be able and willing to put enough hours of use onto the test device to effectuate a thorough and complete analysis of its effectiveness.  Depending on FDA regulatory requirements and the complexity of the design, field testing could take as little as several months or as long as several years.

     During field testing valuable data is gathered to enable engineers to evaluate the performance of the Preproduction devices.  This data will then be measured up against stakeholder requirements.  What this process might entail in a dialysis machine, for example, is that test data is analyzed to make sure all operational parameters fall within the desired range.  Data would be derived from measurements of such things as the pressure of blood flowing pre- and post- introduction to the dialyzer.  Measurements are dutifully recorded by engineers and field personnel onto data sheets for later evaluation back at the manufacturer’s engineering office.  Persons contributing data vary widely, from healthcare facility end users and maintenance personnel, to the medical device dealer’s service technicians.

     End users also provide feedback to design engineers regarding the field test device’s functionality, effectiveness, reliability, and maintainability.  Feedback can include specific information about things like glitches in software, unusual noises, erratic operation, breakdowns, and even difficulties encountered during repairs.

     If any problems are discovered with the device during lab and field testing, revisions are made.  Design engineers and technical writers get back to the drawing board to rework things and find resolutions until all issues have been addressed.  Only then is the design presented to stakeholders for final approval.  If all goes well, manufacturing will now take over and place the device into full commercial production.

     We have now concluded our discussion on the Development stage of systems engineering as it relates to medical device design.  Next time we’ll move on to the Production stage where we’ll examine post-production concerns.


medical device field test data

Medical Device Design Controls – Output, Verification, Review, and Validation

Sunday, September 5th, 2010

     Recently my wife was on a quest to make the perfect pound cake, but before she put butter to flour she did her research.  What’s the best butter?  Best flour?  Eventually she came up with a recipe she felt would prove to be the Queen of all pound cakes.  After the recipe came reviews by her test panel, or family members, including myself.  Questions were asked, such as, When you first bite into a pound cake, do you want to be aware of vanilla or lemon?  It was only then that she would begin to combine ingredients for the final mouth watering product.  Very much this same procedure is used when coming up with a new medical device.

     Previously we’ve discussed FDA requirements for medical devices as they concern design controls with respect to design and development planning and design input procedures.  We’ll now focus on requirements for Design Output, Design Verification, and Design Review Procedures.

     Design Output and Design Verification Procedures go hand in hand to ensure that design output is properly documented, organized, reviewed, and evaluated in light of design input.  What this means is that medical device companies must scrutinize and evaluate what is going into the design process, then make a comparison to what is coming out.  The design is ultimately verified when all requirements for the medical device as previously set out have been met.

     “Design output” is just another name for work product after major phases of the design project are completed, such as when my wife determined which butter would produce the best pound cake.  Design output typically takes the form of specifications, notes, calculations, computer programs, mechanical drawings, electrical schematics, printed circuit board (PCB) layouts, bills of materials (BOM), mockups, prototypes, test data, and test reports.  These are then utilized by people outside engineering circles to manufacture components and assemble them into a final product.

     Design Review Procedures ensure that the design output is evaluated by others not directly involved in or responsible for the design work product, much as when family members served as a reviewing committee for my wife’s inquiries into taste preferences in pound cake.  Sometimes she’d even ask a friend or neighbor to put their two cents in, and companies, too, will at times go outside and hire consultants to perform this function.  By so doing, unbiased opinions are sought out, in the hopes that this fresh set of eyes will be more likely to spot errors, omissions, and misinterpretations that could prove disastrous if put into play.  Design reviews are typically conducted after each major phase of a design project is complete.

     Just as a recipe that looks good on paper may not necessarily taste good, a device design will often seem to work perfectly on paper, then prove otherwise when its manufacture begins or it’s used in the field.  Ideally bugs are worked out before the product hits production and, later, the marketplace.  Design Validation Procedures make use of prototypes for testing and careful evaluation under simulated or actual use conditions.  Does the design safely meet requirements for intended use?  Does it conform with industry standards?  If not, there’ll be a lot of wasted “dough” going into the trash — pun intended!

     Next time we’ll explore FDA requirements for Design Transfer and Design Changes.  We’ll also talk about procedures for Design History Files.