Focus: Medtech
Medtech regulatory outlook: What embedded system designers need to get right early
By Rita King, CEO, MethodSense F
or embedded system designers in medtech, regulatory strategy is no longer something that sits at the end
of development. It is part of the design process itself. With the FDA’s Quality Management
System Regulation (QMSR) now in eff ect and continued alignment with ISO 13485, the expectation is clear. Devices should demonstrate safety, performance and traceability as they are built. In practice, this shows up in very
tangible ways across cybersecurity, AI, human factors and traceability. Each of these areas is familiar to engineering teams, but in medtech they carry an added expectation. Design decisions need to be connected, intentional and clearly supported.
Cybersecurity – a core design input Cybersecurity is now part of system architecture from the beginning, regardless of connectivity. T e level of control depends on the device’s risk profi le, and regulators expect that risks are identifi ed early and managed throughout the product’s lifecycle. A practical example is soſt ware updates.
Designing a secure and controlled update mechanism early allows teams to manage vulnerabilities effi ciently when the device is in the fi eld. With authentication, encryption and update pathways being built into the architecture, cybersecurity becomes part of product development. Guidances such as the Secure Product
Development Framework help structure this approach by integrating cybersecurity into design reviews and system engineering.
08 June 2026
www.electronicsworld.co.uk
Designing a secure and
controlled update mechanism early allows teams to manage vulnerabilities effi ciently once the device is in the fi eld
AI requires a clear strategy AI-enabled systems introduce additional considerations that extend beyond performance during development. The focus shifts to how the model performs in the real world. For example, a model trained on a well-curated dataset may perform strongly in development, but additional planning is needed to ensure that the data reflects the intended patient population and clinical use. Engineering teams that work closely
with clinical, regulatory and biostatistical colleagues early can define data strategies that support both development and future claims. This includes understanding data sources, ensuring representation across relevant subgroups, and planning how performance will be monitored over time.
Human factors are also part of system design Human factors are most eff ective when incorporated early rather than treated as a fi nal validation step. Decisions around user interfaces, workfl ows and information display directly infl uence how a device is used in practice. For example, the way clinical data is presented can shape how a user interprets device output. T oughtful design, supported by early user feedback, reduces ambiguity and improves consistency in use. Early usability risk assessments help
identify critical tasks and guide design decisions, allowing engineering teams to address potential challenges through design.
Traceability connects design decisions Traceability is what connects these elements in practice. Under QMSR, there is an increased focus on ensuring that quality systems refl ect how work is actually performed. For engineering teams, this means connecting requirements, design outputs, risk controls and verifi cation activities in a way that clearly shows how the system evolved. When these connections are built as part of development, they provide clarity for both internal teams and regulatory review.
Submissions are built along the way Regulatory submissions become a natural outcome of development when information is captured as decisions
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44