NNS-QP01 Rev 04 Document Management Procedure PDF

Document Management Procedure Document Revision History Effective Date Revisions made to document 2022-02-17 First approved version 2022-07-20 Updates as per Jira QM-24...

Document Management Procedure Document Revision History Effective Date Revisions made to document 2022-02-17 First approved version 2022-07-20 Updates as per Jira QM-241 2023-07-05 Updates as per Jira QM-410 2024-06-27 Updates as per Jira QM-865 2024-07-11 Updates as per Jira QM-871 Document References Reference Title EN ISO 13485:2016 Medical devices — Quality management systems — Requirements for regulatory purposes Incorporating corrigendum March 2016 EU MDR Medical Devices Regulation NNS-QP00 Quality Manual NNS-QF01a Template: NNS-QF Information and Communication Technology (ICT) Readiness for Business Continuity (IRBC) Plan NNS-QP03 Auditing Procedure NNS-QP04 Design Control Procedure NNS-QP11 Production Control Procedure Table of Contents 1. Introduction............................................................................................................. 3 1.1. Purpose of this document......................................................................................................3 1.2. Scope of this document..........................................................................................................3 1.3. Intended audience of this document......................................................................................3 2. Definitions................................................................................................................ 4 3. Control of Documents............................................................................................... 5 3.1. Process flow – document control (Figure 1)...........................................................................4 3.2. Responsibility assignment matrix (RAM) for QMS documents and records...........................5 3.3. Document control workflow process (See Figure 1)...............................................................6 3.4. Document and Record Control Attributes..............................................................................8 3.5. Point of Application: single location for approved QMS documents................................... 11 3.6. Change Control in each PEMS Release................................................................................ 12 3.7. Change Control Workflow Process with reference to Design Control [NNS-QP04]............. 13 4. Control of Records...................................................................................................15 4.1. Disaster Recovery for Documents and Records................................................................... 15 NNS-QP01 Rev 02 Document Management Procedure CONFIDENTIAL Page 1 of 17 5. Procedure Metrics...................................................................................................16 NNS-QP01 Rev 02 Document Management Procedure CONFIDENTIAL Page 2 of 17 1. Introduction 1.1. Purpose of this document The purpose of this document is to define the controls to be exercised on documents, data and records that are crucial to the operation of the quality system and for the purposes of complying with regulatory requirements. The document includes the process for raising, reviewing, approving, distributing, and training on quality documents, product drawings, labels and specifications within Neuronostics. The purpose of this document is to express the Document Management Procedure, in conformity with: [BS EN ISO 13485:2016] o §4.2.4 Control of Documents o §4.2.5 Control of Records In this revision of the procedure, US FDA requirements are not considered. 1.2. Scope of this document The scope of this document management procedure is the control of documented information relating to any medical device product or service development and deployment, covering the pre-market (development), regulatory certification or approval, and post-market (deployment) activities. 1.3. Intended audience of this document The intended audience of this document is the set of internal and external stakeholders concerned with Document, Record and Change Control, including EU Notified Bodies (NBs) and UK Approved Bodies (UKABs), the USA’s Food and Drug Administration, etc. NNS-QP01 Rev 02 Document Management Procedure CONFIDENTIAL Page 3 of 17 2. Definitions CCR Change Control Record – a package of related document changes DCO Document Change Order – the workflow for a document item within a CCR Deviation Any departure from an approved policy, plan or procedure Management The individual (or their designee) assigned by the organisation’s top Representative management per [EN ISO 13485:2016] §5.5.2 Assignee The individual (or their designee) assigned by the Management Representative to manage the Document or Change Control Designee The individual (or their designee) assigned by the Management Representative to implement the changes for the Document or Change Control Reviewer The individual (or their designee) assigned by the Management Representative to review the Document or Change Control Approver The individual assigned with the responsibility of signing off and approving use of new document(s) or changes Trainee Individuals who are to be trained prior to use of new document(s) after approval PEMS Programmable Electrical Medical System (PEMS) SaMD Software as a Medical Device NNS-QP01 Rev 02 Document Management Procedure CONFIDENTIAL Page 4 of 17 3. Control of Documents 3.1. Responsibility assignment matrix (RAM) for QMS documents and records The following RAM gives the roles and responsibilities for documents and records that are not covered in RAMs within specific plans in the QMS or within Medical Device Files (MDFs) for products: Key: - R – responsible author - A – accountable approver - C – document reviewer (between authoring and approving) - I – informed after approval (and trained as necessary) Operati Scientifi Chief ons Managing Management c Technology Manage Director Representative Director Officer r Quality Manual (NNS-QP00) I I A C R SOPs (NNS-QP01, NNS-QP02, …) R QMS forms (NNS-QF##) Quality System Record (QSR) I A C R Management Review records I I I R Audit Plans and Reports IT Disaster Recovery Plan I A C R Other QMS records made from approved QMS forms (NNS- QF##) Technical Documentation NNS-QP01 Rev 02 Document Management Procedure CONFIDENTIAL Page 5 of 17  3.2. Document control workflow process (See Figure 1) Rules Details 1. Create Issue within Jira A new Change Control Record (CCR) epic within Jira is to be created and Document Control workflow the following rows within the CCR form populated: Summary – one-line textual summary of the change(s) Description – Detailed summary of changes, expected documents/records to be changed The CCR status at this point is Open. 2. Review of Change Control The Management Representative or Designee shall ensure that the Record CCR is checked for completeness and correctness. Further information is to be requested if not present, prior to proceeding to next step. The CCR shall also be checked to ensure it is not a duplicate and may, at the discretion of the Management Representative or Designee, be rejected, and the CCR closed with a justification if a change control action is deemed unnecessary. The CCR status at this point is Open. 3. Create Issue within Jira for The Management Representative or Designee is to add a DCO Jira Document Change Order (DCO) issue to the CCR for each new or changed document. The list of reviewers and approvers is to be recorded on the DCO. Once the above task is completed, the CCR is to be either moved to the In Progress state and the DCO to the Drafting state; alternatively the CCR is Parked and the DCO left in the Open state. This will then be revisited from this step once the changes the CCR and DCO suggest are ready to be implemented. 4. Population, Review and The Management Representative or Designee is to appoint an Approval of Design Change Order Assignee to work on the DCO. Once work is complete the status shall be changed to Reviewing, and reviewers shall each be assigned JIRA subtasks. Reviewer(s) are then to add their comments/ suggestions to the assigned DCO. Once review is complete, the Management Representative or Designee is to check for adequacy. If deemed unsatisfactory (reasons for this are to be recorded on the DCO), the DCO is to be returned to the Drafting state until reassigned and reviewed again. If deemed adequate, the document is to be prepared for signing following section 3.4 rules and approval via Adobe Sign. The Assignee and approver(s) are then to sign the document in the roles of author and approver respectively. If either refuse to sign due to inadequacy, this is then to be escalated to the Management Representative or Designee who shall then return the DCO to the Drafting state again until reassigned and reviewed again. 5. Approval, Training and Closure The Management Representative or Designee is to put the signed PDF of DCO & CCR revision of the document into use by uploading it to either the QMS folder in the company virtual drive or the applicable technical documentation folder tree (previous revisions must be removed from service and clearly marked as superseded) and determine if training is required. Trainees are to be assigned using the training platform. Once training has been completed via a suitable method e.g., reading the document NNS-QP01 Rev 02 Document Management Procedure CONFIDENTIAL Page 6 of 17 Rules Details or receipt of formal training from a suitable member of staff, or if it is determined that training is not required, the Management Representative or Designee is to change the associated DCO to the Closed state followed by changing the CCR to the Closed state when all the DCOs and other issues within it have been closed. NNS-QP01 Rev 02 Document Management Procedure CONFIDENTIAL Page 7 of 17  3.3. Document and Record Control Attributes Rules Details Issue and Document Nomenclature: Amendment Controls Each document/record shall have a unique identifier, from one of the below prefixes, as part of its name, depending on the document/record type: o QMS documents & records ▪ NNS-QP## – Procedures NNS identifies the company ## is two numbers (with QP00 being the Quality Manual and QP02-01 being the Employee Handbook) ▪ NNS-QR## – Registers e.g. NNS-QR09 Supplier Control Register ▪ NNS-QF##a – Template forms ##a is two digits and one letter e.g. NNS-QF03b Audit Plan o Technical Documentation ▪ NNS-XXX-ZZZ-### XXX identifies the product ZZZ is an optional identifier for the specific regulatory submission that document is tailored to e.g. NNS-PFM-Class1 ### is three numbers e.g. NNS-PFM-001 Intended Use Specification ▪ NNS-XXX-###-### for annexes to identified documents For Quality Procedures, template forms and Technical Documentation, the names of documents shall include the relevant revision number of that document as two digits, e.g. NNS-QP01 Rev 02 Document Management Procedure Completed templates forming records: For records which are generated for an individual event, such as a Management Review, the filename shall include the date of the event in the format YYYY-MM-DD e.g. NNS-QF00a Management Review Record 2022-01-26 For records that are generated for an individual person, such as an induction schedule, the filename shall include the person’s initials e.g. NNS-QF02d Induction Schedule CM For all other records for which a date or initial as a unique identifier is not more appropriate, a sequential three digit number (###) shall be used e.g. NNS- QF03b-001 Audit Plan Supplier Management. For records which are subsequently updated, such as if a plan is changed after being approved, then a version number shall also be included in the document name e.g. NNS-QF03b-001 Audit Plan Supplier Management Ver 01 (where the original can be assumed Ver 00). General Administration: All pages shall show the page number, the total number of pages in the footer and document name including revision/version number. All Quality Procedures, Technical Documents and records must be approved and signed (via Adobe Sign) by the Management Representative or designee as NNS-QP01 Rev 02 Document Management Procedure CONFIDENTIAL Page 8 of 17 Rules Details well as at least one functional or technical approver prior to being put in use. Once signed they shall be saved in PDF format to prevent unapproved changes o See the Responsibility Assignment Matrix in the section above for QMS documents o See the applicable Product Quality Plan (PQP) or Software Development Plan (SDP) or another formal plan for a particular product All effective revisions of these documents/records must be monitored within the Document Control Register, which shall be maintained in Jira and accessed via Jira queries (see below workflow). Each document shall contain a table showing the revision history: revision number, date, summary of revision (starting with “Initial revision”) Draft/ superseded documents are to be kept within a separate folder on the company virtual drive and appropriately labelled as such whilst being stored away from their current revisions Approved versions of source documents of those which have been digitally signed shall be kept in an Archive folder and appropriately labelled in order to be available for future editing when a new revision/version is required. Should any administrative changes be required e.g., Document ID alterations, naming convention changes etc., then a CCR shall be opened justifying the changes (excepting administrative immaterial changes such as company headers and typos etc.). Documents are to adhere to brand guidelines. Effective Date and Each DCO has date fields as follows: Review Date - Effective Date – when the given revision of a document becomes effective, i.e. after any distribution and training has been completed, and/ or when a regulatory requirement causes a change to become applicable - Review Date – the date by which a document must be reviewed for continuing applicability per the guideline given in the Control of Records section below – o if the given document needs to be revised then apply the Change Control section below else comment in the DCO that the review has been completed and that no change is required, and change the Review Date per the given guidance Document & Record The retention period for quality and regulatory documents and records is 10 years Retention Period after the last product has been manufactured, per [EU MDR]. Therefore, obsolete revisions of documents shall be retained for at least this period. The Management Representative or appointed Designee(s) remain responsible for the disposal of documents after the retention period. Data Confidentiality Confidential Health information, personal data and other confidential information is appropriately stored on the secure company virtual drive with access only available to authorised personnel as per the Data Protection Procedure [NNS- QP12]. External Documents All relevant standards and regulations shall be checked for revision via online Monitoring checks and resources such as TÜV SÜD & BSI Newsletters. New copies of the standards shall be purchased and implemented prior to their official implementation deadlines. It shall remain the responsibility of the Management Representative or a suitable Designee to monitor and maintain up-to-date copies of documents of external origin within the company’s shared drives and process their initial implementation and revisions, including necessary training activities, through Change Control Records (CCRs) same as for internal documents. NNS-QP01 Rev 02 Document Management Procedure CONFIDENTIAL Page 9 of 17 Rules Details Storage and Backup Electronic copies of documents/records shall be kept on the company’s virtual drive which is regularly backed up to allow for the retrieval of documents in the event of corruption, loss of access or loss of documents (see Disaster Recovery Plan) [NNS- QF01a-001]. NNS-QP01 Rev 02 Document Management Procedure CONFIDENTIAL Page 10 of 17 3.4. Point of Application: single location for approved QMS documents Documents and records will be held on SharePoint in the following folder structure with permissions set appropriately (read-only, read-write, access control for confidential records) and verified via the Computer Software Validation Procedure: NNS-QP01 Rev 02 Document Management Procedure CONFIDENTIAL Page 11 of 17 3.5. Deviation Management This section relates to temporary Deviations; permanent revisions to documents are handled under the Relationship between document control and design control of change and Change Control Workflow Process sections, below. Each proposed deviation should be recorded in Jira before it is applied, as a subtask of the DCO under which the subject document was approved; the deviation subtask(s) should also be linked to the DCO for the output of a process e.g. a report document, as an indication that the output/ report document needs to contain information on the deviation(s) applied. 6.7 Documents created and managed in Confluence Technical documentation including requirements and risk tracking are created in Confluence, pulling through information from Jira projects. These documents are approved in Jira using an e-sign plug in similar to Adobe sign. Documents once approved, should be exported to SharePoint for permanent secure storage. Cross-reference the Design Control Procedure [NNS-QP04] regarding design change for SaMD: NNS-QP01 Rev 02 Document Management Procedure CONFIDENTIAL Page 12 of 17 6.9. Change Control Workflow Process with reference to Design Control [NNS-QP04] Rules Details 1. Analysis of impact and The Management Representative or Designee is to analyse the impact creation of Issue within Jira of change(s) on the number of Feature Requests (FR) and Problem Document Control workflow Reports (PR) and decide which should be implemented for the next (Release Planning) release. A new Change Control Record (CCR) Jira epic is to be created and the following rows populated: Summary – the release number and details that the changes will be part of The CCR status is Open at this point, although it could be moved to Parked if the next release is not planned for some time. 2. Revision of requirements, risks The Management Representative or Designee appoints an Assignee to and software architecture revise the appropriate requirements, risks and architecture in addition (Design Input) to revising the appropriate verification and/ or validation plans. The appropriate documents which need to be amended at this stage are added to the CRR as DCOs and worked through (Open, Drafting, Reviewing, Approving). The CCR status is Doing. 3. Implementation, testing and The Assignee of the CCR conducts the implementation, integration and integration of test software testing of the hardware and/ or software, as applicable. This is to be including changes to relevant followed by changes to accompanying documentation e.g., Instructions documentation (Design Output) for Use (IFU), User Training Manuals, etc. The Assignee processes the constituent FRs and PRs accordingly. The appropriate documents which need to be amended at this stage are added to the CRR as DCOs and worked through (Open, Drafting, Reviewing, Approving) The CCR status is Doing. 4. Execution of The Assignee executes the System Verification Plan(s) (SVP). Once Validation/Verification (Design complete, they are to write the System Verification Report(s) (SVR). Verification and Validation) The Assignee is then to conduct the Product Validation Plan (PVP) on the hardware, software and associated documentation, followed by validation/re-validation on the new/changed processes and subsequently the write up of the Product Validation Report (PVR). The appropriate documents which need to be amended at this stage are added to the CCR as DCOs and worked through (Open, Drafting, Reviewing, Approving). This should also include DCO’s for all release documentation Description – detailed summary of changes which changes are to be made, in which tier(s) (this is captured in the software release note) The CCR status is Doing. 5. Design Review and CCR The Assignee is then to conduct a Design Review prior to final Closure (Design Transfer) deployment. The Management Representative or Designee is to sign off any associated documentation including that within the CCR. NNS-QP01 Rev 02 Document Management Procedure CONFIDENTIAL Page 13 of 17 Rules Details The Assignee is then to ensure that all relevant Technical Documentation is complete, including but not limited to: Medical Device File (MDF)/Device Master Record (DMR) Design History File (DHF) Device History Record(s) (DHR) Once all the DCO documentation has been amended and approved, the Assignee is to close the CCR. NNS-QP01 Rev 02 Document Management Procedure CONFIDENTIAL Page 14 of 17 4. Control of Records Critical documents and records (which are QMS-related Procedures and Technical Documentation) shall be subject to review at a minimum interval of once every 12 months or more often if: (i) deemed appropriate by the Management Representative, or (ii) if related to any Corrective Actions or Non-Conformances. Less critical documents and records (QMS related records) shall be reviewed as deemed appropriate by the Management Representative or Designee. Documents and records shall be reviewed as deemed appropriate by the Management Representative or Designee using the follow guidance: - the default review period for QMS documents is annual; alternatively they may be aligned to appropriate points in the typical three-year surveillance and recertification cycle of the QMS - the appropriate timings for Clinical Evaluation Reports (CER), Periodic Safety Update Reports (PSUR) etc. are per regulatory requirements of each jurisdiction in which product is deployed e.g. one year, two years, five years - if there is a known upcoming regulatory change then the review date is to be set accordingly ahead of the effective date of the change This process is to be recorded and monitored via JIRA Change Control Records with pre- determined future due dates for review to act as a reminder. The CCR is to have a Design Change Control for each document attached to review at the stated time. If changes/corrections are to be made to an existing record(s), the record(s) shall be annotated with the appropriate changes/ corrections with the original text still visible, followed by the reason for the change. The change(s) shall be signed and dated via Adobe Sign by the person who made the change(s). All changes are to be approved by the Management Representative or Designee. 4.1. Disaster Recovery for Documents and Records An Information and Communication Technology (ICT) Readiness for Business Continuity (IRBC) Plan will be established and maintained, using the given template [NNS-QF01a]; the template describes the applicable regulatory requirements for data retention periods. Testing of the plan will be part of the internal audit programme, per the Auditing Procedure [NNS-QP03]. NNS-QP01 Rev 02 Document Management Procedure CONFIDENTIAL Page 15 of 17 5. Procedure Metrics Timing and scheduling of Document and Change Controls are at the discretion of the Management Representative based on the following criteria: Criticality of the change, Time required to implement and review changes. The following metrics shall be monitored: Number and type of Document/Record changes conducted per year, Time taken to open and close CCRs/DCOs, Number of rejected CCRs and reasons for rejected CCRs. The metrics shall be monitored by the Management Representative and may be reviewed during Management Review Procedure given in the Quality Manual [NNS-QP00]. NNS-QP01 Rev 02 Document Management Procedure CONFIDENTIAL Page 16 of 17 6. Signatures For and on behalf of the author, by Name: Lucy Rogers Lucy Rogers (Jul 17, 2024 16:03 GMT+1) Title: HoRA For and on behalf of the approver, by Name: Title: Operations Manager NNS-QP01 Rev 02 Document Management Procedure CONFIDENTIAL Page 17 of 17 NNS-QP01 Rev 04 Document Management Procedure Final Audit Report 2024-07-17 Created: 2024-07-17 By: Grace Sutcliffe ([email protected]) Status: Signed Transaction ID: CBJCHBCAABAAaDejeneInbt2D3srIRlNP8jKRR1P2Bk3 "NNS-QP01 Rev 04 Document Management Procedure" History Document created by Grace Sutcliffe ([email protected]) 2024-07-17 - 15:01:55 GMT Document emailed to [email protected] for signature 2024-07-17 - 15:02:56 GMT Document emailed to Callum McMahon ([email protected]) for signature 2024-07-17 - 15:02:56 GMT Email viewed by [email protected] 2024-07-17 - 15:03:29 GMT Signer [email protected] entered name at signing as Lucy Rogers 2024-07-17 - 15:03:46 GMT Document e-signed by Lucy Rogers ([email protected]) Signature Date: 2024-07-17 - 15:03:48 GMT - Time Source: server Email viewed by Callum McMahon ([email protected]) 2024-07-17 - 15:09:04 GMT Document e-signed by Callum McMahon ([email protected]) Signature Date: 2024-07-17 - 15:10:14 GMT - Time Source: server Agreement completed. 2024-07-17 - 15:10:14 GMT