How to structure a SaMD software architecture for FDA pre-submission

For engineering leads and software architects building Software as a Medical Device, regulatory compliance is often perceived as an administrative burden that happens at the end of the development cycle. When a SaMD software architecture is created without considering international lifecycle standards, primarily IEC 62304, ISO 14971, and FDA pre-market guidelines, the resulting technical debt can cause major submission delays and require complete architectural refactoring.

In agile software development, teams prioritize working code over extensive documentation. Retrospectively documenting a SaMD software architecture to satisfy an auditor or notified body is exceedingly difficult if the system was not consciously partitioned around risk and safety boundaries from the start.

By treating regulatory requirements as foundational system constraints and aligning architectural decomposition, boundary isolation, third-party dependency tracking, and cybersecurity controls directly within your system blueprints, you establish a predictable path through technical documentation reviews.

1. Decomposing a SaMD software architecture under IEC 62304

To build a compliant system, you must first adopt the explicit structural hierarchy defined by IEC 62304. The standard expects manufacturers to iteratively decompose a SaMD software architecture into a structured tree:

• Software system – SaMD application as defined by its intended medical purpose.
  
• Software items – Discrete structural or logical sub-components resulting from system decomposition. A software item can be composed of other software items.
  
• Software units – The lowest level of architectural decomposition, where the internal logic is small enough to be verified through unit testing rather than system integration testing.
  
• Software interfaces – The explicit boundaries, data contracts, API protocols, and shared memory spaces that govern communication between software items, units, or external systems.

The depth of your architectural design documentation depends on the safety classification of your software items. Under IEC 62304, software items are assigned a safety class based on the potential severity of harm resulting from a software failure:

• Class A – No hazardous situation or injury is possible, or effective risk control measures exist external to the software system.
  
• Class B – Non-serious injury is possible.
  
• Class C – Death or serious injury is possible.

For Class B and Class C software, regulatory reviewers expect detailed architectural descriptions for every item and interface, alongside explicit justifications for how data flows safely across boundaries.

2. Risk segregation in a SaMD software architecture

A primary challenge in a SaMD software architecture is avoiding a monolithic codebase where high-risk and low-risk functions are tightly coupled. If a diagnostic algorithm shares an execution process, memory pool, or database instance with a simple audit logger or UI layout renderer, regulatory standards require the entire software system to be tested at the highest applicable safety class.

To prevent this bottleneck, architects use item segregation to isolate safety-critical modules from non-critical ones. Segregation can be achieved logically (via strict API encapsulation, containerization, or process isolation) or physically (via separate cloud microservices or execution environments).

Practical application of risk segregation

Consider a digital therapeutics application for diabetes management:

• Dose calculation engine (Class C / Enhanced) – Calculates medication doses based on real-time blood glucose metrics. A calculation anomaly could cause severe hypoglycemia or death.
• Dose history viewer (Class A / Basic) – Displays historical log entries to the user. A rendering failure might cause inconvenience, but it does not present a direct clinical hazard if isolated.
• Audit logger (Class A / Basic) – Records telemetry and system interactions for analytics.

If the history viewer and audit logger are properly segregated from the calculation engine within the SaMD software architecture, ensuring memory corruption or process crashes in the UI cannot cause the calculation engine to output an incorrect value, the manufacturer can justify a reduced testing and documentation scope for those non-critical modules. This isolation also simplifies post-market maintenance: teams can update the UI or logging logic without triggering a full regression test of the safety-critical dose engine.

3. Third-party dependencies in a SaMD software architecture

Modern software applications rely heavily on commercial libraries, open source packages, and cloud runtime environments. Regulators categorize these external components as Off The Shelf (OTS) software or Software of Unknown Provenance (SOUP).

Because you do not control the software lifecycle or source code of SOUP components, you cannot perform traditional unit-level verification on them. As the medical device manufacturer, you retain full legal responsibility for any device failure introduced by third-party code.

Regulatory expectations for SOUP management

• Functional and structural requirements – You must document the exact title, manufacturer, version, patch release, and hardware or software prerequisites for every third-party component.
  
• System and integration testing – Because unit testing SOUP is impossible, verification shifts heavily to integration and system-level testing. You must prove through interface testing that inputs to and outputs from the SOUP component behave safely under edge conditions.
  
• Restricting unneeded functionality – Your SaMD software architecture must prevent unused third-party capabilities from executing in the background. For example, unused communication ports, debugging protocols, or background telemetry services must be explicitly disabled at the system level.
  
• Obsolescence and end-of-life planning – Open source packages and commercial operating systems eventually reach End of Life (EOL). Your technical file must contain an active decommissioning and patch migration plan detailing how package deprecations will be handled without compromising patient safety.

4. Cybersecurity in a SaMD software architecture

Under Section 524B of the FD&C Act in the U.S. and corresponding MDCG guidelines in Europe, any SaMD that connects to the internet, whether via Wi Fi, cellular, Bluetooth, or cloud API endpoints, is classified as a cyber device and must implement a Secure Product Development Framework (SPDF).

Cybersecurity cannot be retrofitted through external penetration testing at the end of development. It must be depicted directly within your SaMD software architecture through four specific Security Architecture Views:

1. Global system view

Maps the entire deployment ecosystem. It must detail all physical and cloud assets, database engines, external API gateways, third-party integrations, and communication protocols (including TLS encryption versions).

2. Multi-patient harm view

Demonstrates how the SaMD software architecture isolates users to prevent a single security compromise from scaling into a systemic event. Key architectural controls include multi-tenant database isolation, role-based access control (RBAC), token authentication at every microservice boundary, and cryptographic separation of user data.

3. Updatability and patchability view

Documents the secure, end-to-end pathway for deploying over-the-air (OTA) updates and emergency vulnerability patches. The architecture must show how updated binaries are cryptographically signed on secure build servers and verified by the target client device before execution, ensuring resilience against man-in-the-middle (MitM) attacks.

4. Security use case view

Uses call flow diagrams to demonstrate how sensitive workflows (such as user authentication, password resets, clinical data queries, and system configuration changes) are handled across logical trust boundaries.

Submissions must include a machine-readable Software Bill of Materials (SBOM) generated during the build pipeline. The SBOM catalogs every open source package, third-party library, and operating system dependency to enable continuous vulnerability tracking post-launch.

5. Pre-submission checklist for your SaMD software architecture

Before finalizing your technical documentation for submission to a Notified Body or FDA reviewer, verify your system design against the following criteria:

• Hierarchical decomposition – The system is broken down into software items, units, and interfaces according to IEC 62304 guidelines.
  
• Documented segregation – Safety-critical items are isolated from non-critical items, supported by an architectural rationalization document that justifies reduced verification scope for Class A or Basic items.
  
• Interface specifications – All internal and external interfaces (including data formats, parameters, range checks, and error handling) are defined in detailed interface design specifications.
  
• SOUP registry and testing – Every third-party library is logged with its exact version, and integration tests verify its behavior under edge conditions.
  
• Port and feature restriction – Unused communications ports, hardware connectors, and unused SOUP functions are explicitly disabled in the system configuration.
  
• Complete SBOM – A machine-readable Software Bill of Materials is generated and checked against active vulnerability databases.
  
• Security architecture views – Visual diagrams and explanatory narratives cover the Global System, Multi Patient Harm, Updatability, and Security Use Case views.
  
• Bidirectional traceability – A traceability matrix links clinical hazards identified in ISO 14971 risk management to software safety requirements, specific architectural items, and corresponding test records.

Conclusion

Speaking from years of leading MedTech engineering teams, treating a SaMD software architecture as an administrative checklist for regulatory auditors is the fastest way to burn through your runway. I have seen too many projects stall because engineering teams ignored compliance constraints during early system design. The result is always the same, late-stage refactoring, endless regression testing cycles, and a delayed market entry that frustrates both investors and stakeholders. The cost of ripping apart a monolithic codebase to satisfy an FDA reviewer will absolutely always outweigh the initial effort of architecting it correctly.

When you require your team to embed risk segregation, SOUP management, and cybersecurity controls directly into the codebase from day one, your technical documentation simply becomes a natural byproduct of good engineering.

You stop fearing the compliance review by doing the hard architectural work upfront, and then regulatory submissions transition from a high-risk bottleneck into a completely predictable milestone in your product roadmap.