actively harvesting user complaints is a basic defense against unintended harm and product recalls.
a manufacturer's obligation for product safety extends across the whole lifecycle--from concept to salvage and disposal. this concept holds true regardless of the industry.
how can timely recognition of product safety issues be achieved and successfully managed? the process is called risk management and is applied across the complete product lifecycle. the principle is enshrined in many well-recognized industry standards (such as, for medical devices, iso 9001, iso 13485, and iso 14971) and is an engineering best practice. correct application of lifecycle risk management is your primary tool for minimizing unintended harm, reducing product recalls, limiting product liability, and protecting shareholders.
product risk management ? financial risk management
the general approach to risk management is outlined in figure 1. risk is future uncertainty of the deviation from an expected outcome. in product risk management, we are only concerned with undesirable (unsafe) deviations. risk is generally quantified as some combination of the severity of harm of the identified hazard and the frequency of occurrence of that identified hazard.1
nearly every senior executive understands financial risk management: "the identification, analysis, assessment, control, and avoidance, minimization, or elimination of unacceptable risks. an organization may use risk assumption, risk avoidance, risk retention, risk transfer, or any other strategy (or combination of strategies) in proper management of future events."2
|figure 1 shows the risk management process comprised of three stages: identification, mitigation, and assessment.|
but the strategies for financial risk management do not map well to product risk management; risk avoidance and risk transfer (from manufacturer to customer)3 ultimately result in unintended risk assumption and risk retention by the product manufacturer.
furthermore, from a sales and marketing perspective (the background of many senior corporate leaders), if there is no consumables "tail" once the product is sold and delivered, there is strong motivation to shift focus to the sale of the next product, rather than focusing on managing risk for product already sold. this makes eminently good sense, but only from a myopic financial perspective. sales and marketing move product; they are also the firm's principal interface for customer satisfaction and product safety information. they are essential for generating revenue, but also foundational for protecting that revenue by identifying complaints and supporting timely product lifecycle risk management. motivate them to sell product and to acquire satisfaction and safety data. this will reduce delays managing product risks and the rapid response will reduce unintended harm, product recalls, and product liability.
modern western expectations and industry standards demand that manufacturers eliminate essentially all product safety hazards. but eliminating all is, by definition, an impossible task. what is possible is eliminating risks from hazards that can be identified during premarket development and manufacturing. but, this must be followed by rigorously and systematically searching for previously unrecognized hazards in the postmarket phase, until the product is replaced or disposed. this is the well-established "cradle-to-grave" risk management engineering best practice identified in international consensus standards and required by many federal agencies.
identifying hazards requires an understanding of context. engineers set boundaries followed by conducting worst case analyses to inform their design validation testing. well-known examples of boundaries include operating ceiling and descent rate for aircraft, operating voltages and currents for electronic devices, and encapsulation for software components. unbounded problems are eschewed by engineers because they are not generally amenable to closed solutions and product realization. it is this reason that operationalization(operationalization means (a) defining what to measure, (b) defining how, and with what, to measure it, and (c) what measurement results in a pass or fail) of product requirements (design inputs) is crucial to engineering design. carefully established boundaries reduce the complexity of product design and risk management, thus decreasing time to market. not establishing clear boundaries results is arbitrary, and potentially undesirable, assumptions about the required boundaries.
for medical devices, one important set of boundaries is defined by the intended use, the intended users, and the intended use environments. this constrains the context, but does not fully eliminate risk complexity. there are two types of product use errors: system use errors and individual user
a well-known example of an individual user error is driving while intoxicated. a well-known example of a system use error is the set of mistakes operators make as a result of a poorly designed interface. hazards arise not only from how the device is designed, manufactured, and deployed, but also from how the device is used after it is sold. the manufacturer can reasonably expect intended use, novel use, misuse, and abuse of their device, as well as latent and drift errors from product development, manufacturing, and deployment processes.6 one cannot reasonably assume their product will be used exactly as they envision it. ignoring the full spectrum of potential use errors in product risk management is not adequate, reasonable, or technically correct. it only delays effective internal risk management and invites external risk management in the form of product recalls and expensive lawsuits.
elements of risk management
managing product risk involves both administrative and engineering activities. there are administrative standard operating procedures that must be managed and reports that must document the required activities. however, the documentation only serves as evidence of the occurrence of engineering activities.7 you can envision five discrete engineering activities for risk management:
- identification of a potential hazard.
- recognition or acceptance of an identified hazard as relevant for the specific product.
- evaluation of the risk.
- control of the risk.
- verification or validation of the risk control measure(s).
risk management is well-described in standard texts and various consensus standards; what is not well described is the correspondence between premarket and postmarket risk management activities (see table 1). understanding the correspondence and nomenclature differences is an important element in promoting complete and correct product lifecycle risk management. product risk management does not stop with the end of development and the beginning of sales; it stops when the product is no longer sold or used.
device lifecycle risk management
sentinel event recognition
health hazard evaluation
risk control application
corrective and preventive action (capa)
risk control verification/validation
table 1: pre- vs. post-market risk management activities
premarket risk management generally uses terminology familiar to engineers. first, you have to identify a potential hazard. then, you have to determine whether the hazard is affecting your specific product. once you have accepted that a hazard is relevant, you have to evaluate the risk by determining (or estimating) the probability of the hazard occurring and the severity of the harm that can result. if you deem that risk is acceptable, then you accept the risk or you can attempt to transfer the risk to your customer; if you decide the risk is not acceptable, then you are obligated to implement an effective risk control measure. there are four types of premarket risk control measures:
- transfer of control of the risk to the end-user through labeling or training.
- not selling the product.
once a candidate risk control has been agreed and implemented, you are obligated to verify or validate that the risk control (a) actually reduced the targeted risk and (b) did not create any new hazards; risk control verification or validation is always required, even if you chose to employ labeling or training.
postmarket risk management is no different, except in the terms used. complaint management (acquiring and analyzing complaints and other postmarket information) is foundational; it is your primary mechanism for getting information on potential previously unidentified hazards. a deficient complaint management system undermines all remaining postmarket risk management activities. sentinel events are the occurrence (or the possibility of occurrence, such as from a "near miss") of unexpected events involving death or serious injury not related to the natural course of an injury or illness.8 sentinel event recognition corresponds to premarket hazard recognition and is, by definition, an accepted hazard. postmarket evaluation of the risk associated with this hazard is often called a "health hazard evaluation" and is used to determine whether risk control (corrective and preventive action; capa) is warranted. if you decide capa is not warranted, you are deciding to accept the risk. but, if you decide that a capa risk control is warranted, then the options include (a) redesign, (b) guarding, (c) transfer of risk control to the end-user using labeling or training, or (d) removal of the device from the market. as in the premarket situation, you have to verify or validate that the risk control (a) actually reduced the targeted risk and (b) did not create any new hazards.
the "pa" in capa includes public reporting, which is itself a validated risk control. it is a regulatory obligation in the united states and it is the means of informing the public of death or serious injury associated with the use of your product. it is a critical element in postmarket risk management that expands the risk management process beyond the manufacturer to external agencies. this crucial risk control is defeated by manufacturer reporting noncompliance.
product lifecycle risk management is an engineering approach for increasing product safety and reducing unintentional harm, product recalls, and product liability. unlike financial risk management, product risk avoidance and risk transfer ultimately result in manufacturer risk assumption and risk retention. the terminology used for premarket risk management and postmarket risk management differ, but the underlying engineering activities are the same. not doing complete and correct premarket risk management undermines the viability of your product in the marketplace; not doing complete and correct postmarket risk management negates your premarket efforts and increases your firm's financial risk. fundamental to successful postmarket risk management is an effective and efficient complaint management system. motivate your primary connection to your customers--your sales personnel--both to sell your product and to quickly share with you user complaints and field observations. the commissions you pay will reduce unintended harms, reduce product recalls, protect your shareholders, and allow you to innovate new, improved products for everyone's benefit.
1. samaras, gm. use, misuse, and abuse of the device failure modes effects analysis. md+di online (and later print magazine august 2013).
2. http://www.businessdictionary.com/definition/risk-management.html accessed 5/10/15.
3. minimizing type ii errors (producer risk) at the expense of type i errors (consumer risk).
4. operationalization means (a) defining what to measure, (b) defining how, and with what, to measure it, and (c) what measurement results in a pass or fail.
5. samaras, gm. medical device mechatronics maturity. medical electronics design online (and later print magazine, january 2013).
6. samaras, gm. reducing latent errors, drift errors, and stakeholder dissonance. work: a journal of assessment, prevention, and rehabilitation, 41(s1):1948-1955 (2012).
7. samaras, gm. the use, misuse, and abuse of design controls. ieee eng med biol magazine 29(3):12-18, 2010.
8. http://www.jointcommission.org/sentinel_event_policy_and_procedures/defa... accessed 5/10/15. samaras manuscript "medical device lifecycle risk management."
g.m. samaras is a biomedical scientist and engineer in private practice (pueblo, co) since 1996. trained as an electrical engineer, he has doctorates in physiology and industrial engineering. he has worked at the fda as a reviewer and manager.