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

Document	Family members involved	JD-001	JD-002
GP-001	Author	Approver	Reviewer
GP-002	Author	Approver	Reviewer
SP-002-*	Author	Approver	Reviewer
GP-003	Author	Approver	Reviewer
GP-004	Author	Approver	Reviewer
GP-005	Author	Approver	Reviewer
GP-006	Author	Approver	Reviewer
R-002-*	Author	Reviewer and approver
GP-010	Author	Reviewer	Approver

Inputs

Outputs

Procedure

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 Bitbucket for most of our QMS. However we use other tools.

Bitbucket

We use Bitbucket for archiving our QMS procedures and records, including personal documentation.

Regarding the QMS, we have defined a folder structure within Bitbucket 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
• Personal File: containing all the documentation of each person.
• 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.

Holded

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.

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
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
Personal File records	According to the template it comes from: R-PF-000-ZZZ Name of the record	YYYY_nnn
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 Bitbucket 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 Bitbucket, 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 Bitbucket, 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.

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

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.

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

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.

Personal documentation

The Personal documentation is the file that contains, or identifies, documents defining each person.

Content of the personal file

It contains, at least, the information cited below:

• Personal identification
• ...

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.

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: Family members involved
• Reviewer: JD-002
• Approver: JD-001