Medical Device Testing

Describes version 4.37.1

A purpose-built layer for human factors validation work on medical devices - critical tasks, participant demographics, use errors and close calls, and a draft HFE/UE report in the FDA submission outline.

Two things must both be true before these features show: your license includes Medical Device Testing, and the study itself is marked as one. A general study on a licensed machine looks exactly like it always did. Nothing in this guide leaks into ordinary research work, and recording behaves identically either way.

Marking a study as medical device work

1. When you create a study, choose Medical device study / regulatory submission (FDA human factors guidance / IEC 62366-1) as the study purpose. Your last choice becomes the default for next time. The purpose covers the whole series - formative rounds and the summative alike; which one this study is, you declare with the study type in Study Setup.
2. Already-created study? Change it under Study Setup → Study purpose. Switching a study off hides these features but deletes nothing. Everything recorded is still in the file if you switch back.

The question is about the deliverable, not your industry: pick it when the study supports a regulatory submission.

Critical tasks

A task is critical when its failure could cause harm. In Study Setup → Tasks, each task gains a criticality choice and, when critical, a box for what harm could result, that rationale goes straight into the report's critical-task section.

Participant demographics

A validation reports its results per user group, and often by age band, prior experience, or dexterity too. Define those characteristics and record each participant's values in Study Setup → Participants:

• Each characteristic is a row: its name, a picker for this participant's value, and an edit button that opens the value editor (add, rename, reorder, remove, with a warning that says how many participants a removal affects).
• Values are a fixed list rather than free text, so two participants who are the same are recorded the same way. That is what makes a per-group breakdown computable.
• Renaming or reordering values never disturbs who is already recorded; participants are stored against the value itself, not its wording.
• A participant left blank is reported as not recorded, never silently dropped from the counts.

Use errors, close calls and difficulties

Three kinds of thing can go wrong on a task attempt, and the report counts each: a use error (did something wrong, or failed to do something needed), a close call (caught it themselves and recovered), and a use difficulty (managed it, but with observable trouble).

Capture works in two halves, matching how validation sessions actually run:

1. During the session, just take notes. Nothing new to learn - the observer types what they see, exactly as in any study.
2. In Review, promote the note. Right-click the task attempt on the band and open Edit task timing. The What went wrong on this attempt panel lists any notes taken during that attempt. Click Mark as use error…, pick the kind, and add the root cause (usually what the participant told you in the debrief). The note stays in the log; the use error cites it.

Use-related risk analysis (URRA)

Study Setup → Use-Related Risk Analysis records the analysis section 6 of the HFE report is built from: for each task, the anticipated use error, the potential hazardous situation and the potential harm as separate columns (the 2026 guidance's format), plus the risk control in place. A line can also be device-level - storage, packaging, rather than tied to one task. Each line can carry a reference into the manufacturer's risk file (an ID or clause); the risk file itself stays with the manufacturer - the study holds the linkage and the evidence, which mirrors how FDA reads submissions: the applicant authors the URRA, and observed use issues are reviewed against it.

That reading is built in: the report's section 6 shows the URRA table and then reads the validation's observed use errors against it - a use issue observed on a task the URRA doesn't cover is called out (it's the gap reviewers cite first), as is a critical task with no line. The format check raises the same findings while you work.

The HFE/UE report

Analysis → HFE/UE Report opens the report as a workspace: the draft renders in the eight-section outline from FDA's Content of Human Factors Information in Medical Device Marketing Submissions, built fresh from the study's current data, with the narrative sections editable in place.

• Click Write this section… (or Edit…) on a narrative section and it becomes editable right in the document - bold, italic, lists, headings and quotes, with guidance above it saying what the section is expected to contain. Save lands it in place.
• Photographs and diagrams go in the document. Section 3 is expected to show the device's controls, displays and labelling, so the editing toolbar has an image button: pick a picture, describe it for screen-reader users, add a caption if you want a figure number, and it is placed at your cursor. The image is stored inside the study and embedded in the exported file, so the report stays a single document you can mail. See the main guide.
• Only the sections the study cannot generate are editable; every figure and table is computed and cannot be changed here or anywhere.
• Export HTML… writes the clean document beside the study and opens it in your browser, no editing controls, no workspace markers, ready to send.

• Each section is badged: generated from study data, to be authored (device description, known use problems, the conclusion - always written by a person), or cannot be generated yet, with the reason stated in place.
• Generated sections include the participant demographics breakdowns, the critical-task table with rationales, task outcomes, and use errors counted per task and grouped by root cause.
• Every use issue is also accounted for individually, critical tasks first: what happened, which participant and user group, how the attempt was scored, the root cause, whether your risk analysis anticipated that task's failures - called out loudly when a critical task's issues were not anticipated, and which design change answers it. Nothing there is new information; it is everything you have already recorded, read together the way a reviewer asks about it. The judgement of whether the remaining risk is acceptable stays yours, in the conclusion.
• Results per user group. Mark one demographic characteristic as the user-group dimension (edit the characteristic in the Participants editor and tick “This characteristic defines the user groups”) and section 8 reports its outcome tables per group - the breakdown a summative is required to show, with participants missing a group value collected into a visible “no user group recorded” bucket rather than silently pooled. The format check also counts group sizes against FDA reviewers’ stated expectation of at least 15 participants per distinct user group.
• Declare the validation. Study Setup carries a study type picker for regulated studies. Choose Summative validation for the submission's HF validation and the validation rules switch on: group sizes are checked against each group's recruitment plan (set per value on the user-group characteristic) and fall short as blocking findings, every critical task must be exercised by every user group, and the report opens section 8 with the protocol facts - the frozen device/UI version you state in Study Setup, each participant's training arm (trained, untrained by design, or not recorded - set in the Participants editor with the training date and materials), and the training-to-testing gap computed from those dates. Formative studies see none of this.
• A regulated study starts set up for this. Choosing the regulatory-submission purpose (at creation, or later in Study Setup) seeds a marked “User group” demographic ready for your group values, and labels four quicklog tags to match the reporting vocabulary: U Use error, C Close call, D Use difficulty, H Help given, so live observer notes land pre-aligned with what section 8 counts. Nothing you have already named or labelled is ever overwritten.
• Section 5 comes from the study series. The preliminary analyses and evaluations span several studies - the formative rounds that led to the design you validated, so they cannot come from one study file. Group the studies into a study series (Analysis → Study Series; see the main guide) and add the validation study to it: section 5 then generates the round table, when, who took part and in which user groups, tasks, use errors - followed by each round's design changes and, where you have said so, the later round that verified them. The validation itself is not listed there, since section 5 is the preliminary work and section 8 is where the validation is reported; it stays available as the round a change can be marked verified in. A round whose study file has since been deleted or archived still reports, from what was read, with the date it was read.
• The file is self-contained HTML - mail it, print it, open it anywhere.

Checking your writing against the required format

Check format reviews the report against the FDA outline and shows its findings in the document, beside the section each one is about. Two kinds of check run:

• Format check - computed. Exact checks Ovo Logger does itself: sections not yet written, whether section 2 mentions all four of users, uses, environments and training, numbers in the conclusion that match no figure the study computed, critical tasks with no scored result, and use errors with no root cause. These run instantly and need no AI Pack.
• ✨ AI review - advisory. With the AI Pack installed, the same click also has the AI read each written section against that section's required content and suggest what is missing, too vague, or not supported by what the text says, including whether recorded root causes actually explain why an error happened rather than restating what happened. The AI never writes or rewrites anything; the failure mode of a wrong suggestion is a moment of your time, and a qualified person decides every change.

Checking again after you revise doesn't start from scratch: sections you haven't touched keep their previous review unchanged, and where you've addressed an earlier finding the new review says so - an “Addressed since the last review” note listing exactly which items your revision answered. The note quotes the earlier review word-for-word - the AI only points at which of its items were addressed; Ovo Logger supplies the wording and discards anything that doesn't correspond to a real earlier finding, so the credit is real. The AI review runs only when you click. Nothing reviews your writing while you're still authoring.

Findings never appear in the exported document. They belong to the workspace.