GP-012 Design, redesign and development

Owners

Name	Title	Meaning	Approved Date & Time
Gerardo Fernández Moreno	JD-007 Technology Manager	processowner	17 Jul 2025 10:22 CET
Saray Ugidos Semán	JD-004 Quality Manager & PRRC	verifier	17 Jul 2025 10:22 CET
Taig Mac Carthy	JD-003 Design & Development Manager	approver	17 Jul 2025 10:22 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 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.

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

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. 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
- 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
- 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).
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.
Outputs

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-024 Cyber Security, by JD-007.
AI/ML Development activities are launched regarding the GP-028 AI Development by JD-005.
Usability activities are launched regarding the GP-025 Usability by JD-003.

Inputs:

Device description and specificaction
Product Requirements

Outputs:

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

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

warning

link to templates

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

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.

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

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

Technical documentation traceability overview

See below 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).

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-028-010 V&V Release Report.
- T-012-033 Software Tests Plan

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

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

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 Commissioning Checklist
- 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.

Owners​

Change History​

Purpose​

Scope​

QMS Relationships​

Reference Documents​

Terms and Definitons​

Process and Responsibilities​

Responsibilities​

Phase 1. Product Design​

Product specification​

Product Design Review​

Phase 2. Software Design​

Other procedures kickoff​

Software Planning and Specification​

Validation Plan​

Software Architecture, Detailed Design and Implementation​

Software Design Review​

Technical documentation traceability overview​

Phase 3. Agile & Iterative development​

Phase 4. Software Verification​

Software verifications​

Software Verification Review​

Phase 5. Product Validation​

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​