The technical documentation for a medical device is sometimes seen as a regulatory file to be finalised before a submission or conformity assessment.
This view is misleading.
Technical documentation is built throughout device development. It progressively brings together design decisions, verification and validation evidence, risk-management records, clinical or performance data, product information and post-market surveillance activities.
It must then remain up to date throughout the entire device lifecycle.
For a startup or small MedTech company, the challenge is therefore not simply to produce the required documents. The company must also maintain their consistency, connections and history as the product, requirements and available evidence evolve.
A collaborative environment such as Confluence can provide a particularly useful structure for this process.
Technical documentation is not a collection of independent files
Annexes II and III of the Medical Devices Regulation (MDR) and the In Vitro Diagnostic Medical Devices Regulation (IVDR) define the main elements expected in the technical documentation.
Depending on the type of device, these may include:
- device description and specifications;
- intended purpose and intended users;
- regulatory qualification and classification;
- variants, accessories and configurations;
- design and manufacturing information;
- demonstration of conformity with the General Safety and Performance Requirements;
- the risk-management file;
- verification and validation results;
- clinical evaluation or performance evaluation;
- labelling and instructions for use;
- post-market surveillance information;
- applicable periodic reports and vigilance data.
These elements are not independent.
A change to the intended purpose may affect the device classification, applicable regulatory requirements, risk analysis, clinical or performance evaluation, specifications, testing and labelling.
Similarly, new information arising from verification, a complaint or post-market surveillance may lead to a product change and require updates to several parts of the technical documentation.
When this information is distributed across Word files, spreadsheets, shared folders and email exchanges, inconsistencies become increasingly difficult to prevent.
Building living technical documentation
Controlled technical documentation should make it possible to answer several questions easily:
- Which documents are expected for this device?
- Which documents are available, in progress or still to be planned?
- Which version has been reviewed or accepted?
- Who is responsible for each deliverable?
- What evidence supports each regulatory requirement?
- Which risks are addressed by which risk-control measures?
- Which verification activities demonstrate that the specifications have been met?
- Which parts of the documentation must be revised following a change?
- Which documents must be provided to the notified body or competent authority?
To answer these questions, the documentation can be managed using a structured index or compliance matrix.
Each element can be assigned a controlled status, for example:
- Planned;
- In progress;
- Available;
- Reviewed;
- Accepted;
- Not applicable.
This approach makes it possible to identify missing deliverables, documents that are available but have not yet been reviewed, and exclusions that require justification.
The objective is not merely to create a table of contents. It is to provide visibility over the actual completion status of the technical documentation.
The common foundation for medical devices and IVDs
The MDR and IVDR share many technical-documentation requirements.
Under both regulations, the manufacturer must control:
- the device description;
- the intended purpose;
- the classification;
- the General Safety and Performance Requirements;
- risk management;
- design and manufacturing information;
- verification and validation;
- information supplied with the device;
- post-market surveillance;
- product changes.
However, the structure of the documentation must be adapted to the nature of the device and its stage of development.
A product at an early development stage will not yet have all the evidence required for market placement. Documents that are not yet available should therefore be identified and planned, without presenting the documentation as complete.
As development progresses, the technical-documentation index also becomes a tool for managing the regulatory workstream of the project.
Specific considerations for IVDR technical documentation
For an IVD, the technical documentation must include the elements specific to performance evaluation.
Depending on the device, these may include:
- scientific validity;
- analytical performance;
- clinical performance;
- the performance evaluation plan and report;
- study protocols and reports;
- stability;
- metrological traceability;
- acceptance criteria;
- post-market performance follow-up;
- information relating to specimens, calibrators and controls.
This information is often produced by several teams or partners, including internal laboratories, research subcontractors, contract manufacturers, clinical centres and academic partners.
The manufacturer must retain access to the source data, protocols, complete results and final reports. A summary report supplied by a subcontractor may not be sufficient to demonstrate proper control of device performance.
A collaborative documentation structure can connect the reports received to the corresponding specifications, risks, performance requirements and development decisions.
Specific considerations for Medical Device Software
For Medical Device Software, or MDSW, technical documentation must remain closely connected to the actual software-development activities.
Depending on the product and applicable standards, the documentation may include:
- user needs;
- system and software requirements;
- software architecture;
- interfaces;
- software safety classification;
- third-party software components;
- risk and cybersecurity analyses;
- test plans and results;
- anomaly management;
- software configuration;
- versions and release notes;
- changes and their impact assessments;
- verification and validation evidence.
A major risk is the creation of an artificial separation between the regulatory documentation managed by the quality team and the operational data used every day by the developers.
The quality team may work with static documents while developers manage requirements, tasks, anomalies, tests and versions in Jira. When a regulatory release or audit approaches, the links between the two environments must then be reconstructed.
Connecting Confluence and Jira for MDSW projects
The integration between Confluence and Jira can bring regulatory documentation closer to the developers’ daily activities.
In Confluence, a page describing a requirement, risk analysis, software release or verification plan can contain links to the corresponding Jira work items.
Depending on the selected configuration, Confluence can display:
- an individual Jira work item;
- a list of work items generated through a JQL query;
- anomalies associated with a release;
- open verification tasks;
- actions resulting from a design review;
- the status of development activities;
- a Jira dashboard or timeline.
Smart Links and Jira macros can display updated information in Confluence, such as the status, priority or assignee of a Jira item. A dynamic list can be generated from a JQL query and embedded in a monitoring page. Atlassian provides guidance on displaying Jira work items in Confluence and using Smart Links across Atlassian products.
This integration can, for example, connect:
- a software requirement to its implementation tasks;
- a risk-control measure to its development activity;
- an anomaly to its safety assessment and correction;
- a test protocol to its results and associated anomalies;
- a change request to the Jira items required for its implementation;
- a software release to its tasks, residual anomalies and verification evidence.
Jira remains the operational development-management tool, while Confluence provides the documentation structure, regulatory context and content requiring review or approval.
This connection does not automatically create regulatory traceability. The company must define which relationships are required, how they are verified and which information must be frozen or exported for each device release.
The advantages of Confluence for technical documentation
Active links between documents
Pages can be linked to one another: procedures, forms, requirements, risks, test reports, clinical evaluations, design decisions or changes.
This navigation reduces dependence on folder structures and makes it easier to retrieve the context surrounding a particular item of information.
Version history
Confluence maintains a history of changes made to pages. The team can compare versions and identify how the content has evolved.
This history must be supplemented by rules defining the approved regulatory versions, responsibilities and records to be retained.
Reuse of common content
The Excerpt function can be used to maintain a source text and display it on several pages.
Used with appropriate controls, it can support common information such as:
- the device description;
- the intended purpose;
- manufacturer details;
- selected definitions;
- a controlled list of variants.
A change made to the source can then be reflected on the pages using the excerpt. This can help reduce inconsistencies between different parts of the QMS or technical documentation.
However, this mechanism must be controlled. A change to shared content can affect several documents and should therefore be subject to an appropriate impact assessment.
Tables for structured information
Some information is more effectively managed in tables than in narrative documents, for example:
- the technical-documentation index;
- the General Safety and Performance Requirements compliance matrix;
- the traceability matrix;
- risk-management tables;
- the software-components list;
- verification and validation tracking;
- the change register.
Spreadsheet-type applications can complement Confluence when functionality similar to an Excel workbook is required.
Approvals and electronic signatures
Applications available within the Atlassian ecosystem can add review, approval and electronic-signature workflows.
The selection and configuration of these applications must correspond to the manufacturer’s requirements. Their use may also require validation proportionate to the intended use of the system.
Exports for external assessment
An individual Confluence page can be exported as a PDF. A space or structured collection of pages can also be prepared as a package for a notified body, competent authority or external partner.
The collaborative environment can therefore remain the working source, while controlled versions are generated for external assessment.
Before transmission, the company must verify the completeness of the export, the links, attachments, version identification and confidentiality of the information.
ReadySet: connecting the QMS and technical documentation
ReadySet for Confluence provides a structure for organising the quality and regulatory processes of a medical-device manufacturer.
This structure can cover:
- document and record control;
- design and development;
- risk management;
- technical documentation;
- supplier management;
- change control;
- nonconformities and CAPAs;
- clinical evaluation or performance evaluation;
- post-market surveillance;
- audits and management reviews.
Versions adapted to medical devices, IVDs and Medical Device Software are available.
ReadySet can therefore bring the QMS and technical documentation together within the same environment. Procedures define how activities are controlled, while forms, matrices and technical-documentation pages collect the evidence generated during development and throughout the device lifecycle.
For MDSW teams using Jira, this structure can also be connected to the tasks, anomalies, tests and releases managed by the developers.
ReadySet provides a structure, not automatic compliance
ReadySet does not automatically make Confluence compliant and does not guarantee that technical documentation is complete or acceptable to a notified body or competent authority.
Each manufacturer remains responsible for:
- determining the applicable requirements;
- adapting the structure to the device and target markets;
- producing the required evidence;
- defining responsibilities;
- approving documents;
- controlling changes;
- maintaining traceability;
- validating computerised tools where necessary;
- verifying documentation completeness before submission.
ReadySet provides a structured foundation intended to facilitate this work and reduce the risk of having to reconstruct the technical documentation at a late stage from scattered files.
Conclusion
MDR or IVDR technical documentation should not be assembled only when a submission or audit is approaching.
It should accompany device development and evolve with the requirements, risks, verification and validation results, clinical or performance data and post-market information.
Confluence can provide a collaborative environment in which these elements remain organised and connected. For Medical Device Software, integration with Jira can also bring the regulatory documentation closer to the team’s actual development activities.
ReadySet for Confluence provides a structure designed to help MedTech teams establish this continuity between the QMS, product development and technical documentation.
Would you like to discover how ReadySet can be adapted to your medical device, IVD or Medical Device Software?
Contact AZ Biotech Consulting for further information or to arrange a presentation of ReadySet for Confluence.