How to Structure and Document Your SaMD Software Architecture for Efficient Certification
A Software-as-a-Medical-Device (SaMD) manufacturer must carefully and thoroughly consider software architectural design from the beginning of product development and throughout. What are the best ways to design and document your software architecture in preparation for certifying your SaMD product?
Why is software architecture important in SaMD development?
The software medical device standard IEC 62304 has explicit expectations on the documented evidence of your software architectural design. Whilst modern agile software development practices promote working software over comprehensive documentation, attempting to retrospectively document a complete software architecture to support your SaMD certification can be challenging if the software architecture was not consciously designed with IEC 62304 in mind.
To avoid trouble later on, it is important to understand the architectural design guidelines within IEC 62304 before developing your SaMD product.
Outside of SaMD certification, following industry-standard software architectural design best practices is also important to facilitate the development of a high-quality, testable, maintainable, and scalable software product.
How should you document your SaMD software architecture?
For software systems with a safety classification of class B or C, IEC 62304 expects the creation of a software architecture in which the system is decomposed into the following component types:
- items
- interfaces
- units
The standard explains that the software system shall be iteratively decomposed by the manufacturer into a hierarchy of software items, with the lowest level of decomposition chosen by the manufacturer termed software units. Interactions between items, units, or external software systems shall be described by software interfaces.
The level of software architectural design documentation, and associated detailed software design documentation, required by the manufacturer increases for safety-critical software, where documentation is also required to describe any segregation between software items for the purposes of risk control, and must describe the detailed design of individual software units.
This guidance in IEC 62304 is akin to modular software architecture, which is a common design approach in the broader software engineering industry. Here, software systems are divided into discrete modules that encapsulate specific functionality. These modules can be decomposed into sub-modules and granular software units, with components interacting through well-defined software interfaces, similar to the above guidance from IEC 62304. The difference in terminology used by IEC 62304 merely groups software modules and units under a single term: software items. For familiarity, this article shall speak in terms of software modules, units and interfaces.
Why is modular software architecture encouraged by the standards?
As stated, defining software architecture in terms of software module, unit, and interface components is common in software engineering. The software medical device standards encourage this approach for the following reasons:
- Separation of concerns
- Modular software can be decomposed such that a software component addresses a single concern or function
- Encapsulation and interfaces
- Encapsulation conceptually separates internal logic within a software module or unit from the interface it shares with other components. This improves design clarity and minimises the surface of interactions between software components
- Re-usability
- Modularity allows for easy re-use of software components within or across products
- Rigorous and traceable verification
- Modular software enables tiers of software testing, such as unit testing, integration testing, and system testing. This makes identifying and resolving issues discovered in the software product easier
- Change management
- When modifying the software after release, it is possible to justify reducing the scope of regression testing activities if the change is limited to a subset of isolatable software modules
- Segregation of risk
- Modularity allows safety-critical software modules to be isolated from non-critical software modules and, thus, allows for independent safety classification to be applied to each module
As specified by IEC 62304, all software components defined in your software architecture will inherit a software safety classification based on the risk profile of your device. The classification is assigned as follows:
- Class A: No hazardous situation due to software failures, or effective risk control measures external to the software system that reduce the risk to an acceptable level
- Class B: Hazardous situations due to software failures might arise, resulting in non-acceptable risks (after consideration of risk controls external to the software system) but limited to non-serious injuries
- Class C: Hazardous situations due to software failure might arise, resulting in non-acceptable risks (after consideration of risk controls external to the software system) with the potential of serious injury or death.
In order to meaningfully separate each component and the safety classification thereof, the segregation of risk is a great tool. Segregation of risk involves isolating software components within your device to limit the impact of software failures. It is advisable to define your architecture of software components such that safety-critical functions are sufficiently isolated from non-critical functions and ensure that the failure modes of the non-critical software components cannot result in failures of the safety-critical software components. Subsequently, by evaluating the risk of each individual software component, it is possible to lower the software safety classification of non-critical software components.
Software components classified as Class B and Class C require more extensive risk analysis, verification, and documentation. Therefore, by providing sufficient reasoning for reducing the safety classification of software components in your device, you will benefit from a more efficient path to certification and a safer device.
An example of risk segregation within software architecture could be evident within an SaMD product that uses an advanced mathematical model to calculate required medication doses based on a trend of prior doses and health indicators. This device could contain the following software modules:
- Dose-calculation algorithm: This is a safety-critical software module that calculates the dose of medication required to be taken by the patient. A failure or miscalculation within this function could result in serious injury to the patient
- Dose-history viewer: This software module allows a patient to view a history of their previous doses. A failure or incorrect display within this function may not lead to serious injury. This module's classification could be reduced if sufficiently isolated from the safety-critical software module
- Audit logger: This software module logs a history of user data and actions. It is of business value to the manufacturer but does not influence the medical device's primary function. This module's classification could be reduced if sufficiently isolated from the safety-critical software module
Final Thoughts: Balancing compliance, efficiency, and safety
By following the above key principles of SaMD software architectural design, you will ensure that your software architecture is designed and documented in accordance with the expectations of IEC 62304, and is optimised for efficient completion and documentation of related regulatory activities, such as risk management, verification, and change management. And most importantly, it will enhance the safety of your device.
Prioritising software architecture from the start will save time, reduce compliance hurdles, and contribute to the long-term success of your SaMD product.

Want Scarlet news in your inbox?
Sign up to receive updates from Scarlet, including our newsletter containing blog posts sent straight to you by email.