Product Development Insight

By and large, manufacturers developing medical devices for the United States, European Union (EU), and some Asian markets are now heavily invested in human factors engineering (HFE), rather than just coming up to speed. It took about 10 years to get there after FDA updated its quality system regulation in 1996, which calls for manufacturers to validate that new devices meet users' needs. Standards released by AAMI and IEC helped grease the skids by describing the kind of human factors programs that could help ensure safe and effective user interactions with devices.^1,2 But, Medical Device Use-Safety: Incorporating Human Factors Engineering into Risk Management, a guidance published by FDA on June 18, 2000, has been the real force behind the movement. In short, manufacturers have been driven to invest in HFE to help ensure that their medical devices receive FDA approval.

However, because FDA's guidance and the aforementioned standards encourage manufacturers to conduct human factors programs scaled appropriately to the associated device's complexity, manufacturers are left to judge: How much human factors engineering is enough? Most human factors specialists, many of whom have to justify funds spent on HFE, will tell you there are core HFE activities and some elective ones.

Seems sensible enough, does it not? Companies are encouraged to perform a prudent amount of HFE sufficient to meet their need. However, the idea of picking and choosing among optional HFE activities causes some folks heartburn—particularly those involved in regulatory affairs who want each design history file (DHF, also called usability engineering file) and application for market approval (e.g., 510(k)) to be complete. They are averse to FDA letters requesting more information about the user interface design process, and such complications can result in product launch delays and added expense. Ideally, companies would like to put checkmarks on a standard checklist of required HFE products. But there is no official checklist (see the sidebar “Behind the DHF”). So, let us examine the emerging standard for HFE and associated products that compose the DHF and support a 510(k) application. The following passages take a U.S.-centric view, but much of what follows applies in other regions as well.

Emerging Practice
The emerging practice reflects the case studies offered in AAMI HE74:2001. The following sections present the core HFE activities: plan the HFE program, conduct user research, develop user requirements, and design and model the user interface. Then the interface must be tested (in its preliminary form), the use-related risks identified, and the final user interface verified and validated.
Plan the HFE Program. AAMI HE74:2001 and FDA's guidance provide extensive details on HFE program planning. The basic idea is to take a strategic, rather than ad hoc, approach to HFE. HFE plans tend to read like proposals and are certainly subject to revision over time. But they help guide user interface design efforts and give regulators a roadmap to follow while reviewing a manufacturer's response to HFE-related regulations.
Conduct User Research. User research methods include observing similar medical devices in use, interviewing a sample of people who are likely to use the new device, and conducting benchmark (i.e., comparative) usability tests of competing and predecessor devices. These activities are typically documented in research plans and reports.
Develop User Requirements. This step involves converting accumulated knowledge about users, use environments, and use scenarios (including worst cases) into requirements for the future product—this is what FDA terms design inputs. User requirements may also be derived from human factors design principles found in standards and textbooks. Although user requirements may be combined with other engineering requirements, many companies consolidate them into a stand-alone document, or at least into a single section within a broader set of product requirements. Here are some sample user requirements:
•Users shall be able to read the critical parameter values (heart rate, respiration rate, oxygen saturation, etc.) at a distance of 10 m.•Center-to-center distance between buttons shall be at least 2 cm to guard against accidental actuation.

Design the User Interface. The design is a highly varied process. Design products will take very different forms depending on the type of device being designed. For example, a new infusion set and a cardiopulmonary bypass machine likely have different design products. Still, most user interface design efforts involve an orderly progression from design concepts to one or more preliminary designs, then to a single, refined design, and to a final design. Finished HFE products, which FDA terms design outputs, include conceptual model diagrams, task flow diagrams, control panel layouts, software hierarchy diagrams, and software screens.
Model the User Interface. If a company is developing a hardware product such as a plastic disposable, for example, it might build multiple nonworking and working models. If a company is developing a software product (e.g., a diabetes management application that enables users to analyze blood glucose–level trends), it will probably start with basic representations, such as slide shows or screen flows. It may then move on to interactive simulations, such as high-fidelity prototypes built in Adobe Flash, and, ultimately, working software. A company developing a hybrid product with both hardware and software user interfaces will likely produce all of the models described above. From an HFE standpoint, such models enable important design assessment activities, such as usability tests.
Test the Evolving User Interface. Conducting so-called formative usability tests of an evolving user interface design is the cornerstone of good research-based design. It is the time when representative users perform representative tasks with the best user interface models available at the given stage of design. Tests intended to identify opportunities for design refinement are termed formative usability tests and are documented in test plans and reports.
Identify Use-Related Risks. Manufacturers are typically tasked with determining whether a device could fail in dangerous ways related to electrical, mechanical, and thermal hazards, for example. But they must also identify use-related hazards, assess the risk of a hazardous event, and mitigate the risk to a feasible and practicable extent. In other words, manufacturers must view device use as another source of risk. As explained in FDA's guidance, the process results in a residual risk of a hazardous event.
Driven in large part by the guidance, manufacturers are conducting increasingly detailed analyses of use-related risks. Some are even going beyond what they consider reasonable risks to address highly unusual circumstances associated with unintended uses and even unintended users. The product of such analysis might be included in an overall risk analysis report, or stand alone as a human factors risk analysis report. Sample use-related risks include:
•User connects the gas line to the fluid line port.•User fails to calibrate the gas sensor before use.•User with high-frequency hearing loss doesn't hear the auditory alarm.
The testing activity described above might identify new risks that warrant follow-up analysis, or at least help to characterize the nature of previously recognized residual risks.
Verify the User Interface. As with other forms of engineering verification, this step calls for the manufacturer to confirm that the final design products (outputs) correspond with the design requirements (inputs). As such, verification does not require usability testing with representative users. Rather, it requires someone to sit at a desk and play the match game, documenting the findings in lengthy tables, for example.
Validate the User Interface. The subject of usability testing comes up again after the design is virtually complete. At this point, the design is available as a working prototype that might be indistinguishable from the marketable device. Such testing focuses on user tasks that could lead to dangerous use errors. It produces what is arguably the most important HFE product: the validation usability test report. Logically, every validation test report claims that a device meets users' needs. The report's primary purpose is to assure regulators that the tested device is appropriately free of user interface shortcomings that could lead to personal injury or death.
In practice, if the validation usability test (also called a summative usability test) reveals problems, it reverts to a formative usability test. In such instances, the failing user interface design must be corrected, and a fresh validation test must be conducted. That said, there are nuances in the art of validation usability testing. Manufacturers might choose to quickly fix user interface design flaws on the fly (i.e., during the early stages of testing) and then continue with testing, perhaps adding more sessions and including additional participants to ensure a sufficient sample size. A validation test might identify a user interface problem that subsequent risk analyses prove to be acceptable, negating the need for a fix and retesting.
Reviewing the DHF
At this point, let us examine our growing DHF. It contains the following:
•Human factors program plan.•User research plans and reports.•User requirements.•User interface design documents.•Risk analysis report(s).•Usability test plans and reports.
The DHF contents leave something to be desired. Drawing an analogy to automobiles, we have a base model stripped of useful options. It will get you where you are going. In the final analysis, a validated user interface is the goal. But, just as some automotive options benefit drivers, additional HFE activities benefit manufacturers and should not be viewed as luxuries. In fact, spending more on HFE can produce a substantial return on investment.³
Optional HFE Activities
Let's begin with a caveat: One person's optional HFE activity is another person's mandatory activity. Consensus on such matters is growing but incomplete. So readers may regard the following activities as mandatory if they wish, and expect to reap a nice payoff from the extra effort. Metaphorically speaking, these are the upgraded seats with good lumbar support, power windows, antilock brakes, and xenon headlights.

Develop Personas. HFE professionals create profiles or personas that document user characteristics pertinent to the ensuing user interface design effort. Such personas may be one- to two-page write-ups or tables that describe an archetypical user's age, physical characteristics, education, occupation, learning style, technical proficiencies, and product-related needs. It is typical to develop six to eight personas for most medical devices (see an example persona in the blue box to the right). You do not have to describe every possible type of user—just those that provide a good reference point for defining user requirements and making design trade-off decisions.
Define the Use Environment. Some user requirements are derived from the expected use environment. For example, if paramedics might use a device during rescues, it helps to characterize possible rescue settings, such as stairwells in apartment buildings and rain-soaked roadsides, in a report.
Define Use Scenarios. Writing use scenarios is one more path toward defining user requirements. A use scenario is a situation involving the use of the device. For example, one scenario could be an anesthesiologist switching a patient from one mode of ventilation to another near the end of a surgical case, when it is time for the patient to start waking up. Complex devices might warrant several dozen use scenarios, one or more paragraphs in length.
HFE Report. An HFE report is an executive summary of sorts that provides regulators with a succinct summary of the HFE program and its results. One might expect such a report to be required, but the same information contained in the report may be distributed across other DHF products.
International Perspective
Recall the earlier point that human factors professionals could wage an energetic debate regarding which HFE activities are core versus optional. Let's assume that there is not a single correct answer because the true answer is case-specific. It could depend on the nature of the device and the residual risks associated with its use. It could depend on a company's prior experience and current working relationship with the regulatory agencies such as the United States' FDA; the UK's Medicines and Healthcare Products Regulatory Agency (known as MHRA); or Japan's Ministry of Health, Labour, and Welfare. It could also depend on a company's relationship with a notified body, such as TÜV in the EU. Other factors include a manufacturer's level of commitment to a comprehensive HFE program and acceptance that its applications for device approval might encounter HFE-related obstacles resulting in delays.
That said, IEC 60601-1-6, “Medical Electrical Equipment Part 1–6: General Requirements for Basic Safety and Essential Performance—Collateral Standard: Usability,” is rather specific about the scope of a usability engineering process and its associated products.⁴ For example, the document calls for manufacturers to produce the following:
•Usability engineering process plan.•Usability validation plan. •Operator profiles (i.e., personas).•Use scenarios.•Description of operator actions associated with device functions (i.e., a task analysis).•Hazards related to equipment use.•Risk mitigations such as warnings, labels, and training materials.
IEC 62366:2007, “Medical Devices—Application of Usability Engineering to Medical Devices,” presents the same kind of guidance found in IEC 60601-1-6. This standard may soon supersede IEC 60601-1-6, and it calls for manufacturers to generate the same kinds of HFE products.
Conclusion
Medical device developers better purchase some fresh printer cartridges, because there is a lot of paperwork to accompany the aforementioned HFE activities. A complete HFE DHF is going to be chock full of plans and reports. However, rather than signaling more bureaucracy and wasting paper and electronic storage capacity, these documents will reflect intensive scrutiny on how people interact with medical devices and the development of final designs that are safe and usable.
References

1.ANSI/AAMI HE74:2001, “Human Factors Design Process for Medical Devices” (Arlington, VA: AAMI, 2001).

2.IEC 62366, “Medical Devices—Application of Usability Engineering to Medical Devices” (Geneva: International Electrotechnical Commission, 2007).

3.M Wiklund, “Return on Investment in Human Factors,” Medical Device & Diagnostic Industry 27, no. 8 (2005): 48–55.

4.IEC 60601-1-6, “Medical Electrical Equipment—Part 1–6: General Requirements for Basic Safety and Essential Performance—Collateral Standard: Usability” (Geneva: International Electrotechnical Commission, 2006).

Copyright ©2009 Medical Device & Diagnostic Industry