Chapter 19
Requirements, hazards, and useful tests
From "it seems to work" to evidence someone else can rely on
Human Biology for the Medical Maker
Why this chapter exists
- A requirement nobody wrote down, so nobody checked
- A hazard that was obvious in hindsight
- A test result carried forward to a version it did not apply to
- A prototype that met every dimension and was unusable
It is not bureaucracy. Each element exists because someone was harmed by its absence.
Intended use, users, and environment
| Statement | Must say |
|---|
| Intended use | What it is for in one sentence — and what it is not for |
| Intended users | Who operates it: training, familiarity, frequency, capabilities |
| Use environment | Lighting, noise, interruptions, gloves, wet hands, surface, time, storage |
Example: a tabletop teaching aid showing elbow flexion. Not for attachment to a person, not clinical, not load bearing.
The unglamorous conditions
Real conditions
- Interruptions and clutter
- Gloved or wet hands, poor light
- The ninth use today: nobody reads the label
Foreseeable misuse
- If it can be assembled backwards, it will be
- If a cord can be yanked, it will be
- The question is whether the design tolerates it
Turning adjectives into requirements
Who, does what, under what conditions, to what criterion
Vague versus workable
| Vague | Workable requirement | How it is checked |
|---|
| Easy to reset | After one demonstration, the intended educator restores the start position without tools | The actual educator does it; prompts recorded |
| Durable | 50 handling cycles under agreed gentle operation without separation or loss of function | Counted cycles, inspection at intervals |
| Clearly labelled | An unfamiliar learner can say which element generates and which transmits force | Three unfamiliar learners, unprompted |
| Washable (a sewn strap) | After 50 cycles of the laundry's real programme, seams intact and fastening holds | Wash in the actual process; pull-test |
| Reliable (firmware) | After power loss at any point, restarts to a defined safe state and reports its version | Scripted power interruptions, logged |
"Safe" is not a requirement. Decompose it into hazards and controls.
Do not choose numbers to pass
"50 cycles chosen as an exploratory check; not derived from expected service life; does not establish durability."
That sentence is worth more than a fabricated justification.
Hazards, hazardous situations, and harm
The ISO 14971 chain, and where you can act
From hazard to harm
Hazard, sequence of events, hazardous situation, harm — three places to intervene
The risk control hierarchy
| Priority | Control | On the elbow model |
|---|
| 1. Inherently safe design | Eliminate the hazard | Geometry with no pinch gap; travel limited so the strips cannot close |
| 2. Protective measures | Guard, interlock, limit | A guard over the pivot; a mechanical stop; a cord that detaches at low force |
| 3. Information for safety | Labels, instructions, training | "Keep fingers clear" — necessary, and least effective |
The order is an effectiveness ranking, not a preference. Make the wrong thing impossible.
Every control creates new questions
- Does the guard hide the anatomy the model exists to show?
- Does it obstruct the reset?
- Can it loosen and become a loose part?
- Does it create a crevice that cannot be cleaned?
- Does it add mass at the end of a moving part?
Implement the control, then re-test everything the change could affect.
Non-physical harms count
Teaching something false
is the most likely harm from a teaching aid — delayed, invisible at the bench, durable
The software equivalent: a stale value shown as current, or a label implying a judgement you are not qualified to make.
A lightweight hazard table
| Hazard | Hazardous situation | Harm | Control and how it is checked |
|---|
| Moving gap at the pivot | Finger in the gap during operation | Pinch | Limit travel so the gap stays above 20 mm; measure at every point of travel |
| Cord under tension | Part springs back toward a face | Impact | Low-force attachment; measure the release force |
| Ambiguous labelling | Learner thinks the tendon generates force | Durable misconception | Redundant labels; unfamiliar learners explain it back |
| Symmetrical parts | Reassembled wrongly after cleaning | Misleading demo or failure | Asymmetric geometry; someone reassembles from parts |
Rank by judgement and say so. A made-up probability looks like evidence and is not.
Designing a test around one question
Version, criterion agreed first, honest record
Anatomy of a test record
| Element | Content |
|---|
| Version | Exactly which configuration was tested |
| Question | The single thing this test answers |
| Requirement and criterion | Agreed before the test |
| Setup and procedure | Enough detail for someone else to repeat it |
| Result | What happened, including the unexpected |
| Conclusion | What the result supports — stated narrowly |
| Limits | What it does not establish |
| Action | What changes, and what must be re-tested |
Worked example: seven of ten
| Record | Verdict |
|---|
| "Failed at attempt 7 of 10. Cord slipped from the guide. Guide retention needs revision." | Honest |
| "Worked six times." | True and misleading — omits the criterion and the failure |
| "Mostly successful." | Not a result |
| "Passed after fixing the guide." | Conflates two versions |
| "10/10 after retest." | Only if the retest on the new version is recorded separately |
The most common documentation failure
Never carry a result forward to a version it was not obtained on.
When the object changes, ask what the change could affect — and re-run those checks.
Verification and validation
Verification
- Did we build the thing right?
- Meets its specification: 200 plus or minus 1 mm as drawn
- Failure mode: meets every dimension, unusable
Validation
- Did we build the right thing?
- Meets user needs: the educator can teach the concept
- Failure mode: users love it, a key requirement is unmet
An informal tryout is not a validation study. Call what you did by its real name.
Traceability links object to evidence
Need, requirement, design feature, verification, validation, record
Versioning a physical object
| Record | Detail |
|---|
| Identifier | V0.1, V0.2 — on the object itself, durable through cleaning |
| Design files | CAD, drawings, schematics, patterns, firmware — with revision IDs |
| Materials | Type, grade, supplier, batch; certificates where they exist |
| Process settings | CNC program, laser settings, print profile, cure schedule, stitch, weld, firmware build |
| Assembly and post-processing | Fasteners, adhesives, order; deburring, passivation, curing |
| What changed and why | The why stops you re-making an old mistake |
Put the whole project in version control, and the tag on the object's label. A photograph is not a record.
Engineering bridge: the shape of the professional process
| Element | What it is |
|---|
| Design controls | Inputs, outputs, review, verification, validation, transfer — ISO 13485 |
| Design history file | Your portfolio in miniature |
| Risk management file | ISO 14971: hazards, controls, residual risk, for the product's life |
| Usability engineering | IEC 62366-1: formative and summative evaluation |
| Software lifecycle | IEC 62304, including SOUP — your dependencies |
| Biological, electrical safety | ISO 10993; IEC 60601-1 |
| Post-market surveillance | Development does not end at launch |
Every element pairs an intention with a record. You can adopt that habit today, on a cardboard model.
Process-specific practices
Software and electronics
- Synthetic data; units in the type system
- Distinguish no-data from zero; version in the UI
- Protected cells, defined safe state, nothing on a person
Metal, moulding, fabric, glass, print
- Burrs removed; welds proof-tested; grade recorded
- Cure and lot recorded; voids and flash inspected
- Seams after real laundering; acrylic stress cracking; print orientation
Worked example: three requirements and their limits
| Requirement | What it establishes | What it does not |
|---|
| Cord pull shows visible flexion | The motion occurs; educator accepts the labelling | That all joint mechanics are shown; that learners interpret it correctly |
| Reset without tools | This educator could do it on this occasion | That all users can; that it lasts; that it is quick enough |
| Version label readable after handling | Legibility after that handling | Service life; survival of a cleaning process not yet done |
The third column is always narrower than you want, and the fourth always longer. That is honest evidence.
Workshop exercise and exit criteria
- Rewrite three adjectives as requirements; agree one criterion before testing
- Five-row hazard table including a non-physical harm
- Write a full test record before running the test — then run it
- Change one thing; list every earlier test it could invalidate; re-run two
- Rebuild a configuration from your records alone
What this chapter does not establish
- Your project is not compliant with any standard
- A bench test is not clinical evidence
- An informal tryout is not validation
- You do not decide whether the project proceeds
- Risk ranking by judgement is judgement, not quantification
Next — Health data, medical software, and security.