GP-001 Control of documents

Procedure flowchart

Purpose

To define the method to control the Quality Management System (QMS) documents and records to demonstrate conformity to specified requirements and the effective process of the quality system.

Scope

All the documents and records of the Quality Management System and the external documentation.

Responsibilities

JD-001

To provide the organisation with a set of appropriate resources to establish all the documents and documents control tools to guarantee the clarity and reproducibility of the activities, and the compliance with the applicable regulatory requirements.

To review and approve all the procedures and records related to the QMS management.

JD-004

To create the necessary documents and templates to correctly carry out the activities and ensure that the quality records are managed following the indications made in the Quality Manual and in this General Procedure.

JD-003

To ensure the specific procedures describing concrete technical details of process or sub processes for products are prepared. Also responsible for personnel data protection.

JD-005

To identify and notify all the applicable requirements in relation to harmonized standards of application.

To review all the documents of the QMS and approve all the documents and records required for the medical device technical files.

Inputs

• Need of new documents of the Quality Management System (QMS).
• Need of modifications of the QMS documents.
• Need of record and control of all documents related to the QMS.
• IMDRF Principles and Practices for Medical Device Cybersecurity (IMDRF/CYBER WG/N60FINAL:2020).
• MDCG 2019-16 - Guidance on Cybersecurity for medical devices (MDCG 2019-16).
• MDR Annex I, GSPR 17

Outputs

• Updated QMS documents.
• Management of obsolete versions of the QMS documents.
• T-001-001 Control of documents
• Medical devices Technical Files (TF)

Development

All of our documents must be easily recoverable and correctly preserved and readable. The content of this procedure is written to guarantee its correct execution. If any member of the company detects some defects or improvement opportunity, it must be communicated to the JD-004, who evaluate the proposal and manage the communication as required. In the event of the communication was considered a non-conformity, it will be managed in accordance with the procedure GP-006 Non-conformity, corrective and preventive actions.

QMS structure

We use GitHub for most of our QMS. However we use other tools from the Atlassian suite of applications to manage certain quality processes, Hubspot for customer complaints and Factorial as the main tool for our human resources management.

GitHub

We use GitHub for archiving our QMS procedures and records, including technical documentation, and the instructions for use (IFU).

Regarding the QMS, we have defined a folder structure within GitHub comprising the following:

• Quality Manual: Containing the Quality Manual and the Annexes.
• Procedures: Containing all the general procedures, specific procedures and templates for the records.
• Records: containing all the records generated within their corresponding folders
• Technical File: containing all the technical documentation of the medical device, including the Design History File (DHF).
• Licenses and accreditations: Where we archive all the licenses and accreditations obtained
• External documentation: With all the relevant external documentation

In each folder, you will find the procedures and records with the latest version, signed and dated by the responsible people. Also, in the same directory of the records and the technical file you'll find a folder called Deprecated where we store the previous records when required.

Atlassian

Regarding the Atlassian suite of applications, we use it to manage and document our nonconformities and corrective and preventive actions (CAPA) and to manage and document some of the design and development processes, as detailed below:

Process	Location inside Atlassian
Design activities	Jira, Bitucket
Design test (unit and integration test)	Bitbucket
Nonconformity and CAPA management	Jira

Hubspot

And finally, our CRM; Hubspot, is used to compile all the customers communications including complaints, feedback, technical assistance requests and other consults.

Factorial

We include within factorial all the personnel documents required as: payrolls, CVs, documents related to work safety, trainings, time control, job descriptions and holidays and other abscenses.

The documents that required it (as job descriptions) will be reviewed and approved within the platform, and the evidence of the approval will be included using the signature tool "Signaturit" included within Factorial.

QMS documents control

All documents within the QMS have a specific codification to allow their identification. The code always appeared at the document title and file name.

Documents and templates distribution and current revision are listed at the R-001-001 Control of documents, that is reviewed and updated at least on a yearly basis.

Versions and change control

The different version of the documents and their changes can be followed using git, being the version of the document the last commit's code.

To ensure that only the approved documents are available we have implemented the following procedure:

• When a new document or template needs to be created, or a major change is required to any of the existing procedures, we must create a new branch with a descriptive name to perform the modification or creation.
• The responsible of the document complete or modify the document (it is possible to include more than one document in the same pull request if we can encompass all the modifications under the same pull description).
• The responsible of the document creates a pull request assigning the review activity and the pull request to the corresponding reviewer.
• The reviewer perform the review, modify and improve the document/s when required, and perform the corresponding commit. Then the reviewer assigns a new review activity and the pull request to the approver.
• The approver also reviews and improves the document/s when required. Then they perform the corresponding commit.
• Then the approver merges the pull request.

Once the pull request is merged, the new version of the document is released and available to be consulted.

What is git?

Git is a distributed version control system (VCS) that allows us to track changes to files and collaborate with others effectively. It was primarily designed for software development projects but can be used effectively for versioning documents in any context, including a Quality Management System (QMS) compliant with ISO 13485. Here's an explanation of Git and why it can be considered the best possible way for versioning documents in our QMS:

• Distributed Version Control: Git is a distributed VCS, which means that each user has a complete copy of the repository, including the entire history of changes. This ensures that every document version is available even if the central server or network is down. It offers redundancy and improves the reliability of document versioning, which is crucial for maintaining compliance with ISO 13485.
• Full Version History: Git maintains a detailed history of changes for each document, recording who made the change, when it was made, and the specific modifications. This provides an auditable trail of document revisions, which is essential for ISO 13485 compliance. The ability to track changes at a granular level ensures accountability and facilitates the identification of any issues or non-compliant activities.
• Branching and Merging: Git allows the creation of branches, which are independent lines of development. This feature is particularly valuable for a QMS because it enables parallel work on different document versions, such as developing new procedures or revising existing ones. Branching provides a structured approach to document management, allowing for concurrent editing while maintaining a clear distinction between the main branch (representing the approved version) and other branches (representing ongoing work or experimental changes). Merging branches back to the main branch ensures that only approved changes are integrated into the QMS.
• Collaboration and Review: Git facilitates collaboration among team members by allowing multiple individuals to work on documents simultaneously. It provides mechanisms for reviewing and commenting on changes, making it easier to gather feedback, address suggestions, and improve document quality. This collaborative approach promotes continuous improvement, a fundamental principle of ISO 13485, as it encourages the involvement of stakeholders and subject matter experts in the QMS document development process.
• Security and Access Control: Git provides mechanisms for access control and permission management, allowing us to restrict document modification rights to authorized personnel. This feature is vital for maintaining the integrity of our QMS and ensuring compliance with ISO 13485. By controlling who can make changes and enforcing a review and approval process, we can prevent unauthorized modifications and mitigate the risk of non-compliance.
• Documentation Integrity: Git employs cryptographic hashes to ensure the integrity of document versions. Each version is assigned a unique identifier based on its content, making it practically impossible to tamper with or modify a document without detection. This feature aligns with the requirements of ISO 13485, which emphasizes the need for accurate and reliable documentation.

By leveraging the features of Git, we can establish a robust and compliant version control system for our QMS. It provides a secure and auditable environment for managing document revisions, supports collaboration, and enhances overall document integrity. Integrating Git as our version control solution aligns well with the principles and requirements of ISO 13485, helping us maintain an efficient and compliant Quality Management System.

Types of changes

• Minor: Changes intended to clarify the current wording of instructions, cautions and precautions relating to a device or procedure. Changes made to procedures or documents accompanying a device which are intended only to clarify instructions in order to make its use easier, safer and more efficient, but without changing the procedures or the conditions of use of the device. This changes can be performed by the JD-004, JD-005 or designee, and they do not require to follow the review and approval flow established for the new documents or the ones that have been modified with major changes. They can be approved and released by the author of the minor change.
• Major: Changes performed to procedures or documents accompanying a device that modify the operation of the user or the conditions of use of the device. This changes required to be reviewed and approved according to the established procedure and affected personnel must be notified and, when required, retrained on the procedure.

Major changes will always be performed on a new specific branch to ensure its proper control and distribution. Minor changes can be performed either on the master branch or on a new specific one. We label every pull request with a minor o major change accordingly to make it easier to follow the review and approval activities that need to be performed or have been performed related to each one.

Nomenclature

The following nomenclature is used to identify the documents and records:

• YYYY: approval year of newest version
• ZZZ: correlative number of SP or record order.
• nnn: correlative number record, from 001 to 999.
• XX: correlative number corresponding to the folder in which it is archived
• xx: correlative number of document assigned by us.

	Code	Versioning
Quality Manual	Quality Manual	Using git through commits codes
Quality Policy	Annex-1_Quality policy	Using git through commits codes
Process Map	Annex-2_Process map	Using git through commits codes
Organisation Chart	None	Using Factorial
Job Description	JD-nnn Job title	Using Factorial
General Procedures	GP-000 Name of the procedure	Using git through commits codes
Specific Procedures	SP-000-ZZZ Name of the procedure	Using git through commits codes
Templates	T-000-ZZZ Name of the template	Using git through commits codes
Records	According to the template it comes from: R-000-ZZZ Name of the record	YYYY_nnn
Data protection records	According to the template it comes from: R-DP-000-ZZZ Name of the record	YYYY_nnn
Medical device description	Product name description and specifications	YYYY_nnn
Technical File records	According to the template it comes from: R-TF-000-ZZZ Name of the record	YYYY_nnn
DHF requirements	REQ_ZZZ Name of the requirement	Using git through commits codes
DHF test plan	PLAN_ZZZ Name of the test plan	Using git through commits codes
DHF test run	TEST_ZZZ Name of the test plan	Using git through commits codes
DHF SOUP	Name of SOUP	Using git through commits codes
DHF version release	REL_ZZZ Version R.X.Y.Z	Using git through commits codes
IFU	IFU Product name	Using git through commits codes
External documents	XX_xx Name of the document	Assigned by owner

info

Retention period is established to 10 years for each medical device version documentation according to Annex 9 of MDR 2017/745 from the last commercialization of the last medical device .

Format of date

We have established a common format for dates to be used in the procedures and records of the QMS to ensure common understanding and consistency among all the documentation.

The chosen format is the one defined in ISO 8601 and it is the following: YYYY-MM-DD where

• YYYY corresponds to the 4 digits of the year
• MM corresponds to the 2 digits of the month
• DD corresponds to the 2 digits of the day.

Documents signature 🔏

We have implemented a signature tool that allow us to comply with the 21 CFR part 11: GPG (GNU Privacy Guard), that enhances data integrity and authenticity in our GitHub QMS and IFU repositories.

Using electronic signatures

Regarding electronic signatures, the signing process will comply with provisions from Electronic Records 21 CFR Part 11, Electronic Records; Electronic Signatures.

Such provisions include the following requirements:

• The signature must be validated.
• The signing process must be secure.
• The signer should not be able to repudiate the signature.
• The signature must include the signer's full name.
• The signature must include the date and time of signing.
• The signature must include a brief summary of the reason for signing.

We have confifured the GPGkey signature to sign every commit we perform in GitHub, meaning that to perform one new commit, we must be logged on our corresponding account, and then we have to introduce our unique and personnel GPGkey to complete the signature procedure.

All commits must be performed in the Visual Studio Code terminal, within the branch we are working on, using the following commands:

• git add -A
• git commit -m "Commit description"

When commits are performed for review or approval, the commit description will be the corresponding activity.

Each signature can be easily and quickly verified by checking every commit at its corresponding repository. It will have the label verified, along with the author and the date and time of the signature.

The signature meaning can be checked at corresponding section included within the document, and the review and approval meanings will also be included at the corresponding commit name.

The signing methodology will be as described:

Storage of the documents

• When the signature is digital, there will be no need for the custodian to re-locate the document as it is already signed from its right location. Likewise, there is no need to change the name of the file to reflect the signing process.
• When the signature is on paper, after each person signs the document, they will scan it and rename the file finishing with their initials, and they will notify by email, or by instant messaging, the people involved. The custodian will move the file to the correct directory as an approved document and delete the other intermediate files. Then, the custodian will change the file name to the final name, identifying the document version.

info

It is worth noting that our system is fully electronic, but we include the procedure for paper format in case any document requires this consideration.

Retention of documents

We have defined a minimum retention period of 10 years from the last commercialization of the last medical device (according to Annex 9, chapter III, of MDR 2017/745), during which it is retained at least one copy of obsolete documents situated in the pertinent folder (current and old documents) for all types of QMS documents.

Planning of documents

When we need to create a new document to develop a new procedure to comply with the regulatory, customers or our own requirements, the JD-004 creates a new branch at GitHub, assign a new code of the document and create the new document draft to be completed by the responsible of the document.

When the new document is written, reviewed and approved, it is released (pull request is merged) and included at the corresponding T-001-001 Control of documents record, that contains the following information:

• Code and name of the document
• Approval date
• Impact verification
• In the event of a new document or version whose implementation has had an impact, we will include an explanation of the new document or version and, when required, the need of the risk management review.

We review this record R-001-001 Control of documents at least once per year, since this is a living document that is updated when new document versions are implemented and distributed.

Any deviation from the yearly review must be supported by a non-conformity that justifies this unplanned change, according to the procedure GP-006 Non-conformity. Corrective and preventive actions.

Review of documents

Documents are reviewed every three years or when there are changes in the procedures that required their update. Every procedure that requires a different frequency of review, it will be specified at the corresponding procedure.

Every year, the JD-004 will revise the QMS documents status and will provide an updated report at the annual management review. With this revision, Top management will have the required data to evaluate and control the QMS status and it will define any required action as output of this review.

This report will analyze the new or revised regulatory requirements in relation with the current status of the system. The analysis will include approval date of each document and possible required changes associated with all inputs of the management review.

Control of responsibilities over documents of the QMS

The following table shows the responsibilities for authoring, reviewing and approving documents in general terms. These responsibilities are detailed in each procedure, as well as the meaning for each signature made.

• 🔏: Signature and date

	Author	Evidence	Reviewer	Evidence	Approver	Evidence	Custodian
Quality Manual	JD-004	🔏	JD-005	🔏	JD-001	🔏	JD-004
Quality Policy	JD-004	🔏	JD-005	Not required	JD-001	🔏	JD-004
Process Map	JD-004	🔏	JD-005	Not required	JD-001	🔏	JD-004
Organisation Chart	JD-006	🔏	JD-005	Not required	JD-001	🔏	JD-004
Job Description	JD-001 or department manager	🔏	Not required	Not required	JD-001	🔏	JD-004
General Procedures	See Annex 1 Responsibility matrix	🔏	See Annex 1 Responsibility matrix	🔏	See Annex 1 Responsibility matrix	🔏	JD-004
Specific Procedures	See Annex 1 Responsibility matrix	🔏	See Annex 1 Responsibility matrix	🔏	See Annex 1 Responsibility matrix	🔏	JD-004
Templates	JD-004	🔏	JD-005	🔏	JD-001	🔏	JD-004
Technical File	JD-005, JD-004	🔏	JD-003	🔏	JD-005	🔏	JD-005, JD-004
IFU	JD-003, JD-004, JD-005	🔏	JD-003, JD-005	🔏	JD-005	🔏	JD-005

All our documentation is managed electronically and the evidence of each step of the document cycle (writing, revision and approval) is performed using the electronic signatures mentioned above, but it can also be in paper when required.

The responsibles of each phase of the document creation or modification are specified in the table, but they can also delegate their functions to other team members. The designee of each activity will be included within the signature meaning section of the record instead of the original responsible to ensure the complete traceability of the process.

Additionally, the JD-004 can modify and review all the QMS documents to ensure they comply with the QMS procedure and the regulatory requirements.

Training on procedures of the QMS

When required, e.g. after a major change in the procedure or as an identified action of a corrective action plan, the impacted employees will be trained in the new version of the procedure.

The training can be performed in two different ways:

• Reading and understanding of the procedure by impacted employees
• JD-004explaining procedures to impacted employees

Evidence of the training will be documented in the template T-001-009 Training on procedures of the QMS.

The employees who needs to be trained can be found in the QMS procedures section of the R-005-003 Training plan.

Control of records of the QMS

When the necessity to record something arises, an internal record R-000-ZZZ_Name of record_YYYY_nnn is created (or R-TF for the records that belongs to the Technical File, or R-DP to the records that belongs to the Data Protection section). Where 000 represents the corresponding General Procedure number, ZZZ is a correlative number that corresponds to the template number within the General Procedure. When it is required to generate a specific record per year we will include YYYY at the end of the name of the record as described above, that is the year in which the record is generated. And when it is required to create more than one record of the same template we will include nnn after the year, being a correlative number for each new record from 001 to 999.

Every record that is required is collected in its pertinent folder within the folder Records. They are based in their pre-established templates created by the JD-004 or designee.

All forms, records or reports can be temporally replaced by unclassified documents whenever the document contains all the information which is required by our QMS and saved in the corporate folder.

You can consult the list of current templates in the R-001-001 Control of documents.

In each procedure the associated records are named. The clear and concise identification and readability of the different records is the basis to allow their effective management and accomplish the pertinent requirements.

QMS records and responsibilities

As the other documents, all records within the QMS have an specific codification to allow their identification. The code always appeared at the document title and file name.

• YYYY: approval year of newest version
• MM. current month
• DD: current day
• nnn: version correlative number record, from 001 to 999.

There are some records that, due to their own nature they are archived and managed through a different system:

Record	We use this record so that...	Code	Basic information	Author
Non-conformity (NC)	We know when something went wrong with the product/process and what was the proccess for fixing it	YYYY-MM-DD_R-006-001_Brief summary of the non-conformity	Source of non-conformity, description, first assessment and immediate correction, cause analysis, need of CAPA, notification to regulatory authority	JD-004
Corrective/preventive action (CAPA)	We know when something went wrong with the product/process and what actions were implemented to avoid recurrence of the same issue	YYYY-MM-DD_R-006-003_Brief summary of the CAPA	Type, source, description, CAPA plan, follow up, effectiveness verification plan, effectivenss confirmation, impact assessment	JD-004 / JD-005
T-009-001 Implementation plan	We facilitate a successful implementation of our medical device service provision	R-009-001 Name of customer YYYYMMDD	Metrics and implementation timeline	Sales team

External documentation

All the external documentation referring to the quality is transmitted to the JD-004, JD-005 or JD-001, who after studying it, decides the treatment (internal diffusion, answer or archive).

The JD-004 compiles and updates at the T-001-005 List of external documents the external standards and regulations based on the information received from companies and institutions with which it exists a relationship (certification body, AEMPS, clients or others). Additionally, the JD-004 checks annualy the validity state and if the new document has any impact on any process that requires to be modified or updated.

The storage of all the external documentation, that comprises the standards and rules, and other relevant documentation, allows recovering it in a fast way when it is necessary. The archiving of the documentation is made in the QMS.

Finally, the relation of rules and standards situated there becomes in the practical list that is contemplated in the QMS. The control, update or classification of old versions corresponds to the JD-004, who will store in the named folder the current version of the standards and rules that are required in the QMS and will move the obsolete version to the Deprecated folder as a historical document.

All changes about the external documentation will be notified in written format by the JD-004 to the implicated people.

Protection of personal information

Personal information will be protected and saved with enough protection in accordance with the current legislation.

Personal information will not be transmitted to third parties but will be replaced by its numeric code. The database of relationships with personal data will be protected by access code, only accessible to the JD-001 and the JD-003 and its communications with the Cloud application will be encrypted.

We have hired a consulting company that will ensure proper compliance with the legislation. The JD-003 will assume the responsibility of data security and will receive a specific training, in accordance with the procedure GP-005 Human resources and training, when required.

The protection of the data or documentation of the customer will be managed according to GP-050 Data protection.

Corporate password policy

All employees and collaborators must keep the following security measures when accessing company information:

• Two-factor authentication (2FA) for login
• Additional confirmation when loggin into from a new device
• Strong passwords (special characters, at least 8 characters lenght)
• Password rotation schedule every 6 months

Such measures are implemented by default across the whole organisation and are not deactivable by individual users.

Furthermore, all company employees use the company's password manager tool Passbolt, due to its strong security features, convenience, and simplicity. It enhances productivity by saving time and automating the login process. The tool's collaboration features enable secure sharing within our team and with external parties, while audit and control functionalities offer transparency and accountability.

Backup of QMS and DHF documents

We have established a methodology to preserve the documentation about our workers, activities, clients and production inputs.

By leveraging the inherent features of Git, our QMS benefits from multiple local backups of the documentation. Each collaborator maintains a complete copy of the project, enabling redundancy, availability, and ensuring the integrity of the information. The commit history and collaboration capabilities further enhance data integrity and version control, providing a robust foundation for maintaining compliance with ISO 13485.

When a collaborator clones the Git repository to their local machine, they obtain a complete copy of the repository, including all document versions and revision history. This local repository acts as a backup, preserving the integrity of the QMS documentation even if the central server or network is inaccessible. Collaborators can work with this local copy, make commits, and track changes without relying solely on a central server.

Since every collaborator has a local backup of the documentation, there are multiple copies distributed across different machines. This redundancy reduces the risk of data loss or corruption. If one collaborator's machine or repository becomes unavailable, other collaborators can still access their local copies, ensuring the availability of the QMS documentation and mitigating the impact of potential hardware or network failures.

This on top of the data backups and integrity measures that Atlassian performs as a supplier of Bitbucket, and Microsoft as a supplier of GitHub.

Validation of the backups

As we have already mentioned, the commit history and collaboration capabilities of the QMS based on Git allow us to check and validate the local backups every time a collaborator perform a new commit or pull requested, as it is confirmed that the back up and the original QMS completely match without deviations.

Technical documentation

The Technical Documentation is the file that contains, or identifies, documents defining the product specifications and the system requirements for the quality management. The responsible of the Technical Documentation is established in the responsibilities table of this procedure.

93/42/EEC MDD technical file

Currently we have one medical device placed in the market, that is Legit.Health and it has its own CE marking according to MDD 93/42/ECC. Its technical documentation was prepared accordingly during the manufacturing license application. Then we planned to move to the MDR 2017/745 and to adapt our QMS and technical documentation to the new regulation. For that reason, the documents prepared for the MDD regulation were not updated in the TF, but they were transferred to our new QMS and updated there according to the new regulation. In order to maintain the proper traceability of all the procedures and documents required for the MDD technical file, we have created within the original tecnical file folder an index (google sheet one) that compiles the list of the documents as they were named in the first version, and the corresponding name and location of the new ones TF_LEGIT.HEALTH_Index.

2017/745 MDR technical file (TF)

We will create a new TF folder for each medical device or family of medical devices manufactured within the QMS following this procedure.

The specific documents of the new technical file for the new Class IIa product (Legit.Health Plus) are archived within the new QMS under the corresponding TF_Legit.Health Plus folder.

We will also create an index for each TF according to the selected Notified Body instructions, in order to ensure all the documents and records required are properly identified and traceable. The index will be archived within each TF as _Device name_ TF index_YYYY_nnn.

The index for the TF of the device Legit.Health Plus is part of the technical documentation and stored in the corresponding TF_Legit.Health Plus folder.

Content of the technical file

It contains, at least, the information cited below:

• Product description and specifications
  • Product description
  • Intended use
  • Product identification
  • Targeted patients and diseases
  • Principle of operation
  • Justification that it is a medical device
  • Product classification according to risks
  • MDR conformity assessment route
  • Novel features
  • Accessories
  • Consumables
  • Variants and models
  • Functional elements
  • Raw materials characterization
  • Technical specifications
  • Product history
• Label & information provided by the manufacturer
  • Applied standards
  • Product label, including the UDI-DI and UDI-PI
  • Instructions for Use (IFU)
• Design, redesign and manufacturing
  • Technical description of the product
  • Ensemble drawings
  • Quality system certificate of the design entity
  • Design verification
  • Design validation
  • Manufacturing process description
• General safety and performance requirements checklist
  • General safety and performance requirements
  • Applied technical standards
  • Test reports identification
• Benefit-risk analysis & risk management
  • Introduction
  • Complaint history
  • Procedure for risk management revision
  • Risk management report
• Product verification and validation
  • Preclinical and clinical data
  • Product verification
  • Product validation
  • Clinical evaluation
• Conclusions: general safety and performance requirements accomplishment
• Sterilization does not apply to our medical devices
• Conclusions
• Declaration of conformity
  • MDR conformity
• Technical details (when required)
  • Components executive drawings
  • Bill of materials (BOM)
  • Identification of suppliers
  • Manufacturing procedures
  • Quality control procedures
  • Manufacturing and Quality control records
  • Subcontractors agreement

The specified and required information can be organized with this sequence or similar, always guaranteeing its easy understanding and relationship with other documents. At least the specified title will be the same as specified above. When necessary we will add some Annexes to organize the information with easy and understandable structure.

Customer information or information supplied by the manufacturer

According to the applicable regulation, MDR 2017/745, each product must be accompanied by the necessary information to use it safely and properly, taking account of the training and knowledge of the user. The user's previous training and experience is analyzed in each product risk analysis.

In addition, the information provided will follow the applicable standards:

• ISO 15223-1:2021 Medical devices - Symbols to be used with information to be supplied by the manufacturer - Part 1: General requirements. Full aplication.
• UNE-EN ISO 20417:2021 Medical devices - Information to be supplied by the manufacturer

User manual or IFU

The instructions for use or user manual must contain, at least:

• The name or trade name of the device.
• The name or trade name and address of the manufacturer.
• The details strictly necessary to identify the device and the contents of the packaging especially for the users.
• The special storage and/or handling conditions.
• Any special operating instructions.
• Any warnings and/or precautions to take.
• Device's intended purpose with a clear specification of indications, contra-indications, targeted patients and intended users.
• The classification of the device according to the applicable standards.
• Warning for any undesirable side effects.
• All information needed to verify whether the device can operate correctly and safely, with details of the nature and frequency of the maintenance to ensure safety and performance.
• Information regarding the risks of reciprocal interference posed by the presence of the device during specific treatment.
• Any contra-indications or precautions to be taken for the device safety use and performance.
• Date of issue of the instructions for use.
• A notice to the user and/or patient that any serious incident that has occurred in relation to the device should be reported to the manufacturer and the competent national authority.

According to the Commission implementing regulation (EU) 2021/2226 regarding the electronic instructions for use of medical devices we keep the instructions for use available for the users in electronic form for 15 years after the last device has been placed on the market.

Revision for safety reasons

If and when we revise the user manual for safety reasons, we will notify users in the user manual itself.

Product label

The product label must contain, at least:

• The name or trade name of the device.
• The name or trade name and address of the manufacturer.
• The details strictly necessary to identify the device and the contents of the packaging.
• The lot number or the serial number of the device.
• The UDI-DI number code.
• The special storage and/or handling conditions.
• Any special operating instructions.
• Any warnings and/or precautions to take.
• Year of manufacture.
• If the intended purpose of the device is not obvious to the user, it must be clearly stated.
• An indication that the device is a medical device.

EU Declaration of conformity (DoC)

We create the Declaration of conformity following the template T-001-002 Declaration of conformity for the device placed on the market under the MDD 93/42/EEC regulation, that must contain, at least:

• Name or trade name and address of manufacturer.
• Certification of compliance under its responsibility.
• Trade name and version of the device.
• Applicable standards identification.
• Device classification.
• Name, code and address of the Notified Body responsible for the CE certification, if applicable.
• Signature of the JD-001, with date and place, as maximum representative of the company.

We also create the Declaration of conformity following the template T-001-007 Manufacturer declaration of conformity_MDR for each device placed on the market under the MDR 2017/745 regulation, that must contain, at least:

• Name or trade name and address of manufacturer.
• Certification of compliance under its responsibility.
• Basic UDI-DI.
• Trade name and version of the device.
• Applicable standards identification.
• Device route of conformity.
• Device classification.
• Name and code of the Notified Body responsible for the CE certification.
• Certificate ID
• Signature of the JD-001, with date and place, as maximum representative of the company.

Review and validation of the IFU and the label

We perform a review of each product IFU and labelling when a new product version is validated according to the GP-012 Design, redesign and development procedure and it is going to be released to the market. Then we validate both documents following the checklist compiled at the template T-001-006 IFU and label validation to ensure they cover all the applicable requirements and the new features that can be included during the new version manufacturing process.

Minimum IT requirements of the IFU

As part of our commitment to ensuring the cybersecurity and reliability of the Instructions for Use (IFU) for our software medical device, we outline the minimum IT requirements.

This adherence is in line with the mandates of MDR Annex I, GSPR 17, and MDCG 2019-16. Our primary objective is to maintain secure, continuous access to the IFU, which is crucial for the safe and effective operation of our medical device.

Technical and organisational measures

Firstly, it's key to understand that we develop and release the IFU exactly as we work in the development and the release of our medical device, and the QMS.

For further clarification: our IFU is not some PDF that is written in Microsoft Word and then exported. Neither is a illustrator file that a designer prepares. It's the furthest thing from that. We develop and deploy our IFU like it was code, because it is code. In other words, we develop and release our IFU following the same process as the medical device; and our QMS, for that matter.

This includes inherent measures such as:

• Managing the content and the versions though Git
• Editing the content using signed commits with GPG Keys
• Using a branch structure with approvals for merging changes
• Automated verification of code correctness and lack of bugs or errors before merge
• Programmatic deployment, directly to the server, after checks have passed
• Secure stage of environmet variables in Git repository
• Redundant backups, both in Git repository and deployment server

In other words, the IFU is maintained in accordance with the highest security standards, and it enjoys all the benefits of being maintained as code.

IT security Measures

A cornerstone of our IT security strategy is stringent access control. This encompasses robust authentication systems for administrative access and a role-based access control (RBAC) framework for delineating user permissions.

Data protection is ensured through comprehensive encryption strategies for data at rest and in transit, alongside mechanisms for maintaining data integrity. However, there is no personal data involved in our IFU.

IT environment configuration

We utilize Git for secure version control, conduct regular code reviews, and adhere to a strict policy for timely and traceable updates.

The IFU is hosted on a cloud platform that guarantees high availability and scalability.

Our backup strategy includes regular and systematic backups, with routine checks on backup integrity and restoration procedures. Utilizing a reputable cloud provider for hosting the IFU, ensuring high availability and scalability.

Accessibility

The IFU is accessible through a dedicated, secure URL.

Additionally, it is integrated into the output of our medical device's API, allowing users to access it as a key-value pair.

This dual-access approach ensures that users can reliably and conveniently obtain the information they need for the safe use of our device.

Associated documents

• T-001-001 Control of documents
• T-001-002 Declaration of conformity
• T-001-005 List of external documents
• T-001-006 IFU and label validation
• T-001-007 Declaration of conformity_MDR
• T-001-009 Training on QMS procedure record
• GP-005 Human resources and training
• GP-006 Non-conformity. Corrective and preventive actions
• GP-012 Design, redesign and development
• GP-016 Traceability and identification
• GP-050 Data protection

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