Product architecture is the high-level structure of a medical device: how its functions are divided among mechanical, electronic and software subsystems and how those parts connect through defined interfaces. It provides the structural foundation for an electromechanical medical device, mapping requirements onto components, establishing boundaries for risk controls, and guiding design, verification and manufacturing decisions across the device lifecycle.
What is Product Architecture?
Product architecture is developed early in the medical-device design phase, after user needs and system requirements have been defined but before detailed design begins. It answers two fundamental questions: which parts of the device perform each function, and where do the boundaries between those parts fall?
A product architecture may divide a device into:
- Mechanical structures, housings and mechanisms
- Electronic circuits, sensors and power systems
- Embedded software and firmware
- User-interface components
- Communications and connectivity functions
- Disposable and reusable elements
- Accessories and external equipment
In regulated medical-device development, the architecture is a controlled design output under ISO 13485:2016 Clause 7.3. It anchors traceability from requirements through design and verification. A maintained Requirements Traceability Matrix (RTM) can connect each system requirement and risk control to the subsystem that implements it and the evidence used to verify it.
Product-architecture records should also capture the reasoning behind major structural decisions. A clear architecture allows engineers, reviewers and auditors to understand where each requirement is implemented, how subsystems interact and where individual risk controls operate.
Why Product Architecture matters in medical device development
Architecture decisions are difficult and expensive to reverse. By the time a device reaches detailed design or verification, restructuring its major subsystems can require changes to hardware, software, interfaces, documentation and testing. A late architectural change may trigger re-verification of everything downstream, affecting both the project schedule and budget.
Product architecture also has a direct safety role. Under ISO 14971, risk-control measures must be implemented in identifiable parts of the device. If the architecture does not separate safety-critical functions appropriately, a single fault may propagate across multiple subsystems.
For medical electrical equipment, IEC 60601 expects basic safety and essential performance to be established through the device’s design. Electrical isolation, means of protection, alarm behavior, power boundaries and single-fault safety therefore need to be considered within the architecture rather than added after detailed design.
Architecture also shapes the device’s regulatory evidence. Submissions under EU MDR 2017/745 and FDA requirements depend on technical documentation that traces requirements and risk controls to the resulting design. When subsystem boundaries and interfaces are unclear, that traceability becomes difficult to demonstrate and reviewers may question whether all requirements and risks have been addressed.
How Product Architecture works
Product architecture develops through several connected activities. The precise sequence varies with device type and complexity, but the core activities remain consistent across regulated programs.
Decompose the system
Break the device into functional blocks and assign each function to a mechanical, electronic, software or combined subsystem. Each block should have a defined purpose, owner and relationship with the rest of the device.
For software-containing devices, IEC 62304 requires the software system to be divided into software items with defined interfaces. This architectural activity is particularly important for Class B and Class C software, where inadequate separation can expand the scope of safety-critical development and testing.
Define the interfaces
Specify how the architectural blocks exchange:
- Data and control signals
- Electrical power
- Mechanical loads
- Fluids or gases
- Thermal energy
- User inputs and outputs
- Alarms and status information
Clear interface definitions allow engineering teams to work in parallel and make integration testing meaningful. Interfaces should state the expected inputs, outputs, limits, failure behavior and responsible subsystem.
Allocate requirements and risk controls
Map every system requirement and ISO 14971 risk-control measure to the subsystem responsible for implementing it. This allocation prevents orphaned requirements and ensures every risk control has a defined owner.
Requirements shared across multiple subsystems need particular attention. The architecture should identify which subsystem owns the requirement and how the other participating elements will be integrated and verified.
Record architectural decisions
Document why the structure was selected, including relevant trade-offs involving:
- Safety
- Performance
- Reliability
- Cost
- Manufacturability
- Serviceability
- Cybersecurity
- Component availability
- Future product variants
Recording the rationale helps later teams understand why a decision was made and whether a proposed change could undermine an earlier safety or performance assumption.
Verify the architecture
Review the architecture before committing substantial resources to detailed design. Confirm that it supports the approved system requirements, intended use, risk controls and applicable standards.
Architectural verification should examine whether:
- Every function has been assigned to a subsystem.
- Every requirement has an implementation path.
- Safety-critical functions are appropriately isolated.
- Interfaces are complete and unambiguous.
- Expected failures are contained.
- The proposed structure can be integrated, tested and manufactured.
- Architectural assumptions are supported by analysis or evidence.
For software, IEC 62304 Clause 5.3.6 explicitly requires verification of the software architecture.
Prepare for design transfer and manufacturing
Product architecture feeds directly into detailed design, design transfer and production planning. A structure that ignores how parts will be molded, machined, assembled, tested or serviced tends to create problems during process validation or manufacturing scale-up.
Applying Design for Manufacturability (DfM) during architecture development helps teams evaluate assembly strategy, component access, tolerance interactions, inspection requirements and production risks before the design becomes expensive to change.
Common challenges and best practices
The most common mistake is treating architecture as documentation created after the engineering work has already been completed. When teams build the device first and write the architecture document later to satisfy an auditor, the documented structure rarely matches the actual system. The traceability the architecture is supposed to provide then breaks down.
Fuzzy interfaces are another frequent problem. Two teams may each assume that the other owns a function, or a data format may remain undefined until integration. The problem becomes visible only when the subsystems are connected. Writing interface specifications early and treating them as controlled agreements prevents many integration failures.
Over-coupling is a third risk. When safety-critical and non-critical functions share the same component without adequate separation, the safety-critical classification can spread across a larger portion of the device. That increases the amount of design documentation, risk control and verification required.
Other common problems include:
- Allocating one requirement to several subsystems without assigning a clear owner
- Failing to document architectural assumptions
- Ignoring manufacturing and service requirements
- Allowing software, electronics and mechanical teams to create incompatible interface definitions
- Changing subsystem boundaries without assessing downstream verification
- Treating architecture review as an informal engineering meeting rather than a controlled design review
Good product architecture consists of a manageable set of clearly bounded subsystems, interfaces defined before detailed design, requirements and risk controls mapped to specific blocks, and a living architectural record that engineering updates as the design evolves.
Architecture should be reviewed by representatives from systems, mechanical, electronics, software, quality, regulatory, manufacturing, service and clinical functions where appropriate. Cross-functional review identifies boundary problems that individual engineering disciplines may not see.
How SJML helps with Product Architecture
SJML develops product architecture through its end-to-end medical device design and engineering capabilities. Its teams work across mechanical engineering, electronics, embedded software, firmware and systems engineering, allowing architecture to be managed as one connected activity instead of a collection of disconnected supplier handoffs.
SJML supports programs from concept and feasibility through system architecture, detailed design, verification and design transfer. ISO 14971 risk management and IEC 62366-1 usability engineering are incorporated into architectural decisions, while phase-gate program management and formal change control keep structural decisions documented and traceable.
In-house laboratories support IEC 60601 electrical-safety, electromagnetic-compatibility, reliability, environmental and endurance testing. These capabilities allow architectural assumptions involving isolation, power, thermal behavior, interfaces and subsystem reliability to be evaluated before the design reaches costly production tooling.
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.
