Medical Device Design & Development

Design controls can feel like an imposition on the creative act of designing a product, but they exist for a genuine reason. History is full of medical devices that failed not because the technology was bad but because the design process was undisciplined — a requirement that was never really pinned down, a change made without understanding its consequences, a test that did not actually verify what it claimed. Design controls are the response: a requirement that the development of a device be deliberate, documented and traceable, so the design that reaches patients is one that was properly thought through.

The practical effect is that you cannot simply build a prototype, like it, and manufacture it. You have to be able to show what the device was required to do, how the design meets those requirements, and how you verified and validated it. Far from stifling good engineering, this discipline usually improves it, because it forces the requirements to be clear and the testing to be meaningful. We implement design controls in a way that supports the engineering rather than smothering it, so the process adds rigour without killing pace.

• Many device failures are design-process failures, not technology failures.
• Design controls make development deliberate, documented and traceable.
• Done well, they improve the engineering rather than hinder it.

Everything downstream depends on the design inputs — the definition of what the device must do. These come from the intended use and the real needs of the users, from the applicable standards and regulations, and from the risks the device must control. Vague, incomplete or unrealistic inputs are the original sin of device development: a requirement that is not measurable cannot be verified, and a user need that was never properly captured produces a device that works on the bench but disappoints in the field. Time spent getting the inputs right is repaid many times over.

We help you develop design inputs that are clear, complete, measurable and traceable to their source, so the rest of the process has a firm foundation. This is unglamorous work — interrogating what the device really needs to do, translating fuzzy user needs into concrete specifications, folding in the standards that apply — but it is where the quality of the whole development is largely determined. A design built on solid inputs tends to sail through verification; one built on shaky inputs tends to thrash.

Verification and validation are often confused, but the distinction is fundamental. Verification asks: did we build the device right — do the design outputs meet the design inputs? Validation asks: did we build the right device — does the finished product meet the user needs in real-world use? Both are required, and both have to genuinely close the loop: verification tests that actually demonstrate the inputs are met, and validation that actually confirms the device works for real users in the real environment, not just in an idealised test.

The frequent failing is verification and validation that look thorough but do not truly connect to the requirements — tests run because they are easy rather than because they prove the inputs are satisfied, or validation in conditions too controlled to reflect real use. We design verification and validation that genuinely answer the questions they are meant to, with clear traceability back to the inputs and user needs. That traceability is exactly what an auditor follows, and a chain that holds together is one of the clearest signs of a well-controlled design.

A striking proportion of medical-device incidents stem not from the device breaking but from how it is used — a control misread, a step performed out of order, an alarm missed. Usability engineering, framed by IEC 62366, treats this as a design problem rather than a training problem: it studies how real users interact with the device in the real environment, identifies where use errors could occur and what harm they could cause, and drives design changes to make the safe use the natural use. Regulators increasingly expect this work, especially for devices where a use error could seriously harm someone.

We build usability engineering into the development so use-related risk is designed out where possible rather than papered over with warnings in a manual nobody reads. This means understanding the actual users and environment, evaluating the interface and workflow, and feeding the findings back into the design and the risk file. A device that is genuinely easy and safe to use is not only more compliant; it is a better product, and the usability work that gets it there is increasingly non-negotiable in a serious submission.

• Many device incidents come from use errors, not device failures.
• IEC 62366 treats usability as a design problem, not a training one.
• Designing for safe use beats warning against unsafe use.

All of this development effort has to be captured in a Design History File — the record that demonstrates the device was developed in accordance with the design controls. The DHF tells the whole story: the inputs, the outputs, the reviews, the verification and validation, the changes and their justification. A complete, coherent DHF is one of the strongest signals to a regulator that a device was properly developed; a thin or retrospectively assembled one is a classic and serious audit finding, because it suggests the controls were an afterthought rather than a discipline.

We build the Design History File as development proceeds, not as a reconstruction at the end, so it grows naturally and tells an honest, contemporaneous story. This contemporaneity matters: a DHF assembled after the fact rarely holds together under scrutiny, and the effort to fake one is both large and risky. Captured as you go, the DHF is simply the by-product of doing development properly, and it becomes a genuine asset — the evidence base your regulatory submissions draw on directly.

A design is not finished when it works in the lab; it is finished when it can be manufactured consistently and to specification, which is what design transfer achieves. Transfer is the deliberate hand-off from development to production — turning the design outputs into manufacturing specifications, procedures and controls, and confirming that the production process actually makes the device as designed. A design that works as a prototype but was never properly transferred is a design that produces scrap, variation and frustration when manufacturing tries to scale it.

We manage design transfer so the move from development to production is controlled and complete, connecting it to the validation that proves the manufacturing process and to the quality system that will govern ongoing production. Done well, transfer is the bridge that turns a good design into a manufacturable product; done poorly or skipped, it is where a promising device stumbles at the last step before it can actually be made and sold at scale.