Prerequisites 🔗
You need to have completed user needs, requirements, risk control measures, verification tests, indications, contraindications, and intended users. Although not required, I find it useful to create verification tests that verify something is present in the user manual. For example, take the following trace:
- RISK 001: Operator forgets to unlock the wheel lock, pushes the device from above the center of gravity, the device tips over and causes operator injury, patient injury, or property damage.
- RCM 001: Device label must include a paragraph reminding the user to ensure the wheels are unlocked before moving.
- VER 001: Check the user manual to ensure the requirement is met.
This may seem contrived but this concept fits well inside existing risk management activities. You can imagine the user manual as an implementation of requirements. Having verification tests will ensure that important labeling requirements are not accidentally deleted in the future.
Device Description 🔗
Should include a high level description of the device. This should be equivalent to the device description you are submitting with your FDA application. Making changes to this section could involve hunting down duplicate copies all over your submission. This can take a lot of time so I suggest leaving this as a placeholder until you have finalized the device description. Alternatively, you can use some clever Microsoft word templating, programmatic template language + Markdown, or something like our Medtech OS.
Warnings 🔗
Go through all of your risk control measures and ensure there is a verification test that checks the user manual for the presence of the warning. Then, one by one, add verbiage for each one of the RCMs such that the verification test is satisfied. This is akin to “test driven development” in the software development world—you write the verification test first.
Indications 🔗
This should match exactly your indications for use statement. Example: The usage of this device is indicated for any adult over the age of 21 that has recently received a CT scan for suspicion of lung cancer.
Contraindications 🔗
This should describe under what situations this device should NOT be used. Example: This device is contraindicated for emergent care.
Intended Users 🔗
This section should describe the users intended to use this device and their required qualifications. For example: This device is intended to be installed by qualified IT personnel. The outputs of the device are intended to be consumed by board certified radiologists or radiology residents in training.
System Requirements 🔗
If your software runs on off the shelf hardware, you should include the minimum system requirements necessary to run the software here. For the case of AI/ML applications, be sure to include GPU requirements. Example:
| CPU | 12 core x86 CPU |
| RAM | > 16GB |
| Storage | > 256 GB |
| GPU | > 8 GB VRAM CUDA compatible |
| OS | Ubuntu 21.04 or compatible |
Software Installation 🔗
This section should have step by step instructions on how to install the software. I also recommend include a sanity check test to make sure everything is working as intended. This can just be manually running a DICOM study through the device and ensuring expected outputs are met.
Operating Instructions 🔗
This is the meat and potatoes of the user manual. An easy way to do this is to iterate through your user needs and write step by step instructions on how a user would use the device to satisfy the user need. Use screenshots and icons as necessary. Avoid external links that could go stale or become unavailable. Video instructions can be useful but unfortunately you need to have a version that can be printed—even though you only intend on making the manual available digitally.
Customer Support 🔗
This section should contain your company’s support email address, phone number (if applicable), and address.
