Confluence is increasingly used by MedTech companies to organise their quality management systems. Its flexibility allows procedures, forms, records, design documentation and quality processes to be managed within a collaborative environment.
However, one question is frequently raised: since Confluence is a widely used platform maintained by an established supplier, does it still need to be validated when used as an eQMS?
The short answer is yes. When software supports the operation of the quality management system, the organisation should demonstrate that it is suitable for its intended use.
This does not mean validating the entire Confluence platform or repeating all the testing performed by its supplier.
A reputable platform is not automatically a validated system
The fact that software is supplied by an established company, widely adopted and hosted within a professional infrastructure provides useful assurance.
It does not demonstrate that a particular organisation’s configuration meets its specific quality-system requirements.
Two organisations may use Confluence very differently.
One may use it only to display procedures approved elsewhere. Another may rely on workflows, electronic approvals, access restrictions, templates, connected applications and automations to operate most of its QMS.
Their validation scope and level of effort should therefore be different.
What actually needs to be validated?
The objective is not to validate Confluence in the abstract. It is to demonstrate that the configured system is fit for the use assigned to it by the organisation.
The process begins by defining the intended use. This may include:
- creating and revising quality documents;
- approving and publishing procedures;
- controlling document versions;
- using forms and templates;
- creating and retaining quality records;
- managing training;
- tracking CAPAs, audits and nonconformities;
- maintaining change traceability;
- controlling user access;
- archiving and retrieving information.
The organisation should then evaluate the functions it actually uses and the potential consequences if those functions fail.
A display error on an informational page does not present the same risk as the loss of a training record, an unauthorised change to an approved procedure or the inability to reconstruct a product-release decision.
A risk-based validation approach
A risk-based approach allows the validation effort to focus on functions that may affect:
- device safety or performance;
- product quality;
- regulatory compliance;
- data integrity and availability;
- document and record control;
- the organisation’s ability to demonstrate QMS compliance.
Low-risk functions may be verified through straightforward checks. Critical functions require more structured evidence, including representative scenarios, expected results, actual results and formal approval.
Validation should not become a disproportionate documentation exercise. It should provide sufficient confidence, supported by objective evidence appropriate to the associated risks.
Configuration is part of the system
Many functions that determine how Confluence operates depend on the organisation’s configuration, including:
- space structure;
- groups and access permissions;
- page templates;
- document statuses;
- approval workflows;
- publication rules;
- editing restrictions;
- version management;
- automations;
- archiving conventions.
When these elements contribute to QMS control, they should be documented and verified.
Validation of a theoretical or standard configuration is insufficient if the production environment is configured differently.
Connected applications must be considered
Confluence is often combined with applications that provide workflows, approvals, electronic signatures, spreadsheets, reports or other specialised functions.
These applications may play a critical role in the QMS and should be assessed for inclusion in the validation scope.
The organisation may need to verify:
- workflow creation and modification;
- approver identity and authorisation;
- date and time records;
- traceability of changes;
- behaviour when an approved page is modified;
- retention of approval evidence;
- data export and recovery.
Installing an approval or electronic-signature application does not, by itself, demonstrate compliance with all applicable requirements.
What documentation is needed?
The validation file can remain reasonably concise. It would normally include:
- a description of the system and its scope;
- the intended use;
- relevant user requirements;
- a risk assessment;
- a description of the configuration;
- a validation plan;
- test cases and results;
- management of identified anomalies and deviations;
- a validation report;
- formal approval for operational use.
Supplier documentation, security information, release histories and available test evidence may support the assessment.
They do not replace verification of the organisation’s own intended use and configuration.
Maintaining the validated state
Validation does not end when the system enters operational use. Confluence Cloud and its connected applications are updated regularly.
The organisation should define how it assesses:
- significant platform updates;
- configuration changes;
- new or replaced applications;
- workflow modifications;
- new automations;
- incidents affecting quality-related functions.
Not every update requires complete revalidation. A documented impact assessment should determine whether additional testing is necessary.
Can Confluence therefore be used as an eQMS?
Yes. Confluence can provide an effective and adaptable environment for an ISO 13485 QMS, particularly for small and medium-sized MedTech organisations seeking to avoid an unnecessarily complex enterprise system.
Its flexibility nevertheless creates a responsibility for the organisation to define, control and verify the configuration it uses.
Confluence’s reputation and widespread adoption do not provide an exemption from validation. The appropriate approach is to validate the intended use, critical functions, deployed configuration and relevant connected applications, using a level of effort proportionate to the associated risks.
A validation module included in ReadySet
ReadySet includes a dedicated module for the validation of software used within the quality management system.
The module includes a validation procedure and a structured report for documenting:
- the software, instance and configuration;
- its intended use within the QMS;
- risk-based classification considering product quality, regulatory compliance and data integrity;
- the validation scope, including relevant Confluence functions and connected applications;
- the selected validation approach, such as IQ, OQ and PQ or an equivalent approach;
- test activities and results;
- identified deviations and associated corrective actions;
- the validation conclusion and approval;
- the supporting evidence retained as attachments.
The template addresses functions such as page creation and editing, version history, access permissions, page templates, approval workflows, electronic signatures, traceability and the connected applications used to support the QMS.
ReadySet does not mean that a Confluence configuration becomes automatically validated when it is installed.
The organisation remains responsible for defining its intended use, identifying the actual configuration, assessing the risks and performing the applicable tests.
The module nevertheless provides a practical method and a ready-to-use documentation structure for conducting validation in a consistent, traceable and risk-based manner.
ReadySet for Confluence
ReadySet is a structured ISO 13485 QMS framework implemented in Confluence. It includes organised procedures, forms and reference documents covering:
- document control;
- design and development;
- risk management;
- supplier management;
- training;
- CAPAs;
- audits;
- post-market activities.
By also providing the elements needed to validate software used within the QMS, ReadySet helps organisations address from the outset an aspect that is frequently overlooked when implementing a Confluence-based eQMS.
Would you like to discover ReadySet and its validation module? Contact AZ Biotech Consulting to request an introduction.
References
- ISO 13485:2016 — Medical devices — Quality management systems
https://www.iso.org/standard/59752.html - ISO/TR 80002-2:2017 — Validation of software for medical device quality systems
https://www.iso.org/standard/60044.html - FDA — Computer Software Assurance for Production and Quality Management System Software
https://www.fda.gov/regulatory-information/search-fda-guidance-documents/computer-software-assurance-production-and-quality-management-system-software
Donat De Groote, PhD. More than 40 years of experience in quality and regulatory affairs. Founder of AZ Biotech Consulting and creator of ReadySet.