GP-012 Design, Redesign and Development

Procedure flowchart

Purpose

To describe the systematic procedure by which we manage the design, redesign and development of the medical devices that we manufacture.

Scope

The design and development process of all our medical devices, that are software devices.

Definitions

• DHF: Design History File
• HCP: Health Care Professionals
• QMS: Quality Management System
• TF: Technical File

Responsibilities

JD-001

• To approve the entire design and development process of the products according to the initial requirements.

JD-005

• To ensure that the entire process of control, verification and validation of the products design and development is carried out according to the methodology established in the present procedure.

JD-003

• To oversee and coordinate the entire design and development process of the products in accordance with the methodology outlined in this procedure.

JD-004

• To ensure that the design and development procedure is performed following this procedure, and that all the records required are properly generated, reviewed, approved and archived accordingly.

Inputs

• User, regulatory, technical, security and other requirements that must be accomplished.

Outputs

• Design History File (DHF):
  • T-012-001 Requirements
  • T-012-002 Activities
  • T-012-018 Test plan
  • T-012-003 Test run
  • T-012-004 Software version release
  • T-012-005 Design change control
  • T-012-013 Design stage review
  • T-012-019 SOUP
• T-012-006 _Product name_ life cycle plan and report
• T-012-007 Formative evaluation plan
• T-012-008 Formative evaluation report
• T-012-009 Validation and testing of machine learning models
• T-012-010 Device back up verification
• T-012-012 Customers product version control
• T-012-014 Summative evaluation plan
• T-012-015 Summative evaluation report
• T-012-016 Software usability guide
• T-012-017 Integration test review

Development

Design, redesign and development archive

To document and manage our design and development process, we have created a DHF stored in GitHub. However, some of the design and development processes are managed and documented in the Atlassian suite of applications. This is comprised by Jira, Confluence and Bitbucket, that we use as a design and development tool. The details about the design and development processes management is provided below:

Process	Tool
Requirements	GitHub
Activities	Jira and Bitbucket
Test plan	GitHub
Test run	GitHub (system test run), Bitbucket (unit, integration test run)
Releases	GitHub
Design change control	GitHub and Jira

We have also included the templates that are used in Atlassian. You can check them out at the Atlassian Global Templates section.

The other records that we create as a result of the application of this procedure are archived according to GP-001 Documents and records control within the corresponding medical device QMS TF folder.

DHF document review and approvals. 21 CFR part 11 compliance

DHF documents signature

Since some of the documents of the DHF are part of the Atlassian suite of applications, users need an Atlassian account to sign in. Each account has unique permissions, enabling us to track every action, its owner, and the date. We also utilize the eSign signature tool, which ties each signature to a unique account ID provided by Atlassian for the user profile. These eSign signatures are saved within our Atlassian Jira cloud instance, linked directly to the Jira issue as an extended property. To guarantee signature integrity, we use cryptographic encoding, ensuring the contents cannot be ordinarily tampered with. The initial signing process requires three identification components:

• Atlassian Jira username
• Atlassian Jira password
• eSign Signature pin

Subsequent signings (within continuous system access to JIRA) requires only the eSign Signature Pin.

For the rest of the DHF documents stored in GitHub, the signature process is managed and recorded in GitHub following the instructions provided in the procedure GP-001 Control of documents.

DHF documents review and approval

• Requirements (T-012-001 Requirements) can be created by JD-004, JD-005, JD-009 or JD-017, while they are approved by JD-003.
• Activities (T-012-002 Activities) can be created by JD-009 or JD-017, while they are approved by JD-005.
• Test plans (T-012-018 Test plan) can be created by JD-004, JD-009 or JD-017, while they are approved by JD-005.
• Test runs (T-012-003 Test run) can be created by JD-004, JD-009 or JD-017, while they are approved by JD-005.
• SOUP (T-012-019 SOUP) can be created by JD-004, JD-009 or JD-017, while they are approved by JD-005.
• Version release (T-012-004 Software version release) is created and approved by JD-005.

Activities

The Jira application enables tracking of all actions related to an activity by reviewing its history, since Jira records every modification made. Being part of the Atlassian suite of applications, users need an Atlassian account to sign in. Each account has unique permissions, allowing us to trace every action back to its owner and the date it occurred.

Product specifications

We include at the technical file PRODUCT_Description and specifications_YYYY_nnn document, at least, the following applicable specifications:

1. Intended use
2. User profile
3. Work environment
4. Information security considerations
5. Interaction with other devices
6. Principles of operation and mode of action
7. Product benefit
8. Safety requirements
9. Regulatory requirements
10. Packaging and labelling requirements
11. Storage and transportation requirements
12. Product classification according to applicable regulation
13. Previous experience and users' comments
14. Risks analysis

Traceability matrix

In the Technical File for each device, we keep a Design control matrix as Annex I of the R-TF-012-006 Lifecycle plan and report. Here we keep the traceability matrix for User requirements, Software requirement specification (SRS), Design requirements and Regulatory requirements.

Software versioning

In order to version our software, we apply the following scheme: R.X.Y.Z.

Given a version number R.X.Y.Z, we increment the following digits in the given scenarios:

• R: when we change the intended use or a functionality of the device that negatively affect the benefit:risk ratio.
• X: version when we make incompatible API changes.
• Y: version when we add software functionality in a backward compatible manner.
• Z: version when we make backward compatible bug fixes.

Changes to the intended use, changes to functionalities of the device that negatively affect the benefit:risk ratio, incompatible API changes are considered major changes; while changes in the software functionality in a backward compatible manner are consider minor changes.

When a need of change arises, we classify it according to the type of design changes described above, and we evaluate their signficance according to the guidance MDCG 2020-3.

In general, major changes are classified as significant while minor changes and bug fixes are classified as non-significant.

Further information on design change management are provided in this procedure in the section Change control.

Requirements (Design inputs)

Why do we do what we do? Because there is a problem to solve or a need to fulfill. That is why the first thing we do is understand what is the problem we are solving. Then, we define what the solution looks like. The document contains this information is what we call the requirements.

Requirements can come from requests made by customers, HCP, patients or members of our team, and they are shared with the top management to discuss their feasibility and priority to be developed.

Requirements may be related to new feature requirements, but they can also be update or upgrade requirements or bug fix requirements.

Once the requirement has been approved by JD-003, the JD-005, or designee, gathers the initial specs for a new product or new specs for the product development following the template T-012-001 Requirements. These requirements work as the input elements for the design and development of the product.

These input elements must include:

1. User requirements;
2. Functional and capability requirements, interfaces requirements, usability requirements, security requirements, data definition and database requirements, installation and acceptance requirements, requirements related to methods of operation and maintenance, according to the intended purpose;
3. Regulatory requirements and applicable standards;
4. The associated hazards;
5. The associated risk control measures;
6. Where appropriate, information derived from previous similar designs;
7. Other essential requirements for the product and process design and development.

The JD-003 reviews and approves the input elements to determine their adequacy, and by signing the requirements, JD-003 confirms that the requirements are complete, unambiguous, verifiable and not in conflict with each other, and they implement risk controls.

Types of requirements

1. Major requirements

When the requirement affects the core medical features of the device, such as the diagnostic or clinical features, or affects the intended use of the device, we call them major requirements.

The release of a change that comes from a major requirement implies the creation of a new version as explained in the section Software versioning of this procedure and it implies a complete revision of the TF and accompanying documentation, and notification to the Notified Body.

2. Minor requirements

When the requirement does not affect the core medical features of the device, such as the diagnostic feature, we call them minor requirements.

The release of a change that comes from a minor requirement gives place to a new intermediate version of the product, as follows:

Requirements arising from changes

In case of a design change, we follow GP-023 Change control management to verify if the change shall be communicated to the regulatory authorities (according to the Medical Device Regulation (MDR) 2017/745 and MDR 120).

The design change is documented in the template for requirements (T-012-001 Requirements), the content of which is defined below.

Requirements template and management

Requirements are created, approved and stored in GitHub by using the requirement template T-012-001 that contains the following information:

• Category (major, minor, functional)
• Source (regulatory, internal, HCP...) and source name(s)
• Activities generated
• Related risks
• User requirement, Software Requirement Specification, Design Requirement and Regulatory requirement (when applicable)
• Description
• Success metrics
• Previous related requirements (when required)
• Approval
• Design change description and need for communication of the change according to MDR 120 (when there is a design change).

When we receive or notice a new requirement, we share it with the top management (JD-001 and JD-003) to study its viability. If they decide we should include the new requirement into the manufacturing procedure, the JD-005, or designee, gathers the initial specs for a new product or new specs for the product development following the template T-012-001 Requirements.

Then, the JD-005 will procced to plan the requirement approach by creating the corresponding activities (see below), and the JD-003 will review and approve the final requirement document.

Design planning

As we have previously described, we document in the DHF the planning and the control of the product design and development process.

In this process, we take into account, at least:

• The design and development stages: requirements gathering, design planning, development, verification, validation, release and design change control.
• Information security considerations (see below).
• The necessary revision(s) at each stage of the design and development, that are explained throughout each section of this procedure and they are recorded in the T-012-013 Design stage review and they are part of the DHF.
• The design verification, validation, and transfer activities that are appropriate at each stage of the design and development.
• The responsibilities and authorities for the design and development, that are explained throughout each section of this procedure and defined along the DHF.
• The methods to ensure traceability of the design and development results regarding the design and development inputs.
• The necessary resources, including the necessary staff competence, are described within each activity.

Once the new requirement is approved and stored as part of the DHF, the JD-005 or designee plans and describes the activities required to complete the development of the software with the new requirement, with the start day of the activity and the planned due date, responsible and other details (see activities section).

Information security

Among other things, testing takes into account information security considerations following best practices from the industry and aligned with ISO/IEC 27001:2022.

During the design planning process, and as an output of our GP-013 Risk management procedure, we observe the OWASP® Foundation's Top 10 framework to foresee vulnerabilities and prevent attacks and malfuctions that may lead to information security non-conformities. The vulnerabilities that we are considering are, among others:

• A01:2021-Broken Access Control
• A02:2021-Cryptographic Failures
• A03:2021-Injection
• A04:2021-Insecure Design
• A05:2021-Security Misconfiguration
• A06:2021-Vulnerable and Outdated Components
• A07:2021-Identification and Authentication Failures
• A08:2021-Software and Data Integrity Failures
• A09:2021-Security Logging and Monitoring Failures
• A10:2021-Server-Side Request Forgery

Activities

To meet the requirements and to record how we develop our devices we carry out a series of activities, documented using the Jira template T-012-002 Activities in our DHF.

When we create an activity in our DHF, the layout and the properties will be inherited from the template, and we specify the following information:

• The tasks that it comprises
• The status
• The start date
• The deadline for its completion.
• The person responsible for executing it.
• The supervisor
• When applicable, the dependence with other activities
• The link requirement it comes from
• The tests it generates as a result, which contain the evidence related to the execution and the verification of the activity

In Jira, activities may have children issues, called tasks.

The tasks and the activity are linked in such way that the information from tasks is available at the activity level.

Managing activities

As mentioned, we use Jira to document our activities.

Jira is a tasks management application that is specially optimized for digital team processes. It is part of the Atlassian family, so an Atlassian account is required to sign in. Jira already has many of the functionalities that are necessary to comply with quality management.

Jira has boards, in which we manage and coordinate the work we are doing. One of these boards is the board dedicated precisely to the activities.

It's worth mentioning that Jira has a view Roadmap that automatically generates the GANTT diagrams from the activities, and even shows the tasks that belong to each activity. This GANTT diagrams allow us to plan and follow up the design and development activities.

It's also worth mentioning that, to manage the code itself, we use another atlassian tool, called Bitbucket. Bitbucket is a web-based repository hosting service for development and source code projects using Mercurial or Git revision control systems. We use the Git system to control the development of the software. This is not only applicable to us: practically all software companies use Git to keep track of software. In this regard, we follow the following procedure:

1. Once a task has been assigned to a developer, the first step is to move the task tab to "In Progress" in Jira, which means that the developer is working on it.
2. The developer then creates a new branch in code on Bitbucket from the master branch, whose name corresponds to the activity's code and name.
3. Once the task is complete, the developer will mark it in Jira as "Done". And it will be the person responsible for the activity, in case it is different, who will mark the task as finished in the corresponding activity.
4. Once the activity is complete, the responsible of the activity will mark it in Jira as "Done" as evidence of the verification of the tasks and activity has been performed satisfactorily.

This process ensures the traceability of the software developed with the defined activities and tasks, requirements and tests.

Design and development review

To ensure that the results meet the requirements, we conduct systematic product design and development reviews on each phase: requirements specifications, development of the activities, verification, validation and release of the product. As previously mentioned, the approval or design stage review is registered in the template T-012-013 Design stage review. This template documents the design stage and the design documents under revision, the participants involved in the design review as well as the date of the review. In case the output of the review is the approval of the design, the decision is documented in the template T-012-012 Design stage review and the design documents under reviewed are signed by the assigned roles. This means that the design phase under review has been successfully completed and reviewed.

If we find an issue during the review, we also propose the necessary actions to fix it and we document them in the T-012-013 Design stage review.

Design stage review are performed through dedicated meetings. The attendees of the review meetings include the leaders in charge of the area of the product that is under review, as well as any other required specialists.

Additionally, we have established automatic alerts to the activities responsibles to be aware of any activity deviation.

SOUP management

Each device may use specific SOUPs, and some of them may have very specific characteristics. But unless stated otherwise in the Technical File, the provision of this procedure will apply to SOUPs.

What is SOUP? 🥣

SOUP is an acronym for Software of Unknown Provenance.

A SOUP is a software element that:

1. Has already been developed, is generally available and has not been developed as an integral component of the device (also known as off-the-shelf software)
2. Is a previously developed software for which adequate records of the development process are not available.

SOUP documents are created starting from the template T-012-019 SOUP which contains the following information:

• Description
• General details
• Intended use on the device
• Requirements (functional, performance)
• System requirements (software, hardware)
• Documentation
• Related software items
• Related risks
• List of published anomalies
• History of evaluation of SOUP anomalies.

We perform an evaluation of SOUP anomalies to determine if any of the known anomalies that we have identified result in a sequence of events that could result in a hazardous situation. The evaluation of SOUP anomalies is recorded in the SOUP document.

We also specificy the system hardware and software required by the SOUP item to see if there are specific hardware and software requirements for the SOUP items that may be relevant to each device.

SOUP and versioning

Regarding the use of SOUP in our code, we must document the unique SOUP designator and the history of SOUP as they are related to the versions of our devices. This is crucial to guarantee traceability between the versions of our device and the version of the SOUPs used.

Unless stated otherwise, we use a file named requirements.txt inside the repository of each software item. That file has the purpose, precisely, of documenting the SOUP used on each software item, and thus on each version released of each device.

SOUP = Dependencies

In the domain of software development, SOUPs are called dependencies rather than SOUPs. These include packages, tools and frameworks, among other software items that are invoked or imported in the code.

We use requirements.txt by default in the design and development because this is the state of the art and the way in which all professional AI/ML software is developed. If the technical documentation of the device does not state otherwise, assume that this is how SOUP and versions are managed.

Also please note that we use technologies such as Pip that have also the purpose of tracing the SOUP versions (dependency versions) and ensure reliability across environments. These technologies read the requirements.txt file in the repository and build from there.

For instance, Pip is a technology created precisely to achieve consistency across environments and managing versions of dependencies used inside the code when deploying code into microservices. Pip looks for the unique SOUP designator in the requirements.txt file.

Example of requirements.txt file inside each repository

albumentations==1.3.1
boto3==1.28.45
cog==0.8.6
efficientnet_pytorch==0.7.0

Design verification

As we have mentioned, the activities and tasks performed as a result of the development process performed to satisfy a new requirement are transferred to one phase to the following one of their workflow by the responsible of the activity or designee, until they reach the "Done" status, meaning the completion of the activity and its verification.

Design validation: Tests (Design outputs)

We also carry out design and development validation to ensure that the resulting product is capable of meeting the particular requirements for its intended purpose. In other words, we test the activities.

The testing is carried out by verifying the technical, safety and operational aspects in accordance with the verification test plan (T-012-018 Test plan) that is contained in the Design History File, including information about the method of testing, the acceptance criteria and, where appropriate, the statistical techniques with justification for the size of the sample.

The person responsible for the test, in accordance with the responsibilities described in this procedure and in the T-012-006 _Product name_ life cycle plan and report, defines and prepares the necessary tests that must be carried out to ensure the activities performance was satisfactory.

The results of the test execution are documented by using the template T-012-003 Test run that is reviewed for completeness and approved (in case the test results meet the established acceptance criteria) by JD-005.

If there are tests that do not meet the acceptance criteria, these generate new activities to correct the errors found. This means that the activities end regardless of whether there are errors in the tests or not, they are the tests which generate new activities.

It's worth mentioning that tests can be very different between each other, depending what we are testing. For instance, we can conduct functional Tests (also called black box). These are tests on the software modules and that verify that a technical requirement is met. We conduct integration tests to ensure that all the software components work properly, and regression tests, that are the tests required to determine that a change to a system component has not adversely affected functionality, reliability or performance and has not introduced additional defects. However, we may also want to conduct user acceptance tests (UAT) when we want to involve actual users to see how they interact with the product.

When the device includes machine learning models, the specific metrics and methodologies to test their performance will be properly explained at the T-012-009 Validation and testing of machine learning models.

Before we release the product, the validation must be completed:

• If the release contains minor or functional requirements it is needed to justify that the previous clinical validation results are still applicable.
• If the release contains at least one major requirement it is required to perform a new clinical evaluation to ensure that the clinical safety and efficiency are preserved.
• If the release contains a change in intended purpose, it is required to perform a new clinical evaluation to ensure that the clinical safety and efficiency are preserved.

Any discrepancies or unexpected outcomes coming from the execution of the test are documented in an anomaly table in the section Defects and issues at the end of each test run record (T-012-003 Test run). This step makes sure that every defect, no matter how minor, is recorded for further analysis.

Following the identification and documentation of defects, an analysis is conducted to understand the root causes and impacts of these anomalies. This analysis informs the necessary corrections and modifications required to resolve the defects. If the implemented changes introduce new functionalities or significantly alter existing ones, new system tests are created to adequately cover these modifications.

This iterative process of testing, defect recording, analysis, correction, and re-testing is repeated until no inadmissible defects are identified.

Occasionally, minor defects may persist in new software releases. These are referred to as known residual anomalies. When such anomalies are identified, they are carefully assessed for their impact on the overall system. The evaluation criteria ensure that these defects are minor and have a low impact, confirming they do not compromise the security or functionality of the device. Only defects that meet these stringent criteria are accepted, since they pose no risk to the device's performance or user safety.

Managing tests

As mentioned, the DHF contains both test plan (T-012-018 Test plan) and test run (T-012-003 Test run).

Test plans are the documents where we describe how to execute the test (to allow repeatability of the test) and they contain at least the following:

• Description
• Minimum equipment
• Preconditions
• Input data
• Steps
• Expected outcomes
• Requirements that the test verifies
• Associated hazards
• Approvals

Test runs are the documents where we register the results of the test execution and they contain at least the following:

• Test type
• Linked activities
• Result (Passed / Failed)
• Description
• Run environment
• Expected results
• Actual results
• Summary of results
• Defects and issues
• Observations and recommendations
• Approvals

Things we verify

In the test, among other things, we verify that:

• The quality controls indicated in the Technical Documentation have been carried out with satisfactory results.
• The medical device is fully safe to use.
• The medical device is in compliance with regulatory and legislative requirements (related to the European MDR 2017/745) and any other applicable regulations in accordance with the technical documentation of the medical device.
• The medical device complies with its intended use and with the product quality standard.
• As manufacturers, we are providing adequate data.

The responsible person for executing the test will complete the corresponding template (T-012-003 Test run), adding the evidences of the test completion, once they have been performed. Then the JD-005 will review the test runs for their completion and, if the actual test results meet the expected outcomes, the JD-005 will perform the medical device release.

Information security

Testing also takes into account information security considerations following best practices from the industry and aligned with ISO/IEC 27001:2022.

OWASP Top 10

During testing process we observe the OWASP® Foundation's OWASP Top 10 framework to foresee vulnerabilities previously mentioned.

Penetration testing

We also carry out periodic penetration testing, as further explained in the general procedure GP-018 Infrastructure and facilities to discover vulnerabilities and protect the device from threats. This is done through a specialized supplier that performs the testing.

Penetration testing is carried out periodically, and also every time an activity is tested by the development team.

Programatic QA

The device incorporates Cypress for both Component Testing and E2E Testing. Testing is carried out at every activity testing.

Test examples

• Feature testing: when we are testing features of the device, we may want to extract metric about the accuracy, sensibility or specificity.
• Platform testing: when we test the interfaces that users use to write or read data.
• Integration testing: we are testing the code or achitecture related to the integration of the device with third parties.
• Medical testing: when we carry out tests with the specialists of a medical center to ensure that we achieved what they were specifically looking for.
• Patient testing: likewise, we may want to test if patients are happy with a feature, specially if it's somehow related to patients (which should not be the norm, as we are a clinical decision support tool for healthcare professionals).

Technical specifications

The technical specifications of the product are documented within each T-012-004 Software version release (DHF), and will be, among others:

• General features
• Programming language
• Specific features
• Compatibility: identification of the compatible operating system.

info

The following information is not applicable to our device, due to its technological nature:

• Environment: environmental limits (work, storage, transport).

Version release (Design transfer to production)

Once we have verified and validated the product, we transfer the design to production. In other words, we release a new version of the product into the market.

The results and conclusions of the transfer are recorded in the the DHF, following the template T-012-004 Software version release, that contains:

• New version to be released
• Prior version
• Approved requirements
• Sotftware verification and validation performed and successfully passed
• Technical specifications
• Final checklist to ensure that
  • all risks have been identified, evaluated, addressed and reduced as far as possible (including the ones coming from known anomalies)
  • design control traceability is well-documented
  • the technical documentation is up to date
  • all the verification and validation activities have been perfomed according to established plans and successfully passed
  • label is correctly applied, including CE marking
  • if the release includes significant changes, the Notified Body has been informed
  • the medical device complies with all the applicable regulatory and legislative requirements set out in MDR 2017/745 and any other applicable regulations and standards as specified in the technical documentation
  • the device has obtained the required regulatory approval (CE mark certificate)
• Known residual anomalies (and their evaluation in terms of risks)
• Approval performed by JD-005.

This version release constitutes the final step in the design and development process, that is why the template T-012-004 Software version release records the conformity of the results during the verification and validation proccesses, and the technical specifications. This way, we ensure that the results of product design and development meet product requirements and are appropriate for the intended use of the device.

In case the medical device requires regulatory approval from the Notified Body, the software version release will be performed once the regulatory approval is obtained.

Deployment of changes

Our deployment tool of choice is Bitbucket Pipelines, which is part of the Atlassian suite of applications.

Bitbucket Pipelines is a continuous integration (CI) and continuous deployment (CD) service built directly into Bitbucket. It allows us to build, test, and deploy our code based on a configuration file defined within the repositories. Essentially, it automates the process from code commit to deployment, ensuring that the code integrates and works as expected before it's deployed to a production environment.

Deployment of branches to multiple environments

Bitbucket Pipelines allows us to deploy to multiple environments. With Pipelines, we can set up different environments like staging, QA, and production, and control how and when the code gets deployed to these environments.

We do this alongside the Branch-Based Configurations. Ideed, we specify different pipeline behaviors based on the branch being pushed to.

Only when a branch has successfully passed all tests does Pipelines initiate the deployment process. This step-by-step progression ensures that only vetted and validated changes are integrated into the production software, but it does so in an automated way, to avoid errors in the proccess of running the deployment scripts.

Environment Variables

In Bitbucket Pipelines we also define secure environment variables for things like deployment keys or other secrets, ensuring they aren't exposed in our code or configuration. This increases the security of the application and limits the access to employees to sensitive information.

Common errors

Bitbucket Pipelines is a powerful CI/CD tool, but like any system, users can encounter errors based on a variety of circumstances. Here are some common errors and issues faced by users when deploying with Bitbucket Pipelines:

Pipeline Configuration Errors

Issue	Common Solution
Invalid YAML Syntax	Use a YAML validator. Ensure proper spacing and avoid using tabs.
Misconfigured Steps	Review the pipeline configuration. Refer to Bitbucket Pipelines documentation for proper step configuration.
Unsupported Docker Image	Check the image's compatibility with Pipelines. Prefer using well-supported, commonly-used images.

Environment Variables Issues

Issue	Common Solution
Missing Environment Variables	Define all necessary environment variables within Bitbucket Pipelines settings.
Sensitive Data Exposure	Use environment variables for secrets. Avoid hardcoding sensitive data in scripts or configuration.

Build Failures

Issue	Common Solution
Test Failures	Check test reports/logs. Fix the failing tests in the codebase.
Dependency Issues	Ensure all dependencies are listed and available. Consider using a lock file for consistency.
Insufficient Resources	Optimize the build process or consider splitting tasks. Monitor resource usage during build.

Deployment Failures

Issue	Common Solution
Authentication Errors	Check and refresh authentication tokens, SSH keys. Ensure proper permissions for deployment targets.
Connection Errors	Verify network connectivity. Ensure deployment targets are online and reachable.
Missing Deployment Scripts or Tools	Ensure all necessary scripts and tools are available in the Docker image or fetched during the pipeline.

Timeouts and Delays

Issue	Common Solution
Build Time Exceeded	Optimize build and test processes. Consider breaking the pipeline into smaller chunks or parallel tasks.
No Output Timeout	Ensure each step produces log output within the timeout window or adjust the configuration.

Concurrency Issues

Issue	Common Solution
Concurrency Issues	Implement locking mechanisms or queues. Schedule deployments to avoid overlap.

Repository and Git Issues

Issue	Common Solution
Repository and Git Issues	Check repository configurations. Resolve any merge conflicts or branch-related issues.

Cache Issues

Issue	Common Solution
Cache Issues	Clear and rebuild cache. Ensure caching configurations are correctly set up.

Service Interruptions

Issue	Common Solution
Service Interruptions	Monitor Bitbucket's status page. Consider retry mechanisms for transient errors.

Custom Script Errors

Issue	Common Solution
Custom Script Errors	Review and test custom scripts in isolation. Look for syntax or logical errors.

Third-party Integration Issues

Issue	Common Solution
Third-party Integration Issues	Check the respective third-party service's documentation and status. Ensure correct integration settings.

Ensuring that customers use the latest version

Our objective is to ensure that all customers access the most recent version of the medical device. Upon the release of a new version, the JD-005 assumes the responsibility of reaching out to customers to facilitate their transition to the updated version.

Given the enhancements in the new release, we strongly recommend customers to adopt the latest version by default. Nonetheless, we diligently maintain the T-012-012 Customers product version control document, which identified customers who haven't transitioned. This document is updated annually. The primary intent of maintaining this record is not only to realize our objective but also to establish a mitigation strategy for potential risks.

In the event of an incident or a product recall, we reference the version information stored directly on the server, rather than this record. This ensures that we accurately identify and communicate with the impacted customers.

IFU version

Considering that some users might be using previous versions of the device, to guarantee they can access to the proper IFU for that previous version, in the IFU there will be a drop-down containing the different IFU for the different device versions to select each of them and view the specifications of each version.

Usability engineering process

To ensure the safety and proper usage of each one of the medical devices that we manufacture, we perform during all the software life cycle an usability engineering process according to the UNE-EN 62366:2009/A1:2015 standard.

We include within the documents provided with the medical device (usually the Instructions for use) the interactions between the users and the medical device, including, but not limited to:

• Installation
• Operation
• Maintenance
• Disposal

note

Due to the software nature of the products that we manufacture, transport and storage do not apply to us.

The usability engineering process is divided into two phases: formative evaluation and summative evaluation. We document the usability test in the templates T-012-007 Formative evaluation plan and T-012-014 Summative evaluation plan respectively.

Both plans shall contain at least the following:

• Objective
• Description of intended users, uses, environments and training
• Description of the device user interface
• Analysis of hazards associated with the use of the device
• Study methods, user profile, study device and materials, user tasks
• Data analysis, success criteria.

The level of effort and the choice of methods and tools used to perform the usability engineering process may vary based on:

• the size and complexity of the user interface,
• the severity of the harm associated with the use of the medical device,
• the extent or complexity of the use specification,
• the presence of user interface of unknown provenance, and
• the extent of the modification to an existing medical device user interface that had been subjected to the usability engineering process.

To register the results of the usability engineering process, we create a report for the formative evaluation test by using the template T-012-008 Formative evaluation report and for the summative evaluation test by using the template T-012-015 Summative evaluation report. Both documents provide a detailed summary of the results obtained by executing the formative and summative evaluation tests respectively.

Results and technical file

When the design and development process is finalised, we update the technical file accordingly. If the new version released contains a major requirement change, it will be required to contact the Notified Body and perform a new medical device modification application. They then will perform a new audit to our product to ensure it is safe to put on the market the new version.

At least we will review and update the following documents:

• Manufacturing and control technical instructions,
• Product technical specifications,
• Labels and traceability,
• UDI or batch number,
• User manuals,
• Declaration of CE conformity,
• Other legal documents.

We also compile the template T-012-006 _Product name_ life cycle plan and report for each medical device family with all the specific characteristics concerning the software life cycle according to ISO 62304:2007/A1:2016, including the corresponding software development plan.

It we are developing a new medical device, once the product design and development results are final and approved, we complete the preparation of the technical file to request the CE Marking.

UDI assignment

The Regulation (EU) 745/2017 on medical devices introduces an EU identification system for medical devices based on a Unique Device Identifier (UDI). The UDI system is intended to provide single, globally harmonized positive identification of medical devices through distribution and use, requiring the label of devices to bear a globally unique device identifier. As we manufacture software as medical devices, we have follow the MDCG 2018-5 UDI Assignment to Medical Device Software guideline to design our UDI assignment.

The UDI is comprised by two different codes:

• UDI-DI (Device Identifier)
• UDI-PI (Production Identifier): in our case it will comprise the Batch - lot AI(10) and the Manufacture date AI(11).

Moreover, the UDI system requires to assign an additional code that is the basic UDI-DI, that is related to the family of products that share the same intended purpose, risk class and essential design and manufacturing characteristics.

To assign the UDI for the medical devices that we manufacture we follow the guidelines established by GS1. GS1 is an UDI Issuing Agency/Entity based on many regulations worldwide, meaning that manufacturers supplying regulated medical devices can use the GS1 standards to implement the UDI requirements.

In addition to the UDI, GS1 also provides us with a company identifier code.

The basic UDI-DI is placed in the medical device Declaration of Conformity and the relevant reports within the TF that requires it, and the UDI is placed in the label and IFU of the manufactured device.

Changes to consider

A new UDI-DI shall be required, in the specific case of software, when there is:

• Any change of the Basic UDI-DI
• Any changes which impact the original performance, safety, or the interpretation of data
• A change to the name or trade name, version or model number, critical warnings or contra-indications, user interface language.

This changes can include new or modified algorithms, database structures, operating platform, architecture or new user interfaces or new channels for interoperability.

In accordance with Annex VI, Part C, point 6.5.4 of the MDR and Annex VI, minor software revisions (previously described in this document) require a new UDI-PI and not a new UDI-DI.

When any of these changes occur, the TF documentation will be updated accordingly.

Change control

If you want to know what are our procedures to control the changes in the design and development of our devices, check out the general procedure GP-023 Design change Management.

The significance of the change in relation to the functionality, performance, usability, safety, and applicable regulatory requirements of the medical device and its intended purpose can be significant or non-significant, corresponding the significant one to the major requirements, and the non-significant one to the minor or functional requirements. This means that every time we detect the need of a change, a new requirement will be opened at the DHF, and the significance of the change will be determined by the requirement category. These new entries in the design files also contain the possible new version of the design that it would give rise to.

Design and development changes must be reviewed, verified,validated and approved before to their release as they are managed as new requirements.

When reviewing the changes, we must evaluate the impact of the changes over the product, over inputs and outputs of risk management (following GP-013 Risk Management) and over the processes of product delivery (GP-011 Provision of services).

The list of all the changes performed along the different versions releases are recorded in the DHF following the template T-012-005 Design change control.

Software maintenance

The software maintenance we perform consists of bug fixing, that is performed according to this procedure considering any bug a new minor requirement.

Backups

The device data is meticulously updated at regular intervals to ensure optimal performance and up-to-date information. With a precise update frequency of 12 hours, our robust system guarantees that the most current data is consistently available to users.

In order to safeguard the integrity of our data, we have implemented a comprehensive backup strategy. Our carefully devised plan utilizes an incremental backup approach, which efficiently captures and stores any modifications made to the data since the last backup. This method not only reduces storage requirements but also minimizes the time and resources needed for the backup process.

By employing this best-in-class data update and backup system, we maintain a high standard of reliability, efficiency, and security, providing our clients with the utmost confidence in the quality and accuracy of the information provided by our device.

When it comes to the device's code, we employ git as the version control system, a deliberate choice that guarantees the flawless preservation of every version. Our verification process is meticulous; we revert to previous commits, compile the code, execute it, and administer fundamental tests to ascertain its operability. To corroborate the device's execution on the server, we document a screenshot of this process following the T-012-010 Device backup verification template.

Associated documents

Templates

• T-012-001 Requirements
• T-012-002 Activities
• T-012-003 Test run
• T-012-004 Software version release
• T-012-005 Design change control
• T-012-006 _Product name_ life cycle plan and report
• T-012-007 Formative evaluation plan
• T-012-008 Formative evaluation report
• T-012-009 Validation and testing of machine learning models
• T-012-010 Device backup verification
• T-012-012 Customers product version control
• T-012-013 Design stage review
• T-012-014 Summative evaluation plan
• T-012-015 Summative evaluation report
• T-012-016 Software usability guide
• T-012-017 Integration test review
• T-012-018 Test plan
• T-012-019 SOUP

Procedures

• GP-001 Control of documents
• GP-011 Service provision
• GP-013 Risk management
• GP-018 Infrastructure and facilities
• GP-023 Change control management

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