GP-012 Design, redesign and development

Procedure flowchart

Purpose

This procedure describes the phases of software development and maintenance in the lifecycle of software developed by AI Labs.

The purpose of this procedure is to describe:

• the review required at each stage of product design phase
• the appropriate verification, validation and design transfer activities
• responsibilities and authorities for design
• methods for ensuring traceability of design outputs and development inputs
• the resources required, including the necessary competence of personnel

Scope

This procedure applies to AI Labs and must be respected for the design and development of AI Labs's medical devices, as a Legal Manufacturer.

Please refer to the GP-028 AI Development for software development related to Al model development and GP-019 Software validation plan for other software developments.

Responsibilities

Role	Responsibilities
JD-007	Application of the present procedure Responsible for the software Design, development and Verification Operational follow up of the software development team
JD-003	Responsible of the product Design and Validation process Responsible of the validation Phase process
Product Team	Create and specify the Product Requirement Support the writing of the software requirements Design user interfaces and experiences
Software Development Team	Conversion of PRs into SRS Create the Software Architecture and Detailed Design Implementation and automated testing
Software Testing Team	Write test cases and plan the software testing Execute the software verification activities

Inputs

The procedure is initiated based on the following inputs:

• New business inputs, technical inputs, or product ideas
• Change Requests for an existing product
• Regulatory requirements

Outputs

The final outputs of this procedure are:

• The released software package, which can be deployed to target markets
• An updated Device History File (DHF)
• The Validated Version Transfer document detailing the artifacts transferred for deployment
• A completed Commissioning Checklist
• Regulatory submission documents, such as the Device Master File (DMF) and General Safety and Performance Requirements (GSPR) checklist
• Regulatory approvals, such as the CE Declaration and FDA 510K Clearance

Development

This SOP describes how software as a medical device is specified, developed, and released, compliant with the IEC 62304: 2006 standard & A1: 2015. The Software Development Process described in this SOP resembles an "evolutionary" strategy (IEC 62304:2006, Annex B), acknowledging that the user need is not fully understood and not all requirements are defined up front. Whenever requirements change, the preceding process steps and their outputs need to be redone to ensure consistent and complete documentation.

QMS Relationships

Reference Documents

• ISO 13485:2016 - Medical devices Quality management systems - Requirements for regulatory purposes, 4.2 Documentation requirements
• EN ISO 13485/A11:2021
• 21 CFR 820.40 - Document control
• 21 CFR 820.180 - General requirements
• 21 CFR 820.181 - Device master record
• 21 CFR 820.184 - Device history record
• 21 CFR 820.186 - Quality system record
• IEC 62304:2006 A1:2015
• IEC 82304-1:2016
• IEC 62366:2015
• ISO 14971:2019
• Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on Medical Devices, Amending Directive 2001/83/EC, Regulation (EC) No 178/2002 and Regulation (EC) No 1223/2009 and repealing Council Directives 90/385/EEC and 93/42/EEC

Terms and Definitons

• Product Requirements (PRS): High-level requirements of the product including user needs, regulatory.
• Regulatory Requirements (RR): Regulatory requirements are rules that AI Labs must follow. Means all applicable laws, rules, regulations, orders, requirements, guidelines, interpretations, directives, etc.
• Software Requirements (SRS): Software Requirements is a detailed document that outlines the functional and non-functional requirements of a software system. It serves as a contract between the stakeholders and the development team.
• SOUP: Software Of Unknown Provenance.
• Agile Methodology: Refers to the practices in software development that involve discovering requirements and developing solutions through the collaborative effort of self-organizing and cross-functional teams and their customer(s)/end user(s). It advocates adaptive planning, evolutionary development, early delivery, and continual improvement, and it encourages flexible responses to change. (Source: Agile Software Development).
• Backlog: A backlog is a set of tasks that must be finished before product can be released. During a product backlog grooming session, the Software Development Team works with business owners to prioritize a list of work that is backlogged and break the list into user stories for future use. (Source: Search Software Quality Information, News and Tips from Tech Target).
• Sprint: In Agile product development, a sprint is a set period of time during which specific work has to be completed and made ready for review. (Source: Search Software Quality Information, News and Tips from Tech Target).
• User Stories: A user story is a tool in Agile software development used to capture a description of a software feature from a user's perspective. The user story describes the type of user, what they want and why. A user story helps to create a simplified description of a requirement. (Source: Search Software Quality Information, News and Tips from Tech Target).
• GSPR: The General Safety and Performance Requirements (GSPRs) are a set of regulations established by the European Union (EU) to ensure the safety and effectiveness of medical devices placed on the European market. These requirements are outlined in the Medical Devices Regulation (MDR).

Phase 1. Product Design

All the Design process starts with the validation of the inputs to kick off the project.

Overview of Product Design Phase process:

• Who. The person responsible for the Product Design process is the JD-003.
• What. Phase 1: Establish Input Data for Software Design.
  • Business input / Technical input / Product ideas
  • Regulatory requirements
  • Change Request
  • Intended use / Device description
  • Product Requirements
• How. JD-003 surrounded by JD-018, JD-004, JD-007 and JD-001 produce all the documentation needed to describe the expected Medical Device
• When. Start with new business input, technical input, product ideas or Change Request.
• Records
  • Product Design Phase 1 Checklist (T-012-021). This record corresponding of the proof of review of the phase. It includes the reference all records described below.
• Outputs
  • Device description and specificaction
  • Product requirements
  • Product Design Phase 1 Checklist (T-012-021)
  • Estimated medical device class
  • Estimated software class

Product specification

The intended use describes the core medical functionality of the device and how it treats, diagnoses, or alleviates a disease using. The intented shall be described in the document "Description and specifications" of the Technical File.

Based on the intended use, the JD-001, JD-007, and JD-003 provide a high-level description of the product, notably providing the operating principles of the software in the document "Description and specifications" of the Technical File. They shall consider technical, business, and medical input to match the device's intended use.

The JD-003 is then responsible for defining the Product Requirements (also referred to as user needs or stakeholder requirements) that describe the high-level requirements the product must fulfill to address all stakeholders (User, Patient, Regulatory, Company, etc.).

• Input
  • Business input
  • Technical input
  • Product ideas
  • Regulatory requirements
  • Change Request
• Output
  • Device description and specificaction
  • Product requirements

Product Design Review

The JD-003 verifies that product requirements address all stakeholder's needs and cover the product's intended use.

The JD-001, JD-003, JD-007 and JD-004 review all the outputs of the phase. If the review is successful, move forward to the next step. If it's not, the output have to be reworked with possible changes to the PRs.

• Input
  • Device description and specificaction
  • Product Requirements
• Output
  • Product Design Phase 1 Checklist (T-012-021)
  • Estimated medical device class
  • Estimated software class

Phase 2. Software Design

The Software Design process starts with the validation of the inputs of Product Design.

Overview of Software Design Phase process.

• Who The person responsible for the Software Design process is the JD-007. Surrounded by the Lead Software Developper, who is in charge of driving operational tasks with the Software Development Team.
• What. Phase 2: Establish Input Data for development
  • Software development plan
  • Strategy for regulatory compliance, including device qualification and classification
  • Applicable GSPRs, applicable Harmonized Standards and Common Specifications
  • Application Specifications: Scientific Committee - Inventor - User
  • Software Specifications (SRS)
  • Preliminary risk analysis
  • Plan of other procedures
  • Software Architecture
  • Security Class of Software Elements/Units
  • Risk Management: Software Element Error Effects Analysis
• How According to the determined steps with their planning and formal reviews for passing each project milestone. This phase is the Kick off for other procedures. As the risk management steps are carried out according to the procedure GP-013 Risk management.
• When Start with the approval for Design of a new project (Product Design review) or change of an existing device (Change Control Request T-023-001).
• Records.
  • Software Design Phase 2 Checklist (T-012-022). This record corresponding of the proof of review of the phase. It includes the reference all records described below.
• Outputs
  • T-012-023 Software Development Plan
  • T-012-028 Software Requirement Specification
  • T-012-030 Software Configuration Management Plan
  • T-012-029 Software Architecture Description
  • T-012-033 Software Tests Plan
  • T-012-034 Software Test Description
  • T-012-043 Traceability Matrix (draft)
  • T-012-040 Documentation level FDA
  • T-012-041 Software Classification 62304
  • T-012-019 SOUP
  • T-013-001 Risk management plan
  • T-013-002 Risk management record_YYYY_nnn
  • T-015-001 Clinical Evaluation Plan_YYYY_nnn
  • T-030-002 Cyber Security Risk Management Plan
  • T-030-003 Cyber Security Risk Matrix
  • T-028-001 AI/ML Description
  • T-028-002 AI/ML Development Plan
  • T-028-003 Data Collection Instructions
  • T-028-004 Data Annotation Instructions
  • T-028-005 AI/ML Design Checks
  • T-001-005 List of external documents
  • T-025-001 Usability Plan

Other procedures kickoff

The start of this phase declares the kickoff of other procedures:

• Safety Risks activities are launched regarding the GP-013 Risk management, by JD-003 and JD-004.
• Clinical activities are launched regarding the GP-015 Clinical evaluation, by JD-018.
• Cyber Security activities are launched regarding the GP-030 Cyber Security Risk Management, by JD-007.
• AI/ML Development activities are launched and completed regarding the GP-028 AI Development by JD-017. Unlike other procedures, AI/ML development must be fully completed during Phase 2, delivering all algorithm packages, documentation, and validation reports before Phase 3 begins. This ensures the software development team receives complete, validated AI/ML components for integration.
• Usability activities are launched regarding the GP-025 Usability by JD-003.

Inputs:

• Device description and specificaction
• Product Requirements

Outputs:

• T-013-001 Risk management plan
• T-013-002 Risk management record_YYYY_nnn
• T-015-001 Clinical Evaluation Plan_YYYY_nnn
• T-001-005 List of external documents
• T-030-002 Cyber Security Risk Management Plan
• T-030-003 Cyber Security Risk Matrix
• AI/ML Complete Package (All outputs delivered at end of Phase 2):
  • T-028-001 AI/ML Description
  • T-028-002 AI/ML Development Plan
  • T-028-003 Data Collection Instructions
  • T-028-004 Data Annotation Instructions
  • T-028-009 AI/ML Design Checks
  • T-028-005 AI/ML Development Report
  • T-028-006 AI/ML Release Report
  • T-028-010 AI/ML V&V Checks
  • T-028-011 AI Risk Matrix
  • Algorithm package ready for software integration

Software Planning and Specification

The development team translates the PRs and Risks into Software Requirements (SRS) based on the specification and risk analysis.

The SRS are attributed to categories according to the IEC 62304 such as functional, data and database, security, regulatory, and including user interface requirements.

All Software Requirement Specifications, including those related to cybersecurity, AI/ML functionality, usability, and any other specialized domain, are centralized in a single consolidated document (T-012-028 Software Requirement Specification) to ensure complete traceability and consistency throughout the development process.

SRS that are safety and security risk control measures are labeled and new risks that may arise from SRS are listed and integrated in the safety and security risk matrices.

In addition, a software development plan is created (T-012-023 Software Development Plan), including notably:

• project organization, planning, and management
• development environment and tools
• development methodology
• problem/bug collection and resolution
• verification of the release
• validation of the release

The Development Plan is updated if necessary, as development proceeds.

Further, a configuration management plan is created, notably describing software versioning.

Software Versioning

Software versioning follows the guidance established in MDCG 2020-3 Rev.1 to ensure appropriate documentation and regulatory compliance for software changes.

Determining Change Significance

The significance of a software change is determined based on the potential impact to device safety, performance, and intended use. This evaluation considers:

• The nature and scope of modifications to the software
• Impact on device functionality and clinical performance
• Changes to the intended purpose or user interface
• Modifications to risk mitigation measures
• Updates to Software of Unknown Provenance (SOUP) components

For each software change, the team evaluates whether existing documentation remains valid or requires updates.

Documentation Management for Version Changes

Based on the change significance assessment, documentation is managed as follows:

• New document required: When changes are substantial and affect the device's safety profile, intended use, or clinical performance, new versions of relevant technical documentation (e.g., Instructions for Use, Clinical Evaluation, Risk Management) must be created.
• Update existing document: When changes are moderate but do not fundamentally alter the device's characteristics, existing documents are updated to reflect the modifications.
• Validation of existing documentation: When changes are minor and do not affect previously documented information, existing documentation is validated as still applicable without modification.

Version Numbering System

AI Labs uses a four-digit versioning scheme (W.X.Y.Z) to clearly communicate the significance of software changes:

• Fourth digit change (W.X.Y.↑) - Patch version: Represents minor corrections that do not affect the device's functionality, safety profile, or performance characteristics. Examples include:

  • Typographical corrections in non-critical text
  • Minor UI refinements that do not change user workflows
  • Performance optimizations without functional changes
  • Documentation updates without code modifications

• Third digit change (W.X.↑.Z) - Minor version: Indicates functional enhancements or non-critical updates that do not substantially alter the device's intended use or safety profile. Examples include:

  • New features that expand functionality within the existing intended use
  • SOUP component updates that improve functionality or security
  • Bug fixes that address non-critical issues
  • Enhancements to existing features that maintain backward compatibility

• Second digit change (W.↑.Y.Z) - Major version (Moderate): Represents significant modifications that may affect the device's performance, user interaction, or risk profile, but do not fundamentally change the intended purpose. Examples include:

  • Substantial changes to the user interface or clinical workflows
  • Introduction of new algorithms or processing methods that affect clinical outputs
  • Significant architectural changes that may impact device performance
  • Changes to intended patient populations or clinical indications within the same therapeutic area
  • Modifications requiring updated clinical evaluation or risk assessment

• First digit change (↑.X.Y.Z) - Major version (Substantial): Reserved for fundamental changes that significantly alter the device's intended purpose, core functionality, or introduce entirely new therapeutic applications. Examples include:

  • Complete redesign of core algorithms or clinical decision-making logic
  • Extension to new medical specialties or therapeutic areas
  • Fundamental changes to the intended purpose requiring new regulatory submissions
  • Major architectural overhauls that substantially change how the device operates
  • Introduction of new intended uses that expand beyond the original regulatory clearance scope

Technical File Organization by Version Type

The arrangement of documentation in the technical file depends on the type of version change:

• Patch versions (W.X.Y.↑): Only records that have changed are added to the technical file. A Change Request (CR-*) document must be included to explain the specific changes made.
• Minor versions (W.X.↑.Z) and Major versions (W.↑.Y.Z or ↑.X.Y.Z): All records from the technical file must be duplicated, even if some documents remain unchanged. This ensures complete documentation sets are maintained for each significant version.

SOUP Updates and Bug Fix Evaluation

Updates to Software of Unknown Provenance (SOUP) components are carefully evaluated to determine if they constitute minor version changes. Similarly, bug fixes are assessed to understand their impact:

• SOUP updates may trigger a minor version change if they affect device functionality, security, or performance
• Bug fixes are evaluated for their significance - critical bug fixes affecting safety or performance may warrant version incrementing beyond patch level
• All SOUP updates and bug fixes are documented in the Change Request system with appropriate justification for the version change determination

This versioning approach ensures that software changes are appropriately documented and that the technical file maintains clear traceability across all software versions.

Further, the software test plan includes test cases covering all software requirements. As requirements may change, the software system test plan is continuously updated to reflect those changes. In addition, a software test description further details the test cases.

• Input
  • Device description and specificaction
  • Product Requirement
  • Risk Matrix (draft)
• Output
  • T-012-023 Software Development Plan
  • T-012-028 Software Requirement Specification
  • T-012-033 Software Tests Plan
  • T-012-029 Software Architecture Description
  • T-012-030 Software Configuration Management Plan
  • T-012-043 Traceability Matrix
  • T-012-040 Documentation level FDA
  • T-012-041 Software Classification 62304
  • T-012-019 SOUP

Validation Plan

JD-003 prepare the Validation Plan of the Product. Validation will be conducted during Phase 5 by the review of each report.

In accordance to the intended use, all plans for Usability, Cyber Security, Risks, Clinical, will be produce to be validated during the review of this phase.

• Input
  • Device description and specificaction
  • Product Requirement
  • Risk Matrix (draft)
• Output
  • T-001-005 List of external documents
  • T-025-001 Usability Plan
  • T-030-002 Cyber Security Risk Management Plan
  • T-013-001 Risk management plan
  • T-015-001 Clinical Evaluation Plan_YYYY_nnn

Software Architecture, Detailed Design and Implementation

Software architecture is created. As the software development process follows agile methodology, the software architecture may evolve as new knowledge is gained during implementation. The result should be that both the implementation and the documented software architecture are synchronized. Software architecture may be described with components, equivalent to software items according to the IEC 62304.

SOUP is added/updated here, if necessary. For each SOUP, we specify the name, version, manufacturer, website link (incl. release notes and issue tracker), requirements, and prerequisites. SOUP must be verified before moving to the next step. Possible SOUP verification criteria include sufficient test coverage by the author and is commonly used; correct SOUP functioning is also verified through software verification and software system testing in the following steps.

SOUP request and approval process

Before introducing any new SOUP (Software of Unknown Provenance) into the medical device software, the following approval process must be completed:

1. Request submission: The developer proposing the new SOUP shall complete the T-012-044 SOUP Request and Approval Form, documenting:

   • SOUP identification (name, version, vendor/maintainer)
   • Intended use within the device
   • Justification for selection over alternatives
   • Preliminary risk assessment (patient data impact, safety criticality, security considerations)
   • License compliance verification

2. Review and approval: The completed request form shall be reviewed and approved by:

   • JD-007 (Software Development Lead) - Technical evaluation
   • JD-004 (Quality Manager) - Risk and compliance evaluation

3. Documentation: Upon approval, the SOUP documentation shall be created using T-012-019 SOUP template, including full requirements, system requirements, related risks, and anomaly evaluation.

4. Rejection handling: If the SOUP request is rejected, the rationale shall be documented and alternative solutions shall be considered.

Important

No new SOUP shall be integrated into the medical device software without prior completion and approval of the SOUP Request and Approval Form.

If new Safety Risks and Cyber Security Risks relating to software units and potential failure modes are discovered during this phase, they are added to the Risk Matrix.

Based on the SRS, the software architecture and the detailed design, the software development team creates tasks or user stories in the development backlog. The software development team plans and implements those during sprints of 1 to 4 weeks, along with potential bug fixes.

Software Design Review

The JD-001, JD-003, JD-007 and JD-004 review all the outputs of the phase. If the review is successful, move forward to the next step. If it's not, the output have to be reworked with possible changes to the risk analysis and PRs. In that case, move back to the relevant step above.

• Input
  • Product Design Phase 1 Checklist (T-012-021)
  • All outputs of Phase 2
• Output
  • Software Design Phase 2 Checklist (T-012-022)
  • DHF updated

Technical documentation traceability overview

Traceability from Product Requirements through Test Cases is established and maintained using GitHub's integrated toolchain.

• GitHub Issues: Track Product Requirements (PRs), Software Requirements (SRS), Test Cases, bugs, and risk controls. Each Issue links to originating requirements and downstream verification artifacts.
• GitHub Projects: Organize and visualize work across sprints and releases; filter by labels (e.g., safety-risk, security-risk) to verify risk control coverage.
• GitHub Pull Requests: Link code changes to SRS via issue references (e.g., Closes #1234), establishing bidirectional traceability between requirements and implementation.
• GitHub Releases: Tag verified releases (e.g., v1.2.0.0) and associate with GitHub Milestones, linking completed work to specific versions.
• Traceability Matrix (T-012-043): Demonstrates end-to-end traceability from PR → SRS → Test Cases → Test Results, including explicit linkage of risk controls to verification evidence.

See below a scheme representing the traceability chain implemented across the development lifecycle:

Phase 3. Agile & Iterative development

The Development process may starts during the Software Design Phase 2 as agile process in case of inputs.

Overview of Agile & Iterative development process:

• Who. The person responsible for the Development Phase process is the JD-007. Surrounded by:
  • Software Development Team, who is in charge of the development and produce all output as technical documents and software package
  • Software Testing Team, who is in charge of the planification of the verification phase
• What. Phase 3: Agile & Iterative development.
  • Coding
  • Integration
  • Verification test plan
  • Release of a version clearly identified according to the configuration management, on the pre-production environment
  • Updating of risk management
  • Formative evaluation of the application
• How. All the process and activities are described in the T-012-023 Software Development Plan.
• When. Start after Software Design Phase 2, once the product requirements have been clearly identified and SRS begins to be produced.
• Records. T-012-024 Software Candidate Release Phase 3 Checklist. This record corresponding of a Release Candidate package, ready to be verified by the Software Testing Team.
• Outputs
  • Release Candidate Software package
  • DHF updated
  • T-012-033 Software Tests Plan
  • AI/ML algorithms integrated into software (AI/ML development was completed in Phase 2)

Phase 4. Software Verification

The Software Verification process starts with the review of a Release Candidate.

Overview of Design Phase project process.

• Who. The person responsible for the Verification and Validation Phase process is the JD-007. Surrounded by:
  • Software Testing Team who is in charge of testing tasks
• What. Phase 4: Verification of software
  • Testing activities
  • Verification results
• How. According to the determined steps with their planning and formal reviews for passing each project milestone. Testing activities are described in the T-012-023 Software Development Plan and the T-012-033 Software Tests Plan.
• When. Start after Phase 3, once Release Candidate have been identified
• Records.
  • T-012-025 Software Verification Phase 4 Checklist. This record corresponding of the proof of validation of the phase. It includes the reference all records described below.
• Outputs
  • Records from previous phases
  • Residual anomalies list
  • Release Candidate Software package
  • T-012-025 Software Verification Phase 4 Checklist
  • T-012-035 Software Test Run
  • T-012-038 Verified Version Release.
  • DHF updated

Software verifications

The software is built from the release branch (named release/W.X.Y.Z for the target version) to create a Release Candidate (RC). The Software Testing Team then executes the test cases as detailed in the software test plan. Any anomalies encountered are reported as defects. These reported defects are then analyzed for their impact on patient safety.

The JD-003 and/or JD-007 will decide whether to fix the defects before release or allow the product to go live with them. If a fix is required, a new Release Candidate will be built, and a new round of testing will be conducted using a revised test plan if necessary.

If the test results have successfully passed and all residual anomalies are considered minor, the JD-007 initiates the RC software release to build a final release and its associated documentation to be validated in phase 5.

• Input
  • DHF updated
  • T-012-033 Software Tests Plan
  • Release Candidate Software package
• Output
  • T-012-035 Software Test Run
  • Residual anomalies list

Software Verification Review

The JD-001, JD-003, JD-007 and JD-004 review all the outputs of Development Process and Phase 3. If the review is successful, move forward to the next step: Phase 5. If it's not, the output have to be reworked.

In that case, move back to the relevant step above.

• Input:
  • Release Candidate Software package
  • All outputs of previous phases
• Output:
  • Release Candidate Software package
  • T-012-025 Software Verification Phase 4 Checklist with residual anomalies listed with their risk analysis
  • T-012-038 Verified Version Release with the description of the verified version release.
  • DHF updated

Phase 5. Product Validation

The Product Validation process starts once:

• the Release Candidate has been verified
• no known anomalies are identified, or identified anomalies have acceptable risk assessments
• all reports from other procedures are completed.

Overview of Product Validation Phase process:

• Who. The person responsible for the Product Validation Phase process is the JD-003. Surrounded by:
  • JD-007, who is in charge of the operational follow up of the team
  • JD-004 who are in charge of the Product Validation
• What. Phase 5: Product Validation.
  • Clinical Evaluation Report (CER): Demonstrated Claimed Use, Known Adverse Reactions, Satisfactory Benefit/Risk Balance
  • Clinical Investigations, if applicable
  • Summative evaluation of the application (Usability)
  • Final Risk Assessment: Complete "Verification of Effectiveness" column in Risk Management Record
  • Commissioning activities in production environment
  • Post-Commissioning Risk Review: Confirm no new risks identified during commissioning
  • PMS Plan and PMCF Plan
  • Labelling / User manual / Translation
  • Regulatory Files available, demonstrating conformity to GSPRs
  • Release of a version uniquely identified according to configuration management on the production environment: "market launch"
• How. According to the determined steps with their planning and formal reviews for passing each project milestone. The team proceed to the review of the software related SOP reports and finalize risk assessment and conclusions.
• When. Starts once the Release Candidate have been verified and know anomalies are acceptable.
• Records
  • T-012-026 Product Validation Phase 5 Checklist
  • This record corresponding of the proof of validation of the product. It includes the reference all records described below.
• Outputs
  • T-012-039 Validated Version Transfer
  • DHF updated and all reports from other procedures

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 Al/ML development team, and the software development team collects all necessary data for releasing the product and its associated documentation generated throughout:

• the current SOP
• GP-015 Clinical evaluation and associated records
• GP-028 AI Development and associated records
• GP-013 Risk management and associated records
• GP-030 Cyber Security Risk Management 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.

Final Risk Assessment and Risk-Benefit Analysis

The overall risk of the product is evaluated by analyzing all identified risks so far. This includes completing the "Verification of Effectiveness" column in the Risk Management Record (T-013-002) to confirm that all risk control measures have been implemented and their effectiveness verified.

The final risk assessment shall verify:

• All risks have been identified and assessed
• All risk control measures have been implemented
• The effectiveness of each risk control measure has been verified (documented in "Verification of Effectiveness" column)
• All residual risks are within acceptable limits
• No unacceptable new risks were introduced by risk control measures

If unacceptable risks exist, they are weighed against the benefits of the Medical Device as part of the Clinical Evaluation SOP and as specified by the Clinical Evaluation Report. We only continue to release the Medical Device if the benefits outweigh the risks.

If unacceptable risks remain which are not outweighed by the benefits, we consider adding new risk control measures and move back into the relevant step in the process.

The finalization of the Risk Management Report is the prerequisite for finalizing the Software Safety Classification.

• 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

Before a medical device is released for public use, it undergoes a rigorous commissioning process. This involves setting up the device in a real-world environment, mimicking its intended use scenario. Here, Software Testing Team meticulously test all the core functionalities to ensure the device performs as designed. This real-world testing helps validate the device's effectiveness and safety in the actual conditions it will encounter, ultimately ensuring it meets its intended purpose and delivers the expected benefits to patients.

All activities for distribution, installation and commissioning are described in the GP-029 Software Delivery And Comissioning. The Software Testing Team produce the commissioning records as described in:

• T-029-001 Deployment & Configuration Commissioning
• T-029-002 Functional & Interface Commissioning
• T-029-003 Clinical Workflow & Operational Readiness Commissioning

Post-Commissioning Risk Review

Per GP-013 Risk Management and ISO 14971:2019, after commissioning activities are completed, a final review of the Risk Management File is required to confirm that no new risks were identified during commissioning in the production environment.

This review shall verify:

• No new risks were identified during deployment and configuration commissioning (T-029-001)
• No new risks were identified during functional and interface commissioning (T-029-002)
• No new risks were identified during clinical workflow commissioning (T-029-003)
• No existing risk control measures were found to be ineffective in the production environment
• The Risk Management Record (T-013-002) is updated if any new risks are identified
• The overall residual risk assessment and risk-benefit analysis remain valid

If new risks are identified during commissioning, they must be assessed and controlled according to GP-013 Risk Management before proceeding with design transfer. If no new risks are identified, the Risk Management File can be closed and design transfer can proceed.

• Input
  • Commissioning records (T-029-001, T-029-002, T-029-003)
  • T-013-002 Risk Management Record
  • T-013-003 Risk Management Report
• Output
  • Post-commissioning risk review confirmation (documented in T-012-026 Product Validation Phase 5 Checklist)
  • Risk Management File closure confirmation

Design transfer

Artefacts transferred to production are documented in the T-012-039 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.

Phase 5 Closure and Technical File Completion

Phase 5 is closed through the completion and approval of two key documents:

1. T-012-026 Product Validation Phase 5 Checklist: Records the review of all Phase 5 activities (Clinical Evaluation, Usability Summative Evaluation, Final Risk Management Review, Commissioning, and Post-Commissioning Risk Review)
2. T-012-039 Validated Version Transfer: Records the formal authorization for market release

Upon approval of both documents, Phase 5 is complete and the Technical File for this version is formally closed. This closure signifies that:

• All validation activities have been completed satisfactorily
• All regulatory documentation is complete and consistent
• All procedural reports (Clinical, Risk Management, Usability, Cybersecurity, AI/ML) are finalized
• The Risk Management File has been closed with no outstanding risks
• The Design History File (DHF) contains all required records for the version
• The version is ready for regulatory submission and market release

Product Validation Review

The JD-001, JD-003, JD-007, JD-004 and JD-018 review all the outputs of Phase 4. If the review is successful, move forward to final product release. During this review, attendees will verify that all procedures have produced reports according to their plan, and verify that all regulatory requirements are fulfilled.

If it's not, the output have to be reworked. In that case, move back to the relevant step above.

• Input
  • T-012-021 Product Design Phase 1 Checklist
  • T-012-022 Software Design Phase 2 Checklist
  • T-012-024 Software Candidate Release Phase 3 Checklist
  • T-012-025 Software Verification Phase 4 Checklist
  • All outputs of previous phases
  • All reports of Clinical, Risks, Usability, AI/ML, cyber security
• Output
  • T-012-039 Validated Version Transfer
  • T-029-001 Deployment & Configuration Commissioning
  • T-029-002 Functional & Interface Commissioning
  • T-029-003 Clinical Workflow & Operational Readiness Commissioning
  • T-012-026 Product Validation Phase 5 Checklist
  • Release Candidate Software package
  • CE Declaration
  • FDA 510K Clearance
  • DHF updated

Post validation activities & product release

Before the product validation review (as outlined in T-012-026 Product Validation Phase 5 Checklist) ensures the completion of all required process steps (software development, usability evaluation, risk analysis, cyber security), the JD-004 can proceed with product certification and registration. Once the review confirms completion, the JD-004 can initiate the submission process.

This submission typically includes, at a minimum:

• Device Master File (DMF) creation (or revision for product updates)
• General Safety Performance Requirement Checklist (GSPR)
• FDA Submission (cover letter, 510(k) application with fees, eStar)
• CE Submission (CE Declaration of Conformity, cover letter, BSI checklist)
• Notification to the national authorities of each distribution country
• Change control closure (for product updates)

All documents must be signed by both a member of Top Management and the Person Responsible for Regulatory Compliance (PRRC).

Following approval from the relevant authorities, the product can then be released on the market.

Software maintenance and Problem resolution

When technical issues are identified, they are immediately added to the project backlog. The team consistently reviews the list of anomalies during a Bug Triage meeting. This meeting aims to define the risk associated with each issue, prioritize the list, and ensure all bugs are identified, documented, and addressed according to relevant medical device standards, guaranteeing regulatory compliance. The JD-003 and/or JD-007 is responsible for overseeing this process. The Bug Triage process is further described in the T-012-023 Software Development Plan.

Concerning product released to end-users, AI LABS provides support to users. The process is described in SOP22_Servicing activities.

Design Modification

Pre-market changes: Changes in the design and development phase of the product prior to market launch will trigger the same procedure and the new phases until the new validation. For more information on this process see this same procedure. GP-012 Software Design and Development.

Post-market changes: changes to the device once it is already on the market will be managed through GP-023 Change control Management. The analysis of the relevant change will be performed not only in the device but also in the communications to customers or authorities. For more information on this process see GP-023 Change Control Management.

To be consistent, Design Modification process use the same process and review that Initial Design.

Associated Documents

• T-012-019 SOUP name
• 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-038 Verified Version Release
• 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 (PRS)
• T-012-033 Software Test Plan
• T-012-034 Software Test Description
• T-012-035 Software Test Report
• 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-043 Traceability Matrix (draft)
• T-012-044 SOUP Request and Approval Form

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