STUDY TYPE | MY ROLE | TIMELINE | PARTICIPANTS |
|---|---|---|---|
Formative Study | Human Factors Co-Lead | July – December 2024 | N = 22 |
Summary
When I joined the Baxter Front Line Care team in May 2025, I onboarded to join the human factors effort for the 6.6.0 update project and corresponding 510(k) submission for the Q-Stress and XScribe stress testing systems (to be referred to as "Q-Stress," as the systems are functionally identical).
The most important user-facing change within the project scope was a design mitigation related to the integration of Mortara's proprietary Source Consistency Filter (SCF) into the user interface associated with a Class 2 FDA recall.
My work on the Q-Stress project was my first experience as an in-house human factors engineer after my three-year career in human factors and usability consulting. For the first time, I was in charge of not only using and creating HF input documents such as the URRA, but I was also now building the product's complete HF file, contributing to its design history file, and facilitating handoffs to the cross-functional systems and UX design teams.
Background
This case study reviews my contributions to the usability engineering file for Q-Stress, which includes the use-related risk analysis (URRA), user interface evaluation plan (UIEP), and a formative study conducted in August 2024 for the Q-Stress 6.3.0 device, which is currently on the market.
Context for the recall
A customer complaint indicated "low amplitude, small, or incorrect QRS measurements" present in the ECG, which internal investigation determined was related to activation of the SCF. Internal testing determined that QRS amplitude can present differently when the SCF is active, which could result in misdiagnosis of a patient's condition by a clinician who is not aware the SCF is active.
After Baxter initiated an urgent medical correction, designing a permanent solution was added to the scope of the 6.6.0 update.
Objectives
Develop the usability engineering file for the Q-Stress system according to IEC 62366-1 and FDA HF guidance.
Evaluate the safety and effectiveness of Q-Stress 6.3.0, which is currently on the market.
Assess the current Q-Stress user interface and identify potential use errors in preparation for the Q-Stress 6.6.0 project.
Challenges
This was my first project as an in-house human factors engineer. I was excited to start at Baxter because, as a consultant, I didn't have the chance to work with cross-functional R&D teams, and any information I got about the project was through our client. With the Q-Stress project, I would have the opportunity to see the inputs for the HF file and influence what happens to testing results after the report is finished.
I was new at Baxter. As a new hire, I knew I had a lot to learn about corporate process and cross-functional trust-building ahead of me.
I would be managing third-party researchers for the first time. I went from being the consultant to being the client, which I was mindful of when interacting with the research team contracted to conduct our testing. I knew I would have to avoid both micromanaging and being too hands-off, so I leaned on my co-lead, who had never worked in HF consulting, to set the tone for client interactions.
We could not be onsite for testing. Due to travel limits, both my co-lead and I could not travel to Raleigh, NC to observe testing in-person and assist with troubleshooting.
Developing the HF File
When I joined the project, my co-lead, Alex, was about 75% finished with the URRA, which was the first ever developed for the Q-Stress given that it is a legacy product. Members of the project's cross-functional team representing risk, systems, and medical affairs were part of this effort.
The first thing I noticed in the URRA was that there were over 400 tasks for internal Baxter service personnel. I had learned from internal documentation developed by HF management that service personnel were out of scope for URRAs. I pointed this out to Alex, who was both grateful that I noticed it and understandably bummed that she had spent time working on identifying these tasks, and we decided to keep the rows in the project folder but not route them in the final version of the document.
After routing the URRA, Alex and I created the UIEP and study protocol, and I wrote the moderator's guides for each user group.
All in all, my observation that we could eliminate the internal user group saved at least $6,000 in testing fees and participant compensation.
Want to read more?
The rest of this case study is password-protected simply because they include some internal test results.
This is not a paywall: email me for the link to the rest of the case study and the password, and I will happily provide it.