Skip to main content
QMSQMS
QMS
  • Welcome to your QMS
  • Quality Manual
  • Procedures
  • Records
    • GP-001 Documents and records control
    • GP-002 Quality planning
    • GP-003 Audits
    • GP-004 Vigilance system
    • GP-005 HR and training
    • GP-007 Post-market surveillance
    • GP-009 Sales
    • GP-010 Suppliers
    • GP-012 Design, Redesign and Development
    • GP-018 Infrastructure and facilities
    • GP-019 Software validation
      • Deprecated
      • R-019-001 Software validation report_Atlassian_2023
      • R-019-001 Software validation report_HubSpot_2024
      • R-019-001 Software validation report_GitHub_GPG key signature_2024
      • R-019-001 Software validation report_Atlassian_2024
      • R-019-001 Software validation report_CVAT_2024
      • R-019-001 Software validation report_Docker_2024
      • R-019-002 External software list
    • GP-023 Change control management
    • GP-050 Data Protection
    • GP-051 Security violations
    • GP-052 Data Privacy Impact Assessment (DPIA)
    • GP-200 Remote Data Acquisition in Clinical Investigations
    • GP-011 Provision of service
    • GP-110 Esquema Nacional de Seguridad
  • Legit.Health Plus Version 1.1.0.0
  • Legit.Health Plus Version 1.1.0.1
  • Licenses and accreditations
  • Applicable Standards and Regulations
  • Grants
  • Pricing
  • Public tenders
  • Records
  • GP-019 Software validation
  • R-019-001 Software validation report_Atlassian_2023

R-019-001 Software validation report_Atlassian_2023

Scope​

The aim is to gather additional requirements and configuration specifications not encompassed within the application, together with their respective validations. This ensures adherence to both our internal requirements and those imposed by regulatory bodies. This involves detailing specifications and criteria which are external to the application but fundamental for ensuring our outputs align with all requisite standards and regulations.

Software description​

Name​

Atlassian

Manufacturer​

Atlassian corporation (Atlassian Pty Ltd and Atlassian US, Inc.)

Intended use​

We selected Atlassian to have a controlled system to be used:

  • As Design History File (DHF), to contain all the records required during the manufacturing process
  • To register and follow up all the non-conformity and corrective and preventive actions (NC & CAPAs).

Risk-based analysis​

Design History File (DHF)​

Atlassian is also used as a DHF to register, monitor, review and approve all the software as medical device life cycle information required by the applicable regulations. Failure of the release feature of the application configuration would result in a quality problem that foreseeably compromises safety. As such, we have determined that this function pose a high process risk.

Non-conformities and corrective and preventive actions (NC & CAPAs)​

Failure of the NC & CAPAs application to perform as intended may delay the follow up of the NC & CAPAs, but would not result in a quality problem that foreseeably compromises safety, as twe have additional processes in place for containment of non-conforming product. As such, we have determined the initiation operations did not pose a high process risk.

Requirements and design specification​

Design History File (DHF)​

  • Requirement 01: Users sign the documentation according to their role and in compliance with the 21 CFR part 11.
  • Requirement 02: When the users log in to the DHF they can check the identification of the product and the T-012-005 Design change control record.
  • Requirement 03: Users can register the requirements, activities, tests, and version releases on their corresponding section.
  • Requirement 04: Users provide the information specified at theGP-012 Design, redesign and development procedure.

Non-conformities and corrective and preventive actions (NC & CAPAs)​

  • Requirement 01: Users sign the documentation according to their role and in compliance with the 21 CFR part 11.
  • Requirement 02: User can identify the status of the non-conformities according to GP-006 Non-conformities. Corrective and preventive actions:
    • Reception
    • CAPAs
    • Efficacy verification
    • Impact verification
    • Solved
  • Requirement 03: User is able to transfer the NC status as follows:
    • Reception to Solved
    • Reception to CAPAs
    • CAPAs to Efficacy verification
    • Efficacy verification to Impact verification
    • Impact verification to Solved
    • Efficacy verification to CAPAs
  • Requirement 04: User provide the information specified at the GP-006 Non-conformities. Corrective and preventive actions.

Assurance activities and test plan​

In addition to the tests and checks designed to ensure the configuration complies with the establised requirements, we have performed an assessment of the system capability (see R-002-007 Process validation card 2023_003) and a supplier evaluation (see R-010-001 Suppliers evaluation), being considered the only tool providing, in the same ecosystem, a task manger, a knowledgebase and a git code repository. This makes it perfect to manage all the process mentioned: QMS, DHF and NC & CAPAs applications.

Design History File (DHF)​

IDTest descriptionAcceptance criteriaRequirement tested
Test 01Verification of the electronic signatureSignature comply with the regulatory requirementsRequirement 01
Test 02Verification that the users can provide all the information required at the GP-012 Design, redesign and developmentTemplates are correctDHF Requirement 03, Requirement 04
Test 03User validation: to perform a simulation of the performance of the DHF configurationSatisfactory simulation without errorsDHF Requirement 02, Requirement 03, Requirement 04

Non-conformities and corrective and preventive actions (NC & CAPAs)​

IDTest descriptionAcceptance criteriaRequirement tested
Test 01Verification of the electronic signatureSignature comply with the regulatory requirementsRequirement 01
Test 02Verification that the users can provide all the information required at the GP-006 Non-conformities. Corrective and preventive actionsTemplate is correctNC Requirement 04
Test 03Verification of the different status for the NC and the flow is properly establishedFlow defined properlyNC Requirement 02, Requirement 03

Test Results and deviations detected​

Design History File (DHF)​

Test 01​

  • Result: Pass
  • Deviation: No deviations found

evidence of DHF

Test 02​

  • Result: Pass
  • Deviation: No deviations found

Test 03​

  • Result: Pass. The simulation performed worked as expected.
  • Deviation: No deviations found

Non-conformities and corrective and preventive actions (NC & CAPAs)​

Test 01​

  • Result: Pass
  • Deviation: No deviations found

evidence of NC

Test 02​

  • Result: Pass
  • Deviation: No deviations found

evidence of NC

Test 03​

  • Result: Pass
  • Deviation: No deviations found

Non-conformities status evidence of NC

Non-conformities flow evidence of NC

Design review​

Result
Have the appropriate tasks and expected results, outputs, or products been established for each software life cycle activity?TRUE
Do the tasks and expected results, outputs, or products of each software life cycle activity:
Comply with the requirements of other software life cycle activities in terms of correctness, completeness, consistency, and accuracy?TRUE
Satisfy the standards, practices, and conventions of that activity?TRUE
Establish a proper basis for initiating tasks for the next software life cycle activity?TRUE

Conclusion​

Design History File (DHF)​

Non-conformities and corrective and preventive actions (NC & CAPAs)​

No errors were observed in the fields destined for filling the required information. Incorrectly inputting text into the fields is immediately visible and does not impact the risk of the intended use.

In addition, some fields are mandatory for the user to fill in, to avoid lost of required information, and other fields have predefined choices to ensure the proper information is completed.

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
Previous
R-019-001_Software validation report 22_001 AppFire
Next
R-019-001 Software validation report_HubSpot_2024
  • Scope
  • Software description
    • Name
    • Manufacturer
    • Intended use
  • Risk-based analysis
    • Design History File (DHF)
    • Non-conformities and corrective and preventive actions (NC & CAPAs)
  • Requirements and design specification
    • Design History File (DHF)
    • Non-conformities and corrective and preventive actions (NC & CAPAs)
  • Assurance activities and test plan
    • Design History File (DHF)
    • Non-conformities and corrective and preventive actions (NC & CAPAs)
  • Test Results and deviations detected
    • Design History File (DHF)
      • Test 01
      • Test 02
      • Test 03
    • Non-conformities and corrective and preventive actions (NC & CAPAs)
      • Test 01
      • Test 02
      • Test 03
  • Design review
  • Conclusion
    • Design History File (DHF)
    • Non-conformities and corrective and preventive actions (NC & CAPAs)
All the information contained in this QMS is confidential. The recipient agrees not to transmit or reproduce the information, neither by himself nor by third parties, through whichever means, without obtaining the prior written permission of Legit.Health (AI LABS GROUP S.L.)