A medical device company can usually find people who can design the hardware. What it struggles to find is people who can design it in a way that will be approved, and then keep it compliant for its commercial life.
That is a training gap rather than an engineering one, which makes it unusually tractable.
The engineering is rarely the constraint
Engineers arriving from aerospace, automotive, industrial electronics or consumer hardware bring design capability that transfers directly. Mechanical design, electronics, embedded software, materials, manufacturing.
What they arrive without is the framework the device has to live inside.
In most industries the documentation describes the product. In medical devices the documentation is part of the product, and a design decision that cannot be justified in the file is a design decision that cannot ship.
Four things are unfamiliar to almost everyone coming from outside.
Everything must be justified and traceable. Design decisions trace to requirements, requirements trace to clinical need and risk, and verification traces back to both.
The evidence bar is clinical. Demonstrating that a device works means demonstrating it in use, against a defined intended purpose, with data.
Classification drives everything. How a device is classified determines the evidence, the scrutiny and the route to market, and getting that wrong early is expensive.
Changes are not free. A modification that would be routine elsewhere can require re-verification and sometimes regulatory notification.
What the direction covers
The scope: diagnostic devices, implants and wearables, biomedical electronics, safety and regulatory approval.
Four capabilities.
Biomedical engineering fundamentals. Designing for interaction with a body, including biocompatibility, sterilisation, and the physiological variation covered in the anatomy direction.
Design controls and the technical file. The structured process that makes a design defensible.
Risk management. Covered below.
Regulatory pathways. Classification, conformity assessment, clinical evaluation and the approval routes in the relevant markets, which differ enough that a product strategy has to account for them.
Risk management as a design discipline
The single most misunderstood part of the field by people arriving from other industries.
Risk management here is not a document produced before submission. It is a process running through the entire lifecycle, and it has a specific logical structure.
Identify hazards arising from the device, including from foreseeable misuse rather than only from correct use.
Estimate risk in terms of severity of harm and probability of occurrence.
Control risk, in a defined order of preference: design it out first, then protective measures, then information for safety. Relying on a warning in a manual when the hazard could have been designed out is not acceptable, and this ordering catches out teams used to industries where a warning label is a legitimate control.
Evaluate residual risk against the clinical benefit, which is a judgement requiring clinical input rather than engineering alone.
Monitor in the field, because real use reveals hazards that analysis did not.
Teams that treat this as documentation produce files that fail review. Teams that treat it as a design method produce safer devices and, incidentally, files that pass.
Where this sits in the domain
Medical devices and biomedical engineering is the seventh of ten directions in Astra Trainer's medicine and healthtech domain, drawing on anatomy and physiology for the body-interaction layer and connecting to medical AI and imaging, health informatics, and healthcare systems and regulation.
For partners whose engineers come from other sectors, it is usually scoped alongside domains those engineers already know: advanced manufacturing for quality engineering and reliability, semiconductors and electronics for the hardware layer, and advanced materials for biomaterials. That cross-domain shape is common, because the engineering exists and the clinical and regulatory layers are what is missing. You can see the ten directions here.
Software as a device, which catches people out
Software that performs a medical function can itself be a regulated medical device, independent of any hardware.
This surprises teams from a software background, and the consequences are substantial.
Development process is regulated. Software lifecycle requirements apply, with documentation, verification and configuration management expectations that do not resemble a typical commercial development process.
Rapid iteration becomes complicated. Continuous deployment is difficult when changes may require re-verification or notification, and teams have to design a release process that accommodates both.
Intended purpose defines the boundary. The same functionality can fall inside or outside regulation depending on what it claims to do. Marketing language can move a product across that line without anyone in engineering noticing, which is a genuine organisational risk.
Cybersecurity is a regulatory expectation, not only an engineering one, because a security failure in a connected device is a patient safety failure.
Software teams entering healthtech need this early. Discovering it late means rebuilding a development process around a product that has already been built.
The roles, named
Design and development engineers across mechanical, electronic and software specialisms.
Regulatory affairs specialists. Persistently short and central to timelines.
Quality engineers and quality management staff.
Verification and validation engineers.
Usability and human factors engineers. A regulatory requirement and a scarce specialism, because use error is a recognised source of harm and designing it out is a discipline in its own right.
Clinical affairs staff, generating and evaluating clinical evidence.
Post-market surveillance and vigilance staff.
Biomedical equipment technicians in health services, maintaining and calibrating devices in use. A large and frequently overlooked population.
Who can be trained into it
Engineers from other regulated industries. Aerospace and automotive staff already understand traceability, verification and safety culture, and the transfer is mostly a matter of learning a different framework rather than a different mindset.
Engineers from unregulated industries. Consumer electronics and general software. Strong technically, and the regulatory layer is a genuine adjustment rather than an addition.
Quality professionals from other sectors. Direct transfer of the quality system mindset.
Clinical staff moving into industry. Into clinical affairs, usability and product roles, bringing the understanding of actual use that engineering teams most lack.
Biomedical equipment technicians. Already understand devices in real clinical use, which is an unusual and valuable perspective, and a route into design or quality roles.
Manufacturing staff from regulated production. Pharmaceutical or aerospace, into device manufacturing.
Regulatory obligations are legal. Placing a medical device on the market requires conformity with the applicable regulations in each jurisdiction, and these differ. Quality management system certification, notified body or regulator involvement, clinical evaluation and post-market obligations are legal requirements with penalties attached. Training builds engineering and regulatory understanding. It does not constitute regulatory approval, quality system certification, or authority to place a device on any market, and regulatory strategy for a specific product requires qualified professional advice.
Post-market, which is where the obligations continue
Approval is a milestone rather than an endpoint, and teams that treat it as the finish line create problems.
Surveillance is required. Manufacturers must actively monitor performance in use, not wait for complaints.
Incidents have reporting timelines that do not flex.
Clinical evidence needs maintaining, not only generating once.
Field actions and recalls have to be executable, which means traceability has to work in practice rather than in principle.
The workforce consequence is that post-market functions need real staffing from launch, and they are consistently under-resourced because they are not part of the excitement of getting a product approved.
What to take from this
The engineering transfers. The regulatory and evidence framework is the gap, and it is trainable.
Risk management is a design discipline with a defined control hierarchy, and a warning in a manual is not an acceptable substitute for designing a hazard out.
Software can be a device in its own right, and intended purpose is what decides. Marketing language can move that line without engineering knowing.
Usability is a regulatory requirement because use error harms people, and human factors engineers are genuinely scarce.
And obligations continue after launch, so post-market functions need staffing from day one rather than after the first incident.
What is hardest about medical device engineering?
Not the engineering. The requirement that every design decision be justified, traceable and supported by clinical evidence against a defined intended purpose, and that changes may trigger re-verification.
Is software a medical device?
It can be, depending on what it claims to do. Intended purpose decides, which means marketing language can move a product across the regulatory boundary without engineering noticing.
Why does usability have regulatory weight?
Because use error is a recognised source of patient harm. Designing it out is a discipline in its own right, and human factors engineers are consistently scarce.
Who converts into this field well?
Engineers from aerospace and automotive, who already hold traceability and safety culture; quality professionals from any regulated sector; clinical staff moving into clinical affairs and usability; and biomedical equipment technicians, who understand devices in real use.
Where does this fit in the domain?
Seventh of ten directions in Astra Trainer's medicine and healthtech domain, frequently scoped with advanced manufacturing, electronics or advanced materials. You can see them here.