Skip to main content
QMSQMS
QMS
  • Welcome to your QMS
  • Quality Manual
  • Procedures
    • GP-001 Control of documents
    • GP-002 Quality planning
    • GP-003 Audits
    • GP-004 Vigilance system
    • GP-005 Human Resources and Training
    • GP-006 Non-conformity, Corrective and Preventive actions
    • GP-007 Post-market surveillance
    • GP-008 Product requirements
    • GP-009 Sales
    • GP-010 Purchases and suppliers evaluation
    • GP-011 Provision of service
    • GP-012 Design, redesign and development
      • Deprecated
      • Templates
        • T-012-004 Software version release
        • T-012-005 Design change control
        • T-012-006 _Product name_ life cycle plan and report_YYYY_nnn
        • T-012-007 Formative evaluation plan_YYYY_nnn
        • T-012-008 Formative evaluation report_YYYY_nnn
        • T-012-009 Validation and testing of machine learning models_YYYY_nnn
        • T-012-010 Device backup verification_YYYY_nnn
        • T-012-012 Customers product version control_YYYY_nnn
        • T-012-013 Design stage review
        • T-012-014 Summative evaluation plan_YYYY_nnn
        • T-012-015 Summative evaluation report YYYY_nnn
        • T-012-016 Software usability test guide
        • T-012-017 Integration test review
        • T-012-019 SOUP
        • T-012-020 Predetermined Change Control Plan
        • T-012-021 Product Design Phase 1 Checklist
        • T-012-022 Software Design Phase 2 Checklist
        • T-012-023 Software Development Plan
        • T-012-024 Software Candidate Release Phase 3 Checklist
        • T-012-025 Software Verification Phase 4 Checklist
        • T-012-026 Product Validation Phase 5 Checklist
        • T-012-028 Software Requirement Specification
        • T-012-029 Software Architecture Description
        • T-012-030 Software Configuration Management Plan
        • T-012-031 Product Requirements Specification
        • T-012-033 Software Tests Plan
        • T-012-034 Software Test Description
        • T-012-035 Software Test Run
        • T-012-037 Labeling and IFU Requirements
        • T-012-038 Verified Version Release
        • T-012-039 Validated Version Transfer
        • T-012-040 Documentation level FDA
        • T-012-041 Software Classification 62304
        • T-012-042 Regulatory Requirement
        • T-012-043 Traceability Matrix
      • GP-012 [Old version] Design, Redesign and Development
      • Specific procedures
    • GP-013 Risk management
    • GP-014 Feedback and complaints
    • GP-015 Clinical evaluation
    • GP-016 Traceability and identification
    • GP-017 Technical assistance service
    • GP-018 Infrastructure and facilities
    • GP-019 Software validation plan
    • GP-020 QMS Data analysis
    • GP-021 Communications
    • GP-022 Document translation
    • GP-023 Change control management
    • GP-024 Cybersecurity Risk Management
    • GP-025 Usability and Human Factors Engineering
    • GP-027 Corporate Governance
    • GP-028 AI Development
    • GP-029 Software Delivery And Comissioning
    • GP-050 Data Protection
    • GP-051 Security violations
    • GP-052 Data Privacy Impact Assessment (DPIA)
    • GP-100 Business Continuity (BCP) and Disaster Recovery plans (DRP)
    • GP-101 Information security
    • GP-200 Remote Data Acquisition in Clinical Investigations
    • GP-026 Market-specific product requirements
    • GP-110 Esquema Nacional de Seguridad
  • Records
  • Legit.Health Plus Version 1.1.0.0
  • Legit.Health Plus Version 1.1.0.1
  • Licenses and accreditations
  • External documentation
  • Public tenders
  • Procedures
  • GP-012 Design, redesign and development
  • Templates
  • T-012-029 Software Architecture Description

T-012-029 Software Architecture Description

Object​

Instructions

Briefly state the objective of this document. Clarify that it supports regulatory submissions (e.g., CE marking, FDA) and explain its relevance in the software lifecycle.

Scope​

Instructions

Define the software product or system to which this architecture applies. Mention the version and context of deployment if relevant.

Document Overview​

Abbreviations, Terms & Definitions​

Instructions

List and define all acronyms, technical terms, and domain-specific language used throughout the document.

Project References​

Instructions

Include references to related project documents: development plans, requirement specifications, lifecycle plans, etc.

Standard and Regulatory References​

Instructions

List applicable regulations and standards (e.g., IEC 62304, ISO 14971, ISO 81001-1, MDR Annex I). Provide the clause numbers where possible.

Conventions​

Instructions

Describe any formatting, color-coding, or naming conventions used for diagrams, terminology, or sections.

Architecture​

Architecture Overview​

Users and Environment​

Instructions

Describe who the end users are (e.g., clinicians, patients) and the physical or digital environments where the software operates.

Purpose and Workflow​

Instructions

Explain the high-level purpose of the software and outline its core workflow from start to end.

Main Functions​

Instructions

List the major functionalities provided by the system. Keep it high-level and aligned with user goals.

Main Interfaces​

[Interface Name]​
Output​
Instructions

Describe the data, messages, or behavior produced by the system through this interface.

Input​
Instructions

Describe the expected inputs received through this interface, including source, format, or trigger.

Global System Views​

Connections​

Instructions

Explain how software modules or external systems connect (APIs, libraries, data buses, etc.).

Dataflow​

Instructions

Illustrate the main flows of data between components or systems. Identify key transformations or endpoints.

Multi-Patient Harm View​

Instructions

Describe measures to prevent harm caused by data overlap, contamination, or corruption across patients.

Updatability / Patchability View​

Instructions

Detail how the system will be updated in production (e.g., remote patches, validated updates).

Security Use Case View(s)​

Instructions

Explain at least one use case per security function (e.g., authentication, encryption, access control) with its expected behavior.

Logical Architecture Overview​

Instructions

Break down the system into software items (components). For each:

  • Describe its purpose
  • Mention any included SOUP or third-party tool
  • Explain how it connects with others

Create one sub-section per software item.

Dynamic Behavior of Architecture​

Instructions

Describe common sequences or interaction flows between users, components, and systems. Each use case (e.g., "User starts exam") should include a short narrative or sequence diagram.

Justification of Architecture​

System Architecture Capabilities​

Performance​

Instructions

Explain how the architecture meets required performance constraints (e.g., speed, responsiveness).

User Safety​

Instructions

Describe architectural decisions that enhance user or patient safety (e.g., fail-safes, alerts, validation layers).

Software Security​

Instructions

Explain how the design prevents unauthorized access, data leaks, or abuse (e.g., encryption, access tokens).

Adaptability, Flexibility​

Instructions

Justify how the architecture can accommodate future changes or product variants.

Monitoring​

Instructions

Describe monitoring and observability mechanisms (e.g., logging, alerts, health checks).

Network Architecture Capabilities​

Interoperability​

Instructions

Explain how the software communicates with other systems or follows interoperability standards (e.g., DICOM, HL7).

Communication Security, Data Integrity and Confidentiality​

Instructions

Describe how secure communications are achieved (e.g., HTTPS, TLS, data hashing, audit trails).

Risk Analysis Outputs​

Instructions

List any architectural modifications that resulted from the risk management process. If none, explicitly state it.

Human Factors Engineering Outputs​

Instructions

Summarize architecture changes influenced by usability studies or human factors analysis.

SOUP Integration​

Instructions

Mention which SOUPs are used and how they are integrated. Include versioning, licensing, and purpose.

Cybersecurity​

Instructions

Describe how cybersecurity best practices (e.g., secure boot, threat modeling, defense-in-depth) are reflected in the architecture.

6. Requirements Traceability​

Instructions

Link the components or architectural decisions to the relevant software requirements. You can reference a traceability matrix or summarize the mapping directly.

Previous
T-012-028 Software Requirement Specification
Next
T-012-030 Software Configuration Management Plan
  • Object
  • Scope
  • Document Overview
    • Abbreviations, Terms & Definitions
    • Project References
    • Standard and Regulatory References
    • Conventions
  • Architecture
    • Architecture Overview
      • Users and Environment
      • Purpose and Workflow
      • Main Functions
      • Main Interfaces
        • [Interface Name]
          • Output
          • Input
  • Global System Views
    • Connections
    • Dataflow
    • Multi-Patient Harm View
    • Updatability / Patchability View
    • Security Use Case View(s)
  • Logical Architecture Overview
  • Dynamic Behavior of Architecture
  • Justification of Architecture
    • System Architecture Capabilities
      • Performance
      • User Safety
      • Software Security
      • Adaptability, Flexibility
      • Monitoring
    • Network Architecture Capabilities
      • Interoperability
      • Communication Security, Data Integrity and Confidentiality
    • Risk Analysis Outputs
    • Human Factors Engineering Outputs
    • SOUP Integration
    • Cybersecurity
  • 6. Requirements Traceability
All the information contained in this QMS is confidential. The recipient agrees not to transmit or reproduce the information, neither by himself nor by third parties, through whichever means, without obtaining the prior written permission of Legit.Health (AI LABS GROUP S.L.)