As technical writers we are always supposed to know our audience. With medical devices we have to provide data that proves we know our audience.
The FDA now has guidance documents for human factors data. These documents are based on:
- ANSI/AAMI HE75:2009, Introduction
- ISO/IEC 62366:2007, Definition 3.17
- 21 CFR 820.30, Design Controls
- ANSI/AAMI/ISO 14971:2007
Detailed information can be found at http://www/fda.gov/humanfactors.
Right now I’m in the learning stages of what I need to know about human factors and usability studies. I’m learning more about human factors for two reasons.
- Due to reorganization I moved from the software department to system integration.
- A thread on the STC LinkedIn group about Technical Writers and where in the food chain we landed.
I’m not at the bottom, nor am I near the top. I was given the opportunity to work on creating human factor documents for our newest device release (learning opportunity). This means that I will be helping to create or modify existing system requirements. I'm also gathering data on how we have met the FDA’s requirements on human factors. Trust me on this: I’m out of my comfort zone for the first time in years.
When you consider the users of the device, your users could be doctors and nurses or the parent of a child with diabetes. Your user could be someone with limited education trying to understand the instructions on their blood pressure cuff.
From the flow diagram from ANSI/AAMI HE75:2009:
- Define intended use, users, and environment
- Identify use related hazards
- Estimate and prioritize use error risk (Hazard, Risk Analysis (HRA))
- Implement risk controls (this could be within the software, actual hardware design, or mitigation within the user instructions.
- Validate safety of use
- Is the risk acceptable or are new risks introduced with the implemented risk controls?
- Document the process that was used for the conclusion
- Then monitor unanticipated risks in the post market
All of the items above are expanded into detailed documents, tests/protocols, and reports. You as the technical writer can either create the documents or provide clarity.
You may be asked to:
- conduct interviews or work with focus groups
- do a task analysis of the device
- break down the steps the user needs to use the device
- create use cases that lead into actual testing or write the protocols
- help document risk mitigations
All of the data collected is part of the Design History File (DHF). This is an iterative process. If your device is updated, then the process starts again. If you have questions regarding the device’s design, the FDA encourages companies to contact them early in the development process. The later in the process the more expensive it is to make changes or corrections.
This isn’t just an FDA requirement; Human Factors also applies to the European Union and other countries around the world.
Beth Tripp is a technical writer for a medical device manufacturer. Beth will be posting monthly on the area of medical writing under the “MedDevDiva” title.