Product architecture is the high-level structure of a medical device: how its functions are divided into subsystems (mechanical, electronic, and software) and how those parts connect through defined interfaces. It maps requirements onto components, sets boundaries for risk control, and guides design, verification, and manufacturing decisions across the device lifecycle.
What is Product Architecture?
Product architecture sits early in the device design phase, after user needs and system requirements are defined but before detailed design begins. It answers a basic question: which parts of the device do what, and where do the boundaries between them fall?
In regulated development, the architecture is a controlled design output under ISO 13485:2016 clause 7.3. It anchors traceability from requirements through to verification, and it records the reasoning behind major structural decisions. A clear architecture makes it possible to show a reviewer or auditor exactly where each requirement lives and how each risk control is implemented.
Why Product Architecture matters in medical device development
Architecture decisions are hard to reverse. By the time a device reaches detailed design or verification, the cost of restructuring subsystems climbs sharply, and a late change can trigger re-verification of everything downstream. Getting the structure right early protects both the schedule and the budget.
There is a safety dimension too. Under ISO 14971, risk controls have to be assigned to specific parts of the device. If the architecture does not cleanly separate safety-critical functions, a single fault can propagate across subsystems, which is exactly the failure mode auditors and notified bodies look for. For electrical medical equipment, IEC 60601-1 expects safety to be built into the structure through means of protection, applied by design rather than added later.
Architecture also shapes your regulatory story. A submission under EU MDR 2017/745 or an FDA review rests on technical documentation that traces requirements to design. When the architecture is muddled, that trace breaks, and reviewers notice.
How Product Architecture works
Product architecture develops through a few connected steps. The exact sequence varies by device, but the core activities are consistent across regulated programs.
- Decompose the system. Break the device into functional blocks and assign each to a domain: mechanical, electronic, embedded software, or a combination. This is where IEC 62304 clause 5.3 applies to the software portion, requiring the software system to be split into items with defined interfaces (mandatory for Class B and C software).
- Define interfaces. Specify how blocks exchange signals, data, power, and mechanical loads. Clear interfaces let teams work in parallel and make integration testing meaningful.
- Allocate requirements and risk controls. Map each system requirement and each ISO 14971 risk control onto a specific block, so nothing is orphaned and every control has an owner.
- Record design decisions. Capture why the structure looks the way it does, including trade-offs between cost, reliability, serviceability, and manufacturability.
- Verify the architecture. Confirm the structure actually supports the requirements and risk controls before committing to detailed design. IEC 62304 clause 5.3.6 calls this out explicitly for software.
The architecture feeds directly into design transfer and manufacturing. A structure that ignores how parts will be molded, machined, or assembled tends to surface problems late, during process validation or production ramp.
Common challenges and best practices
The most common mistake is treating architecture as documentation created after the fact. When engineers build first and write the architecture document later to satisfy an auditor, the document rarely matches the real system, and the traceability it is supposed to provide falls apart.
Fuzzy interfaces are another frequent problem. Two teams each assume the other handles a function, or a data format is left undefined until integration, and the gap only shows up when subsystems are joined. Writing interface specifications early and treating them as contracts prevents most of this.
Over-coupling is a third trap. When safety-critical and non-critical functions share the same component, the safety-critical classification tends to spread, pulling more of the design into the strictest verification regime and inflating cost. Good architecture isolates safety functions so rigorous testing stays focused where it is needed.
What good looks like: a small set of clearly bounded subsystems, interfaces defined before detailed design, risk controls mapped to specific blocks, and a living document that engineering actually updates as the design evolves.
How SJML helps with Product Architecture
SJML works across the full electromechanical stack, so product architecture can be handled as one connected effort rather than a set of disconnected handoffs. Its engineering teams cover mechanical, electronics, embedded software, and systems engineering, taking a device from concept and feasibility through architecture, design, verification, and design transfer. Risk management under ISO 14971 and usability engineering under IEC 62366-1 are built into the architecture work, and phase-gate program management with formal change control keeps structural decisions traceable. In-house labs for IEC 60601 electrical safety, electromagnetic compatibility, and reliability testing let architectural assumptions be checked early.
Talk to SJML’s engineering team →
Frequently asked questions
System requirements state what a medical device must do. Product architecture decides how the device is structured to meet them, dividing functions into subsystems and defining the interfaces between them. Requirements come first and stay solution-neutral. The architecture is the first major design decision that commits to a structure, and it maps each requirement onto a specific part of the device.
No single standard owns product architecture, but several shape it. ISO 13485:2016 clause 7.3 treats it as a controlled design output. IEC 62304 clause 5.3 governs software architectural design. ISO 14971 drives how risk controls are allocated to the structure, and IEC 60601-1 sets safety expectations for electrical medical equipment. EU MDR 2017/745 and the FDA QMSR then rely on that structure for technical documentation.
Product architecture is defined early, after user needs and system requirements are set and before detailed design starts. It usually falls at a phase-gate review, where the team commits to a structure before investing in detailed component design. Defining it too late is costly, since changing the structure after detailed design forces re-verification of everything built on top of it.
Regulatory submissions rest on traceability from requirements to design to verification. A clear product architecture gives reviewers a map: each requirement and risk control point points to a defined part of the device. Under EU MDR 2017/745, this feeds the technical documentation, and under the FDA QMSR, effective February 2, 2026, it supports the design and development records now framed by ISO 13485:2016.
Related terms
- Design Controls
- Design Verification
- System Requirements
- Risk Management (ISO 14971)
- Software Architecture
