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

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

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
  • 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-024-002 Cyber Security Risk Management Plan
  • T-024-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-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:

• 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-024-002 Cyber Security Risk Management Plan
• T-024-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

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
  • 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 (draft)
  • T-012-040 Documentation level FDA
  • T-012-041 Software Classification 62304
  • T-012-019 SOUP

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
  • T-001-005 List of external documents
  • T-025-001 Usability Plan
  • T-024-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.

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

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-042 Regulatory Requirement
• T-012-043 Traceability Matrix (draft)