UseTrace HFE
AI-powered automation for Human Factors Engineering documentation in medical device development. Turns weeks of manual HFE workflow formatting into hours: task analysis tables, use error categorization, risk-use traceability, and simulated-use protocol generation.
The Problem
HFE Documentation Is Still Done in Excel
Every medical device going through FDA 510(k) or PMA review must pass a Human Factors Engineering evaluation under IEC 62366-1. The process requires safety engineers to manually construct task analysis tables, categorize use errors, trace hazards to tasks, and format simulated-use study protocols. All typically done by hand in Excel or Word.
This isn't a niche edge case. Every device that touches a clinician's hands: infusion pumps, surgical robots, diagnostic equipment, monitoring systems. Goes through this process. The documentation bottleneck directly slows the path from prototype to submission.
Safety engineers spend weeks manually formatting task analyses, categorizing use errors, and building traceability matrices. Work that's repetitive, error-prone, and consistently underestimated in project timelines.
The structure of HFE documentation is highly predictable. IEC 62366-1 and FDA guidance define exactly what's needed. That structure is automatable. The engineer's judgment about device-specific risk remains human-led.
Between 2018 and 2024, FDA issued 23 warning letters citing inadequate human factors documentation under 21 CFR 820.30(c). Common findings: missing use error analysis, incomplete task analysis, and HFE reports that couldn't trace design mitigations back to identified risks. UseTrace addresses each of these gaps with structured, traceable output that maps directly to IEC 62366-1 requirements.
How It Works
Automation Pipeline
UseTrace takes structured device and use scenario inputs and outputs complete, submission-ready HFE document components. Reducing manual effort while keeping the safety engineer in control of all substantive decisions.
Why structured templates over free-form generation
FDA reviewers are trained to expect specific table formats and field names. Free-form generation that deviates from established patterns creates review friction. UseTrace targets the formatting problem, not the content judgment problem.
Why keep the engineer in the loop
Use error categorization and risk severity decisions require device-specific knowledge and contextual judgment. Automating those judgments would produce documentation that can't survive an FDA audit. UseTrace accelerates structure, not substance.
Why start with literature, not code
The project began with a systematic literature review of IEC 62366-1, FDA HFE guidance, and existing tooling gaps. Building on a documented foundation means every design decision can be traced back to a regulatory or research rationale.
Deployment & Integration
UseTrace is designed to drop into existing HFE workflows without IT involvement. The intended flow: teams export observation data from their preferred tool (Qualtrics, REDCap, or manual entry), run it through UseTrace, and get formatted output in minutes. It is a research prototype, not a deployed product. It has not been piloted with an HFE team yet, and getting it in front of one is the obvious next step.
Regulatory Context
Standards Foundation
UseTrace is grounded in the specific regulatory framework that governs HFE submissions. These aren't aspirational references. The tool's output templates were designed to align directly with what FDA reviewers expect to see.
IEC 62366-1:2015
The primary international standard for medical device usability engineering. Defines the Use Specification, task analysis requirements, use error analysis, and summative evaluation criteria that UseTrace targets.
FDA HFE Guidance (2016)
FDA's "Applying Human Factors and Usability Engineering to Medical Devices" guidance. Defines what must be in a Human Factors Engineering Report and what evidence is required for 510(k) and PMA submissions.
ISO 14971:2019
Risk management standard for medical devices. Informs how use-related hazards and risk-use traceability are structured in UseTrace's output, connecting HFE analysis to the broader risk management file.
UseTrace is architected for regulatory evolution. The classification taxonomy is stored as a versioned JSON schema, not hardcoded. When FDA updates its Human Factors guidance (last major revision: February 2016, next expected within 2 years), updating the taxonomy requires editing one configuration file, not rebuilding the application. Similarly, if the team switches from Qualtrics to REDCap for data collection, only the import adapter changes. The analysis engine and output templates remain untouched.
Project Scope
What Was Built
UseTrace is a research prototype. Currently functional and under active development. The codebase includes the automation engine, test suite, and the full documentation package required to position it for real-world HFE team evaluation.
Tech Stack
Built With
Why Python
Python's ecosystem for document parsing, text analysis, and structured data output is well-suited to the HFE documentation problem. The script-first approach makes it easy for safety engineers to run on their own machines without requiring a web deployment.
Inter-rater Reliability (Krippendorff's Alpha)
Use error categorization involves judgment calls. To make UseTrace's classification outputs defensible in regulatory contexts, inter-rater reliability metrics were incorporated into the evaluation methodology. The same approach FDA expects in summative study reports.
Reflection
What I Learned
The real bottleneck isn't what engineers think it is
Talking to people in HFE consulting and reading FDA warning letters made it clear: the documentation delays aren't from lack of knowing what to write. They're from the formatting and traceability grunt work. Once I understood that, the scope of UseTrace became much cleaner. Automate the scaffolding. Let the engineer do the thinking.
What scoped the project
Reading through FDA warning letters and the HFE guidance, the pattern was hard to miss. The documentation delays in HFE submissions are not about engineers not knowing what to write. They are about the formatting and traceability grunt work. That part is automatable. The judgment is not. UseTrace draws the line exactly there.
Regulatory documents are more useful than they look
IEC 62366-1 and the FDA HFE guidance aren't vague policy statements. They're essentially detailed specifications for what a compliant document looks like. Once I treated them as design requirements rather than compliance overhead, building to them became much more straightforward. Every design decision in UseTrace has a standard number attached to it.
Starting with literature review before code is the right call in regulated domains
In a regulated space, shipping something that doesn't align with existing guidance isn't just a product mistake. It can cause harm. Doing the literature review first forced clarity on what UseTrace should and shouldn't try to automate. It also made the pitch document far more credible because every claim had a citation behind it.
Post-Mortem
What I got wrong.
UseTrace solves a real workflow problem. But I made assumptions about the domain that someone with more HFE field experience wouldn't have made.
I treated IEC 62366-1 as a spec without talking to people who actually submit 510(k)s.
I read the standard. I read FDA guidance documents. I built UseTrace's taxonomy and output format based on what the documents say compliant HFE documentation should look like. But I didn't talk to anyone who has actually submitted a 510(k) with HFE deliverables until the tool was mostly built. When I finally showed it to an HFE consultant, she pointed out that FDA reviewers care about specific narrative structures and cross-reference patterns that aren't in the standard itself. They're institutional knowledge. My document templates were technically correct but structured in a way that would require manual reorganization before submission. That feedback came too late to change the architecture cheaply.
I overestimated how much HFE engineers want automation.
My pitch was: "UseTrace automates the scaffolding so you can focus on the thinking." That assumes HFE engineers view scaffolding as waste. Some do. But several I spoke with after building the tool said they actually use the manual formatting process as a review step. They catch errors in the use error categorization while they're formatting the table. Automating that away removed a quality check they relied on. The better design would be to generate the scaffold and then present it for human review with inline editing, not to produce a "finished" document that skips the review step.
I built for one regulatory pathway and assumed it would generalize.
UseTrace was designed around FDA 510(k) HFE requirements. When I started looking at EU MDR requirements (IEC 62366-1 Annex C, the European Essential Requirements), the document structure expectations are different enough that UseTrace's templates don't transfer cleanly. The taxonomy is the same, but the output format, the required narratives, and the cross-referencing to Essential Requirements need significant rework. I should have designed the template system as configurable from the start, with regulatory pathway as a parameter, instead of hardcoding the FDA format.
Questions You Might Ask
Answers before the interview.
If I were screening this portfolio, these are the three questions I'd ask. So here they are, answered.
Q1: Why build this as a tool instead of a consulting service?
Because the bottleneck isn't expertise. It's formatting and traceability. HFE engineers already know how to categorize use errors and write task analyses. What eats their time is reformatting tables, maintaining cross-references between use specifications and risk analyses, and producing documents that match FDA's expected structure. A tool that handles the mechanical parts lets the engineer spend time on the judgment calls: is this use error critical? Does this mitigation actually reduce risk? You can't automate judgment. You can automate the document structure around it.
Q2: How do you know FDA reviewers would accept UseTrace's output?
I don't have direct FDA feedback. What I have is alignment with the FDA HFE Guidance (2016), IEC 62366-1:2015, and the document structures I've seen in published 510(k) summaries that include HFE sections. The taxonomy (use errors, use scenarios, critical tasks) follows the standard directly. The gap, as I noted in the post-mortem, is in the narrative conventions that FDA reviewers expect but that aren't codified in the standard. The honest answer is: UseTrace produces a strong first draft that a regulatory affairs team would still need to review and adjust before submission. It's not a replacement for regulatory expertise. It's a starting point that saves hours of formatting.
Q3: What would you do differently with another semester?
Two things. First, I'd partner with a regulatory affairs professional or HFE consultant from week one, not as a user tester, but as a co-designer. The institutional knowledge about what FDA reviewers actually look for can't be extracted from reading guidance documents. It has to come from someone who has been through the submission process. Second, I'd make the template system pathway-configurable from the start: FDA 510(k), FDA De Novo, EU MDR, and Health Canada. The underlying HFE methodology is the same across regulatory bodies, but the document expectations differ. Building that abstraction layer early would make UseTrace genuinely useful internationally, not just for US submissions.
What's Next
Want to see the repo or talk HFE?
UseTrace is in active development. If you're working on HFE documentation workflows or want to discuss the regulatory framing, I'd love to connect.