GP-012 Software Development Procedure

Owners

Name	Title	Meaning	Approved Date & Time
CTO		processowner	20 Jan 2025 18:22 CET
Saray Ugidos Semán	Saray Ugidos Semán	verifier	21 Jan 2025 10:24 CET
CPO		approver	20 Jan 2025 17:58 CET

Change History

Revision	Summary	Date
01	Initial integration	7 Jul 2025

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 products, as a Legal Manufacturer.

Please refer to the R-TF-012-009 Validation and testing of machine learning modesl for software development related to Al model development and GP-019 Software validation plan for other software developments.

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

Abbreviations or terms	Definition
Product Requirements (PRS)	Product Requirements: 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).

Process and Responsibilities

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.

Responsibilities

Role	Responsibilities
Chief Technical Officer (CTO)	Application of the present procedure Responsible for the software Design, development and Verification Operational follow up of the software development team
Chief Product Officer (CPO)	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

Product Design phase 1

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 CPO.
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. CPO surrounded by Head of Clinical Operation, product designer, QARA, CTO and CEO 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. This record corresponding of the proof of review of the phase. It includes the reference all records described below.
Deliveries
- Intended use
- Device description
- Product Requirements
- 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 CEO, CTO, and CPO 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 CPO 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
- Description and specifications
- Product requirements

Product Design Review

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

The CEO, CPO, CTO, Quality Manager and Regulatory Affairs 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
- Intended use
- Product Requirements
Output
- Product Design Phase 1 Checklist
- Estimated medical device class
- Estimated software class

Software Design Phase 2

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 CTO. 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
- Detailed design of Software Elements (Class C only)
- Risk Management: Software Element Error Effects Analysis
- UI Prototype defined
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).
Records.
- Software Design Phase 2 Checklist. This record corresponding of the proof of review of the phase. It includes the reference all records described below.
Deliveries
- Records from review at the end of phase 1
- Records for the DHF documents that include all documents from design (see below)

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 CPO, Product Designer, and QA/RA.
Clinical activities are launched regarding the GP-015 Clinical evaluation, by the Clinical Operations Manager.
Cyber Security activities are launched regarding the GP-013 Risk management, by CTO.
AI/ML Development activities are launched regarding the R-TF-012-009 Validation and testing of machine learning models.

Inputs:

Device description
Intended use
Product Requirements

Outputs:

warning

These are missing:

PHA Checklist
Security Risk Management Plan
Security Risk Matrix
AI/ML Description
AI/ML Development Plan
Data Collection Instructions
Data Annotation Instructions

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.

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 (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.

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
- Intended use
- Device Description
- Product Requirement
- Risk Matrix (draft)
Output
- T-012-023 Software Development Plan
- Software Requirement Specification
- Software Tests Plan
- Software Architecture Description
- Software configuration management plan
- Traceability Matrix
- Documentation level FDA
- Software Classification 62304
- SOUP List

Validation Plan

CPO 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, Cybersecurity, Risks, Clinical, will be produce to be validated during the review of this phase.

Input
- Intended use
- Device Description
- Product Requirement
- Risk Matrix (draft)
Output
- T-001-005 List of external documents
- All Plans of other procedures listed below

Software Architecture, Detailed Design and Implementation

Software architecture is created (and detailed design, if necessary, for Class C only). 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.

If new Safety Risks and 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

Input
- Product Design Phase 1 Checklist
- All outputs of Phase 2
Output
- Software Design Phase 2 Checklist
- DHF updated

Technical documentation traceability overview

See above a scheme representing the traceability implemented from Product Requirements to Test Cases. All of these items are tracked in the Software Development Factory (Jira and Confluence).

Agile & Iterative development phase 3

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 CTO. 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 SF14.01_Software Development Plan
When. Start after Product Design Phase 1, 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.
Deliveries
- Release Candidate Software package
- Technical Documentation

Software Verification phase 4

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 CTO. 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.
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.
Deliveries
- Records from previous phases
- Residual anomalies list with risk analysis
- Verified software RC
- DHF documents that include all documents from design and development, including verification and validation reports

Software verifications

The software is built from the release branch 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 CPO/CTO 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 CTO initiates the RC software release to build a final release and its associated documentation to be validated in phase 5.

Input
- Software documentation, including risk analysis
- Tests Plan
- Implemented Software
Output
- Test Runs
- Observed defect list during the test activities

Software Verification Review

The CEO, CPO, CTO, Quality Manager and Regulatory Affairs 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
- All outputs of previous phases
Output:
- Implemented Software, i.e. code
- T-012-025 Software Verification Phase 4 Checklist with residual anomalies listed with their risk analysis
- T-012-38 Verified Version Release with the description of the verified version release.
- DHF updated

Product Validation phase 5

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 CPO. Surrounded by:
- CTO, who is in charge of the operational follow up of the team
- Quality Manager et Regulatory Affairs who are in charge of the Product Validation
What. Phase 5: Product Validation.
- Summative evaluation of the application
- Demonstrated Claimed Use
- Known Adverse Reactions
- Clinical Evaluation Report (CER): Satisfactory Benefit/Risk Balance
- Clinical Investigations, if applicable
- PMS Plan and PMCF Plan
- Labelling / User manual / Translation
- SSCP (Class III and Implantable only)
- Regulatory Files available, demonstrating conformity to GSPRs
- Release of a version uniquely identified according to configuration management on the production environment: “market launch”
- Commissioning activities
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.
Deliveries
- Records from review of all phases
- Version Delivery Description
- Residual anomalies list with risk analysis
- All reports from other procedures
- DHF documents that include all documents from design and development, including verification and validation reports
- Technical Documentation CE Marking

The CPO initiates the validation process with the intent to validate verified software. The CPO, 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
R-TF-012-009 Validation and testing of machine learning modesl and associated records
GP-013 Risk management
Cybersecurity and Transparency Requirements

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. 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
- R-TF-012-006 Lifecycle plan and report
- SF26.02_Security Risk Assessment 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-012 Design, Redesign and Development. The Software Testing Team produce the test report executed for commissioning as described in T-029-001 Commissioning Checklist.

Design transfer

Artefacts transferred to production are documented in the T-012-027 Version delivery description.

Design transfer documentation is reviewed to ensure that:

Artefacts are suitable for installation on target sites
Support department in charge of installation and servicing is able to perform these tasks.

Training actions can be planned to ensure that the support department (hotline, customer service, customer care, customer success) can perform these tasks.

Product Validation Review

The CEO, CPO, CTO, QA/RA Manager and head of Clinical Operation 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, T-012-22, T-012-024, T-012-025
- All outputs of previous phases
- All reports of Clinical, Risks, Usability, AI/ML, Cybersecurity
Output
- T-012-027 Version delivery description
- T-029-001 Commissioning Checklist
- T-012-026 Product Validation Phase 5 Checklist
- Software validated
- 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, cybersecurity), the QARA manager can proceed with product certification and registration. Once the review confirms completion, the QARA manager can initiate the submission process.

This submission typically includes, at a minimum:

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 CPO/CTO 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, DESKI provides support to users. The process is described in SOP22_Servicing activities.

Design Modification

This section is applicable to final software versions released to end-users.

A design change is initiated following a change request, which is T-023-001 Change control. There are various sources of information, which can trigger a software maintenance or design modification:

Every information, problem and feedback reported from the field (end-users, technicians...)
Information collected internally: changes in regulatory requirements, information from the software development team or the support team.
Business inputs or market needs leading to the implementation of new features

Every change request (see Change control management) is recorded in the eQMS and can contain:

Product requirements,
Regulatory requirements,
Results of risk assessments requiring change in software,
Results of usability engineering requiring change in software,
Results of cyber-risk assessments requiring change in software,
Any other relevant change (labeling, IFU, packaging ...).

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

Templates to created

Description and specifications

SF14.18_Device Description SF14.19_Intended use

https://qms.legit.health/legit-health-plus-version-1-1-0-0/description-and-specifications

Traceability Matrix

SF14.14_Traceability Matrix

Regulatory

SF14.15_Documentation level FDA SF14.16_Software Classification 62304 SF14.20_Regulatory Requirement

https://qms.legit.health/legit-health-plus-version-1-1-0-0/design-and-development/R-TF-012-006/#software-safety-classification

Owners​

Change History​

Purpose​

Scope​

QMS Relationships​

Reference Documents​

Terms and Definitons​

Process and Responsibilities​

Responsibilities​

Product Design phase 1​

Product specification​

Product Design Review​

Software Design Phase 2​

Other procedures kickoff​

Software Planning and Specification​

Validation Plan​

Software Architecture, Detailed Design and Implementation​

Software Design Review​

Technical documentation traceability overview​

Agile & Iterative development phase 3​

Software Verification phase 4​

Software verifications​

Software Verification Review​

Product Validation phase 5​

Final Risk Assessment and Risk-Benefit Analysis​

Commissioning activities​

Design transfer​

Product Validation Review​

Post validation activities & product release​

Software maintenance and Problem resolution​

Design Modification​

Related QMS Documents​

Templates to created​

Description and specifications​

Traceability Matrix​

Regulatory​