Integrating HFE/UE Activities into Product Development for Complex Medical Device Systems
Integrating HFE/UE Activities into Product Development for Complex Medical Device Systems
Past Agilis newsletters have addressed the importance of integrating the human factors engineering process activities and deliverables into the new product development process. This newsletter will address the important role HFE/UE can serve in system integration of complex medical technology.
Complex systems require multiple layers of risk and requirements analysis that correspond to multiple layers of testing. This is most commonly explained via the V-Model of Systems Engineering shown below:
Figure 1. V-Model of Systems Engineering
How should human factors analysis, activities, deliverables, and testing be embedded into the product development of complex medical device systems? Are all HFE/UE deliverables required at the system, sub-system, and component level? Is usability testing required at the system, sub-system, and component level? Can HFE/UE deliverables be integrated into other system, sub-system and component level design control and risk deliverables? Let’s explore each question and identify options that employ a systems safety approach which streamlines the integration of requirements, risk management, and testing at each level of product development.
Are all HFE/UE deliverables required at the system, sub-system, and component level?
Most of the HFE/UE deliverables should be created and analyzed at the system level. Systems engineering and usability engineering have the same goal of optimizing the performance and safe use of the system while considering the impact of the use environment. The Use Specification (a.k.a. Context of Expected Use Document), HFE/UE Plan, System Use Related Risk Analysis, User Interface Evaluation Plan, Instructions for Use, Training Material, Summative Human Factors Validation Protocol & Report, and final HFE/UE report for the regulatory submission can all be conducted/documented at the system level. Conducting and documenting these HFE/UE activities/deliverables at the system level and reviewing them at the system design reviews provides consistency and system integration of the User Interface. It is also recommended that user needs be documented in the system level requirements document or traceability matrix. The system level user needs can then be cascaded to the system, sub-system, and component design input requirements.
User interface requirements and risks may also arise at the sub-system and component levels but will deductively and inductively cascade from and to the system level requirements and use related risk analysis. An example of how a user interface requirement might deductively cascade from the system to component level is a system design guideline for perceptual cues that is cascaded to the subsystem and component level requirements to ensure consistency of the user interface which will in turn reduce use errors. A system level User Interface Specification document can serve as an integration document for user interface requirements by describing the user interface including all labeling and training then listing which system level, sub-system level and component level requirements documents contain the detailed UI requirements and specifications.
An example of use risks and requirements flowing from a component to the system inductively could be a use risk that pertains to using an incompatible hardware component which is cascaded up to the system level use risk analysis and mitigated by the system software or control logic recognizing the incompatible hardware, alerting the user, and then not allowing the user to proceed in the software workflow.
Is usability testing required at the system, sub-system, and component level?
Formative evaluations are typically performed at the sub-system and system level. For example, early formative evaluations may be sequenced based on when subsystem prototypes are available and at what level of functionality. On a complex robotic assisted surgical device, early formative evaluations may be planned around the availability of hardware and software sub-system prototypes. For instance, formative evaluations for pre-operative use scenarios of system setup and draping might first be conducted at the sub-system level with hardware mockups alone then repeated at the system level when software is available.
User interface verification inspection and testing could occur at all three levels: component, sub-system, and system level. The level at which testing is performed correlates directly to the component, sub-system, and system level requirements and risk analysis.
Can HFE/UE deliverables be integrated into other system, sub-system and component level design control and risk deliverables?
Due to the many layers of documentation for complex medical device systems, it is recommended that the HFE/UE planning and requirements documents be integrated into the system, sub-system, and component level documentation. Separating out HFE/UE planning and requirements from the other system, sub-system, and component level documentation will impede system integration and may result in redundant and conflicting requirements and testing.
To reduce the possibility of conflicting and redundant requirements, the UI user needs, design inputs & design outputs should be embedded into the system, sub-system and component level traceability matrices or product specification documents. It is helpful to categorize the requirements as UI requirements to separate them from performance, functional and other requirements. As described above, the User Interface Specification document can then serve as a pointer document rather than a separate requirements document.
Complex systems have complicated timelines for the delivery of hardware and software prototypes. To ensure successful system integration, the HFE/UE Plan and UI Evaluation Plan should be embedded into the overall Design and Development Plan. If a separate verification and validation plan is maintained, the UI verification and summative human factors validation plan should be embedded into the V&V plan for the overall project. Finally, a Usability Engineering File reference sheet can be created to list all the system, sub-system, and component level documents that comprise the deliverables within the Usability Engineering File.
Stay tuned for future newsletters which will explore the Systems Engineering V-Model approach for HFE/UE activities with case studies.
About the Author:
Denise Wagner, MS
Denise Wagner is a Principal Consultant in Human Factors Engineering at Agilis Consulting Group and is active on standards committees and industry groups for medical devices. Denise has practical experience in the research and development of complex medical device products, risk management, human factors engineering, design controls, product verification and validation, performing heuristic and expert reviews, designing integrated quality procedures, and training medical device product development personnel. Formerly, Denise led Johnson and Johnson’s Orthopedic Robotics Systems Engineering Team. Additionally, Denise’s expertise and leadership developed over the years from consulting on usability engineering and quality systems through her own consulting company, working at Zimmer in R&D development, teaching at Trine University, and beginning her career at NASA Johnson Space Center in their robotics division.