Ovo Logger for medical devices
Human factors evidence, one use error at a time.
A validation is not judged on averages. It is read the way a reviewer reads it: what happened, to whom, on which critical task, whether the risk analysis saw it coming, why it happened, and what was done about it. Ovo Logger keeps that chain intact from the session to the report - on hardware you own, which is where device data belongs anyway.
01 / The evidence chain
Observation → use error → cause → task → hazard → harm.
Every link in that chain is a first-class record, not a phrase in somebody's notes. Sever any one of them and the study answers a reviewer's question with a shrug.
Critical tasks, declared up front
A task is flagged critical with its rationale - the harm if it fails - before anyone is recorded, and the report reads critical tasks first, because that is the order the document is read in.
Use errors are not outcomes
A task can be completed successfully and still contain a reportable close call. So use errors, close calls, and use difficulties are their own records - several per attempt if that is what happened - each with its description, its root cause, and a citation to the observer's note that recorded it live.
Close calls survive
A caught-and-recovered error is invisible in completion statistics, which is precisely why the guidance names close calls as evidence of thorough testing. Here they are counted where nothing else counts them, and the report says so.
Every claim plays
Use errors cite the recorded moment. A finding in the report is a citation you can click and watch, not an assertion someone typed from memory.
02 / The use-related risk analysis
Observed against anticipated - the first thing a reviewer checks.
The use-related risk analysis (URRA) lives in the study: per task or device-level, with the potential hazardous situation and the potential harm as separate columns, the risk control in place, and a pointer into your own risk file. You author and own the URRA; Ovo Logger holds the linkage and the evidence.
Anticipated, per task
Each task carries the use errors the analysis expects of it, in the shape current guidance asks for - hazardous situation and harm stated separately, not blurred into one phrase.
Observed, read against it
The report reads the validation's observed use issues against the analysis, and an observed-but-unanticipated error is called out rather than filed quietly - because that is the row a reviewer reads first.
Checked, not hoped
A summative with no URRA is flagged as a problem before the report is written. A critical task with no anticipated errors is flagged as worth a look. The checks run in the app, against the study's own data.
03 / Summative discipline
The rules of a validation, enforced by the tool.
A summative study is a different instrument from a formative one, and the product knows the difference rather than trusting everyone to remember it.
Frozen interface, attested
A summative opens with an attestation that the design under test is final. If it changes, that is a new study, not a quiet edit.
User groups with floors
Recruitment plans are per user group with per-group minimums, and every critical task must be covered by every group - the coverage rule reviewers actually apply.
Training with computed decay
Where the protocol trains participants, the training-to-testing interval is recorded and the decay computed - not asserted.
Numbers you can defend
Task timing is an explicit start and stop. A span that only located a task is shown but never averaged; an unscored outcome is excluded and stated as excluded. The measurement rules are the same ones the rest of the product lives by.
04 / The HFE report
Written in the reviewer's own outline.
The report renders from the study's data in the structure submissions are reviewed against - device description, user groups, critical tasks, the risk analysis, results per group, and each use issue in detail: what happened, to whom, on which task, whether it was anticipated, why, and what was done about it.
You write the argument
The residual-risk argument - why what remains is acceptable - belongs to the person who signs the conclusion. The report is editable in the app, and the data sections regenerate without touching your prose.
The AI reviews; it never writes
On-device, the model reads your authored sections against the required format and flags what a reviewer would: a missing rationale, an uncovered group, a claim with no citation. It drafts nothing - in a regulated document, wording is a liability only a person should take on.
Design changes, with provenance
Each change cites the observation or use error it answers, and carries its status - recommended, implemented, verified - so the next round starts from the record, not the recollection.
Formative rounds, tied together
A study series links the rounds of the same study across design changes, which is what makes "verified" a claim about evidence rather than optimism.
05 / Where the data lives
Device data, on device-company hardware.
Sessions with patients and clinicians, prototype interfaces, risk files - none of it belongs on a usability vendor's cloud. Ovo Logger runs entirely on machines you own: capture, review, and the AI, air-gap included. Your retention policy, your disk encryption, your custody.
06 / What this is, and is not
A tool for the evidence, not a shortcut past it.
Ovo Logger is not a certification, does not write your submission, and does not decide what risk is acceptable - those belong to your team and your quality system. What it does is keep the chain of evidence a submission is argued from: intact, cited, and playable, from the moment a participant hesitates to the paragraph a reviewer questions.
Medical device human factors
Bring us the study you have to defend.
We'll walk your team through a validation end to end - the URRA, the session, the use-error record, the report - on your own protocol, not a canned demo.