Design Documentation (SAD/SDD)

Create SAD and SDD documents for medical device software per IEC 62304.

26|6|Updated Jan 4, 2026
One-click install
npx skills add https://github.com/AminAlam/meddev-agent-skills --skill design-documentation-sad-sdd
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: Design Documentation (SAD/SDD)
Source: https://github.com/AminAlam/meddev-agent-skills/tree/main/documentation/design-docs
Command: npx skills add https://github.com/AminAlam/meddev-agent-skills --skill design-documentation-sad-sdd

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

This Skill addresses the challenge of creating and maintaining comprehensive Software Architecture (SAD) and Design Descriptions (SDD) that are crucial for medical device safety, traceability, and regulatory compliance.

Core Features & Use Cases

  • Architecture Documentation: Guides the creation of SAD documents detailing components, interfaces, data flows, and safety segregation.
  • Design Detailing: Provides requirements for module-level design documentation for Class B/C software, including algorithms, state machines, and error handling.
  • Traceability: Emphasizes linking design elements to requirements, hazards, and tests.
  • SOUP Management: Includes guidance on documenting Software of Unknown Provenance (SOUP).
  • Use Case: When developing a new Class C medical device, use this Skill to ensure your SAD and SDD meet IEC 62304 and ISO 14971 requirements, including clear documentation of safety boundaries and SOUP components.

Quick Start

Generate comprehensive design documentation for a Class C medical device software component, ensuring traceability to requirements and hazards.

Frequently Asked Questions about Design Documentation (SAD/SDD)

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I document software architecture for a Class C medical device to meet IEC 62304?

To document software architecture for a Class C medical device under IEC 62304, create a Software Architecture Description (SAD) detailing components, interfaces, data flows, and safety segregation, ensuring full traceability to requirements and hazards.

What is SOUP documentation and how is it handled in software design descriptions?

SOUP (Software of Unknown Provenance) documentation in software design descriptions involves recording details of third-party or legacy components used in the medical device software, ensuring their anomalies and configurations are tracked for compliance.

How do I maintain traceability between software design elements and hazards for ISO 14971 compliance?

Maintaining traceability for ISO 14971 compliance involves explicitly linking your software architecture and module-level design elements directly to identified hazards, risk control measures, and corresponding verification tests.

What level of design detail is required for module-level documentation in medical device software?

Module-level design documentation for medical device software requires detailing algorithms, state machines, error handling, and interface specifications to satisfy the safety and compliance requirements for Class B and C software.

Can I use this approach to update an existing Software Architecture Description (SAD)?

Yes, you can use this approach to update an existing Software Architecture Description (SAD) by following the defined update procedures to revise architecture views, SOUP documentation, and traceability linkages as the software evolves.

When do I need to establish safety segregation in my software architecture documentation?

You need to establish safety segregation in software architecture documentation when designing medical device software that incorporates SOUP or modules with varying safety classifications, preventing hazardous interactions and ensuring IEC 62304 compliance.