It's worth the time and effort to develop sound product requirements and consider risk management and usability as integral components of device design. 

George Stone

As a contract design engineering company, we often encounter medical device clients in a rush to get their revolutionary new medical device out to the market place and at minimal cost. This is especially true with the flurry of medical devices accessorized by a mobile application, or with mobile apps as devices themselves. But in the words of Benjamin Franklin, "The bitterness of poor quality remains long after the sweetness of low price is forgotten." And if he were still alive today, he might add "overlooking risk management and usability will short change your design in the end."

In the process of planning, it's tempting, and oftentimes default practice, to focus solely on industrial design, engineering development (architecture, detailed design, prototype builds), and test, including bench testing and design verification. While these elements warrant careful consideration in budget estimates and scheduling, what's equally important and typically slighted is the focus on developing sound product requirements and considering risk management and usability as integral components of design.

It's not enough to point out to your client organization the standards and regulations that apply to their product--the product development company must insinuate the meat of those rules into the design process and be able to convincingly sell that effort.

First, how do you convince the applicable stakeholders to invest time, labor, and budget into a useful set of product requirements, a risk analysis that points out hidden safety issues, and a task flow analysis that ensures your device can be used safely and as intended? These are not tangibles that a product owner can look at and touch, and these deliverables don't traditionally match up with expected product development milestones.

Second, how do you determine the level of effort and fidelity required for these undervalued deliverables? This is an important consideration because that effort and fidelity needs to be scalable, flexible, and tailored for each product. Too many organizations are either devoid of a process that considers these elements, or, conversely, are tied to a process, of their own doing, that constrains them to burdensome and unnecessary work.

Let's address the first question of convincing stakeholders to see the benefit of these underappreciated tasks:

Robust Product Requirements

Product requirements essentially define the inputs that completely inform the design, like a contract between the product development team and the product owners. Product requirements are a succinct way to capture, systematically, what will be designed and built.  Drawings of components and architecture diagrams aren't enough--they don't capture interfaces between components and software; they don't capture function or performance.

It's very expensive to learn a key feature of your device is missing once you've committed a design to a manufacturer for tooling. Product requirements tell you what the end-product should look like and what it's expected to do once those requirements have been tested and proven. You can better sell your product if you can talk about what it will do and how it will perform before you get to the end of the design and build phase. 

The process of defining requirements should include participation not only from the product owner, but also from the human factors, industrial design, and engineering teams. This collaborative effort ensures that everyone involved in the product's development has buy-in on the product requirements as a deliverable, and ultimately with the finished product.

FDA, as well as EU notified bodies, Health Canada, China FDA, TGA Australia, and others, all require directly, or sanction via adoption of process standards (13485, 62304, 62366, 14971, etc.), that you define product requirements that are complete, unambiguous, appropriate and address the intended use of the device.

Effective Risk Analysis

The most obvious benefit of taking the time to determine both the potential hazards that accompany the use of a medical device and the associated risks with each hazard is the controls that are put in place to prevent or mitigate harm to the user.

It's very costly to the product owner if their device is in the field and causes harm to the user, resulting in a recall. Liability cases resulting from medical device recalls are abundant enough and well documented such that they should give product device owners ample reason to have a suitable risk process in place.

You haven't identified product requirements completely if you haven't identified risks and their associated controls, which means the product design is incomplete without them.

As with product requirements, a risk analysis should include participation from all parties impacting a product's development, ensuring collaboration and buy-in of all product design elements that become risk controls.

National and international regulatory bodies require directly, or sanction via adoption of process and safety standards, that you define a process for risk management in product realization, keep records of risk management activities, and define the applicable outputs of risk management.

Practical Human Factors & Usability

A user-centered approach to product development ensures the product is safe, effective, and easy to use. Why invest massive amounts of money on design and build of a product if it doesn't meet the user's needs or could harm the user during use?

Defining possible use scenarios, task flows, and intended users of the product will help guide design decisions throughout the product development process, and help the product owner refine their marketing approach to maximize user adoption.

Some risks in the use of the product are uniquely tied to user perceptions and actions while using the product and would otherwise not be identified during a typical design risk analysis. Identifying these use risks is a primary output of use error analysis and user studies conducted at each of the product's key development stages.

National and international regulatory bodies require directly, or sanction via adoption of process and safety standards, that you define a process for the application of usability in medical devices. FDA guidance further advises that "HFE/UE considerations and approaches should be incorporated into device design, development and risk management processes."[1]

Now that we have reviewed the compelling reasons that a sensible approach to medical device product development will always include considerations for a robust set of product requirements, an effective product risk assessment, and a plan for usability that is practical and value-added let's address the second question and examine scaling those efforts based on risk and product complexity.

Previously, we looked at methods and reasons to justify the time, effort and resources needed for the undervalued and overlooked outputs of product development including product requirements, product risk analysis, and applicable human factors and usability activities. Now we will look at ways to keep those activities lean, yet add maximum value, by scaling and tailoring the level of effort and resolution based on a couple of key factors.

Regarding the level of effort and fidelity applied to generating product requirements, a risk analysis, and appropriate usability output, let's look at ISO 13485, clause 4.1.2--"The organization shall apply a risk-based approach to the control of the appropriate processes needed for the quality management system." What is a "risk based approach"? Throughout ISO 13485 the emphasis is on efforts that are proportionate to the risk associated with the use of the device. 

If the product development team is charged with designing an FDA Class I otoscope (an instrument for looking in the ear), FDA requirements are minimal and only require that the product owner registers their establishment and list their product's classification name. Typically, a company with an adaptable and robust quality process in place will have evidence of their device's lower risk in the form of a short, concise set of product requirements and a system risk analysis. For a device with no identified use-related risks, usability focuses more on ease of use and user satisfaction. In this example, the fidelity of the product requirements, risk analysis and usability documentation becomes far less than for a higher risk Class II device, or Class III device.

Scalable Product Requirements

Product requirements come in all forms and manifestations, some more useful and relevant than others.  An important thing to consider is ensuring that your product requirements add value. They should concisely define the specifications and constraints of your product's design, function, and performance.

Don't reinvent the wheel if someone has already done the work. If you're working with a client who has spent weeks or months formulating a comprehensive set of marketing requirements or customer requirements (an MRD or CRD), then the efficient and expeditious next step is to review that document and determine what can be leveraged for the product requirements specification (PRS). While ideally the CRD will address customer needs and intended uses, the PRS should address system level design input requirements. Frequently, though, much of that design input information will end up in the client's MRD or CRD.  Not a problem--review, clarify, transform, and migrate into a PRS.

For a Class I device and many low-risk Class II devices, a PRS need not be a labor-intensive tome. Even some rather simple and elegant Class III device designs can be summed up with a compact and concise set of product requirements. This is not to suggest skipping important risk and technical analysis, but to consider the risk and complexity of the product and adjust the scope of your PRS accordingly.

Product requirements should leave out implementation details. This can't be overstated because over-specification is prevalent in many organizations; whether by constraining process, outdated templates, misunderstood standards and guidelines (or unread standards and guidelines), or habit.

As an illustration, how do the following two example requirements differ?

PRS 1: The device shall be able to store treatment data for a period of 3 days (72 hours) before it is erased or overwritten.

PRS 2: The device software shall write treatment data to non-volatile flash EEPROM and shall perform periodic circular buffer overflow checks to ensure older data in flash storage is not overwritten for a minimum of 72 hours.

Essentially, they're defining the same thing but PRS 2 is providing specific implementation details that can also be practically accomplished in other ways.  The downside of PRS 2 is that you must now verify three separate specifications --that you're writing to flash EEPROM, that it is non-volatile, and that the software performs periodic overflow checks of a circular buffer. While a code review may be the only way to verify everything that is captured in PRS 2, you can use typical black-box test methods to verify the more succinctly stated requirement in PRS 1--that the treatment data is persistent for a minimum of 3 days.

Although there are always exceptions, in general, keep product requirements lean, concise and free of implementation--state what, not how.

Scalable Risk Management

As with product requirements, risk management activities and deliverables can run the gamut from non-existent to cumbersome and unwieldy. To strike the appropriate balance it's important to understand the classification of your device in the eyes of the regulatory body (FDA, NB's, etc.) and what the target development milestone is for the product that's being designed (for FDA submission, clinical studies, trade show, investor funding). Device classification and target milestones affect the fidelity of your risk management deliverables and activities.

Let's look at device classification as defined by FDA based on device risk, and an overview of how one might scale risk activities and deliverables depending on risk and complexity of the medical device (complex in terms of number of subsystems and/or critical components and relative impact on system or subsystems)--Figure A. The "x" indicates that the deliverable may be appropriate depending on complexity and number of subsystems.

Figure A: Risk-related deliverable as justified by device classification, the level of risk, and level of complexity.

When evaluating the appropriate deliverables take a good look at the value each of those deliverables adds to the overall risk analysis. If you've covered all known hazards and failure modes at a major component level in a system risk analysis, then why retrace those steps in a design failure modes and effects analysis (FMEA)? Note that if you are working under a ISO 62304-compliant system, every medical device that has software controls must include evidence that a process was followed to determine the risks arising from the operation of each software item in the software application.[2] This is typically manifested in a software risk analysis.

Design FMEAs and FTAs are valuable tools that serve an important role in the risk management process, when appropriate. As shown in the above table, the risk and complexity should tell you if there's a need to focus on a subcomponent bottom-up or top-down analysis of failure modes and faults.

Conversely, just because your device may be classified as Class I or Class I Exempt does not eliminate the need for a risk analysis. Oftentimes a product owner may be tasked with providing evidence that their device falls under that classification.  This is an important consideration because with the advent of IoT and mobile applications, the financial inducement to add more capabilities and features to existing traditional predicate devices will be dampened when that newer product gets bumped into a higher risk classification.

Focusing on risk management is important, but stay lean and relevant by scaling risk activities to match the device.

Scalable Human Factors

Product risk should also determine the level of fidelity applied to the human factors (usability) activities that inform product design. First of all, it must be accepted that Usability is required for an FDA 510(k) submission and for a CE Mark. This is a relatively recent change in the regulatory big picture, with the emphasis on user safety, but has been an important element of consumer product marketing for decades.

Determining how to build your medical device to minimize direct or indirect user harm should be a byproduct of the same risk assessment done for scaling the product requirements and risk management activities. The lower the risk of the device and/or the simpler the user interface, the less the fidelity and volume of the usability deliverables. 

There are other important factors to consider when determining how to allocate the appropriate scheduling and resources to usability activities. Is it a new product, a redesign, or a version update? Has extensive user research already been completed? Are there similar competitive products on the market? Does the product owner have an existing understanding of the users, uses and use environments for the device?

Ultimately, to complete successful and appropriate user studies, the Usability Engineer needs to know applicable user groups, use scenarios and use environments, the specific user tasks with the device, and the potential errors caused by user interaction with the device. Additionally, the product owner wants to be assured that the user will actually use the device, and will feel compelled to use it over a competitor's brand.

If the medical device has a simple user interface (e.g., a power-on button) and is Class I or low-risk Class II, the use risk analysis may demonstrate that there are no identified critical tasks[3] associated with the operation of the device. Based on this evaluation, a manufacturer could provide a rationale for not needing to conduct a Formative or Summative evaluation of the device from a regulatory perspective. However, a user study might still be included in the development process to maximize ease of use and user satisfaction for purposes of elevating the product above a competitor's.

Conversely, there are more and more devices with increased complexity entering the market--devices that are networked to other devices, to a physical central server, or to the cloud, as well as devices that are partnered with a mobile application that either controls a medical device or gives feedback from the device. The device classification and UI complexity should then steer the product owner towards the appropriate allocation of usability resources and scheduling into the development process, starting from the initial planning phase. Activities could include user research, several formative evaluations and a summative evaluation (user validation study) on the final product. 

Human factors has always been an important element of a product's look and feel, but with the sharper focus on usability as a primary control against use errors and, in some cases, serious injury, usability tasks and deliverables absolutely belong in the medical device product development process. As with product requirements and risk analysis, adjust the scale of the effort based on a well thought out risk assessment.

References

[1] Guidance for Industry and FDA Staff - Applying Human Factors and Usability Engineering to Medical Devices, Issued Feb 3, 2016.

[2] ANSI/AAMI/IEC 62304:2006, Medical device software - Software life cycle processes, Annex A.

[3] Reference the FDA Guidance, Applying Human Factors and Usability Engineering to Medical Devices for definition of Critical Task.

George Stone is product development director of quality engineering and usability engineering  at Stratos Product Development. Reach him at [email protected].

[Images courtesy of STRATOS PRODUCT DEVELOPMENT]