Biomedical Engineering Editing and Proofreading Services

A device fails its verification testing eleven months into development, and the review discovers that the requirement it failed was never testable in the first place. "The device shall be easy for a nurse to clean" survived every review because everyone agreed with it. Nobody could design a test for it, so a test was invented late, and the argument that followed was about the requirement rather than the device. Almost every expensive surprise in device development traces back to a sentence written in the first quarter.

We edit what biomedical engineers and device developers produce — design input and requirement specifications, design and development plans, traceability matrices linking needs to verification, risk management files and hazard analyses, verification and validation protocols and reports, usability engineering files and use-related risk documentation, biocompatibility and sterilisation rationale documents, software as a medical device documentation, design review and design transfer records, technical files and design history documentation, supplier specifications and incoming inspection criteria, and labelling and instructions for use drafts. Our editors work on the sentence everything downstream is tested against.

The design input requirement is the highest-leverage sentence in device development, and the test of a good one is brutally simple: could two engineers who have never met design the same test for it? We work through requirement sets so every statement carries a measurable criterion with its units, its tolerance and the condition under which it applies, since "shall withstand normal handling" and "shall withstand a 1 m drop onto a hard surface in each of six orientations with no loss of function" are not the same sentence in any respect that matters; so subjective terms such as easy, robust, minimal and user-friendly are replaced by the observable behaviour that stands behind them, often a task time, a force, a temperature or an error rate; so each requirement states one thing, because a compound requirement passes half and fails half and no verification record can express that; so requirements traceable to a user need are distinguished from those traceable to a standard or a regulation, given that the two behave differently when a change is proposed; and so anything genuinely undecided is recorded as an open item with an owner rather than written as an aspiration that hardens into a specification. Requirements written this way keep the arguments in month two, where they are cheap.

Everything you send is treated in confidence, including designs, risk files and clinical information. We are editors rather than regulatory, clinical or engineering advisers, and we offer no view on device design, safety or compliance. What we can do is make each requirement mean the same thing to everyone who reads it.