R-TF-012-023 Software Development Plan

Project plan

This section describes the arrangements put in place to the design and development of the device. The document describes all the activities we carry out to develop the device.

Objectives

This plan describes the processes of the quality management system and the resources implemented within the framework of the development project of the device.

This plan helps us achieve the following objectives:

• constitute a common reference for all members of the project team: it will ensure good consistency and homogeneity in the working methods,
• guarantee the quality of the product and of the services
• reduce risks as far as possible
• define the procedures to be followed, the tools to be used, the standards to be respected, the product development methodology and the checks planned for each activity.

Organization

Role	Description and responsabilities	Person
JD-001	JD-001 General Manager	Andy Aguilar
JD-007	Technology Manager	Gerardo Fernández
JD-003	Design & Development Manager	Taig Mac Carthy
JD-004	Quality Manager & PRRC	Saray Ugidos
JD-017	Machine Learning Ops	Alejandro Carmena
JD-018	Clinical Research Coordinator	Jordi Barrachina

Each role and function are documented in the function sheets present in the QMS.

Software safety classification

Device Class

As described in the device risk analysis, and taking into account the intended use of the device, regarding the MDR medical device class is Class IIb.

The software classification is documented in Technical Documentation of the the device device.

Software safety class

The risks caused or controlled by the device are taken into account to evaluate the class.

info

According to the flowchart above described in standard EN 62304:2006+A1:2015, and according to the risk analysis of the software T-013-002 Risk management record_YYYY_nnn, the intended use described in description and specifications the security class of the device is: Class B.

The software classification is documented in Software Classification 62304 and Documentation level FDA

Planning

The JD-003 is responsible for establishing, maintaining, and monitoring the project planning throughout the entire software development lifecycle. Project planning ensures that all development activities are properly sequenced, resourced, and aligned with regulatory requirements for Class IIb medical device software.

Planning approach

The project planning follows a phase-gate approach as defined in GP-012 Design, redesign and development, consisting of five distinct phases:

1. Phase 1: Product Design - Establish and validate product requirements
2. Phase 2: Software Design - Define software requirements, architecture, and test plans
3. Phase 3: Agile and Iterative Development - Implement software through iterative sprints
4. Phase 4: Software Verification - Execute verification testing against requirements
5. Phase 5: Product Validation - Validate the complete product for regulatory release

Each phase includes defined inputs, outputs, review criteria, and approval gates that must be satisfied before proceeding to the next phase.

Project roadmap and milestones

The project roadmap is maintained in GitHub Projects and defines the release cycles for planned software versions following semantic versioning (MAJOR.MINOR.PATCH).

Key milestones are tracked using GitHub Milestones and include release Candidate availability (Phase 3 gate) and Verification completion (Phase 4 gate).

Project management tools

GitHub provides integrated tools to plan, track, and monitor the device development project:

• GitHub Issues: Primary tool for requirements management, backlog tracking, task assignment, and traceability from product requirements through test cases
• GitHub Projects: Sprint planning, roadmap visualization, and progress tracking with customizable views
• GitHub Discussions: Documentation repository for technical specifications, meeting notes, and project plans
• GitHub Repository: Source code management with integration to Issues for traceability between code commits and requirements via commit messages and Pull Requests

The use of these tools is described further in this document, particularly in the GitHub section.

The Quality Management System (QMS) hosted at qms.legit.health documents all procedures, templates, and records required for regulatory compliance, including product functionality, design documentation, verification records, and validation evidence as defined in GP-012.

Relationships with project stakeholders

Customer or end-user involvement

End-user involvement is integrated throughout the development lifecycle to ensure the device meets clinical needs and usability requirements. Regular feedback sessions are conducted with dermatologists and healthcare professionals during product design and usability evaluation phases as described in GP-025 Usability and Human Factors Engineering. User feedback directly informs product requirements prioritization, interface design decisions, and validation activities. Clinical insights gathered during these interactions are documented and incorporated into the risk management process and clinical evaluation plan.

Subcontractor management

Not applicable to this project, there is no subcontractor involved in the development of the the device software solution. All the development is done by AI LABS team.

Relationships with other teams

The software development team closely works:

• with the Medical Data Science Team to get a good understanding of the AI and machine learning algorithms used in the software.
• with the Product Owner and the JD-003 to ensure that the software meets the product requirements and user needs.
• with the Quality Assurance and Regulatory Affairs Team to ensure that the software meets the quality and regulatory requirements.
• with the Customer Success Team to ensure that the software meets the customer needs and expectations.

Communication

Meetings

Product weekly

• Occurrence: Once a week (30 minutes)
• Objectives: Synchronize on the current status of ongoing product development projects, discuss challenges, and define next steps across different teams involved in the the device solution.
• Responsibilities: JD-003 leads the meeting.
• Attendees: Members from the Software Development Team, Medical Data Science Team, Regulatory and Quality Team, and Product Team are present.
• Activities:
  • Project Status Updates: Each team provides a brief update on their current projects, highlighting progress, completed tasks, and any blockers.
  • Discussion & Alignment: Open discussion to address inter-team dependencies, resolve issues, and ensure alignment on product features and priorities.
  • Next Steps: Key decisions are made, and clear next steps are defined and assigned for the upcoming week.

Quality biweekly

• Occurrence: Once every two week (30 minutes)
• Objectives: Keep the entire team updated on the latest news regarding quality and regulatory operations and address any questions from the team.
• Responsibilities: JD-004 (Quality Manager & PRRC) leads the meeting.
• Attendees: Members from the Software Development Team, Medical Data Science Team, Product Team and Sales Team are present.
• Activities:
  • Quality and Regulatory Updates: JD-004 provides the latest information on quality system changes, regulatory updates, and any relevant compliance news.
  • Q&A Session: An open forum for team members to ask questions related to quality and regulatory matters, seeking clarification or solutions.
  • Action Item Assignment: Identify and assign any necessary follow-up actions based on discussions and questions raised during the meeting.

Business development weekly

• Occurrence: Once a week (1 hour)
• Objectives: Review the status of current customer relationships, gather insights on market needs, and identify potential new requirements for AI LABS' products based on customer feedback.
• Responsibilities: JD-002 (Sales manager) leads the meeting.
• Attendees: Members from the Software Development Team, Medical Data Science Team, Product Team and Sales Team are present.
• Activities:
  • Customer Status Review: Sales Teams report on the status of current customer relationships and progress with prospective clients.
  • Market Insights & Requirements Gathering: Discussion on customer pain points, requested features, and market trends that could influence product development.
  • Strategic Discussion: Alignment on sales strategies and how product development can support business objectives.

Software development biweekly

• Occurrence: Once every two weeks (45 minutes)
• Objectives: Facilitate internal communication within the software development context by providing a dedicated forum for the Software Development Team to address questions, provide updates, and clarify any aspects of their ongoing development efforts for other internal teams.
• Responsibilities: JD-007 leads the meeting.
• Attendees: Members from the Software Development Team and representatives from other teams (e.g., Product, Medical Data Science, Regulatory and Quality) who have inquiries regarding software development status or technical details.
• Activities:
  • Q&A Session: The primary focus is to allow other teams to ask questions directly to the Software Development Team regarding features in progress, technical dependencies, timelines, or any other development-related topics.
  • Brief Status Updates: The Software Development Team may provide quick updates on critical path items or recent completions to inform other teams proactively.
  • Clarification & Issue Resolution: Addressing specific inquiries and working towards immediate clarity or defining follow-up actions for more complex issues.

info

All operational meetings with Software Development Team are described in the Development Methodology section.

Communication channels

Team exchanges and information sharing are carried out mainly through the following channels:

• Slack: Utilized for instant communication and quick discussions among team members.
• Google Workspace: Employed for collaborative creation and sharing of documents, including internal working files and customer proposals.
• Email: Used for formal communications, external correspondence, and general information exchange.
• Planka: Serves as a Kanban board to provide an overall visual representation of the current status of various development initiatives and projects.
• GitHub Issues and Projects: Leveraged for detailed task management, tracking, and collaboration on specific developments related to medical data science and medical device software.

Training

To ensure the team maintains the necessary competencies and remains up-to-date with critical regulations and skills, personnel involved in the the device project receive training in the following areas:

• Data Protection and GDPR: Mandatory annual training is provided to ensure all team members are fully aware of their responsibilities regarding data protection and compliance with the General Data Protection Regulation (GDPR).
• Cybersecurity and Risks: Regular training sessions are conducted to educate staff on cybersecurity best practices, threat identification, and risk mitigation strategies pertinent to medical device software development and data handling.
• Specific Skills Development: Team members are encouraged to undertake various online specific trainings to acquire new skills, tools, and technologies relevant to their roles and the evolving technical landscape of medical software development.

Document version control strategy

The document version control strategy is managed according to the GP-001 Control of documents. Proofreading and validation of documents is describe in the procedure.

Activities and responsibilities

Each activity has someone responsible, mandatory. For small teams, may be always the same person.

Activity	Responsibility
Project management	JD-007 / JD-003
Configuration management	JD-007 / Lead Dev
Setting up the Development tools	JD-007 / Lead Dev
Software specifications	JD-003 / Product Owner
Product Design	JD-003 / UI/UX Designer
Software architecture	JD-007 / Software Architect
Code reviews	Software Engineer

Software development process phases

As described in the GP-012, the software development process is divided into the following phases:

Phase 1. Product design

This phase is initiated by AI LABS stakeholders, who generate and validate the inputs as a general device description. The inputs must come from business input, technical input, product ideas, regulatory requirements or Change Request.

This phase aims to produce the following elements:

• Device description and specifications
• T-012-031 Product Requirements Specification

All the Product Requirements are entered, stored and traced in the corresponding Techical Documentation.

The CEO, JD-003, JD-007 and JD-004 review all the outputs of Phase 1. This review is documented in the T-012-021 Product Design Phase 1 Checklist.

Phase 2. Software design

This phase focuses on initiating the software design based on the stakeholder-provided inputs. Here are the expected activities and outputs for this phase:

• Document the methodology used to implement the product: T-012-036 Software Development Plan.
• Define functional requirements, performances, physical characteristics, environment conditions in which the software will run, including safety and security risk mitigation, documented in T-012-028 Software Requirement Specification.
• Defining the Software Architecture considering all functional, safety, and security risks: T-012-029 Software Architecture Description.
• Plan and document the verification of the product based on the product requirements, risks and functional specification: T-012-033 Software Tests Plan and T-012-034 Software Test Description.
• Expose the traceability showing that all requirements, safety and security risk are handled by tests. T-012-043 Traceability Matrix (draft)
• Document the software classification of the device regarding the applicable standards: T-012-040 Documentation level FDA and T-012-041 Software Classification 62304.

The CEO, JD-003, JD-007 and JD-004 review all the outputs of Phase 2. This review is documented in T-012-022 Software Design Phase 2 Checklist.

Additionally, all SOUPs used in the development and architecture must be listed and documented in the T-012-019 SOUP template.

Other procedures kickoff

The start of this phase declares the kickoff of other procedures base on the outputs of Phase 1 :

• Usability and Safety Risks activities are launched regarding the GP-025 Usability and Human Factors Engineering and T-013-001 Risk management by JD-003 and JD-004.
• Clinical activities are launched regarding the GP-015 Clinical evaluation, by the JD-018.
• Cyber Security activities are launched regarding the GP-030 Cybersecurity by JD-003 and JD-004.
• AI/ML Development activities are launched regarding the T-028-005 AI/ML Design Checks by JD-003 and JD-004.

Phase 3. Agile and iterative development

The methodology used by the AI LABS team to develop the software is described in detail in this Plan, section Development Methodology.

The objective of this phase is to produce a Release Candidate that can verified and validate. The JD-007 must validate the operational checklist, which ensures that all criteria are met for proceeding with verification:

• the version is correctly identified in AI LABS's repository and version is tagged
• the software implements all the software requirements and safety and security risk mitigation.
• the Software Tests Plan and Software Test Description are completed.
• the technical documentation and records have been reviewed and approved.

The JD-001, JD-007, JD-003 and JD-004 review all the outputs of Phase 3. This review is documented in Software Candidate Release Phase 3 Checklist.

Phase 4. Software verification

After development is completed, a release candidate should be identified for executing the verification test plan. This candidate release is documented in the Software Candidate Release Phase 3 Checklist.

The Software Testing Team initiated the software verification process and produced all expected documentation, including:

• T-012-035 Software Test Run which details the execution results for each test and test step.
• T-012-043 Traceability Matrix, which demonstrates that the verification covers all requirements in the SRS, as well. as safety and security risks.
• T-012-038 Verified Version Release with the description of the verified version release.

The JD-007 approves the Release Candidate only if the test report is acceptable. If not, a new Release Candidate must be produced and re-verified. A comprehensive risk assessment of all residual anomalies is conducted to ensure the product's safety for use.

The JD-001, JD-003, JD-007 and JD-004 review all the outputs of Phase 4. This review is documented in Software Verification Phase 4 Checklist.

Phase 5. Product validation

The JD-003 initiates the validation process with the intent to validate verified software. The JD-003, with the support of the clinical team, the regulatory team, the AI/ML team, and the software development team collects all the necessary data for releasing the product and its associated documentation generated throughout:

• the current procedure
• GP-015 Clinical evaluation and associated records
• GP-028 AI Development and associated records
• GP-013 Risk management and associated records
• GP-024 Cyber Security and associated records
• GP-025 Usability and associated records

If validated, the released software along with its documentation can then be submitted to the regulatory body for approval or directly deployed in the target markets given their legislations.

The JD-007 should document the design transfer in T-012-039 Validated Version Transfer.

Final risk assessment and risk-benefit analysis

The final risk assessment integrates all software-specific risk control measures verified during development and testing. Refer to GP-012 § Final Risk Assessment and Risk-Benefit Analysis for the canonical procedure and decision framework.

• Input:
  • Risk Matrix
  • Clinical Evaluation Report
  • Software (Release Candidate)
• Output:
  • T-013-003 Risk management report
  • Documentation level FDA
  • Software Classification 62304
  • Security Risk
  • T-013-003 Risk management report

Commissioning activities

All commissioning activities, including distribution, installation, and post-release validation, are detailed in GP-029 Software Delivery and Commissioning as described in GP-012 § Commissioning activities.

Design transfer

Artefacts transferred to production must be documented following the Validated Version Transfer.

Design transfer documentation is reviewed to ensure that artefacts are suitable for deployment in target servers.

Other actions can be planned to ensure that the customer success department can perform the necessary actions.

Product Validation

The JD-001, JD-003, JD-007, JD-004 and JD-018 review all the report of other procedure. This review is documented in T-012-026 Product Validation Phase 5 Checklist.

If the review is successful, move forward to submission and final product release. If it's not, the output has to be reworked. In that case, move back to the relevat step above.

Software development tools

The section lists the software development tools used and describes their usage.

Workstation

• The typical workstation for a software or verification engineer is a computer.
• The engineer needs to log in on the workstation with its own credentials.
• The engineer accesses all project resources using authenticated and secure connections.

GitHub

This section provides comprehensive guidance on how GitHub is used to establish and maintain traceability throughout the device development lifecycle. All traceability mechanisms described below create a complete audit trail suitable for regulatory submissions.

Overview and tools

GitHub provides integrated tools to manage requirements, track changes, and demonstrate traceability:

• GitHub Issues: Primary tool for tracking Software Requirements, Test Cases, User Stories, Tasks, and Bugs
• GitHub Projects: Sprint planning, roadmap visualization, and progress tracking with customizable views
• GitHub Repository: Source code management with full version control and change history
• GitHub Pull Requests (PRs): Code review workflow with automated quality checks
• GitHub Milestones: Release planning and work organization
• GitHub Releases: Version tagging and release management

The traceability chain implemented spans from Product Requirements through Test Cases, with all items tracked and linked via GitHub. Traceability is established during Phase 2 by linking Issues to Requirements, Tests, and Pull Requests, and maintained throughout the project lifecycle.

Issue linking and referencing

Every software requirement, test case, feature, and bug is tracked as a GitHub Issue in the repository. Traceability is established and maintained through systematic linking:

• Requirement linking: Each GitHub Issue is linked to the corresponding requirement in the Software Requirement Specification (SRS) via issue body, labels, and metadata
• Commit and PR linking: Every commit and Pull Request must reference the related GitHub Issue using the issue number (e.g., #1234), creating an auditable link between code changes and requirements
  • Commit message format: fix: handle null session (#1234)
  • PR title format: feat: add user invites (#1234) (follows Conventional Commits standard)
  • GitHub automatically closes the referenced issue when the PR is merged
• Test case linking: Test Cases are linked to Issues via GitHub Projects and issue relationships, ensuring every requirement has at least one corresponding test
• Safety and security risk linking: Issues addressing safety or security risks are labeled accordingly (e.g., safety-risk, security-risk) and linked to the risk management records per GP-013 Risk management

Branch naming conventions

All branches follow strict naming conventions to maintain auditable traceability. Each branch name must include the GitHub Issue number, enabling end-to-end traceability from requirement to code to release.

Refer to R-TF-012-030 for detailed branching strategies, merge policies, release candidate workflows, and patch release procedures.

Pull request workflow and review requirements

All code changes are submitted via Pull Requests (PRs) to ensure peer review and automated quality checks. The PR workflow is described in detail in R-TF-012-030 Software Configuration Management Plan. Refer to that document for comprehensive guidance on PR creation, review, approval, and merging procedures.

Milestone usage for release planning

GitHub Milestones organize and track work toward specific release versions, providing visibility into progress and planned completion dates:

• Release Milestones: Each GitHub Issue is assigned to a Milestone indicating its target release version (e.g., v1.2.0)
• Phase gate Milestones (optional): May be created to group regulatory and design activities (Phase 1–5)
• Progress tracking: Milestones show percentage completion and remaining open issues
• Traceability: Issues link requirements to releases via Milestone assignment

Release configuration and tagging:

All releases follow Semantic Versioning per R-TF-012-030 Software Configuration Management Plan:

• Release candidates: vMAJOR.MINOR.PATCH-rcN (e.g., v1.2.0-rc1, v1.2.0-rc2)
• Final releases: vMAJOR.MINOR.PATCH (e.g., v1.2.0, v1.2.1)

Tags are applied on main or release/MAJOR.MINOR branches. Refer to R-TF-012-030 for detailed branching strategy, release candidate promotion, and patch release procedures.

GitHub Projects for sprint and release tracking

GitHub Projects provides a board-level view of work and traceability:

• Sprint Projects: Organize Issues and PRs by sprint, showing status (Backlog, To Do, In Progress, Code Review, Done)
• Release Projects: Track all work targeting a specific release milestone
• Custom views: Filter by label (e.g., safety-risk, security-risk, test-case) to verify coverage
• Automation: PRs are automatically moved to "Done" when merged, maintaining current board state

Regulatory audit trail

The combination of GitHub Issues, commits, PRs, Milestones, and Releases creates a complete, tamper-evident audit trail suitable for regulatory submissions:

• Change history: Git commit history shows who made changes, when, and why (via commit messages and PR descriptions)
• Review evidence: PR comments, approvals, and CI results demonstrate verification and testing activities
• Traceability chain: Product Requirement → Software Requirement (Issue) → Branch → Commits → PR → Test Results → Merge → Release Tag

Software design

Tool	Used to
Draw.io	Create software architecture diagrams, UML diagrams, and design documents.
Lucidchart	Design and document system architecture and data flow diagrams.
Visual Studio Code	Code editor with integrated debugging and design-time validation.
Mermaid	Text-based diagramming (embedded diagrams in markdown/MDX) for architecture and sequence diagrams.

Obsolescence management

Updates are made when a new version of the software development tool comes up, with the following attention points:

• All updates are made using the official channel of the development tool.
• Before updating any tool, developers check the compatibility with the development tool. If not compatible, a message is clearly displayed, meaning it shouldn't be updated prior to a thorough investigation from the lead software engineer.
• If compatible with the development tool, developers update all the plugins and tools. This best practice guarantees they all have the latest features of these software. The lead software engineer ensures all developers make the updates.
• Note that these development tools are separated from the source code and do not affect the product

These updates shall respect the GP-019 Software validation plan.

Development methodology

Programming languages

The primary programming languages used in the development of the device software are:

• Python
• Dockerfile
• JSON
• YAML

Software development rules and standards

This section defines the core coding principles, conventions, and architectural patterns that guide all software development activities. Adherence to these standards ensures code quality, maintainability, testability, and regulatory compliance.

Python language standards

All Python code must conform to established language standards and best practices:

• PEP 8 - Style Guide: All code must follow PEP 8 conventions for naming, indentation (4 spaces), line length (max 100 characters), and formatting. Consistent style improves readability and reduces cognitive load during code reviews.
• PEP 484 - Type Hints: All functions, methods, and class attributes must include type hints. Type hints improve code documentation, enable static analysis, and catch type-related errors before runtime.
  • Example: def calculate_risk_score(patient_id: str, lesion_area: float) -> float:
  • Complex types use the typing module: from typing import List, Optional, Dict, Union
• PEP 257 - Docstring Conventions: All public functions, classes, and modules must include docstrings following PEP 257 conventions. Docstrings describe purpose, arguments, return values, and exceptions.
  • Example: Multi-line docstring with parameter descriptions and return type
• Module organization: Imports grouped in order: standard library, third-party, local application
• Naming conventions:
  • Classes use PascalCase
  • Functions and variables use snake_case
  • Constants use UPPER_SNAKE_CASE
  • Private methods/attributes prefixed with underscore (_private_method)

Data validation with Pydantic

Pydantic is the standard library for data validation, serialization, and type enforcement across all software components:

• Mandatory use: All data structures that cross component boundaries, receive external input, or represent domain entities must be defined as Pydantic models.

• Model definition: Each Pydantic model clearly documents expected field types, constraints, and validation rules.

  • Example:

    from pydantic import BaseModel, Field, validator
    
    class PatientRecord(BaseModel):
        patient_id: str = Field(..., description="Unique patient identifier")
        age: int = Field(..., ge=0, le=150, description="Patient age in years")
        lesion_area_mm2: float = Field(..., gt=0, description="Lesion area in mm²")
    
        @validator('patient_id')
        def validate_patient_id(cls, v):
            if not v.isalnum():
                raise ValueError('Patient ID must be alphanumeric')
            return v

• Validation on instantiation: Pydantic automatically validates data when models are instantiated; invalid data raises ValidationError with detailed error context.

• Serialization: Pydantic models serialize to/from JSON and Python dictionaries, enabling clean API contracts and audit logging.

• Configuration: Pydantic model configs enforce immutability (frozen=True) for value objects and defensive copying to prevent accidental mutations.

Architectural principles

The codebase is structured using Domain-Driven Design and Hexagonal Architecture to achieve high cohesion, loose coupling, and testability:

Domain-Driven Design (DDD)

• Ubiquitous Language: Teams use consistent terminology across code, documentation, and communication. Domain concepts (e.g., "lesion classification," "risk assessment") are reflected in code class and method names.
• Bounded Contexts: The system is divided into logical domains (e.g., image analysis, risk management, user management) with clear boundaries. Each context owns its data models and business logic.
• Value Objects and Entities:
  • Value Objects: Immutable domain concepts defined by their attributes (e.g., RiskScore, LesionArea). Value objects are compared by value, not identity.
  • Entities: Domain objects with unique identity that persists over time (e.g., Patient, DiagnosticReport). Entities are compared by identity.
• Aggregates: Groups of related entities/value objects treated as a single transactional unit. Aggregates define consistency boundaries and prevent invalid state transitions.
• Repository Pattern: Data access is abstracted through repository interfaces; persistence details are hidden from business logic.

Hexagonal Architecture

• Core Domain Layer: Contains pure business logic, domain models, and use cases. This layer has no dependencies on external frameworks or infrastructure.
• Port Interfaces: Define contracts for external interactions (database, APIs, message queues, UI). Ports are language constructs (interfaces/abstract classes) that specify what the core domain needs from external systems.
• Adapter Implementations: Concrete implementations of ports that handle specific technologies (e.g., PostgreSQL repository adapter, REST API client adapter, file-based logger adapter). Adapters translate between domain models and external formats.
• Dependency Inversion: Core domain depends on abstractions (ports), not concrete implementations. Adapters implement ports; the core domain imports adapters only for initialization/wiring.
• Testability: Core domain is tested with mock adapters; adapters are tested with real external systems (database, APIs) or fixtures. This separation enables fast unit tests and comprehensive integration tests.

Code organization and module structure

• Single Responsibility: Each module, class, and function has one reason to change. Avoid "god objects" or utility modules.
• Circular dependencies: Strictly prohibited. Use dependency injection or refactor to eliminate cycles.
• Module size: Modules should be focused and reasonably sized (typically under 300 lines); consider splitting larger modules.
• Import order: Standard library → third-party → local application; within each group, sort alphabetically or by logical grouping.
• Avoid star imports: from module import * is prohibited; explicit imports improve clarity and enable static analysis.

Error handling and exceptions

• Use specific exceptions: Define custom exception classes for domain errors (e.g., InvalidLesionClassification, PatientNotFound). Use built-in exceptions for programming errors (e.g., TypeError, ValueError).
• Never silently catch exceptions: Catch specific exceptions and handle appropriately; avoid bare except: clauses.
• Meaningful error messages: Exception messages should provide context (e.g., "Patient ABC123 not found in database" rather than "Not found").
• Propagate vs. handle: Core domain raises domain-specific exceptions; adapters translate them to framework-specific forms (HTTP status codes, database transactions, logging).

Testing and code quality

• Testability by design: Write code that can be tested independently. Use dependency injection to enable mocking. Avoid tight coupling to external systems.
• Test coverage target: Aim for minimum 70% line coverage in core domain logic; aim higher (>85%) for safety-critical paths.
• Test organization: Mirror source code structure; test files located in tests/ with parallel directory structure (e.g., tests/domain/services/test_risk_calculator.py).
• Test naming: Use descriptive names: test_lesion_classifier_returns_high_risk_for_atypical_morphology is better than test_classify.

Scrum framework

The Software Development Team uses Scrum framework that is an agile methodology. This method is apply during the development of the product.

The entire Scrum methodology is tracked and managed using Github Projects and Issues as described in the Software development tools section.

Backlog items

The Product Backlog gathers every functional, regulatory, security and maintenance need identified for the device. User stories are created directly from the approved Software Requirements Specification (SRS) and each story is bi-directionally linked to its originating requirement.

Backlog grooming

• Ownership & cadence: the Product Owner stewards the backlog and schedules a grooming session at least once per sprint with representatives from development, quality and regulatory.
• Activities
  1. Split or merge stories so they fit within a sprint.
  2. Clarify acceptance criteria and add Definition-of-Done (DoD) checks.
  3. Assign target release via GitHub Milestones and apply labels (e.g., v1.2.0, safety-risk, security-risk) to establish requirements traceability.
  4. Re-order items by business value, risk reduction and readiness.
• Outcome: A “Ready” top-of-backlog sized for the next sprint and fully traceable to SRS, risk or maintenance records.

Risk-based prioritization

The backlog is prioritized considering:

1. Safety risk mitigation: Software requirements addressing identified safety risks receive highest priority
2. Security risk mitigation: Cybersecurity requirements per GP-030 Cyber Security Risk Management
3. Regulatory requirements: Features necessary for regulatory compliance and submission timelines
4. Clinical validation needs: Capabilities required for clinical evaluation activities
5. Business value: Customer needs and competitive positioning

The JD-003, in collaboration with JD-007, JD-004, and JD-018, reviews and adjusts priorities quarterly or when significant risks or regulatory changes are identified.

Sprints

Sprints are two weeks long, producing a potentially shippable increment and updated documentation each iteration.

Work breakdown and estimation

Work is decomposed into manageable units tracked in GitHub Issues:

• Epics: High-level features or initiatives aligned with product requirements (PRs), tracked using issue labels
• User Stories: Functional requirements from the end-user perspective, linked to Software Requirements (SRS)
• Tasks: Technical implementation work, including architecture, coding, and unit testing
• Bugs: Defects identified during development, verification, or post-market surveillance
• Test Cases: Verification and validation test specifications linked to requirements

Estimation is performed using story points during backlog refinement sessions. The team maintains a velocity metric to improve planning accuracy over time.

Resource planning

Resource allocation is planned considering:

• Team composition: Software engineers, QA testers, UI/UX designers, medical data scientists, regulatory specialists, and clinical researchers
• Skill requirements: Specific competencies needed for AI/ML development, medical device regulations, and cybersecurity
• Training needs: Planned training activities for GDPR, cybersecurity, and tool-specific skills
• External dependencies: Notified body reviews, clinical site availability, and regulatory authority timelines

Resource availability and capacity are reviewed during sprint planning and adjusted based on competing priorities across multiple projects.

Planning and execution

Software development activities follow an Agile methodology with sprints of 2 weeks duration. Each sprint includes:

• Sprint planning: The Software Development Team, led by JD-007, selects the GitHub issues from the prioritized backlog based on team capacity and product roadmap priorities
• Daily standups: 15-minute synchronization meetings to identify blockers and coordinate work
• Sprint review: Demonstration of completed work to stakeholders, including JD-003 and relevant team members
• Sprint retrospective: Team reflection on process improvements and lessons learned

Sprint planning considers:

• Software requirements priority and risk mitigation measures
• Dependencies on AI/ML model development, clinical data, and regulatory activities
• Technical debt management and SOUP updates
• Verification and validation test preparation

Schedule monitoring and control

Project progress is monitored through:

• GitHub Projects: Real-time visibility into sprint progress, burndown charts, and milestone status
• Phase gate reviews: Formal reviews documented using phase-specific checklists (T-012-021 through T-012-026)
• Risk reviews: Regular assessment of schedule risks and mitigation actions
• Stakeholder reporting: Monthly status reports to JD-001 covering progress, risks, and resource needs

Schedule deviations are managed through:

• Scope adjustment in consultation with JD-003 and stakeholders
• Resource reallocation or additional hiring
• Risk mitigation plan updates
• Formal change control process per GP-023 Change Control when impacts affect validated products

Meetings

Event	Purpose	Time-box	Key roles
Sprint Planning	Agree sprint goal, select backlog items, size tasks	60 min	Product Owner (facilitates), Dev Team
Daily Stand-up	Inspect progress vs. goal, adjust plan	10–15 min	All developers, JD-007
Sprint Review	Demonstrate increment, collect stakeholder feedback	60 min	Dev Team, Product Owner, stakeholders
Retrospective	Identify improvements for next sprint	60 min	Dev Team, JD-007 (facilitator)

Activity and task state management

All work items (user stories, tasks, bugs, test cases) are tracked as GitHub Issues and organized in GitHub Projects boards. Items flow through five explicit states that represent the work lifecycle:

1. Backlog: Issue created but not yet scheduled for a sprint; requires prioritization and sizing
2. To Do: Issue scheduled for current or upcoming sprint; ready for development to begin
3. In Progress: Issue currently being worked on by a developer; assigned to a team member
4. Code Review: Issue implementation complete; Pull Request created and under peer review
5. Done: PR merged to main/target branch, automated tests passed, and issue automatically closed

Continuous amelioration

After each sprint the Retrospective inspects people, process, tools and DoD compliance, then records concrete actions. Peer-review checklists measure code quality, test completeness and static-analysis health; their results feed into the next sprint's improvements. Continuous improvement metrics (cycle time, escaped defects, coverage) are trended to guide process updates and training.

Coding and review workflow

This section describes the coding and code review workflow that integrates with the CI/CD pipeline. For complete CI/CD pipeline details, automated testing stages, and quality gates, refer to the authoritative section Automated tests and continuous integration.

Coding activities

Developers produce the following artifacts during coding activities:

• Source code for software items and software units
• Automated test code (unit tests, integration tests)
• Configuration files (environment configs, CI/CD pipeline definitions, deployment manifests)
• Code documentation (docstrings, inline comments, architecture diagrams)

All code must adhere to the coding standards defined in "Software development rules and standards" section, including PEP 8 style guide, type hints, and Pydantic data validation.

Pull Request workflow

All code changes are submitted via Pull Requests (PRs) to ensure peer review and automated quality checks. The PR workflow is described in detail in R-TF-012-030 Software Configuration Management Plan. Refer to that document for comprehensive guidance on PR creation, review, approval, and merging procedures.

Peer code review

Peer code review serves multiple critical purposes:

• Second opinion on solution: Verify that the technical approach and implementation effectively solve the problem
• Defect detection: Identify bugs, logic errors, uncovered edge cases, or potential failure modes before production
• Knowledge sharing: Distribute understanding of code changes across the team, reducing key-person dependency
• Standards compliance: Ensure code adheres to coding standards, architectural patterns, and best practices
• Test adequacy: Verify that automated tests comprehensively cover the changes and would detect regressions

Automated tests and continuous integration

This section provides the authoritative description of the CI/CD pipeline and Pull Request workflow used throughout the software development lifecycle. All automated testing, quality gates, and integration procedures are documented here to ensure consistent implementation across the development team.

For detailed branch management, merge strategies, and configuration management procedures, refer to R-TF-012-030 Software Configuration Management Plan.

Overview and strategy

The CI/CD workflow is designed for a efficient development team and follows these core principles aligned

• Fail fast: Automated checks run immediately when code is pushed, providing rapid feedback to developers
• Comprehensive validation: Multiple layers of automated testing (unit, integration) catch defects early and verify software item functionality
• Regulatory audit trail: All CI results are logged and linked to Pull Requests for traceability
• Developer experience: Clear, concise feedback enables rapid remediation without disrupting flow
• Integration verification: Automated integration tests verify that software items interact correctly

The testing strategy balances thoroughness with practicality:

• Unit tests: Test individual software components (software units) in isolation; required for all business logic and risk-critical code
• Integration tests: Verify interactions between software items and with external systems (APIs, databases, SOUP components)
• Static analysis and linting: Detect code style violations, security issues, and common defects before runtime
• Code coverage: Target minimum 70% coverage for critical paths; aim for higher coverage in safety-related modules (Class B software)
• End-to-end tests (optional): Exercise full device workflows in staging environments when necessary for validation activities

Tools and workflow

Tool	Used for
GitHub Repository	Source code management, version control, and collaboration on code development; integrated with CI/CD workflows.
GitHub Actions	Automated testing, linting, static analysis, and security scanning triggered on every Push and Pull Request; implements continuous integration
Test frameworks	Unit and integration testing (specific frameworks depend on technology stack, e.g., pytest for Python, Jest for JavaScript).
Code coverage tools	Measure test coverage percentage; reports are generated and displayed on Pull Requests for visibility.
Static analysis tools	Analyze code for security vulnerabilities, code smells, and style violations; integrated into CI pipeline.
TestRail	Centralized test management, test case organization, test execution tracking, manual testing coordination, and traceability linking test cases to requirements and defects.

CI/CD pipeline stages

When a developer pushes code or opens a Pull Request, GitHub Actions automatically triggers the following pipeline stages (integration testing):

Stage 1: Environment setup

• Check out code from the feature/bug branch
• Set up runtime environment
• Install project dependencies from lock files

Stage 2: Linting and code style

• Run linting tools to detect style violations
• Run code formatters to verify formatting compliance
• Verify adherence to coding standards defined in "Software development rules and standards"
• Gate: Pipeline fails if linting errors exceed threshold or critical style violations detected

Stage 3: Build verification

• Compile/build application code to ensure no syntax or compilation errors
• Verify that all imports, modules, and dependencies resolve correctly
• Gate: Pipeline fails if build errors occur

Stage 4: Unit tests

• Execute unit test suite for all software units
• Measure code coverage percentage (line coverage, branch coverage)
• Generate test result reports (pass/fail, execution time, coverage data)
• Gate: Pipeline fails if any unit test fails or coverage drops below configured threshold (70% for critical paths)

Stage 5: Integration tests

• Execute integration test suite verifying interactions between software items
• Test integration with external systems (APIs, databases, SOUP components)
• Verify data flow and interface contracts between components
• Gate: Pipeline fails if any integration test fails

Stage 6: Static analysis

• Run static analysis tools to detect code quality issues
• Scan for security vulnerabilities, code smells, and complexity violations
• Check compliance with coding standards and best practices
• Gate: Pipeline fails if critical security vulnerabilities detected or code quality metrics below threshold

Stage 7: Security and vulnerability scanning

• Scan dependencies for known vulnerabilities
• Verify license compliance for all SOUP components
• Detect secrets or credentials accidentally committed to code
• Flag outdated SOUP components requiring review per T-012-019 SOUP
• Gate: Pipeline fails if high/critical vulnerabilities detected in production dependencies

Stage 8: Coverage reporting and PR annotation

• Generate comprehensive coverage report with line-by-line coverage visualization
• Post coverage summary as PR comment (e.g., "Coverage: 78% (+2% vs. main)")
• Annotate PR with inline code coverage indicators
• Link to detailed coverage report for reviewer inspection

Stage 9: Status check and gating

• Aggregate results from all pipeline stages
• Mark PR check as successful (✅ green check) if all stages pass
• Mark PR check as failed (❌ red X) if any stage fails
• Block PR merge if CI checks fail (enforced by branch protection rules)
• Notify author via GitHub and email if pipeline fails

Test management and traceability with TestRail

TestRail is the centralized test management platform that complements GitHub Actions by providing comprehensive test case organization, execution tracking, and traceability linking. Integration of TestRail into the CI/CD workflow provides the following capabilities:

Test case management

TestRail serves as the single source of truth for all test cases, including:

• Automated unit and integration tests (linked to CI pipeline results)
• Manual verification tests (executed during Phase 4 Software Verification)
• Manual validation tests (executed during Phase 5 Product Validation)

Test cases are organized hierarchically by test suites aligned with T-012-033 Software Tests Plan and linked to requirements in the Software Requirement Specification (SRS). Each test case includes:

• Test case ID (unique identifier)
• Test objective and preconditions
• Step-by-step test procedure
• Expected results
• Linked requirements (from SRS via GitHub Issue reference)
• Linked defects (GitHub Issues)
• Test type (unit, integration, system, acceptance)
• Safety/security risk classification (if applicable)

This hierarchical structure ensures complete traceability between product requirements and test coverage.

Traceability and compliance

TestRail maintains bi-directional links between:

• Requirements (from GitHub Issues and T-012-028 Software Requirement Specification)
• Test cases (stored and versioned in TestRail)
• Test execution results (from both automated CI runs and manual testing)
• Defects (logged as GitHub Issues and linked back to tests)
• Releases (GitHub Release tags and Milestones)

This creates an auditable chain-of-custody suitable for regulatory submissions per MDR Annex II, demonstrating that:

• Every requirement has at least one corresponding test case
• All test cases have been executed and passed (or have documented acceptable failures)
• All defects found during testing have been assessed and mitigated
• Test results are traceable to specific software versions (commit hash, release tag)

Automated results integration

GitHub Actions CI/CD workflows publish test execution results to TestRail via API integration:

• Test case execution status (pass/fail/blocked)
• Execution timestamp and duration
• Code coverage metrics (overall, per-module)
• CI build ID and commit hash (for traceability)
• Test output logs and failure details

This automation ensures that:

• Automated test results are captured in the test management system without manual data entry
• Test results remain consistent with the regulatory record (no transcription errors)
• CI pipeline results are immediately available for review by JD-007, JD-004, and Software Testing Team
• Historical test execution trends are tracked for quality metrics and continuous improvement

Manual testing coordination

For verification activities (Phase 4) and validation activities (Phase 5), TestRail provides a centralized platform for:

• Test run planning: Create test runs for specific release candidates (e.g., v1.2.0-rc1) with assigned test cases
• Test assignment: Assign test cases to Software Testing Team members, JD-007, or external testers
• Progress tracking: Real-time visibility into test execution progress (% complete, pass rate, blocked tests)
• Evidence capture: Attach screenshots, log files, and test evidence directly to test results
• Defect linking: Link failed test cases to GitHub Issues for defect tracking and resolution
• Retest coordination: Automatically flag test cases requiring re-execution after bug fixes

Compliance reporting

TestRail generates comprehensive test execution reports that form the basis for regulatory documentation:

Test coverage reports:

• Demonstrate all requirements in T-012-028 SRS have corresponding test cases
• Show coverage percentage by requirement type (functional, safety, security, performance)
• Identify untested or partially tested requirements requiring attention

Test execution summaries:

• Overall pass rate and execution status (passed, failed, blocked, untested)
• Execution date/time and executed by (tester name)
• Test duration and resource utilization
• Defect summary (total defects found, severity distribution, resolution status)

Traceability matrices:

• Requirement-to-test linkage (every requirement mapped to test cases)
• Test-to-defect linkage (every failed test mapped to defects)
• Defect-to-risk linkage (defects assessed against T-013-002 Risk Management Record)

Release-specific reports:

• Test results for specific release candidates (e.g., v1.2.0-rc1, v1.2.0)
• Regression test results comparing current vs. previous releases
• Safety-critical test results (all tests linked to safety risks)

These reports are exported from TestRail and included in:

• T-012-035 Software Test Run - detailed test execution records
• T-012-043 Traceability Matrix - requirement-to-test-to-risk traceability
• T-012-025 Software Verification Phase 4 Checklist - verification completion evidence
• Device History File (DHF) for regulatory submissions (MDR Technical Documentation, FDA 510(k))

Troubleshooting CI failures

When a CI pipeline stage fails, the following troubleshooting workflow is followed:

Step 1: Failure notification and investigation

• GitHub automatically notifies the PR author via email and in-app notification
• Author reviews the detailed error logs accessible via GitHub Actions interface
• Logs include stage-specific error messages, stack traces, and context (e.g., failing test name, line number)
• Author identifies the root cause (test failure, linting error, security vulnerability, etc.)

Step 2: Fix implementation

• Developer implements corrections on the same feature/bug branch (no need to create new branch)
• Fixes may include:
  • Correcting failing unit/integration tests
  • Fixing linting violations or code style issues
  • Updating dependencies to address security vulnerabilities
  • Resolving merge conflicts with target branch
• Developer pushes corrections to the branch using git push

Step 3: Automatic re-execution

• GitHub Actions automatically re-runs the entire CI pipeline when new commits are pushed
• All pipeline stages execute again from Stage 1 (Environment setup) through Stage 9 (Status check)
• Developer monitors pipeline progress in real-time via GitHub Actions interface

Step 4: Iteration until success

• Process repeats (Steps 1-3) until all pipeline stages pass
• If multiple failures occur, developer addresses all issues systematically
• Developer may run tests locally before pushing to reduce CI iteration cycles

Step 5: Request peer review

• Once CI is green (✅ all checks pass), developer requests peer review from assigned reviewers
• Reviewers are notified via GitHub and can begin code review with confidence that automated quality gates passed

Escalation for persistent failures:

• If CI failures persist after multiple attempts, developer escalates to JD-007 (Technology Manager) for investigation
• Persistent failures may indicate:
  • Flaky tests requiring stabilization
  • Environment configuration issues (missing dependencies, incompatible versions)
  • Infrastructure problems (GitHub Actions runner issues, network timeouts)
  • Process or tooling improvements needed
• Root cause is documented and addressed in sprint retrospectives per "Continuous amelioration"

Auditability and compliance

The CI/CD pipeline creates a complete, tamper-evident audit trail suitable for regulatory submissions:

Timestamped execution logs:

• GitHub provides immutable, timestamped logs of all CI pipeline runs
• Logs show when tests were executed, who triggered them (author, automated trigger), and execution duration
• Logs include complete console output from each pipeline stage (linting, build, tests, static analysis)
• Logs are retained per GitHub's data retention policy and accessible via GitHub Actions interface and API

Test results and artifacts:

• Detailed test results (pass/fail, test case name, execution time) are associated with each commit and PR
• Code coverage reports show percentage coverage (overall, per-file, per-function) with line-by-line visualization
• Security scan results identify vulnerabilities (CVE IDs, severity, affected dependencies)
• Build artifacts ( test reports, coverage HTML) are stored and linked to CI runs

Traceability chain:

• CI results are tied to specific code commits via commit hash (SHA-1, immutable)
• Commits are linked to Pull Requests via PR number (e.g., #1234)
• Pull Requests are linked to GitHub Issues via issue reference (e.g., Closes #1234)
• GitHub Issues are linked to requirements in T-012-028 SRS
• This creates end-to-end traceability: Requirement → Issue → PR → Commit → CI Results → Test Evidence

Configuration as code:

• CI/CD pipeline configuration (GitHub Actions YAML files) is version-controlled in the repository
• Pipeline configuration changes are reviewed via Pull Request workflow (same process as code changes)
• Historical pipeline configurations are traceable via Git history (commit hash, author, timestamp)
• This ensures reproducibility: any historical release can be rebuilt using the pipeline configuration from that commit

Review evidence:

• PR comments, approvals, and review feedback are preserved in GitHub
• Reviewers' approval timestamps and identities are recorded
• All review comments (resolved and unresolved) are accessible in PR history
• This demonstrates that code review requirements were met

Distribution

Verification of the release candidate

The verification phase aims at verifying that the software meet the technical requirements by executing the tests of the T-012-033 Software Tests Plan. Every requirement of the Software Requirement Specification shall be verified by at least one Test Case.

The verification phase commences under the JD-007's responsibility. He documents and verify the release eligibility criteria using the T-012-024 Software Candidate Release Phase 3 Checklist to ensure the software meets all criteria, such as implementing all SRS, risk mitigations and acceptable test coverage.

Test activities are then completed by the Software Testing Team according to the plan. All Test Execution results are documented and tracked in TestRail and GitHub Issues, and the team produce the final version of the T-012-035 Software Test Run and Traceability Matrix (see section "Test management and traceability with TestRail").

warning

If the software is modified in the middle of a tests phase, for example to fix a blocking bug, all tests on which the bug and the bug fix have an impact, shall be re-run, additional testing might be required to demonstrated that no unintended side effects have been introduced and risk management activities shall be performed. A new T-012-024 Software Candidate Release Phase 3 Checklist shall be documented.

Distribution of the software for production

For any version that AI LABS wish to put into production after evolution or correction of an anomaly, the Software Development Team is in charge of producing all the deliverables to ensure production.

The process of releasing a version follows the procedure described and the steps defined in the GP-017 Technical assistance service and GP-029 Software Delivery And Comissioning.

Delivery is initiated by the JD-007, who creates the distribution sheet from design transfer documented in T-012-039 Validated Version Transfer:

• the traceability of the version in question, that is to say the version number and its changelog,
• version tag in the development factory,
• all automatic and manual test reports,
• the updated documentation to fill the DHF and TD,
• up-to-date user manuals.

The distribution sheet constitutes the final step in Product Validation Phase 5, as described in the process documented in T-012-026 Product Validation Phase 5 Checklist. Following this step, the validation activities will be performed:

• checking user manuals,
• regulatory verification,
• release to the pre-production environment,
• validation via usability tests on a pre-production environment,
• release on the production environment,
• verification of the installation and commissioning in the production environment (see Software Delivery and Comissioning)

Software maintenance and problem resolution

Maintenance and servicing activities are carried out by the Support Team as described in the GP-017 Technical assistance service. The JD-003 is responsible for the implementation and execution of the servicing activities. The following diagram illustrates the servicing activities.

Suppport channels

Dedicated support channels, including help desks, online forums, and support teams, will be available to address user queries and issues related to the update, as defined in our GP-017 Technical assistance service procedure.

Support is provided for every customer/user request in all cases, within 48 working hours (first response). Working hours refer to the scheduled period during which Support Team is available at work, from 9am to 5pm.

Bug management

When technical issues are identified, they are immediately added to the project backlog as GitHub Issues. The reporter is responsible for providing the following initial information:

• Clear steps to reproduce the behavior : explain exactly how to trigger the issue
• Expected vs. Actual Results : describe what should happen compared to what actually happens
• Evidence : attach screenshots, recordings, or any other materials that demonstrate the issue
• Affected Version : specify the version of the software where the issue occurs
• Environment Details : clearly identify the environment, including the type of probe used, device model, and operating system version

To guarantee regulatory compliance, that all bugs are identified, documented, and addressed according to relevant medical device standards, a meeting is held under the responsibility of the JD-003 and/or JD-007.

Bug triage meeting

• Objectives. Review the bug backlog to ensure all bugs are documented and addressed according to the relevant medical device standards
• Responsibilities:
  • JD-003 and/or JD-007: leads the meeting, facilitates and guides the discussion, ensuring everyone participates and the team stays focused.
  • Software Development Team / Testing Team members: provides insights into the technical aspects and potential solutions based on their knowledge of the device.
  • QARA Manager: oversees the bug review process and ensures a thorough risk assessment is conducted for each bug. Provides guidance on regulatory considerations for bug classification and resolution based on relevant standards
• Activities
  • Bug Review : each bug undergoes a combined business and technical discussion
  • Risk Assessment : identify and categorize reported bugs based on their severity and potential impact on device functionality and safety
  • Prioritize bugs : define the priority of each bug regarding their Risk Assessment

Risk assessment

During the Triage Meeting, attendees leverage the FMEA methodology (defined in GP-013 Risk management) to discuss and define how the bug affects the safety, security, or performance of the device:

• Risk Evaluation: this step involves defining two key factors Probability of Occurrence and Severity.
• Risk Acceptability : based on the Risk Priority Number (RPN) calculated by multiplying probability and severity, the team determines if the risk is acceptable
• Risk Assessment & Control Measure: the team analyzes the root cause of the bug, proposes a correction plan to address the bug, recommends control measures to mitigate the risk if necessary. Some preventive actions can result is the root cause could be mitigated.

The evaluation results, including the acceptability, risk assessment, and control measures, are documented in the GitHub Issue using labels and comments.

::: warning Review the following part because the risk management doesn't talk about GitHub Issue tickets :::

According to the method described in the product risk management plan and to the procedure, the GitHub Issue must be linked to a risk:

• Previously known hazardous situation: the Issue is linked to a RISK label, and the estimated severity and probability of occurrence of this risk is reviewed and updated if needed.
• New dangerous situation or a sequence of events not yet identified: the new risk is evaluated using the risk analysis method. A new GitHub Issue with the RISK label is created and linked to the Problem Report Issue (via issue relationships or PR references).
• New risk control measures are required.

A Change Request should be opened in these three cases following GP-023 Change control management. If it is decided to take no action, this rationale should be documented in the GitHub Issue.

Priority level

The priority is set based on the risk assessment. Following this, bugs or defects undergo the previously described analysis and refinement process.

SOUPs, Software Items and NPS Management

SOUPs and Software Items management

In accordance with ISO 13485 and EN 62304, a robust procedure for managing SOUPs and Software Items is essential for medical device development. This methodology prioritizes risk mitigation while ensuring software quality.

The JD-007 is responsible of SOUPs and Software Items management activities.

Here are described the activities:

• Identification: all third-party software components and Software Items developped in the device are thoroughly identified and documented.
  • SOUPs, this includes libraries, frameworks, and any embedded code, documented in T-012-019 SOUP, also exported in SBOM (add link)
  • Software Items will be listed and documented in T-012-029 Software Architecture Description
• Classification & Risk Management: each SOUP and Software Items are categorized based on its impact on the device's safety and functionality. Higher risk require stricter controls. If safety risks are identifie, measure control and mitigation should be properly documented. The risk level classification is defined as described in the table below.
  • Acceptable
  • AFAP (“As Far As Possible”). Review required, acceptable with current risk minimization measures.
  • Unacceptable
• Security vulnerabilities : for each SOUP, vulnerabilities should be listed.
• Verification: the functionality and safety of the software are rigorously tested to ensure it meets the device's requirements. This process encompasses both internally developed Software Items and SOUPs used within the device. Verification leverages a suite of Test Cases derived from the SRS. These Test Cases define specific scenarios and expected outcomes, allowing for a systematic evaluation of the software's behavior against the documented requirements. Through rigorous verification, we gain objective evidence that the software functions as intended and adheres to the critical safety standards outlined in the SRS.
• SOUPs Review and Update: the SOUP list (available at T-012-019 SOUP) is reviewed annually. Additionally, the team can initiate an update outside the annual cycle if deemed necessary. Any updates to SOUPs require JD-007 approval following verification of the changelog, potential regressions, and security vulnerabilities. A new revision of the T-012-019 SOUP and Software Bill of Materials. The functionality and safety of the software should be reverified.

Signature meaning

The signatures for the approval process of this document can be found in the verified commits at the repository for the QMS. As a reference, the team members who are expected to participate in this document and their roles in the approval process, as defined in Annex I Responsibility Matrix of the GP-001, are:

• Author: Team members involved
• Reviewer: JD-003, JD-004
• Approver: JD-001