Imagine developing a medical device or drug that could be claimed to work without any evidence….

Systems engineering should be used more often in medical device product development. This may be a strong statement, but it can be transformative for device development through decreased development costs, streamlining of interactions with the FDA, and reduced time-to-market. We would like to address this through a series of articles on systems engineering role in Medical Device Product Development of which this is the first.

There are many inputs to consider when designing a new medical device product: user needs, regulatory requirements, and internal and external customer requirements, to name a few. Finding harmony and documenting everything is not a simple paperwork exercise. This can be overwhelming to even the most seasoned medical device professional. How do you make sure the user needs are linked to actionable requirements, and ensure that all requirements have been addressed?

Often in medical device product development, functions exist in silos. Risk, requirements, and test management functions often exist separately, on their own - different systems, different teams, different objectives. Yet, the data related to these functions are both continuously changing and highly dependent on one another. Some type of process is needed to (1) manage the effect of changes across all three systems and (2) provide evidence of a process for notified bodies if and when needed.

SEPARATE RISK MANAGEMENT AND FMEA FOR BETTER MEDICAL DEVICE DEVELOPMENT. The below is an excerpt of the article originally published on MDDI. FMEA (Failure Mode and Effects Analysis) is utilized to identify potential failure modes in the design or manufacturing of a product. But risks associated with medical devices are not created by failures alone. A product may never fail, but there are still potentially many other risks.

Commonly issued after an FDA inspection, a Form 483 informs a company of observations requiring corrective actions. The Form 483 is often referred to as “Inspectional Observations” as it is a list of conditions or practices that indicate a potential violation of FDA requirements. The form is compiled in order of importance and is considered a snapshot of potential issues; it should not be considered all-encompassing.

There are many immediate short-term benefits a compliance software tool can provide to your life science organization: improved documentation, streamlined day-to-day compliance activities, project data unification, and other advantages. But there are many important long-term benefits that may get overlooked. When deciding to adopt these software tools, it’s important to understand how they can promote growth and innovation at your company.

The market for digital health products is rapidly expanding. Reports from Global Market Insights, Inc. project the value of this marketplace to expand to $504.4 billion by 2025. Many life science organizations have seen the opportunity these technologies can provide and are jumping at it. However, this boom in the industry has not gone unnoticed; in recent years, FDA has been rapidly transforming their policies and organization to handle the necessary regulatory work these digital health products bring to the table.

Your product’s intended patients have a wealth of experience and information that can be valuable to your development process. Whether it’s the day-to-day realities of the condition, the symptoms they feel need the most attention, or things they might be missing in their current treatment regimens, this data cannot be elicited from doctors and engineers alone.