diff --git a/rdm/checklists/13485_2016.txt b/rdm/checklists/13485_2016.txt new file mode 100644 index 0000000..997097b --- /dev/null +++ b/rdm/checklists/13485_2016.txt @@ -0,0 +1,81 @@ +# Audit checklist for ISO 13485:2016 +# +# This checklist is not a substitute for reading, understanding, and implementing the associated standard. +# The descriptive phrase following each keyword reference is intended only as a helpful mnemonic for locating +# and recalling the referenced section of the standard. + +13485:4.1.1 Organization shall document user roles +13485:4.1.2 Organization shall have a process for coming up with new processes +13485:4.1.3 For each quality process, organization shall measure the effectiveness of processes +13485:4.1.4 Organization shall keep up to date with changes to applicable standards +13485:4.1.5 Organization shall ensure outsourced processes are conformant to this standard +13485:4.1.6 Organization shall have a software tools validation process +13485:4.2.1 Organization shall have a document management system +13485:4.2.2 Organization shall maintain a quality manual that includes the scope of the QMS, procedures, and interaction between the procedures +13485:4.2.3 Organization shall maintain separate file for different medical devices. I take this to mean the separation between a product specific QMS vs organization QMS. For example, this would be the DHF for each medical device. Regulatory deliverables usually go here. +13485:4.2.4 Organization shall have a document control system capable of capturing reviews / approval, versioning, accessible by those who need it, legible, ability to deprecate old documents and prevent their use, and prevent loss or deterioration of documents. +13485:4.2.5.a Organization shall document records of conformity to this standard. +13485:4.2.5.b Organization shall document controls needed for storage, security, integrity, retrieval, retention time, and disposition of records +13485:4.2.5.c Organization shall protect PHI contained within records (if applicable) +13485:4.2.5.d Organization shall retain records for at least two years or for the lifetime of the medical device +13485:5.1 Top management shall conduct reviews of the quality policy, ensure enough resources are available to execute the quality policy, and instill a culture of quality throughout the organization +13485:5.2 Top management shall ensure customer and regulatory requirements are met for all products +13485:5.3 Top management shall review and maintain the quality policy +13485:5.4.1 Top management shall ensure quality objectives are met +13485:5.4.2 Synonymous to 5.4.1 +13485:5.5.1 Top management shall document responsibilities of all personell +13485:5.5.2 Top management shall increase awareness and foster an environment of constant improvement for the quality management system +13485:5.5.3 Top management shall ensure appropriate communication channels are established throughout the organization. +13485:5.6.1 Organization shall document procedures for review of quality management system at documented and planned intervals. Records of review shall be maintained +13485:5.6.2 Input to management review shall be documented. Input shall at least contain: employee feedback, complaint handling, customer or patient reports, process monitoring, product monitoring, CAPAs, follow ups from previous management reviews, changes that could affect QMS, new or revised regulatory requirements, changes to this ISO standard +13485:5.6.3 Management review results shall be recorded +13485:6.1 Organization shall determine what resources are necessary to implement the quality manual and meet customer / regulatory requirements +13485:6.2 Organization shall ensure personell are qualified to do what they are tasked to do. This means documenting personell qualifications, provide trainings, evaluate action effectiveness. The amount of oversight here depends on the risk level involved. +13485:6.3 Organization shall document work environment and infrastructure necessary to create conforming product. +13485:6.4.1 Organization shall document any work environment requirements necessary to create conforming product. This probably does not apply to a SAMD. +13485:6.4.2 organization shall have a process to control contamination. This does not apply to a SAMD. +13485:7.1 Organization shall have a product planning process. Organization shall have a risk management and product design and development plan. +13485:7.2.1 Organization shall have process for requirements capture for both premarket and postmarket activities. +13485:7.2.2 The organization shall review product requirements prior to launch of a new product version. +13485:7.2.3 Organization shall document channels used for customer communication: product info, feedback / complaints, advisory notices +13485:7.3.1 Organization shall have a design and development plan +13485:7.3.2 Organization shall have a design and development plan. This will point to 62304 +13485:7.3.3 Organization shall maintain records of requirement review +13485:7.3.4 Organization shall verify design and development outputs for: meeting requirements, field maintainability, purchasability, meet acceptance criteria, RHA +13485:7.3.5 Organization shall identify checkpoints for systematic reviews of design and development. Specifically, the aforementioned reviews shall evaluate the effectiveness of design and development process is able to meet requirements. +13485:7.3.6 Organization shall document verification plan +13485:7.3.7 Organization shall document validation plan +13485:7.3.8 Organization shall have a documented design transfer plan to manufacturing. For a SAMD, this is usually a deployment/ops procedure. +13485:7.3.9 Organization shall document procedures to control design and development process changes. Remember to account for products already in design and development. This is similar to releasing a forced update to users. +13485:7.3.10 Organization shall maintain a DHF for all medical devices +13485:7.4.1 Organization shall establish criteria for evaluation and selection of suppliers based on: supplier capability, supplier performance, level of risk to the quality of the medical device. Organization shall, from time to time, re-evaluate suppliers. +13485:7.4.2 Organization shall document clear purchase order specify what services are to be rendered, acceptance criteria, supplier personnel qualification. +13485:7.4.3 Organization shall establish and execute inspection activities to ensure purchased product meets requirements. Depending on the level of risk to device safety, organization shall implement more stringent supplier evaluation before and during purchased product development. +13485:7.5.1 Organization shall ensure the production of product results in product conforming to specification. SAMD parallel to this could be techniques like locking dependencies, hashes to ensure the validated product is what is being pushed out into production. SAMD differs from physical product in that "produced" software are identical, so typically less process control is necessary. For example, it may be necessary to sample a hardware from the assembly line to QA but this does not make sense for software since we can guarantee they are all binary equivalent. +13485:7.5.2 Organization shall document clininess and contamination control procedures. This does not apply to SAMD. +13485:7.5.3 Organization shall document installation procedure and verification of installation procedure. This is especially important for end user installed product. +13485:7.5.4 Organization shall document servicing procedures, manuals, reference measurements, etc. Organization shall analyze these records to determine if the inforamtion should be a complaint and react appropriately for process improvement. +13485:7.5.5 Organization shall maintain sterilization records. Not applicable for SAMD. +13485:7.5.6 Organization shall validate process used for production or service where the resulting output cannot be or is not validated by subsequent monitoring or measurement. In SAMD terms, this does NOT include a compiler because its output is validated by device verification and validation. Organization shall document procedure for process validation of computer software used in production and service. The computer software validation approach shall be proportionate to the risk level of the application. +13485:7.5.7 Organization shall document procedures for sterilization. Does not apply to SAMD. +13485:7.5.8 Organization shall document procedures for product identification. For SAMD this is related to version numbering and git hash. The bit about returned product does not really apply to a SAMD, but a hashing strategy may be used. +13485:7.5.9.1 Organization shall document procedures to maintain traceability in accordance to regulatory bodies. +13485:7.5.9.2 Requirements for implantable medical devices does not apply. +13485:7.5.10 Organization shall have a process to protect customer provided property. This does not apply to a SAMD. +13485:7.5.11 Organization shall have process for product preservation, storage, handling, and distribution. The main application for a SAMD is cryptographic based integrity and authenticity checks. +13485:7.6 Organization shall have process for monitoring and measuring equipment necessary to provide evidence of conforming product. This is stuff like calibrating a volt meter, oscilloscope, temperature sensor, etc. This does not apply to a SAMD. +13485:8.1 Organization shall implement process for process improvement for processes needed to: demonstration of product conformity, ensure conformation to QMS, maintain effectiveness of QMS. +13485:8.2.1 Organization shall have gather and monitor feedback on whether customer requirements are met. Feedback shall be taken from production and post-production activities. +13485:8.2.2 Organization shall document timely complaint handling procedure. Procedure shall contain at least: receiving and recording complaints, evalutation if the feedback is a complaint (or feature request), complaint investigation, reporting regulatory bodies if necessary, handling of complaint related product (the installation having issue), determining if a CAPA is necessary. +13485:8.2.3 Organization shall document procedures for reporting to appropriate regulatory bodies. +13485:8.2.4 Organization shall conduct periodic internal audits. +13485:8.2.5 Organization shall monitor and measure the effectiveness of the QMS. +13485:8.2.6 Organization shall monitor and measure the conformity of product. +13485:8.3.1 Organization shall ensure non-conforming product does not make it to customers. This does not apply to SAMD in its intended form. However, we can make the case that 62304 compliance features including code review, validation, verification fulfill this requirement +13485:8.3.2 Organization shall detect nonconforming product before delivery. SAMD conforms to this by 62304 compliance. +13485:8.3.4 Organization shall document refurbishing / rework procedures. This does not apply to a SAMD. +13485:8.4 Organization shall document procedure to collect and analyse adequecy and effectiveness of the QMS. This procedure should at minimum contain inputs from feedback (both customer and internal), conformity to requirements, opportunities for improvement, suppliers, audits, service reports. Service reports are support cases. +13485:8.5.1 Organization shall have process for identification and implementation of QMS improvements. +13485:8.5.2 Organization shall attempt to eliminate the cause of nonconformities to prevent recurrence. This is called a corrective action (reactive). Corrective action urgency shall scale with the effect of the nonconformity encountered. +13485:8.5.3 Organization shall attempt to prevent occurence of nonconformity in the future. This is called a preventitive action (proactive). + diff --git a/rdm/checklists/21CFR820.txt b/rdm/checklists/21CFR820.txt new file mode 100644 index 0000000..0324480 --- /dev/null +++ b/rdm/checklists/21CFR820.txt @@ -0,0 +1,66 @@ +# Audit checklist for 21CFR820 +# +# This checklist is not a substitute for reading, understanding, and implementing the associated standard. +# The descriptive phrase following each keyword reference is intended only as a helpful mnemonic for locating +# and recalling the referenced section of the standard. + +21.CFR.820.20.a Management with executive responsibility shall ensure that the quality policy is understood, implemented, and maintained at all levels of the organization. +21.CFR.820.20.b Each manufacturer shall establish and maintain an adequate organizational structure to ensure that devices are designed and produced in accordance with the requirements of this part. +21.CFR.820.20.b.1 Responsibility and authority. Each manufacturer shall establish the appropriate responsibility, authority, and interrelation of all personnel who manage, perform, and assess work affecting quality, and provide the independence and authority necessary to perform these tasks. +21.CFR.820.20.b.2 Resources. Each manufacturer shall provide adequate resources, including the assignment of trained personnel, for management, performance of work, and assessment activities, including internal quality audits, to meet the requirements of this part. +21.CFR.820.20.b.3 Management representative. Management shall appoint quality systems subject matter expert. +21.CFR.820.20.c Management review. Management with executive responsibility shall review the suitability and effectiveness of the quality system at defined intervals and with sufficient frequency according to established procedures to ensure that the quality system satisfies the requirements of this part and the manufacturer's established quality policy and objectives. The dates and results of quality system reviews shall be documented. +21.CFR.820.20.d Quality planning. Each manufacturer shall establish a quality plan which defines the quality practices, resources, and activities relevant to devices that are designed and manufactured. The manufacturer shall establish how the requirements for quality will be met. +21.CFR.820.20.e Quality system procedures. Each manufacturer shall establish quality system procedures and instructions. An outline of the structure of the documentation used in the quality system shall be established where appropriate. +21.CFR.820.22 Third Party quality audit procedure. +21.CFR.820.25.a General. Each manufacturer shall have sufficient personnel with the necessary education, background, training, and experience to assure that all activities required by this part are correctly performed. +21.CFR.820.25.b Each manufacturer shall establish procedures for identifying training needs and ensure that all personnel are trained to adequately perform their assigned responsibilities. Training shall be documented. +21.CFR.820.25.b.1 As part of their training, personnel shall be made aware of device defects which may occur from the improper performance of their specific jobs. +21.CFR.820.25.b.2 Personnel who perform verification and validation activities shall be made aware of defects and errors that may be encountered as part of their job functions. +21.CFR.820.30.a shall establish and maintain procedures to control the design of the device in order to ensure that specified design requirements are met. +21.CFR.820.30.b Design and development planning. +21.CFR.820.30.c Design input. +21.CFR.820.30.d Design output. +21.CFR.820.30.e Design review. +21.CFR.820.30.f Design verification. +21.CFR.820.30.g Design validation. +21.CFR.820.30.h Design transfer. +21.CFR.820.30.i Design changes. +21.CFR.820.30.j Design history file. +21.CFR.820.40.a Document approval and distribution +21.CFR.820.40.b Document changes +21.CFR.820.50.a Evaluation of suppliers, contractors, and consultants +21.CFR.820.60 Identification +21.CFR.820.65 Traceability +21.CFR.820.70 Production and process controls. +21.CFR.820.70.a General. +21.CFR.820.70.b Production and process changes. +21.CFR.820.70.c Environmental control. +21.CFR.820.70.d Personnel. +21.CFR.820.70.e Contamination control. +21.CFR.820.70.f Buildings. +21.CFR.820.70.g Equipment maintenance, inspection, and adjustment. +21.CFR.820.70.h Manufacturing material. +21.CFR.820.70.h.i Automated process. Tools validation. +21.CFR.820.72 Inspection, measuring, and test equipment. +21.CFR.820.75 Process validation. +21.CFR.820.80 Receiving, in-process, and finished device acceptance. +21.CFR.820.86 Acceptance status. +21.CFR.820.90 Nonconforming product. +21.CFR.820.100 Corrective and preventive action. +21.CFR.820.120 Device labeling. +21.CFR.820.130 Device packaging. +21.CFR.820.140 Handling. +21.CFR.820.150 Storage. +21.CFR.820.160 Distribution. +21.CFR.820.170 Installation. +21.CFR.820.180 General requirements. +21.CFR.820.181 Device master record. +21.CFR.820.184 Device history record. +21.CFR.820.186 Quality system record. +21.CFR.820.198 Complaint files. +21.CFR.820.200 Servicing. +21.CFR.820.250 Statistical techniques. + + + diff --git a/rdm/init_files/organization_qms/SOPs/capa.md b/rdm/init_files/organization_qms/SOPs/capa.md new file mode 100644 index 0000000..0afc3aa --- /dev/null +++ b/rdm/init_files/organization_qms/SOPs/capa.md @@ -0,0 +1,77 @@ +--- +revision: 1 +title: CAPA SOP +--- +# Approvals + +All approvers shall add a signed commit with their name and roles appended to the table in this section. + +| Name | Role | Date | +| ---- | ------------------- | ---- | +| | Quality Systems SME | | + +# Training Record + +| Name | Role | Date | +| ---- | ---- | ---- | +| | | | + +# Purpose + +This SOP shall describe the process for creating, executing, and concluding a corrective action / preventative action (CAPA).[[21.CFR.820.100]] + +# Change History + +The change history section shall contain a brief summary of changes made in this revision. + +| Change Description | Date | +| ------------------ | ---- | +| Initial version | | + +# Required Roles to Execute + +The following user roles are required to execute this SOP: + +- Quality Systems SME +- All roles necessary to execute the CAPA + +# Required Roles to Review + +The following user roles are required for initial approval, periodic review, and change approval of this SOP: + +- Quality Systems SME + +# Required Inputs and Dependencies + +The following inputs are required for the execution of this SOP: + +- The event(s) that lead to initiating this CAPA + +# Outputs + +The SOP shall produce the following outputs: + +- A CAPA record +- Potentially one or more changed, removed, or new SOPs + +# Risk Level + +High: Error in SOP or SOP execution is likely to result in patient harm. + +# Periodic Review + +Author shall insert the review periodicity depending on the risk level. + +High: Review every six months. + +# Record Template + +Refer to `templates/capa_record.md` + +# Work Instruction + +1. Ensure you are on the `master` branch of the QMS git repository it is up to date. +1. Create a new branch called `capa/name_of_capa` +1. Create a copy of the CAPA record template to `records` +1. Fill out the CAPA record as requested in the record template. +1. Close the CAPA by merging the branch into `master`. Merging into master signifies the CAPA has been resolved and is ready to be executed. diff --git a/rdm/init_files/organization_qms/SOPs/change_sop.md b/rdm/init_files/organization_qms/SOPs/change_sop.md new file mode 100644 index 0000000..6846d67 --- /dev/null +++ b/rdm/init_files/organization_qms/SOPs/change_sop.md @@ -0,0 +1,79 @@ +--- +revision: 1 +title: SOP Change SOP +--- + +# Approvals + +| Name | Role | Date | +| ---- | ------------------- | ---- | +| | Quality Systems SME | | + +# Training Record + +By signing below you have acknowledged you have read and understood this document. + +| Name | Role | Date | +| ---- | ---- | ---- | +| | | | + +# Purpose + +This SOP describes how to change existing SOPs. [[21.CFR.820.40.b]] + +# Triggers + +This SOP is usually triggered by an upstream CAPA or through a review of the SOP. + +# Change History + +| Change Description | Date | +| ------------------ | ---------------- | +| Initial version | January 20, 2021 | + +# Required Roles to Execute + +The following user roles are required to execute this SOP: + +- Quality Systems SME +- All roles under "Required Roles to Review" for the SOP to be changed +- All roles under "Required Roles to Execute" for the SOP to be changed + +# Required Roles to Review + +The following user roles are required for initial approval, periodic review, and change approval of this SOP: + +- Quality Systems SME + +# Required Inputs and Dependencies + +The following inputs are required for the execution of this SOP: + +- The SOP to be changed + +# Outputs + +The SOP shall produce the following outputs: + +- An SOP with approved changes + +# Risk Level + +Low: Error in SOP or SOP execution is unlikely to result in patient harm. + +# Periodic Review + +Low: Review once a year. + +# Record Template + +The record for SOP execution is a new SOP revision and additions to the "Change History" section +in the SOP to be changed. + +# Work Instruction + +1. Ensure your local quality manual Git repository is up to date. Ensure you are on the `master` branch and perform a `git pull` +1. Create a new branch in the quality manual Git repository. + Give the branch a descriptive name and use snake case such as: `change_sop/new_complaint_sop` +1. Make the necessary changes to the SOP. +1. Commit the changes to Git version control. diff --git a/rdm/init_files/organization_qms/SOPs/complaint.md b/rdm/init_files/organization_qms/SOPs/complaint.md new file mode 100644 index 0000000..3dbafe4 --- /dev/null +++ b/rdm/init_files/organization_qms/SOPs/complaint.md @@ -0,0 +1,140 @@ +--- +revision: 1 +title: New SOP Template +--- + +# Approvals + +All approvers shall add a signed commit with their name and roles appended to the table in this section. + +| Name | Role | Date | +|---|---|---| +| | | | +| | | | +| | || + +# Training Record + +By signing below you have acknowledged you have read and understood this document. + +| Name | Role | Date | +| ---- | ---- | ---- | +| | | | + +# Purpose + +This SOP details the complaint handling procedure. [[21.CFR.820.198]] + +# Customer Complaint Channels + +Identify all channels that customer complaints. + + + + + +TODO: Add more process in compliance with 21.CFR.820.198 + +(a) Each manufacturer shall maintain complaint files. Each manufacturer shall establish and maintain procedures for receiving, reviewing, and evaluating complaints by a formally designated unit. Such procedures shall ensure that: + +(1) All complaints are processed in a uniform and timely manner; + +(2) Oral complaints are documented upon receipt; and + +(3) Complaints are evaluated to determine whether the complaint represents an event which is required to be reported to FDA under part 803 of this chapter, Medical Device Reporting. + +(b) Each manufacturer shall review and evaluate all complaints to determine whether an investigation is necessary. When no investigation is made, the manufacturer shall maintain a record that includes the reason no investigation was made and the name of the individual responsible for the decision not to investigate. + +(c) Any complaint involving the possible failure of a device, labeling, or packaging to meet any of its specifications shall be reviewed, evaluated, and investigated, unless such investigation has already been performed for a similar complaint and another investigation is not necessary. + +(d) Any complaint that represents an event which must be reported to FDA under part 803 of this chapter shall be promptly reviewed, evaluated, and investigated by a designated individual(s) and shall be maintained in a separate portion of the complaint files or otherwise clearly identified. In addition to the information required by § 820.198(e), records of investigation under this paragraph shall include a determination of: + +(1) Whether the device failed to meet specifications; + +(2) Whether the device was being used for treatment or diagnosis; and + +(3) The relationship, if any, of the device to the reported incident or adverse event. + +(e) When an investigation is made under this section, a record of the investigation shall be maintained by the formally designated unit identified in paragraph (a) of this section. The record of investigation shall include: + +(1) The name of the device; + +(2) The date the complaint was received; + +(3) Any unique device identifier (UDI) or universal product code (UPC), and any other device identification(s) and control number(s) used; + +(4) The name, address, and phone number of the complainant; + +(5) The nature and details of the complaint; + +(6) The dates and results of the investigation; + +(7) Any corrective action taken; and + +(8) Any reply to the complainant. + +(f) When the manufacturer's formally designated complaint unit is located at a site separate from the manufacturing establishment, the investigated complaint(s) and the record(s) of investigation shall be reasonably accessible to the manufacturing establishment. + +(g) If a manufacturer's formally designated complaint unit is located outside of the United States, records required by this section shall be reasonably accessible in the United States at either: + +(1) A location in the United States where the manufacturer's records are regularly kept; or + +(2) The location of the initial distributor. + + + +# Triggers + +This SOP is triggered when a customer complaint is received. + +# Change History + +The change history section shall contain a brief summary of changes made in this revision. + +| Change Description | Date | +| ------------------ | ---------------- | +| Initial version | January 12, 2021 | + +# Required Roles to Execute + +The following user roles are required to execute this SOP: + +- Example user role + +# Required Roles to Review + +The following user roles are required for initial approval, periodic review, and change approval of this SOP: + +- Example user role + +# Required Inputs and Dependencies + +The following inputs are required for the execution of this SOP: + +- Example input: All code review records from the code review SOP for the last year. + +# Outputs + +The SOP shall produce the following outputs: + +- Example output: A record to capture a review was performed on an SOP. + +# Risk Level + +Medium: Error in SOP or SOP execution is moderately likely in patient harm. + + +# Periodic Review + +Medium: Review once a year. + + +# Record Template + +Author shall reference or include the template used to create a record capturing the SOP execution. + +# Work Instruction + +A step by step recipe for executing the SOP. + +1. TODO: Add complaint handling steps. diff --git a/rdm/init_files/organization_qms/SOPs/external_audit.md b/rdm/init_files/organization_qms/SOPs/external_audit.md new file mode 100644 index 0000000..1a1471d --- /dev/null +++ b/rdm/init_files/organization_qms/SOPs/external_audit.md @@ -0,0 +1,82 @@ +--- +revision: 1 +title: New SOP Template +--- + +# Approvals + +All approvers shall add a signed commit with their name and roles appended to the table in this section. + +| Name | Role | Date | +|---|---|---| +| | | | +| | | | +| | || + +# Training Record + +By signing below you have acknowledged you have read and understood this document. + +| Name | Role | Date | +| ---- | ---- | ---- | +| | | | + +# Purpose + +This SOP details the purpose of conducting a periodic third party audits of the QMS. [[21.CFR.820.22 ]] + +# Triggers + +TODO: Determine the periodicity of external audits. + +# Change History + +The change history section shall contain a brief summary of changes made in this revision. + +| Change Description | Date | +| ------------------ | ---------------- | +| Initial version | January 12, 2021 | + +# Required Roles to Execute + +The following user roles are required to execute this SOP: + +- Quality Systems SME + +# Required Roles to Review + +The following user roles are required for initial approval, periodic review, and change approval of this SOP: + +- Quality Systems SME + +# Required Inputs and Dependencies + +The following inputs are required for the execution of this SOP: + +- The quality management system + +# Outputs + +The SOP shall produce the following outputs: + +- A report from the third party auditors and an action plan to address the findings. + +# Risk Level + +Low: Error in SOP or SOP execution is unlikely to result in patient harm. + + +# Periodic Review + +Low: Review once a year. + +# Record Template + +TODO: Create record template for capturing an audit was performed, findings, and action items + +# Work Instruction + +A step by step recipe for executing the SOP. + +1. Example Step 1 +2. Example Step 2 diff --git a/rdm/init_files/organization_qms/SOPs/generate_quality_metrics.md b/rdm/init_files/organization_qms/SOPs/generate_quality_metrics.md new file mode 100644 index 0000000..92d3916 --- /dev/null +++ b/rdm/init_files/organization_qms/SOPs/generate_quality_metrics.md @@ -0,0 +1,86 @@ +--- +revision: 1 +title: Generate Quality Metrics SOP +--- + +# Approvals + +All approvers shall add a signed commit with their name and roles appended to the table in this section. + +| Name | Role | Date | +|---|---|---| +| | | | +| | | | +| | || + +# Training Record + +By signing below you have acknowledged you have read and understood this document. + +| Name | Role | Date | +| ---- | ---- | ---- | +| | | | + +# Purpose + +Author shall clearly identify the purpose of this SOP. What does this SOP do? When should this SOP be invoked? + +# Triggers + +This SOP is usually created as a result of a CAPA. + +# Change History + +The change history section shall contain a brief summary of changes made in this revision. + +| Change Description | Date | +| ------------------ | ---------------- | +| Initial version | January 20, 2021 | + +# Required Roles to Execute + +The following user roles are required to execute this SOP: + +- Quality Systems SME +- Engineering SME + +# Required Roles to Review + +The following user roles are required for initial approval, periodic review, and change approval of this SOP: + +- Quality Systems SME + +# Required Inputs and Dependencies + +The following inputs are required for the execution of this SOP: + +- Example input: All code review records from the code review SOP for the last year. + +# Outputs + +The SOP shall produce the following outputs: + +- Example output: A record to capture a review was performed on an SOP. + +# Risk Level + +Low: Error in SOP or SOP execution is unlikely to result in patient harm. + +# Periodic Review + +Low: Review once a year. + +# Record Template + +Refer to `templates/quality_metrics_record.md` + +# Work Instruction + +A step by step recipe for executing the SOP. + +1. Extract and / or compute all quality metrics as stated in the quality manual. +2. Create a new branch called `generate_quality_metrics/YYYY_MM_DD`. Replace the YYYY_MM_DD with todays date. +3. Create a copy of `templates/quality_metrics_record.md` under `records/generate_quality_metrics/YYYY_MM_DD.md` +4. Record the values of quality metrics in this record. +5. Commit the changes, push the branch, and submit a pull request for review. + diff --git a/rdm/init_files/organization_qms/SOPs/internal_audit.md b/rdm/init_files/organization_qms/SOPs/internal_audit.md new file mode 100644 index 0000000..3190f0e --- /dev/null +++ b/rdm/init_files/organization_qms/SOPs/internal_audit.md @@ -0,0 +1,82 @@ +--- +revision: 1 +title: Internal Audit +--- + +# Approvals + +All approvers shall add a signed commit with their name and roles appended to the table in this section. + +| Name | Role | Date | +|---|---|---| +| | | | + +# Training Record + +By signing below you have acknowledged you have read and understood this document. + +| Name | Role | Date | +| ---- | ---- | ---- | +| | | | + +# Purpose + +This SOP shall describe how to conduct SOP reviews. [[21.CFR.820.20.c]] + +# Change History + +The change history section shall contain a brief summary of changes made in this revision. + +| Change Description | Date | +| ------------------ | ---------------- | +| Initial version | January 20, 2021 | + + +# Required Roles to Execute + +The following user roles are required to execute this SOP: + +- Quality Systems SME +- All roles under "Required Roles to review" for the SOPs under review + +# Required Roles to Review + +The following user roles are required for initial approval, periodic review, and change approval of this SOP: + +- Quality Systems SME + +# Required Inputs and Dependencies + +The following inputs are required for the execution of this SOP: + +- The SOPs under review + +# Outputs + +The SOP shall produce the following outputs: + +- An internal audit review record + +# Risk Level + +Low: Error in SOP or SOP execution is unlikely to result in patient harm. + +# Periodic Review + +Low: Only review when SOP is used. + +# Record Template + +Author shall reference or include the template used to create a record capturing the SOP execution. + +# Work Instruction + +1. Ensure your local quality manual Git repository is up to date. Ensure you are on the `master` branch and perform a `git pull` +1. Create a new branch in the quality manual Git repository. + Give the branch a descriptive name and use snake case such as: `review_sop/new_complaint_sop` +1. Copy `templates/review_sop.md` to `records`. +1. Add the newly created record to version control and capture approvals. +1. Commit the changes to Git version control. +1. Create a pull request. Add all approvers. +1. Merge the pull request to `master` once approved. + diff --git a/rdm/init_files/organization_qms/SOPs/new_product.md b/rdm/init_files/organization_qms/SOPs/new_product.md new file mode 100644 index 0000000..437a5f3 --- /dev/null +++ b/rdm/init_files/organization_qms/SOPs/new_product.md @@ -0,0 +1,76 @@ +--- +revision: 1 +title: SOP Change SOP +--- +# Approvals + +| Name | Role | Date | +| ---- | ------------------- | ---- | +| | Quality Systems SME | | + +# Training Record + +By signing below you have acknowledged you have read and understood this document. + +| Name | Role | Date | +| ---- | ---- | ---- | +| | | | + +# Purpose + +This SOP describes how to add a new product under the quality management system. + +# Change History + +| Change Description | Date | +| ------------------ | ---------------- | +| Initial version | January 20, 2021 | + +# Required Roles to Execute + +The following user roles are required to execute this SOP: + +- All roles listed in the quality manual are required + +# Required Roles to Review + +The following user roles are required for initial approval, periodic review, and change approval of this SOP: + +- Quality Systems SME + +# Required Inputs and Dependencies + +The following inputs are required for the execution of this SOP: + +- This SOP does not require any inputs + +# Outputs + +The SOP shall produce the following outputs: + +- A product code git repository with RDM installed. +- A DHF directory in a file sharing platform. [[21.CFR.820.30.j]] + +# Risk Level + +Low: Error in SOP or SOP execution is unlikely to result in patient harm. + +# Periodic Review + +Low: Review once a year. + +# Record Template + +The record for SOP execution is a new SOP revision and additions to the "Change History" section +in the SOP to be changed. + +# Work Instruction + +1. Ensure your local quality manual Git repository is up to date. Ensure you are on the `master` branch and perform a `git pull` +1. Create a new branch in the quality manual Git repository. + Give the branch a descriptive name and use snake case such as: `new_product/name_of_product` +1. Make the necessary changes to the SOP. +1. Commit the changes to Git version control. +1. Create a new directory under Box with the name of the product. +1. Add a new row in `documents/product_registry.md` + diff --git a/rdm/init_files/organization_qms/SOPs/new_sop.md b/rdm/init_files/organization_qms/SOPs/new_sop.md new file mode 100644 index 0000000..b678786 --- /dev/null +++ b/rdm/init_files/organization_qms/SOPs/new_sop.md @@ -0,0 +1,68 @@ +--- +revision: 1 +title: SOP Creation SOP +--- +# Approvals + +| Name | Role | Date | +|---|---|---| +| | | | + +# Training Record + +By signing below you have acknowledged you have read and understood this document. + +| Name | Role | Date | +| ---- | ---- | ---- | +| | | | + +# Purpose + +This SOP shall be invoked when a new SOP needs to be created [[21.CFR.820.20.e]]. New SOPs may be created for a variety of reasons such as: + +- Coming into conformance to existing or new regulations +- A result of a corrective action / preventative action + + +# Required Roles to Execute + +At least a Quality systems SME is required to execute this SOP. Other SMEs shall be involved as necessary. + +# Required Roles to Review + +The following user roles are required for initial approval, periodic review, and change approval of this SOP: + +- Quality systems SME + +# Required Inputs and Dependencies + +This SOP does not have any required inputs. + +# Outputs + +The output of this SOP is a new file in the SOPs directory of the quality manual. Additionally, new a new record template +shall be created in the record_templates directory of the quality manual. + +# Risk Level + +Low: Error in SOP or SOP execution is unlikely to result in nonconforming product or patient harm. + +# Periodic Review + +Low: Only review when SOP is used. + +# Record Template + +A record of execution for this SOP is a new SOP. The template is found in the `templates/new_sop.md` file. + +# Work Instruction + +1. Ensure your local quality manual Git repository is up to date. Ensure you are on the `master` branch and perform a `git pull` +1. Create a new branch in the quality manual Git repository. + Give the branch a descriptive name and use snake case such as: `new_sop/new_complaint_sop` +1. Make a copy of the `templates/new_sop.md` file. Give the filename the name of the SOP. Use `snake_case` for the filename. +1. Open the new SOP file in a text editor of choice. +1. Fill in each section with relevant content for the new SOP. +1. Commit the newly added files. Push the files up to GitHub. +1. In GitHub, create Pull Request for the newly created branch. Add reviewers until all roles listed under the section "Required Roles to Review" have been fulfilled. +1. Once all reviewers have been satisfied with the SOP, each reviewer shall add their name to the approvals table in Github. This creates a signed commit that constitutes an electronic signature. [[21.CFR.820.40.a]] diff --git a/rdm/init_files/organization_qms/SOPs/new_tool_validation.md b/rdm/init_files/organization_qms/SOPs/new_tool_validation.md new file mode 100644 index 0000000..3c41d87 --- /dev/null +++ b/rdm/init_files/organization_qms/SOPs/new_tool_validation.md @@ -0,0 +1,84 @@ +--- +revision: 1 +title: New Tool Validation SOP +--- + +# Approvals + +All approvers shall add a signed commit with their name and roles appended to the table in this section. + +| Name | Role | Date | +|---|---|---| +| | Regulatory SME || + +# Training Record + +By signing below you have acknowledged you have read and understood this document. + +| Name | Role | Date | +| ---- | ---- | ---- | +| | | | + +# Purpose + +This SOP details the process to validate a new tool for use within the quality management system. [[21.CFR.820.70.i]] + +As a software as a medical device manufacturer, most of our tools will be software. Any tool to be used as part of the +quality management system shall be validated using this procedure before use. + +# Triggers + +This SOP must be executed every time the organization wishes to use a new software tool to execute the QMS. + +# Change History + +The change history section shall contain a brief summary of changes made in this revision. + +| Change Description | Date | +| ------------------ | ---------------- | +| Initial version | January 20, 2021 | + +# Required Roles to Execute + +The following user roles are required to execute this SOP: + +- Quality Systems SME +- Any SME necessary to validate the tool. + +# Required Roles to Review + +The following user roles are required for initial approval, periodic review, and change approval of this SOP: + +- Quality Systems SME + +# Required Inputs and Dependencies + +The following inputs are required for the execution of this SOP: + +# Outputs + +- A validation record in the records directory of the QMS git repository. +- An entry in the tools registry document. + + +# Risk Level + +Medium: Error in SOP or SOP execution is moderately likely in patient harm. + +# Periodic Review + +Medium: Review once a year. + +# Record Template + +Found in `templates/new_tool_validation.md` + +# Work Instruction + +1. Ensure you are on `master` and your git repository is up to date +1. Create a new branch called `new_tool_validation/` +1. Copy the record template `templates/new_tool_validation.md` into `records/new_tool_validation/name_of_tool.md` +1. Follow instructions on the record template. +1. Upon finishing tool validation, record completion in `documents/tools_registry.md` +1. Open a pull request and add necessary reviewers. + diff --git a/rdm/init_files/organization_qms/SOPs/new_vendor.md b/rdm/init_files/organization_qms/SOPs/new_vendor.md new file mode 100644 index 0000000..da31296 --- /dev/null +++ b/rdm/init_files/organization_qms/SOPs/new_vendor.md @@ -0,0 +1,80 @@ +--- +revision: 1 +title: New Vendor SOP +--- + +# Approvals + +All approvers shall add a signed commit with their name and roles appended to the table in this section. + +| Name | Role | Date | +|---|---|---| +| | Quality Systems SME | | + +# Training Record + +By signing below you have acknowledged you have read and understood this document. + +| Name | Role | Date | +| ---- | ---- | ---- | +| | | | + +# Purpose + +This SOP details the process to qualify a new vendor. [[21.CFR.820.50.a]] + +# Triggers + +This SOP must be executed every time the organization wishes to outsource a process or activity to a new vendor. + +# Change History + +The change history section shall contain a brief summary of changes made in this revision. + +| Change Description | Date | +| ------------------ | ---------------- | +| Initial version | January 20, 2021 | + +# Required Roles to Execute + +The following user roles are required to execute this SOP: + +- Quality Systems SME +- Any SME necessary to qualify the vendor. + +# Required Roles to Review + +The following user roles are required for initial approval, periodic review, and change approval of this SOP: + +- Quality Systems SME + +# Required Inputs and Dependencies + +The following inputs are required for the execution of this SOP: + +- Requirements the vendor must fulfill. + +# Outputs + +The SOP shall produce the following outputs: + +- A vendor qualification record + +# Risk Level + +Low: Error in SOP or SOP execution is unlikely to result in patient harm. + +# Periodic Review + +Low: Review once a year. + +# Record Template + +The vendor qualification record template is found in `templates/vendor_qualification.md` + +# Work Instruction + +1. Ensure you are on `master` and your git repository is up to date +1. Create a new branch called `new_vendor/name_of_vendor` +1. Copy the record template `templates/new_vendor.md` into `records/new_vendor/name_of_vendor.md` + diff --git a/rdm/init_files/organization_qms/SOPs/release.md b/rdm/init_files/organization_qms/SOPs/release.md new file mode 100644 index 0000000..99c4f32 --- /dev/null +++ b/rdm/init_files/organization_qms/SOPs/release.md @@ -0,0 +1,97 @@ +--- +revision: 1 +title: Release SOP +--- + +# Approvals + +All approvers shall add a signed commit with their name and roles appended to the table in this section. + +| Name | Role | Date | +|---|---|---| +| | | | +| | | | +| | || + +# Training Record + +By signing below you have acknowledged you have read and understood this document. + +| Name | Role | Date | +| ---- | ---- | ---- | +| | | | + +# Purpose + +This SOP details activities that must be performed for a product release. [[21.CFR.820.80, 21.CFR.820.30.j]] + +# Triggers + +This SOP is triggered when a release candidate has successfully undergone all acceptance checkpoints. + +# Change History + +The change history section shall contain a brief summary of changes made in this revision. + +| Change Description | Date | +| ------------------ | ---------------- | +| Initial version | January 12, 2021 | + +# Required Roles to Execute + +The following user roles are required to execute this SOP: + +- Engineering SME +- Produt Management SME +- Quality Systems SME + +# Required Roles to Review + +The following user roles are required for initial approval, periodic review, and change approval of this SOP: + +- Engineering SME +- Produt Management SME +- Quality Systems SME + +# Required Inputs and Dependencies + +The following inputs are required for the execution of this SOP: + +- TODO: Add release activity inputs + +# Outputs + +The SOP shall produce the following outputs: + +- A new directory inside Dropbox with the following structure: + - Design Outputs + - Device Master Record [[21.CFR.820.181]] + - Shall contain design inputs, installation manual, maintenance, and servicing procedures, verification plan +- A new directory in the product's DHF named "Design Outputs" +- Design Outputs directory shall contain: + - Snapshot of the code Git repository + - Docker image used for installation + - Updated user manual +- A regulatory submission if necessary + - TODO: Add note to file vs new 510k determination process +- A new row in the products registry. +- A new entry in the service manual for this release. + +# Risk Level + +Medium: Error in SOP or SOP execution is moderately likely in patient harm. + + +# Periodic Review + +Medium: Review once a year. + +# Record Template + +TODO: Create record template to capture a release was approved and executed. + +# Work Instruction + +A step by step recipe for executing the SOP. + +1. TODO: Fill out work instruction diff --git a/rdm/init_files/organization_qms/SOPs/remove_sop.md b/rdm/init_files/organization_qms/SOPs/remove_sop.md new file mode 100644 index 0000000..dc23d1c --- /dev/null +++ b/rdm/init_files/organization_qms/SOPs/remove_sop.md @@ -0,0 +1,80 @@ +--- +revision: 1 +title: SOP Removal SOP +--- + +# Approvals + +| Name | Role | Date | +| ---- | ---- | ---- | +| | | | + +# Training Record + +By signing below you have acknowledged you have read and understood this document. + +| Name | Role | Date | +| ---- | ---- | ---- | +| | | | + +# Purpose + +This SOP describes how to remove existing SOPs. [[21.CFR.820.40.a]] + +# Change History + +| Change Description | Date | +| ------------------ | ---------------- | +| Initial version | January 20, 2021 | + +# Required Roles to Execute + +The following user roles are required to execute this SOP: + +- Quality Systems SME +- All roles under "Required Roles to Review" for the SOP to be changed +- All roles under "Required Roles to Execute" for the SOP to be changed + +# Required Roles to Review + +The following user roles are required for initial approval, periodic review, and change approval of this SOP: + +- Quality Systems SME + +# Required Inputs and Dependencies + +The following inputs are required for the execution of this SOP: + +- The SOP to be removed. +- This SOP cannot be removed. + +# Outputs + +The SOP shall produce the following outputs: + +- An SOP removal record. + +# Risk Level + +Low: Error in SOP or SOP execution is unlikely to result in patient harm. + +# Periodic Review + +Low: Review once a year. + +# Record Template + +The record for SOP execution is a new SOP revision and additions to the "Change History" section +in the SOP to be changed. + +# Work Instruction + +1. Ensure your local quality manual Git repository is up to date. Ensure you are on the `master` branch and perform a `git pull` +1. Create a new branch in the quality manual Git repository. + Give the branch a descriptive name and use snake case such as: `remove_sop/new_complaint_sop` +1. Copy `templates/remove_sop.md` to records and follow the instructions there. +1. Add the newly created record to version control and capture approvals. +1. Delete the SOP file. +1. Commit the changes to Git version control. +1. Create a pull request. Add all approvers. +1. Merge the pull request to `master` once approved. diff --git a/rdm/init_files/organization_qms/SOPs/training.md b/rdm/init_files/organization_qms/SOPs/training.md new file mode 100644 index 0000000..9f1aef2 --- /dev/null +++ b/rdm/init_files/organization_qms/SOPs/training.md @@ -0,0 +1,85 @@ +--- +revision: 1 +title: Training SOP +--- + +# Approvals + +All approvers shall add a signed commit with their name and roles appended to the table in this section. + +| Name | Role | Date | +|---|---|---| +| | | | +| | | | +| | || + +# Training Record + +By signing below you have acknowledged you have read and understood this document. + +| Name | Role | Date | +| ---- | ---- | ---- | +| | | | + +# Purpose + +Author shall clearly identify the purpose of this SOP. What does this SOP do? When should this SOP be invoked? + +# Triggers + +This SOP is triggered when a new person is onboarded and periodically as needed for existing personnel. + +# Change History + +The change history section shall contain a brief summary of changes made in this revision. + +| Change Description | Date | +| ------------------ | ---------------- | +| Initial version | January 12, 2021 | + +# Required Roles to Execute + +The following user roles are required to execute this SOP: + +- The user role(s) of the person undergiong training. + +# Required Roles to Review + +The following user roles are required for initial approval, periodic review, and change approval of this SOP: + +- Quality Systems SME + +# Required Inputs and Dependencies + +The following inputs are required for the execution of this SOP: + +- All SOPs for which the person may execute or review. +- The quality manual + +# Outputs + +The SOP shall produce the following outputs: + +- New rows or updates to existing rows in the Training Record section for each SOP reviewed + +# Risk Level + +Low: Error in SOP or SOP execution is unlikely to result in patient harm. + +# Periodic Review + +Low: Review once a year. + +# Record Template + +No separate record is generated by this SOP. + +# Work Instruction + +A step by step recipe for executing the SOP. + +1. Create a new branch named `training/your_name` +2. Add your name to the training record for each document you are reviewing. +3. Commit and push the changes. +4. Open a PR and add a Quality Systems SME as a reviewer. +5. Merge the PR once approved. diff --git a/rdm/init_files/organization_qms/documents/tools_registry.md b/rdm/init_files/organization_qms/documents/tools_registry.md new file mode 100644 index 0000000..474c1ac --- /dev/null +++ b/rdm/init_files/organization_qms/documents/tools_registry.md @@ -0,0 +1,35 @@ +--- +id: Tools Register +revision: 1 +title: Tools Register +--- + +# Purpose + +This document shall keep track of all external vendors and their responsibilities. + +# Approvals + +All approvers shall add a signed commit with their name and roles appended to the table in this section. + +| Name | Role | Date | +| -------------- | ------------------- | ---------------- | +| Yujan Shrestha | Quality Systems SME | January 14, 2021 | + +# Change History + +The change history section shall contain a brief summary of changes made in this revision. + +| Change Description | Date | +| ------------------ | ---------------- | +| Initial version | January 12, 2021 | + +# Vendor Registry + +| Tool Name | Risk Level | Validation Date | +| -------------------------------- | ---------- | --------------- | +| GitHub | Moderate | TBD | +| Regulatory Documentation Manager | Moderate | TBD | +| | | | +| | | | + diff --git a/rdm/init_files/organization_qms/documents/vendors_registry.md b/rdm/init_files/organization_qms/documents/vendors_registry.md new file mode 100644 index 0000000..eeadcdd --- /dev/null +++ b/rdm/init_files/organization_qms/documents/vendors_registry.md @@ -0,0 +1,35 @@ +--- +id: Vendors Register +revision: 1 +title: Vendors Register +--- + +# Purpose + +This document shall keep track of all external vendors and their responsibilities. + +# Approvals + +All approvers shall add a signed commit with their name and roles appended to the table in this section. + +| Name | Role | Date | +| -------------- | ------------------- | ---------------- | +| Yujan Shrestha | Quality Systems SME | January 14, 2021 | + +# Change History + +The change history section shall contain a brief summary of changes made in this revision. + +| Change Description | Date | +| ------------------ | ---------------- | +| Initial version | January 12, 2021 | + +# Vendor Registry + +| Vendor Name | Risk Level | Qualification Date | +| ----------- | ---------- | ------------------ | +| Innolitics | Moderate | TBD | +| | | | +| | | | +| | | | + diff --git a/rdm/init_files/organization_qms/quality_manual.md b/rdm/init_files/organization_qms/quality_manual.md new file mode 100644 index 0000000..4170bf0 --- /dev/null +++ b/rdm/init_files/organization_qms/quality_manual.md @@ -0,0 +1,300 @@ +--- +revision: 1 +title: Quality Manual +--- + +# Approvals + +All approvers shall add a signed commit with their name and roles appended to the table in this section. + +| Name | Role | Date | +| ---- | ------------------- | ---- | +| | Quality Systems SME | | + +# Training Record + +By signing below you have acknowledged you have read and understood this document. + +| Name | Role | Date | +| ---- | ---- | ---- | +| | | | + +# Purpose + +This document shall document the quality manual for {{ system.project_name }}. [[21.CFR.820.20.d, 21.CFR.820.186]] + +The quality manual shall contain: + +- the scope of of the quality management system and justification for exclusion or non-application +- documented standard operating procedures (SOPs) or references to them +- description of the interaction between SOPs or references to them + +An effective quality management system shall include the following principles: + +- An organizational structure that provides leadership, accountability, and governance with adequate resources to assure the safety, effectiveness, and performance of SaMD. +- A set of SaMD lifecycle support process that are scalable for the size of the organization and are applied consistently across all realization and use processes +- A set of realization and use processes that are scalable for the type of SaMD and the size of the organization; and that takes into account important elements requried for assuring the safety, effectivness, and performance of SaMD. + +# Leadership Structure + +[[IMDRF.SAMD.N23.2015:6.1, 21.CFR.820.20.a, 21.CFR.820.20.b ]] + +Organization shall appoint one or more individuals to be the quality systems SME to be responsible for the proper maintenance and execution of this QMS. + +# User Roles and Qualifications + +[[IMDRF.N23:6.2.1, 21.CFR.820.20.b.1, 21.CFR.820.20.b.2, 21.CFR.820.25.a, 21.CFR.820.25.b.1]] + +The following roles are necessary to carry out the requirements of the QMS. + +TODO: Review and edit user roles as necessary for your organization. + +- Lead software engineer + - Shall be well versed in translating software design to implementation + - Shall be responsible for developer mentorship + - Shall have all qualification of a software engineering SME + - Shall be responsible for executing verificaiton tests. Defects and errors that may be encountered as part of this task. [[21.CFR.820.25.b.2]] + - Improper performance of this role could lead to device defects by: + - Insufficient requirements gathering + - Insufficient code review + - Improper delegation +- Software engineering SME + - Shall have technical expertise sufficient to foresee sequences of events within the software that could lead to hazardous situations + - Shall have expertise necessary to evaluate technical practicability of a risk control measure. + - Shall be well versed in software engineering best practices necessary to create a conforming product. + - Shall be well versed in our software design and development process. + - Shall understand the clinical aspects of the use of the software. + - Improper performance of this role could lead to device defects by: + - Technical software development error + - Insufficient code review + - Not fully understanding requirements before implementing +- PHI compliance officer + - Shall understand applicable PHI compliance regulations including HIPAA. + - Improper performance of this role could lead to inadvertent PHI disclosure. +- Service engineer + - Shall be trained to conduct postmarket support activities including diagnosing field issues, communicating with customers, executing SOPs related to issue logging, investigation, and triaging. + - Shall be capable of troubleshooting postmarket issues. + - Shall be responsible for updating the service engineering manual. + - Improper performance of this role could lead to device defects by: + - Leaving a device in a defective state after a support session. + - Giving inappropriate advice or executing inappropriate service actions. +- Product manager + - Shall have clinical and industry expertise to bridge the gap between customers and company to create a product that fulfills customer's needs. + - Shall be well versed in requirements and user needs gathering. + - Shall be responsible for executing validation tests. Defects and errors that may be encountered as part of this task. [[21.CFR.820.25.b.2]] + - Improper performance of this role could lead to device defects by: + - Incorrectly specifying design inputs. + - Incorrect elucidation of user needs and / or requirements. +- Project manager + - Shall be capable of managing project deadlines, deliverables, product backlogs, sprint rituals. + - Shall interface with product management and engineering to ensure user needs and requirements are met. + - Shall manage cost, time, scope, and quality constraints. + - Improper performance of this role could lead to device defects by: + - Allowing quality to suffer by failing to balance on cost, time, and scope +- Customer liaison + - Shall be well versed in the users manual and intended use of the device + - Shall possess good communication skills necessary to interact with customers +- Medical SME + - Shall have sufficient medical expertise sufficient to foresee hazardous situations from the normal and abnormal use of the medical device in clinical use. +- Cybersecurity SME + - Shall be well versed in cybersecurity requirements as required by regulatory bodies. +- Risk analysis SME + - Shall understand our risk management process. + - Shall understand ISO 14971 and other applicable standards necessary to make ongoing changes to our risk management process. +- Quality systems SME + - Shall understand our risk management process. + - Shall understand ISO 13485 and other applicable standards necessary to make ongoing changes to our quality management system. + - Responsible for ensuring that quality system requirements are effectively established and effectively maintained in accordance with 21.CFR.820.20 [[21.CFR.820.20.b.3.i]] + - Responsible for Reporting on the performance of the quality system to management with executive responsibility for review. [[21.CFR.820.20.b.3.ii]] +- Regulatory SME + - Shall understand all applicable requirements for achieving regulatory clearance with all applicable regulatory bodies. +- Distributor + - Shall be capable of properly reselling the medical device per the intended use and cleared marketing claims. + - Shall be perform first line support. + +# Quality Objectives + +The following quality objectives must be met: + +- Reduce customer complaints +- Product defects as low as possible +- Customer feedback response as fast as possible +- Product releases have as few unresolved anomalies as possible +- Risk to patients minimized as low as reasonable +- CAPA shall be resolved in the shortest time as reasonable +- Periodic reviews as described in this quality manual shall be conduced on time +- Customer satisfaction shall be as high as possible +- Product requirements shall be met + +The quality objectives shall be reviewed periodically and updated as necessary through corrective action preventive action. + +Top management shall develop project specific plans that are customer focused. + + +# New SOP SOP + +The need to create a new SOP may arise from a variety of places including a CAPA, internal audit, product feedback, etc. + +Refer the New SOP SOP in the SOPs directory of the QMS repository. + +# SOP Change SOP + +Organization shall have a procedure for improving existing SOPs + +# SOP Removal SOP + +Organization shall have a procedure for retiring existing SOPs. + +# SaMD Lifecycle Support Process + +[[IMDRF.N23:7.0, IMDRF.N23:7.1]] + +For each product the organization shall have a SaMD product lifecycle process. This may be waterfall, agile, or a combination of the two. Required regulatory submissions usually means some degree of a waterfall process is required, however, the core development process may be more agile. + +The SaMD product realization, planning, and development process is outlined in the regulatory documentation manager. + +Refer to the new product SOP. + +# Risk Management + +[[IMDRF.N23:7.2]] + +Each product will have its own risk management process. Refer to each product's DHF for the risk management process used. + +# Document and Record Control + +[[IMDRF.N23:7.3, 21.CFR.820.180 ]] + +Records generated to demonstrate QMS conformity shall be appropriately identified, stored, protected, and retained for the lifetime of the company. + +The QMS shall provide mechanisms for: + +| IMDRF Requirement | QMS Implementation | +| ------------------------------------------------------------ | ------------------------------------------------------------ | +| Reviewing and approving documents before use. | Documents are reviewed and approved in a feature branch before merging into master thus preventing their use until reviewed and approved | +| Ensuring current versions of applicable documents are available at points of use to help prevent the use of obsolete documents | All users of the QMS must ensure they are on the `master` branch and run a `git pull` to ensure they have the latest version. Alternatively, if GitHub is used as the frontend, the view will always default to master and will be up to date. | +| Retaining obsolete documentation for an established period | Git will retain all history, including obsolete documentation, for an indefinite period of time. | +| Controlling documents against unauthorized or unintended changes | Signed commits in git prevents unauthorized changes. Unintended changes are unlikely because of the deliberate nature of performing git actions. | +| Maintaining and updating documents across all SaMD lifecycle process. | Each SOP will be periodically reviewed on a schedule based on the level of risk. | + +# Configuration Management and Control + +[[IMDRF.N23:7.4]] + +The QMS shall control configurable items, including source code, releases, documents, and software tools in order to maintain the integrity and traceability of the configuration throughout the SaMD lifecycle. + +| Item | Configuration Management Plan | +| -------------- | ------------------------------------------------------------ | +| Source code | Shall be stored in git version control. | +| Releases | Shall be archived in the respective device DHF. | +| Documents | Shall be stored in git version control and archived in DHF. | +| Software Tools | Shall be stored in git version control and archived in the device DHF. Refer to the tools inventory document for a list of approved tools and risk level. | + +# Measurement, Analysis, and Improvement Processes and Products + +[[IMDRF.N23:7.5]] + +## Required Activities + +Logging and tracking of complaints. + +Clearing technical issues + +Determining problem causes and actions to address them + +Track critical quality characteristics of products developed + +Analysis of customer complaints, problem reports, bug reports, nonconformity to requirements (defects), service reports, and trends of processes and products should be used to evaluate the quality of the SaMD and SaMD process. + +Corrective and preventive action SOP + +SaMD containment of nonconforming product. Our software design and development process does not allow nonconforming product to be released to customers. + +Organization shall keep a record of customer complaints. + +Organization shall, from time to time, shall request customer feedback reviews. + +# Manage Outsourced Processes, Activities, and Products + +[[IMDRF.N23:7.5]] + +Refer to new vendor SOP. + +# Manage Commercial-off-the-shelf (COTS) Products + +Refer to QMS tools validation SOP and product SOUP validation SOP. + +# Requirements Management + +[[IMDRF.N23:8.1]] + +Please refer to the software plan. + +# Design and Development + +[[IMDRF.N23:8.2, IMDRF.N23:8.3, 21.CFR.820.30.b, 21.CFR.820.30.c, 21.CFR.820.30.d, 21.CFR.820.30.e, 21.CFR.820.30.i, 21.CFR.820.60]] + +Refer to the software plan. + +# Verification and Validation + +[[IMDRF.N23:8.4, 21.CFR.820.30.a, 21.CFR.820.30.f, 21.CFR.820.30.g]] + +TODO: Reference product specific verification and validation plan. + +# Acceptance Activities + +[[21.CFR.820.80]] + +See software plan. + +TODO: Add phases of acceptance to software plan. Acceptance checkpoints shall include: Build acceptance tests, verificaiton tests pass, validation tests pass, release. + +# Deployment + +[[IMDRF.N23:8.5, 21.CFR.820.30.h, 21.CFR.820.70, 21.CFR.820.170]] + +TODO: Write SOPs on deploying new installations, training, configuration, for a new customer. Also detail procedures for distributing upgrades and maintenance releases. + +# Maintenance + +[[IMDRF.N23:8.6]] + +Maintenance activities originate from software lifecycle processes such as service monitoring, customer feedback, in-house testing, usability studies, cybersecurity findings, and socio-technological changes. Refer to the software plan. + +# Decommissioning + +[[IMDRF.N23:8.7]] + +Organization shall have an end of life plan for all products. This includes sunsetting older versions that are no longer supported. + +TODO: Implement decommissioning SOP + +# Labeling and UDI + +[[21.CFR.820.120]] + +TODO: expand on how we manage UDI including the FDA GUDID. + +# Conformance Exclusions + +| Name | Reason | +| --------------- | ------------------------------------------------------------ | +| 21.CFR.820.65 | Manufacturer does not manufacture devices intended to be surgicaly implanted. | +| 21.CFR.820.70 | Manufacturer only produces software as a medical device (SaMD) and therefore some considerations do not apply. Deviations from device specifications will not occur from the manufacturing process. | +| 21.CFR.820.70.2 | Deployment of software is unique from production of hardware in that the software can be perfectly replicated. Therefore, no additional monitoring and control of production process is necessary. | +| 21.CFR.820.70.c | Environmental conditions are not expected to have an adverse effect on product quality. | +| 21.CFR.820.70.d | Contact between personnel and product or environment is not expected to have an adverse effect on product quality. | +| 21.CFR.820.70.e | Contamination of equipment or product by substances is not expected to have an adverse effect on product quality. | +| 21.CFR.820.70.f | Building design is not expected to have an adverse effect on product quality, preventing mixups, and ensuring orderly handling of product. | +| 21.CFR.820.70.g | Equipment used in manufacturing process is not expected to have an adverse effect on product quality. | +| 21.CFR.820.70.h | Manufacturing material is not expected to have an adverse effect on product quality. | +| 21.CFR.820.72 | Manufacturer does not manufacture devices requiring procedures to ensure inspection, measurement, and testing equipment is routinely calibrated, inspected, checked, and maintained. | +| 21.CFR.820.86 | All artifacts stored in the "Design Outputs" directory of a product's DHF will be identically reproduced upon installation and therefore all product that is distributed, used, or installed will have passed the required acceptance activities. | +| 21.CFR.820.90 | All artifacts stored in the "Design Outputs" directory of a product's DHF will be identically reproduced upon installation and therefore all product will conform to specified requirements. Therefore, procedures to address the identification, documentation, evaluation, segregation, disposition, and rework of nonconforming product is not necessary. | +| 21.CFR.820.130 | Manufacturer does not ship any physical product. | +| 21.CFR.820.140 | Manufacturer does not handle physical product. | +| 21.CFR.820.150 | Manufacturer does not store physical product. | +| 21.CFR.820.160 | Software product does not have a shelf life that requries manufacturer to implement a procedure to ensure expired devices are not distributed. | +| 21.CFR.820.200 | Software product does not require periodic servicing. | +| 21.CFR.820.250 | All artifacts stored in the "Design Outputs" directory of a product's DHF will be identically reproduced upon installation and therefore all product will conform to specified requirements. Therefore, sampling of production lines are not necessary. | diff --git a/rdm/init_files/organization_qms/registry/device_history_record.md b/rdm/init_files/organization_qms/registry/device_history_record.md new file mode 100644 index 0000000..514efb4 --- /dev/null +++ b/rdm/init_files/organization_qms/registry/device_history_record.md @@ -0,0 +1,25 @@ +--- +revision: 1 +title: Device History Record +--- + +# Purpose + +This living document shall contain a listing of all products applicable under this QMS. [[21.CFR.820.184]] + +# Change History + +The change history section shall contain a brief summary of changes made in this revision. + +| Change Description | Date | +| ------------------ | ---------------- | +| Initial version | January 20, 2021 | + +# Product Registry + +| Product Name | Phase | Release Date | Quantity Installed | UDI | +| --------------- | --------- | ------------ | ------------------ | ---- | +| Windows XP v1.0 | Retired | | | | +| Windows 7 v1.0 | Deployed | | | | +| Windows 11 v1.1 | Inception | | | | + diff --git a/rdm/init_files/organization_qms/registry/personnel.md b/rdm/init_files/organization_qms/registry/personnel.md new file mode 100644 index 0000000..390c715 --- /dev/null +++ b/rdm/init_files/organization_qms/registry/personnel.md @@ -0,0 +1,25 @@ +--- +revision: 1 +title: Personnel Registry +--- + +# Purpose + +This living document shall contain a listing of all personnel associated with implementationa and execution of the QMS. + +# Change History + +The change history section shall contain a brief summary of changes made in this revision. + +| Change Description | Date | +| ------------------ | ---------------- | +| Initial version | January 20, 2021 | + +# Personnel Registry + +| Name | Email | Roles | +| ---- | ----- | ---------------------- | +| | | Quality Systems SME | +| | | Medical SME | +| | | Product Management SME | + diff --git a/rdm/init_files/organization_qms/registry/tools.md b/rdm/init_files/organization_qms/registry/tools.md new file mode 100644 index 0000000..8bdf3c0 --- /dev/null +++ b/rdm/init_files/organization_qms/registry/tools.md @@ -0,0 +1,26 @@ +--- +revision: 1 +title: Tools Registry +--- + +# Purpose + +This document shall keep track of all external vendors and their responsibilities. + +# Change History + +The change history section shall contain a brief summary of changes made in this revision. + +| Change Description | Date | +| ------------------ | ---------------- | +| Initial version | January 12, 2021 | + +# Vendor Registry + +| Tool Name | Risk Level | Validation Date | +| -------------------------------- | ---------- | --------------- | +| GitHub | Moderate | TBD | +| Regulatory Documentation Manager | Moderate | TBD | +| | | | +| | | | + diff --git a/rdm/init_files/organization_qms/registry/vendors.md b/rdm/init_files/organization_qms/registry/vendors.md new file mode 100644 index 0000000..77dded7 --- /dev/null +++ b/rdm/init_files/organization_qms/registry/vendors.md @@ -0,0 +1,26 @@ +--- +revision: 1 +title: Vendors Registry +--- + +# Purpose + +This document shall keep track of all external vendors and their responsibilities. + +# Change History + +The change history section shall contain a brief summary of changes made in this revision. + +| Change Description | Date | +| ------------------ | ---------------- | +| Initial version | January 12, 2021 | + +# Vendor Registry + +| Vendor Name | Risk Level | Qualification Date | +| ----------- | ---------- | ------------------ | +| Innolitics | Moderate | TBD | +| Resellers | Moderate | TBD | +| | | | +| | | | + diff --git a/rdm/init_files/organization_qms/templates/capa_record.md b/rdm/init_files/organization_qms/templates/capa_record.md new file mode 100644 index 0000000..0e1959e --- /dev/null +++ b/rdm/init_files/organization_qms/templates/capa_record.md @@ -0,0 +1,43 @@ +--- +revision: 1 +title: CAPA Template +--- + +# Approvals + +All approvers shall add a signed commit with their name and roles appended to the table in this section. + +This approval indicates all authors certify the contents of the record for accuracy and conformance to the SOP. All personnel that need to be notified of changes as part of this CAPA shall be on the approvers list [[21.CFR.820.100.a.6, 21.CFR.820.100.a.7]]. + +| Name | Role | Date | +|---|---|---| +| | | | +| | | | +| | || + +# Purpose + +This record is capturing the disposition and resolution of a CAPA [[21.CFR.820.100.b]]. + +# CAPA Inputs + +- What was the inciting event(s) that lead to the creation of this CAPA? +- What are the relevant SOPs, quality metrics, or complaints related to this CAPA? [[21.CFR.820.100.a.1]] +- What is the root cause of the nonconformity? [[21.CFR.820.100.a.2]] + +# CAPA Effectiveness Measurement + +Identify some metrics to track the effectiveness of the CAPA. For example, if an increase in customer complaints per week lead to the creation of the CAPA, tracking the same metric is an effective measurement strategy. + +The level of measurement burden shall be related to the risk or harm imposed by this CAPA. A CAPA correcting for a patient death, for example, shall have more oversight than a CAPA correcting for an error in a regulatory submission. + +# Action Plan + +Record a high level summary of action items as a result of this CAPA here. [[21.CFR.820.100.a.3]] + +# Action Verification + +Verify each CAPA action is effectie and does not adversely affect the finished device. [[21.CFR.820.100.a.4]] + +Verify each action is properly implemented. [[21.CFR.820.100.a.5]] + diff --git a/rdm/init_files/organization_qms/templates/external_audit.md b/rdm/init_files/organization_qms/templates/external_audit.md new file mode 100644 index 0000000..18d7703 --- /dev/null +++ b/rdm/init_files/organization_qms/templates/external_audit.md @@ -0,0 +1,28 @@ +--- +revision: 1 +title: External Audit Record Template +--- + +# Approvals + +All approvers shall add a signed commit with their name and roles appended to the table in this section. + +This approval indicates all authors certify the contents of the record for accuracy and conformance to the SOP. + +| Name | Role | Date | +|---|---|---| +| | | | +| | | | +| | || + +# Purpose + +This record shall capture the output of an external audit. + +# Findings + +| Description | Resolution | +| ------------------------------------------------------------ | --------------------- | +| Example: Privacy section needs to be updated to be compliant with European GDPR standards. | CAPA #1 opened | +| Example: Recent updates to ISO 13485 adds additional requirements to this SOP. | SOP has been updated. | + diff --git a/rdm/init_files/organization_qms/templates/internal_audit.md b/rdm/init_files/organization_qms/templates/internal_audit.md new file mode 100644 index 0000000..6daa902 --- /dev/null +++ b/rdm/init_files/organization_qms/templates/internal_audit.md @@ -0,0 +1,40 @@ +--- +revision: 1 +title: Internal Audit Record +--- +# Approvals + +All approvers shall add a signed commit with their name and roles appended to the table in this section. + +This approval indicates all authors certify the contents of the record for accuracy and conformance to the SOP. + +| Name | Role | Date | +|---|---|---| +| | | | +| | | | +| | || + +# Purpose + +This record captures an internal audit of SOPs. [[21.CFR.820.75]] + +# SOPs Under Review + +List out all SOPs that are being reviewed during this internal audit. + +# Considerations + +- Are there any new regulations or standards that need to be incorporated in the SOP? +- Was there any customer or internal feedback that could improve this SOP? +- Were there any findings from recent internal or external audits that need to be addressed in this SOP? +- Are there any outstanding actions from CAPAs that need to be implemented? +- Are there sufficient resources necessary to execute this SOP? +- Are there any followup actions that were not completed from the previous SOP review? + +# Findings + +| Description | Resolution | +| ------------------------------------------------------------ | --------------------- | +| Example: Privacy section needs to be updated to be compliant with European GDPR standards. | CAPA #1 opened | +| Example: Recent updates to ISO 13485 adds additional requirements to this SOP. | SOP has been updated. | + diff --git a/rdm/init_files/organization_qms/templates/new_record_template.md b/rdm/init_files/organization_qms/templates/new_record_template.md new file mode 100644 index 0000000..ee08505 --- /dev/null +++ b/rdm/init_files/organization_qms/templates/new_record_template.md @@ -0,0 +1,24 @@ +--- +revision: 1 +title: New SOP Template Template +--- + +# Approvals + +All approvers shall add a signed commit with their name and roles appended to the table in this section. + +This approval indicates all authors certify the contents of the record for accuracy and conformance to the SOP. + +| Name | Role | Date | +|---|---|---| +| | | | +| | | | +| | || + +# Purpose + +Author shall clearly identify what this record is capturing. + +# Content + +Author(s) shall insert the content of this record here. diff --git a/rdm/init_files/organization_qms/templates/new_sop.md b/rdm/init_files/organization_qms/templates/new_sop.md new file mode 100644 index 0000000..3450176 --- /dev/null +++ b/rdm/init_files/organization_qms/templates/new_sop.md @@ -0,0 +1,89 @@ +--- +revision: 1 +title: New SOP Template +--- + +# Approvals + +All approvers shall add a signed commit with their name and roles appended to the table in this section. + +| Name | Role | Date | +|---|---|---| +| | | | +| | | | +| | || + +# Training Record + +| Name | Role | Date | +| ---- | ---- | ---- | +| | | | + +# Purpose + +Author shall clearly identify the purpose of this SOP. What does this SOP do? When should this SOP be invoked? + +# Triggers + +Under what conditions should this SOP be executed? + +# Change History + +The change history section shall contain a brief summary of changes made in this revision. + +| Change Description | Date | +| ------------------ | ---------------- | +| Initial version | January 12, 2021 | + +# Required Roles to Execute + +The following user roles are required to execute this SOP: + +- Example user role + +# Required Roles to Review + +The following user roles are required for initial approval, periodic review, and change approval of this SOP: + +- Example user role + +# Required Inputs and Dependencies + +The following inputs are required for the execution of this SOP: + +- Example input: All code review records from the code review SOP for the last year. + +# Outputs + +The SOP shall produce the following outputs: + +- Example output: A record to capture a review was performed on an SOP. + +# Risk Level + +Author shall conduct a risk analysis to identify the risk level of this SOP. What is the risk of patient harm if there is an error in the execution of this SOP or an error/omission in the SOP itself? + +There are three levels of SOP risk: + +Low: Error in SOP or SOP execution is unlikely to result in patient harm. +Medium: Error in SOP or SOP execution is moderately likely in patient harm. +High: Error in SOP or SOP execution is likely to result in patient harm. + +# Periodic Review + +Author shall insert the review periodicity depending on the risk level. For reference: + +Low: Review once a year. +Medium: Review once a year. +High: Review every six months. + +# Record Template + +Author shall reference or include the template used to create a record capturing the SOP execution. + +# Work Instruction + +A step by step recipe for executing the SOP. + +1. Example Step 1 +2. Example Step 2 diff --git a/rdm/init_files/organization_qms/templates/new_tool_validation.md b/rdm/init_files/organization_qms/templates/new_tool_validation.md new file mode 100644 index 0000000..5315bee --- /dev/null +++ b/rdm/init_files/organization_qms/templates/new_tool_validation.md @@ -0,0 +1,73 @@ +--- +revision: 1 +title: Requirements Based Tool Validation Record Template +--- + +# Approvals + +All approvers shall add a signed commit with their name and roles appended to the table in this section. + +This approval indicates all authors certify the contents of the record for accuracy and conformance to the SOP. + +| Name | Role | Date | +|---|---|---| +| | | | +| | | | +| | || + +# Purpose + +This record shall capture the tool validation activity for {{Tool Name and version number}} was performed. + +For moderate risk tools either confidence based or requirements based validation is required. + +For high risk tools, requirements based validation is required. + +# Confidence Based Validation + +In a few sentences, identify the reasons we feel this tool is safe to use for our QMS. Here is an example analysis: + +Example 1: +GitHub is used by millions of software engineers worldwide and our usage of the tool does not appreciably differ from +the standard use case. Therefore, we have high confidence that any defects in the tool will impact many people and will be resolved quickly. + + +# Requirements Based Validation + +Optional for moderate risk tools. Required for high risk tools. + +# Requirements + +List out requirements the tool must fulfill. + +Example: + +- R1: Tool shall be capable of editing text files. +- R2: Tool shall be capable of saving text files. + +# Test Script + +For each of the requirements listed above, devise a series of testing steps to prove the tool meets the requirement. Also +specify which requirements each test is validating. + +Example: + +- Test 1: R1 and R2 + 1. Open a text file in the tool. + 1. Make an edit to the text file. + 1. Save the text file. + 1. Open the text file again in the tool. + 1. Assert the change is preserved + +# Test Execution: + +For each test script, record all steps were executed successfully. + +Example: + +| Test Name | Result +---|--- +Test 1 | Pass +Test 2 | Pass +Test 3 | Pass + diff --git a/rdm/init_files/organization_qms/templates/new_vendor.md b/rdm/init_files/organization_qms/templates/new_vendor.md new file mode 100644 index 0000000..73b3d9d --- /dev/null +++ b/rdm/init_files/organization_qms/templates/new_vendor.md @@ -0,0 +1,39 @@ +--- +revision: 1 +title: New Vendor Record Template +--- + +# Approvals + +All approvers shall add a signed commit with their name and roles appended to the table in this section. + +This approval indicates all authors certify the contents of the record for accuracy and conformance to the SOP. + +| Name | Role | Date | +|---|---|---| +| | | | +| | | | +| | || + +# Purpose + +This record captures the qualification of a vendor + +# Vendor Requirements and Qualifications + +The list below outlines requirements the organization has for the vendor and justification for why the organization feels the requirements are met. + +For example: + +Requirement | Qualification +---|--- +Vendor shall be capable of submitting regulatory approval for the US FDA. | Vendor has precedent for producing a successful 510(k) approval. +Vendor shall be capable of carry out our 62304 software development plan | Vendor has read and agreed to abide by our software development plan. + +# Deliverable Review Plan + +Outline a plan for how you intend to review the vendor deliverables, frequency of intermediate inspections, and other relevant audits of the vendor. + +For example: + +- Vendor inspection shall comprise of bi-weekly standups with organization. Organization shall verify vendor is fulfilling services or product by validation of demonstration software deployments. Organization and vendor shall ensure these demonstration deployments are not accidentally deployed into production. diff --git a/rdm/init_files/organization_qms/templates/quality_metrics_record.md b/rdm/init_files/organization_qms/templates/quality_metrics_record.md new file mode 100644 index 0000000..e22ef80 --- /dev/null +++ b/rdm/init_files/organization_qms/templates/quality_metrics_record.md @@ -0,0 +1,32 @@ +--- +revision: 1 +title: Quality Metrics Record Template +--- + +# Approvals + +All approvers shall add a signed commit with their name and roles appended to the table in this section. + +This approval indicates all authors certify the contents of the record for accuracy and conformance to the SOP. + +| Name | Role | Date | +|---|---|---| +| | | | +| | | | +| | || + +# Purpose + +This record captures the value of quality metrics at a certian point in time. + +# Quality Metrics + +Record the all of the values of the quality metrics listed in the quality manual. + +# Actions + +| Finding | Resolution | +| ----------------------------------- | ------------------------------------------------------------ | +| Customer complaints have increased. | Add more validation test cases to reduce the liklihood of regressions. | +| | | + diff --git a/rdm/init_files/organization_qms/templates/remove_sop.md b/rdm/init_files/organization_qms/templates/remove_sop.md new file mode 100644 index 0000000..c0e4a1f --- /dev/null +++ b/rdm/init_files/organization_qms/templates/remove_sop.md @@ -0,0 +1,36 @@ +--- +revision: 1 +title: SOP Removal Record Template +--- + +# Approvals + +All approvers shall add a signed commit with their name and roles appended to the table in this section. + +This approval indicates all authors certify the contents of the record for accuracy and conformance to the SOP. + +| Name | Role | Date | +| ---- | ---- | ---- | +| | | | +| | | | +| | | | + +# Purpose + +This record shall capture the removal of an SOP and the motivations for the removal. + +## Why was this SOP removed? + +Author to provide description of why this SOP was removed. + +## Are there any other SOPs affected by the removal + +Author to determine what processes are currently using the SOP and identify issues caused by its removal. + +## Are there any products that are affected by the removal? + +Author to determine what products could be affected by removal of the SOP. + +## Are there any additional patient safety risks introduced by the removal of this SOP? + +Reviewers diff --git a/rdm/init_files/.gitignore b/rdm/init_files/product_qms/.gitignore similarity index 100% rename from rdm/init_files/.gitignore rename to rdm/init_files/product_qms/.gitignore diff --git a/rdm/init_files/documents/510k.md b/rdm/init_files/product_qms/510k.md similarity index 100% rename from rdm/init_files/documents/510k.md rename to rdm/init_files/product_qms/510k.md diff --git a/rdm/init_files/Makefile b/rdm/init_files/product_qms/Makefile similarity index 100% rename from rdm/init_files/Makefile rename to rdm/init_files/product_qms/Makefile diff --git a/rdm/init_files/documents/architecture_design_chart.md b/rdm/init_files/product_qms/architecture_design_chart.md similarity index 100% rename from rdm/init_files/documents/architecture_design_chart.md rename to rdm/init_files/product_qms/architecture_design_chart.md diff --git a/rdm/init_files/config.yml b/rdm/init_files/product_qms/config.yml similarity index 100% rename from rdm/init_files/config.yml rename to rdm/init_files/product_qms/config.yml diff --git a/rdm/init_files/documents/cyber_security.md b/rdm/init_files/product_qms/cyber_security.md similarity index 100% rename from rdm/init_files/documents/cyber_security.md rename to rdm/init_files/product_qms/cyber_security.md diff --git a/rdm/init_files/data/history.yml b/rdm/init_files/product_qms/data/history.yml similarity index 100% rename from rdm/init_files/data/history.yml rename to rdm/init_files/product_qms/data/history.yml diff --git a/rdm/init_files/data/integration_test_record.yml b/rdm/init_files/product_qms/data/integration_test_record.yml similarity index 100% rename from rdm/init_files/data/integration_test_record.yml rename to rdm/init_files/product_qms/data/integration_test_record.yml diff --git a/rdm/init_files/data/manual_tests.yml b/rdm/init_files/product_qms/data/manual_tests.yml similarity index 100% rename from rdm/init_files/data/manual_tests.yml rename to rdm/init_files/product_qms/data/manual_tests.yml diff --git a/rdm/init_files/data/requirements.yml b/rdm/init_files/product_qms/data/requirements.yml similarity index 100% rename from rdm/init_files/data/requirements.yml rename to rdm/init_files/product_qms/data/requirements.yml diff --git a/rdm/init_files/data/risk.yml b/rdm/init_files/product_qms/data/risk.yml similarity index 100% rename from rdm/init_files/data/risk.yml rename to rdm/init_files/product_qms/data/risk.yml diff --git a/rdm/init_files/data/soup.yml b/rdm/init_files/product_qms/data/soup.yml similarity index 100% rename from rdm/init_files/data/soup.yml rename to rdm/init_files/product_qms/data/soup.yml diff --git a/rdm/init_files/data/system.yml b/rdm/init_files/product_qms/data/system.yml similarity index 100% rename from rdm/init_files/data/system.yml rename to rdm/init_files/product_qms/data/system.yml diff --git a/rdm/init_files/data/unit_test_record.yml b/rdm/init_files/product_qms/data/unit_test_record.yml similarity index 100% rename from rdm/init_files/data/unit_test_record.yml rename to rdm/init_files/product_qms/data/unit_test_record.yml diff --git a/rdm/init_files/data/versions.yml b/rdm/init_files/product_qms/data/versions.yml similarity index 100% rename from rdm/init_files/data/versions.yml rename to rdm/init_files/product_qms/data/versions.yml diff --git a/rdm/init_files/images/lifecycle-processes.svg b/rdm/init_files/product_qms/images/lifecycle-processes.svg similarity index 100% rename from rdm/init_files/images/lifecycle-processes.svg rename to rdm/init_files/product_qms/images/lifecycle-processes.svg diff --git a/rdm/init_files/images/uimockups/example-ui-mockup-001.png b/rdm/init_files/product_qms/images/uimockups/example-ui-mockup-001.png similarity index 100% rename from rdm/init_files/images/uimockups/example-ui-mockup-001.png rename to rdm/init_files/product_qms/images/uimockups/example-ui-mockup-001.png diff --git a/rdm/init_files/images/uimockups/example-ui-mockup-002.svg b/rdm/init_files/product_qms/images/uimockups/example-ui-mockup-002.svg similarity index 100% rename from rdm/init_files/images/uimockups/example-ui-mockup-002.svg rename to rdm/init_files/product_qms/images/uimockups/example-ui-mockup-002.svg diff --git a/rdm/init_files/images/uimockups/example-ui-mockup-003.jpg b/rdm/init_files/product_qms/images/uimockups/example-ui-mockup-003.jpg similarity index 100% rename from rdm/init_files/images/uimockups/example-ui-mockup-003.jpg rename to rdm/init_files/product_qms/images/uimockups/example-ui-mockup-003.jpg diff --git a/rdm/init_files/documents/known_anomalies.md b/rdm/init_files/product_qms/known_anomalies.md similarity index 100% rename from rdm/init_files/documents/known_anomalies.md rename to rdm/init_files/product_qms/known_anomalies.md diff --git a/rdm/init_files/documents/level_of_concern.md b/rdm/init_files/product_qms/level_of_concern.md similarity index 100% rename from rdm/init_files/documents/level_of_concern.md rename to rdm/init_files/product_qms/level_of_concern.md diff --git a/rdm/init_files/documents/release_history.md b/rdm/init_files/product_qms/release_history.md similarity index 100% rename from rdm/init_files/documents/release_history.md rename to rdm/init_files/product_qms/release_history.md diff --git a/rdm/init_files/documents/release_record.md b/rdm/init_files/product_qms/release_record.md similarity index 100% rename from rdm/init_files/documents/release_record.md rename to rdm/init_files/product_qms/release_record.md diff --git a/rdm/init_files/product_qms/risk_management_process.assets/Clinical Management Schematic.svg b/rdm/init_files/product_qms/risk_management_process.assets/Clinical Management Schematic.svg new file mode 100644 index 0000000..158c78b --- /dev/null +++ b/rdm/init_files/product_qms/risk_management_process.assets/Clinical Management Schematic.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/rdm/init_files/product_qms/risk_management_process.assets/JH-5MXSy57IsZj5O68pEKfF9EjEzmnFT2MlUS8jJFfxj962gJpT_ET3Mzul62WeY4xrZuPqxJ1QYZFbze5Yj4Lpo70XUwCb9fSqX9MrURLhd8sGdxCiOecs1bratDtw-S9NWHEv9.png b/rdm/init_files/product_qms/risk_management_process.assets/JH-5MXSy57IsZj5O68pEKfF9EjEzmnFT2MlUS8jJFfxj962gJpT_ET3Mzul62WeY4xrZuPqxJ1QYZFbze5Yj4Lpo70XUwCb9fSqX9MrURLhd8sGdxCiOecs1bratDtw-S9NWHEv9.png new file mode 100644 index 0000000..b536e50 Binary files /dev/null and b/rdm/init_files/product_qms/risk_management_process.assets/JH-5MXSy57IsZj5O68pEKfF9EjEzmnFT2MlUS8jJFfxj962gJpT_ET3Mzul62WeY4xrZuPqxJ1QYZFbze5Yj4Lpo70XUwCb9fSqX9MrURLhd8sGdxCiOecs1bratDtw-S9NWHEv9.png differ diff --git a/rdm/init_files/product_qms/risk_management_process.assets/Modular hazards and harm analysis schematic.svg b/rdm/init_files/product_qms/risk_management_process.assets/Modular hazards and harm analysis schematic.svg new file mode 100644 index 0000000..58e5901 --- /dev/null +++ b/rdm/init_files/product_qms/risk_management_process.assets/Modular hazards and harm analysis schematic.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/rdm/init_files/product_qms/risk_management_process.assets/Risk Management Process Template-1674944.svg b/rdm/init_files/product_qms/risk_management_process.assets/Risk Management Process Template-1674944.svg new file mode 100644 index 0000000..158c78b --- /dev/null +++ b/rdm/init_files/product_qms/risk_management_process.assets/Risk Management Process Template-1674944.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/rdm/init_files/product_qms/risk_management_process.assets/Risk Management Process Template.png b/rdm/init_files/product_qms/risk_management_process.assets/Risk Management Process Template.png new file mode 100644 index 0000000..5523a65 Binary files /dev/null and b/rdm/init_files/product_qms/risk_management_process.assets/Risk Management Process Template.png differ diff --git a/rdm/init_files/product_qms/risk_management_process.assets/Risk Management Process Template.svg b/rdm/init_files/product_qms/risk_management_process.assets/Risk Management Process Template.svg new file mode 100644 index 0000000..158c78b --- /dev/null +++ b/rdm/init_files/product_qms/risk_management_process.assets/Risk Management Process Template.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/rdm/init_files/product_qms/risk_management_process.assets/hMBua-440SFfRkm1JA8qzk7pM9DfK-1AybIlknM6eGc8lchILz0sSxqG-M0gUTO3-FpvE4wdgIyewhkm0j5j8vCFXOzcse9Q-KjWe_CihE6HW3KpeODYc3vkmIraSN82FA9yaMSG.png b/rdm/init_files/product_qms/risk_management_process.assets/hMBua-440SFfRkm1JA8qzk7pM9DfK-1AybIlknM6eGc8lchILz0sSxqG-M0gUTO3-FpvE4wdgIyewhkm0j5j8vCFXOzcse9Q-KjWe_CihE6HW3KpeODYc3vkmIraSN82FA9yaMSG.png new file mode 100644 index 0000000..a8e32fd Binary files /dev/null and b/rdm/init_files/product_qms/risk_management_process.assets/hMBua-440SFfRkm1JA8qzk7pM9DfK-1AybIlknM6eGc8lchILz0sSxqG-M0gUTO3-FpvE4wdgIyewhkm0j5j8vCFXOzcse9Q-KjWe_CihE6HW3KpeODYc3vkmIraSN82FA9yaMSG.png differ diff --git a/rdm/init_files/product_qms/risk_management_process.assets/o5-nYyfRBU4z631Uu58KqWoUKAPvz6bdxV8dU___3MGjTwlkTe75cCJjoCSH0aSZDgDTOV77FkbatBZvNLNgVcaby7yLfVWqIC6qVoyyQZtXOoD5KyDbl_a0MjeIZ_wePWnKdyAY.png b/rdm/init_files/product_qms/risk_management_process.assets/o5-nYyfRBU4z631Uu58KqWoUKAPvz6bdxV8dU___3MGjTwlkTe75cCJjoCSH0aSZDgDTOV77FkbatBZvNLNgVcaby7yLfVWqIC6qVoyyQZtXOoD5KyDbl_a0MjeIZ_wePWnKdyAY.png new file mode 100644 index 0000000..3e40af5 Binary files /dev/null and b/rdm/init_files/product_qms/risk_management_process.assets/o5-nYyfRBU4z631Uu58KqWoUKAPvz6bdxV8dU___3MGjTwlkTe75cCJjoCSH0aSZDgDTOV77FkbatBZvNLNgVcaby7yLfVWqIC6qVoyyQZtXOoD5KyDbl_a0MjeIZ_wePWnKdyAY.png differ diff --git a/rdm/init_files/product_qms/risk_management_process.md b/rdm/init_files/product_qms/risk_management_process.md new file mode 100644 index 0000000..245e580 --- /dev/null +++ b/rdm/init_files/product_qms/risk_management_process.md @@ -0,0 +1,504 @@ +--- +id: RMP-001 +revision: 1 +title: Risk Management Process +--- + +# Risk Management Process + +## Definitions and Acronyms + +An SME is a subject matter expert. + + + +An RCM is a risk control measure. + + + +A harm is a physical injury or damage to the health of people, or damage to the property or the environment. + + + +A hazard is a potential source of harm. + + + +A hazardous situation is a circumstance in which people, property, or the environment are exposed to one or more hazards. + + + +An intended use is the use for which the product, process or service is intended according to the specifications, instructions and information provided by the manufacturer. + + + +Post production refers to the life cycle of the product after the design has been completed and the medical device has been manufactured. + + + +A procedure is a specific way to carry out an activity or process. + + + +A process is a set of interrelated or interacting activities which transforms inputs into outputs. + + + +A record is a document stating results achieved or providing evidence of activities performed. + + + +Residual risk is the risk remaining after risk control measures have been taken. + + + +A risk is a combination of the probability of occurrence of harm and the severity of that harm. + + + +Risk analysis is the systematic use of available information to identify hazards and to estimate the risk. + + + +Risk assessment is the overall process comprising a risk analysis and risk evaluation. + + + +Risk control is a process in which decisions are made and measures implemented by which risk are reduced to, or maintained within, specified levels. + + + +Risk estimation is a process used to assign values to the probability of occurrence of harm and the severity of that harm. + + + +Risk management refers to the systematic application of management policies, procedures and practices to the tasks of analysing, evaluating, controlling, and monitoring risks + +Risk management process (this document) documents the processes for identifying hazards, estimating and evaluating the associated risks, controlling these risks, and monitoring the effectiveness of the controls. This is the “what” needs to be done for risk management. + + + +The Risk management plan shall outline who and when components of the risk management process shall be performed. This is the “who” and “when” of risk management. + + + +Risk management file is a set of records and other documents that are produced by the risk management process. + + + +Safety is the freedom from unacceptable risk. + + + +Severity is the measure of the possible consequences of a hazard. + + + +A use error is an act or omission of an act that results in a different medical device response than intended by the manufacturer or expected by the user. + + + +Verification is the confirmation, through the provision of objective evidence, that specified requirements have been fulfilled. + + + +Practicability refers to the ability of a manufacturer to reduce the risk. + + + +Technical practicality refers to the ability to reduce the risk regardless of cost. + + + +Economic practicality refers to the ability to reduce the risk without making the medical device an unsound economic proposition. + + + +A benefit, in the purview of a risk/benefit analysis, is related to the likelihood and extent of improvement of health expected from the use of the device. + + + +The term “Software as a Medical Device” (SaMD) is defined as software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device. + + + +A serious injury is an injury or illness that: + +i. is life threatening; + +ii. results in permanent impairment of a body function or permanent damage to a body structure; or + +iii. necessitates medical or surgical intervention to preclude permanent impairment of a body function or permanent damage to a body structure. + + + +A formative process is one conducted iteratively during the design and development of the medical device. + + + +A summative process is one that is conducted during specific checkpoints, typically a release, during the design and development of the medical device. A summative process is akin to a final exam whereas a formative process is more like a pop quiz. + +## Introduction + +This risk management plan outlines the established plan for an ongoing process for identifying hazards associated with our medical device, evaluating the associated risks, controlling these risks, and monitoring the effectiveness of the risk control measures. + +## Personnel Qualification + +Risk management is a multidisciplinary process that must involve specialists from multiple fields. The personnel roles and qualifications are listed below: + +| Role | Description | +| ---------------------- | ------------------------------------------------------------ | +| Medical SME | An individual with medical expertise sufficient to foresee hazardous situations from the normal and abnormal use of the medical device in clinical use. | +| Engineering SME | An individual with technical expertise sufficient to foresee sequences of events within the software that could lead to hazardous situations. This role includes a working knowledge of cybersecurity. This role is necessary to evaluate technical practicability. | +| Product Management SME | An individual that can bridge the gap between user needs, engineering, timeline, and budget. This individual is necessary to evaluate economic practicability. | +| Product Support SME | An individual experienced in supporting the product in the field sufficient to foresee sequences of events that could lead to hazardous situations related to the install, use, and logistical aspects of the medical device. | +| Risk Management SME | An individual experienced in the ISO 14971, 62366, 62304, and 80002 standards sufficient to guide the risk management activity. | + + + +## Risk Evaluation Matrix + +Risk quantification shall use the qualitative risk matrix as shown below. + +| | Negligible | Moderate | Severe | +| -------- | ---------- | -------- | ------ | +| Frequent | Medium | Medium | High | +| Possible | Low | Low | Medium | +| Remote | Low | Low | Low | + +Table 1: Risk evaluation matrix + + + +Risk levels are defined: + +| Risk Level | Risk Acceptability | +| ---------- | -------------------------------------------- | +| Low | Acceptable risk | +| Medium | Acceptable only with risk / benefit analysis | +| High | Unacceptable risk | + + + +Severity levels are defined as the following: + +| Severity Level | Description | +| -------------------- | --------------------------------------------- | +| Significant Severity | Death or loss of function | +| Moderate Severity | Reversible or minor injury | +| Negligible Severity | Will not cause injury or only slightly injure | + + + +Probability levels are defined as the following: + +| Probability level | Description | +| ----------------- | --------------------------------- | +| Frequent | Likely to happen, frequent, often | +| Possible | Can happen, but not frequent | +| Remote | Unlikely to happen, rare, remote | + + + +## Process Based Risk Control Measures + +Risk reduction may be achieved by specific risk control measures to mitigate individual risks. Additionally, the manufacturer’s processes, including this document, are also risk control measures. The following risk control measures are process based and lower the overall risk profile of the entire device: + +1. 62304 compliant software design and development plan with 14971 compliant iterative risk analysis built in. Additional risks may be introduced in the post market phase and the software design and development plan must minimise the chance these risks go undetected. + +2. 14971 compliant risk management plan (this document) + +3. Formative risk management activity performed during: + +4. 1. Change request code review + 2. Change request creation + +5. Summative risk analysis activity performed at the end of a product release cycle. + + + +## Risk Management Activity + +The risk management process is intended to be executed iteratively during the product development cycle (formative risk analysis) and holistically at the end of a product development cycle before a new version of the device is released (summative risk analysis.) The term “relevant” is used extensively and has a different meaning for formative vs summative activities. Relevant items in a formative activity refers to software units pertinent to a change request. Relevant items in a summative activity refers to the entire device. The following are the steps involved in the risk management activity: + +1. Intended use and identification of characteristics related to the safety of the medical device. + +2. 1. Use Annex C of ISO 14971:2007(E) + 2. Review any recommendations from Annex C of 14971 + +3. Document any foreseeable misuse. + +4. Identify hazards and hazardous situations + +```mermaid +graph LR + Hazard --P1--> Upstream[Upstream Events] --P2--> B[Functioning Software] --P3--> C[Downstream Events] --P4--> D[Patient Harm]; + Upstream --P2--> S[Software Anomaly] --P3=1--> C; + +``` + +Figure 1. Diagram depicting upstream and downstream events leading to harm. + + + +1. A combination of top down and bottom up approach shall be used. The procedure shall be iterative until no further hazards or foreseeable sequences of events can be identified. + +2. Bottom up approach: + +3. 1. Systematically iterate through relevant software units and record normal use and fault conditions that could lead to hazardous situations. + + 2. Iterate through relevant SOUP items and record normal and fault conditions that could lead to hazardous situations. + + 3. (Summative only) Take a look at reported adverse events related to the device product code that lead to patient injury or death since the last risk review. + + 4. 1. A useful database of these reports are here: https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfMAUDE/search.CFM + +4. Top down approach + +5. 1. Identify relevant hazards that could lead to patient harm arising from the normal use or fault condition of the medical device. + 2. Identify relevant foreseeable sequences of events that could lead to hazardous situations. + 3. Identify relevant risk control measures that would be worthwhile to implement even before risk evaluation. These identified risk control measures may later be deemed unnecessary, as such is the case if a pre mitigation risk rating is low, however, they may be desirable usability improvements worth implementing anyway. More importantly, identifying risk control measures is often a good springboard for identifying hazardous situations. Use these identified risk control measures to iteratively identify new hazards and hazardous situations. + +1. Estimate risk + +2. 1. For each relevant hazardous situation, assign a probability and severity rating in accordance to the risk evaluation matrix. Note that a hazardous situation will have multiple events, each with their own probability. Events related to software failure are assumed to have a probability of 1. Events related to usability --usually downstream to the device-- such as the probability that misinformation can lead to inappropriate medical decision making, requires the insight of a medical SME. Events related to the software environment -- usually upstream to the device-- requires the insight of an engineering and product support SME. + +3. Risk evaluation + +4. 1. Identify the relevant risks requiring mitigation using the risk evaluation matrix and risk acceptability threshold. + +5. Risk control + +6. 1. For all relevant risks requiring mitigation, perform the following: + + 2. 1. Brainstorm risk reduction techniques in the following order of precedence from most preferred to least: + + 2. 1. Inherent safety by design + + 2. 1. Eliminates the probability of the risk. + + 3. Protective measures + + 4. 1. Reduces the probability of the risk. + + 5. Information for safety + + 6. 1. Marginally reduces the probability of the risk. + + 3. All members of the risk analysis team are required to identify risk control measures that satisfy both economic and technical practicability. This step shall repeat until one of two conditions are met: + + 4. 1. The residual risk, assuming all proposed risk control measures are correctly implemented and verified, falls to a negligible level. The manufacturer is still encouraged to implement additional risk control measures if they improve the usability and safety of the medical device and are economically practicable. Note: In general, an RCM in a diagnostic medical device cannot reduce the severity of harm because the medical device only contributes to the probability of a hazardous situation but cannot modulate the hazard itself. In contrast, software controlling a treatment device, such as a surgical cauterization tool, may limit the output power when a hazardous situation is detected. + 2. No further practicable measures are identified. + + 5. Residual risks falling under category Low are acceptable with no further required mitigation. Residual risks under category High are unacceptable and further mitigation is required. Residual risks under Medium require a risk benefit analysis. + + 6. Risk management team shall perform a risk/benefit analysis for any residual risks falling under risk category Medium. A medical SME is required for this step. + + 7. 1. Provide a justification for why the manufacturer believes the benefit of using the medical device outweighs the residual risk. The following tools may be used in the justification statement: + + 2. 1. Direct comparison to existing products. + 2. Compare the risks in the current standard of care to the new state of the art using the device. For a device that provides patient benefit primarily by reducing risk in the standard of care workflow, this approach is usually the most straightforward and appropriate. + + 8. For each risk control measure identified, add a product requirement and follow design and development procedures for requirement implementation and testing. + + 3. Risk control verification + + 4. 1. For each risk control measure, ensure a suitable verification test has been created and performed. + 2. For each risk control measure, ensure no new risks are introduced. + + + +### Modular Hazards and Harm Identification + + + +Our device produces outputs that need to be interpreted by a trained clinician intended to inform clinical management. Clinical management is a complex interaction between clinicians and available information from multiple sources. There are many permutations of inputs and outputs that could lead to patient harm and it is impractical to explicitly consider all paths in our risks and hazards analysis process. We have devised a modular hazards and harm identification process that allows us to focus on our device’s contribution to risk. + +![Clinical Management Schematic](risk_management_process.assets/Clinical Management Schematic.svg) + +Figure 3. Clinical Management Schematic. The clinical management process converts clinical inputs into clinical outputs. A) Clinical inputs are interpreted by clinicians. Clinicians may order more clinical inputs. Some clinical inputs may be incorrect or incorrectly interpreted by clinicians. There may also be communication errors between clinicians. B) Ideally, clinical inputs, both correct and incorrect, are correctly processed by clinicians to produce appropriate clinical outputs. What constitutes “appropriate clinical outputs” is outside of our control and constantly changing with advancements in the practice of medicine. C) Examples of reasons for Inappropriate clinical outputs include: clinicians misinterpreting correct clinical inputs, incorrect clinical inputs, or communication errors between clinicians. + +![Modular hazards and harm analysis schematic](risk_management_process.assets/Modular hazards and harm analysis schematic.svg) + +Figure 4. Modular hazards and harm analysis schematic. This figure shows the ways our medical device can contribute to a hazardous situation. Since our device is meant to inform the clinician, a misinformed clinician is present in any foreseeable sequence of events. Our device’s output is just one piece of information that influences the clinical decision making process. We have identified two ways our device can contribute to a hazardous situation: A) a misinterpreted correct report or an B) incorrect report. Our hazard identification process will focus on identifying how our device can lead to these two events. A misinformed clinician may make an incorrect clinical management decision that could lead to patient harm. C) Every hazardous situation has a non-zero probability of leading to severe harm. For example, a misinformed clinician could order an unnecessary CT scan with contrast. Some patients may be unharmed, others may have a mild reaction, others may go into anaphylactic shock that leads to death. Another example is the incorrect cessation of chemotherapy. Some patients may already have incurable disease and ceasing chemotherapy did not cause harm. Other patients could have progression from a curable to an incurable disease. The practice of medicine is constantly evolving so it is not practical for the manufacturer to enumerate all hazards and hazardous situations, however, we have identified some guiding principles that allows us to mitigate risk without enumerating all the ways a clinician can use information to make an incorrect decision: + + + +1. All foreseeable sequences of events contain misinformed clinician(s). + +2. Our device can contribute to a hazardous situation only through misinformed clinician(s). + +3. 1. Our device is informational only. It does not directly interface to any other device that could directly cause harm. + +4. Our device can contribute to a misinformed clinician through: + +5. 1. Incorrect outputs due to software anomalies or use errors + 2. Correct outputs that are misinterpreted by the clinician + +6. All hazards have a nonzero probability of leading to a severe harm. Examples: + +7. 1. Unnecessary surgery may cause correctable injury to some but sepsis and death for others. + 2. Unnecessary drugs (chemotherapy, contrast agent, etc) could cause mild discomfort for some but anaphylaxis and death for others. + 3. Premature termination of chemotherapy could cause no additional harm for terminal patients but incurable disease progression for others. + +8. Probability of a software anomaly is assumed to be a 1. + +9. 1. Design controls, verification, and validation activities can reduce the number of software anomalies, however, they cannot reduce the number to 0. + +10. Probabilities of the following need to be evaluated on a case by case basis: + +11. 1. Upstream sequences of events leading to a misinformed clinician. An engineering SME is best suited to evaluate this because these events are usually technical in nature. + 2. Downstream sequences events causing misinformed clinician(s) to make an incorrect clinical action. A medical SME is best suited to evaluate this because these events are usually clinical in nature. The medical SME needs to gauge how likely a clinician is to misinterpret the report and how likely the error will not be caught by other clinicians, technicians, surgeons, and other members of the clinical management team. + +12. Risk control measures implemented in our device can only decrease the probability of harm. Our device cannot modulate the severity of harm because our involvement is minimal after the information is given to the clinician. + + + +## Usability Considerations + +The following types of use errors shall be considered during risk analysis [[IEC 62366-1:2015]]: + +- Use error caused by failure see visual information +- Use error caused by inability to hear auditory information +- Use error caused by cognition errors + - Inability to recall knowledge + - Forgetting to perform a planned step + - Unsuitable application of otherwise accepted rule + - Misinterpretation of information due to incorrect mental models or assumptions + - Improvisation under unusual circumstances. + +## Software as a Medical Device Qualification + +The following table shall be reviewed during summative risk management activities. + +| IMDRF Statement | Comment | +| ------------------------------------------------------------ | ------------------------------------------------------------ | +| SaMD is a medical device and includes in-vitro diagnostic (IVD) medical device. | Applies to our device. | +| SaMD is capable of running on general purpose (non-medical purpose) computingplatforms. | Applies to our device. | +| “without being part of” means software not necessary for a hardware medical deviceto achieve its intended medical purpose. | Applies to our device. | +| SaMD may be used in combination (e.g., as a module) with other products includingmedical devices. | Applies to our device. | +| SaMD may be interfaced with other medical devices, including hardware medicaldevices and other SaMD software, as well as general purpose software. | Applies to our device. | +| Mobile apps that meet the definition above are considered SaMD. | Not applicable to our device but not necessary for SaMD designation. | +| SaMD may also:• Provide means and suggestions for mitigation of a disease.• Provide information for determining compatibility, detecting, diagnosing,monitoring or treating physiological conditions, states of health, illnesses orcongenital deformities.• Aid to diagnosis, screening, monitoring, determination of predisposition;prognosis, prediction, determination of physiological status. | Applies to our device. | + +## Factors SaMD Influencing Patient Safety + +The IMDRF outlines several useful aspects to consider for SaMD. + +The following table shall be reviewed during summative risk analysis activities. + + + +| IMDRF consideration | Comment | +| ------------------------------------------------------------ | ------------------------------------------------------------ | +| The type of disease or condition | | +| Fragility of the patient with respect to the disease or condition | Our device provides information that is used, in conjunction with other information, by a trained clinician to make a clinical decision. | +| Progression of the disease or the stage of the disease/condition | Device malfunction is unlikely to result in disease progression | +| Usability of the application | Usability engineering is considered in our risk management activities. | +| Designed towards a specific user type | We have identified multiple user roles and have outlined the expected qualifications for each user type in product labelling. We have also considered the users qualifications in the user interface design and risk analysis. | +| Level of dependence or reliance by the user upon the output information | We have considered this factor in our risk management activities. | +| Ability of the user to detect an erroneous output information | We have considered this factor in our risk management activities. Our reports and visualizations are immediately reviewed by the user and are designed to allow users to easily detect erroneous information. | +| Transparency of the inputs, outputs and methods to the user | We have considered this factor in our risk management activities. | +| Level of clinical evidence available and the confidence on the evidence | We have considered this factor in our risk management activities. | +| The type of output information and the level of influence on the clinical intervention | We have considered this factor in our risk management activities. | +| Complexity of the clinical model used to derive the output information | We have considered this factor in our risk management activities. | +| Known specificity of the output information | We have considered this factor in our risk management activities. | +| Maturity of clinical basis of the software and confidence in the output | We have considered this factor in our risk management activities. | +| Benefit of the output information vs. baseline | We have considered this factor in our risk management activities. | +| Technological characteristics of the platform the software are intended to operate on | We have considered this factor in our risk management activities. | +| Method of distribution of the software | We have considered this factor in our risk management activities. | + +## Factors important for SaMD Characterization + +### Significance of information provided by SaMD to healthcare decision + +The following table shall be reviewed during summative risk management activities. + +| From IMDRF Guidance | Comments | +| ------------------------------------------------------------ | ------------------------------------------ | +| **To treat or to diagnose**Treating and diagnosing infers that the information provided by the SaMD will be used to take an immediate or near term action:• To treat/prevent or mitigate by connecting to other medical devices, medicinal products, general purpose actuators or other means of providing therapy to a human body• To diagnose/screen/detect a disease or condition (i.e., using sensors, data, or other information from other hardware or software devices, pertaining to a disease or condition) | This is not the best matching designation. | +| **To drive clinical management**Driving clinical management infers that the information provided by the SaMD will be used to aid in treatment, aid in diagnoses, to triage or identify early signs of a disease or condition will be used to guide next diagnostics or next treatment interventions:• To aid in treatment by providing enhanced support to safe and effective use of medicinal products or a medical device.• To aid in diagnosis by analyzing relevant information to help predict risk of a disease or condition or as an aid to making a definitive diagnosis.• To triage or identify early signs of a disease or conditions. | This is not the best matching designation. | +| **To Inform clinical management**Informing clinical management infers that the information provided by the SaMD will not trigger an immediate or near term action:• To inform of options for treating, diagnosing, preventing, or mitigating a disease or condition.• To provide clinical information by aggregating relevant information (e.g., disease, condition, drugs, medical devices, population, etc.) | **This is the best matching designation** | + +### Healthcare Situation or Condition + +The following table shall be reviewed during summative risk management activities. + +| From IMDRF Guidance | Comments | +| ------------------------------------------------------------ | ------------------------------------------ | +| **Critical situation or condition**Situations or conditions where accurate and/or timely diagnosis or treatment action is vital to avoid death, long-term disability or other serious deterioration of health of an individual patient or to mitigating impact to public health. SaMD is considered to be used in a critical situation or condition where:The type of disease or condition is:Life-threatening state of health, including incurable states,Requires major therapeutic interventions,Sometimes time critical, depending on the progression of the disease or condition that could affect the user’s ability to reflect on the output information.Intended target population is fragile with respect to the disease or condition (e.g.,pediatrics, high risk population, etc.)Intended for specialized trained users. | This is not the best matching designation. | +| **Serious situation or condition**Situations or conditions where accurate diagnosis or treatment is of vital importance to avoid unnecessary interventions (e.g., biopsy) or timely interventions are important to mitigate long term irreversible consequences on an individual patient’s health condition or public health. SaMD is considered to be used in a serious situation or condition when:The type of disease or condition is:Moderate in progression, often curable,Does not require major therapeutic interventions,Intervention is normally not expected to be time critical in order to avoid death, long-term disability or other serious deterioration of health, whereby providing the user an ability to detect erroneous recommendations.Intended target population is NOT fragile with respect to the disease or condition.Intended for either specialized trained users or lay users. Note: SaMD intended to be used by lay users in a "serious situation or condition" as described here, without the support from specialized professionals, should be considered as SaMD used in a "critical situation or condition". | **This is the best matching designation.** | +| **Non-Serious situation or condition**Situations or conditions where an accurate diagnosis and treatment is important but not critical for interventions to mitigate long term irreversible consequences on an individual patient's health condition or public health. SaMD is considered to be used in a non-serious situation or condition when:The type of disease or condition is:Slow with predictable progression of disease state (may include minor chronic illnesses or states),May not be curable; can be managed effectively,Requires only minor therapeutic interventions, andInterventions are normally noninvasive in nature, providing the user the ability to detect erroneous recommendations.Intended target population is individuals who may not always be patients.Intended for use by either specialized trained users or lay users. | This is not the best matching designation. | + + + +### SaMD Categorization + +The following table shall be reviewed during summative risk management activities. + +| State of Healthcare situation or condition | Treat or diagnose | Drive clinical management | inform clinical management | +| ------------------------------------------ | ----------------- | ------------------------- | --------------------------------- | +| Critical | IV | III | II | +| Serious | III | II | I | +| Non-serious | II | I | I | + +Our assessment of the significance of information and state of healthcare situation or condition indicates our device falls under the IMDRF category I. Information provided by the device is an aggregation of data to provide clinical information that will not trigger an immediate or near term action for the treatment of a patient condition that is not normally expected to be time critical in order to avoid death, long-term disability, or other serious deterioration of health. + +### Post Market Surveillance + +The following table shall be reviewed during summative risk management activities. + +| IMDRF Consideration | Comment | +| ------------------------------------------------------------ | ------------------------------------------------------------ | +| Due to its non-physical nature, a SaMD may be duplicated and numerous copies and widely spread, often outside the control of the manufacturer. | We have taken this into consideration during our risk management activities. | +| Often an update made available by the manufacturer is left to the user of the SaMD to install. Manufacturers should make sure that appropriate mitigations address any risks that arise from the existence of different versions of the SaMD on the market. | We have taken this into consideration during our risk management activities. | +| Incident investigations should consider any specific case or combination of use cases that may have contributed to the failure and as appropriate manufacturers should consider accident reconstruction principles, e.g., data logging, black box recorder, etc. | We have taken this into consideration during our risk management activities. | + + + +### Socio-technical environment considerations + +The following table shall be reviewed during summative risk management activities. + + + +| IMDRF Consideration | Comment | +| ------------------------------------------------------------ | ------------------------------------------------------------ | +| Manufacturers should be aware of the socio-technical environment where inadequate considerations could lead to incorrect, inaccurate, and/or delayed diagnoses and treatments; and/or additional cognitive workload (which may, over time, make clinicians more susceptible to making mistakes) | We have taken this into consideration during our risk management activities. | +| If the user does not have sufficient skills and expertise for correct operation of the SaMD, possible inaccurate output data may not be questioned. The same may happen if the user becomes habituated and over-reliant on SaMD over time. | We have taken this into consideration during our risk management activities. | +| The user may seek alternate pathways to achieve a particular functionality, otherwise called a workaround. When workarounds circumvent built-in safety features of a product, patient safety may be compromised. | We have taken this into consideration during our risk management activities. | +| Transparency of information on limitations with algorithms, clinical model, quality of data used to build the models, assumptions made, etc. can help users question the validity of output of the SaMD and avoid making incorrect or poor decisions; | We have taken this into consideration throughout the product's design, development, and installation. | +| Integrating SaMD within real-world clinical workflows (including sufficient involvement of users from all relevant disciplines) requires attention to in situ use and tasks to ensure appropriate use of safety features; | We have taken this into consideration throughout the product's design, development, and installation. | +| SaMD (and other systems connected to the SaMD) may be configured by the user in different ways than intended or foreseen by the manufacturer; | We have taken this into consideration throughout the product's design, development, and installation. | +| Though not specific to SaMD, design of the user interface including: whether designs are overly complex (e.g., multiple, complicated screens), the appropriateness of designs for the target platform (e.g., smart phone screen versus desktop monitor), the dynamic nature of data (e.g., showing information at appropriate times and for an appropriate duration); | We have taken this into consideration throughout the product's design, development, and installation. | + + + +### Technology and system environment considerations + +The following table shall be reviewed during summative risk management activities. + +| IMDRF Consideration | Comments | +| ------------------------------------------------------------ | ------------------------------------------------------------ | +| Connections to other systems (e.g., reliability of the connection, resilience, quality of service, access, security, load capacity of connections to other systems and connection methods, system integration) | We have taken this into consideration throughout the product's design, development, and installation. | +| Presenting information to the users and system integrators about the system requirements and resultant performance of the SaMD (e.g., the effect that changes to firewall rules might have on the operation of the system) | We have taken this into consideration throughout the product's design, development, and installation. | +| Hardware platform(s)—such as smart phones, PC, servers—(e.g., reliability, dependencies, and interconnections with others hardware and software) | We have taken this into consideration throughout the product's design, development, and installation. | +| Operating system(s) platform—such as Windows, GNU/Linux—compatibility; and | We have taken this into consideration throughout the product's design, development, and installation. | +| Modifications and changes to the SaMD integration (e.g., platform updates) may have effects on SaMD that the manufacturer did not anticipate/foresee. | We have taken this into consideration throughout the product's design, development, and installation. | + + + +### Information security with respect to safety considerations + +The following table shall be reviewed during summative risk management activities. + +| IMDRF Consideration | Comments | +| ------------------------------------------------------------ | ------------------------------------------------------------ | +| The SaMD information security and privacy control requirements may need to be balanced with the need for timely information availability. | We have taken this into consideration throughout the product's design, development, and installation. | +| Information security requires the identification and implementation of safe (and formalized) ways to store, convert and/or transmit data. | We have taken this into consideration throughout the product's design, development, and installation. | +| The design should use appropriate control measures to address data integrity when common information is accessed by multiple applications and users. | We have taken this into consideration throughout the product's design, development, and installation. | +| Manufacturers should make it feasible for users to safely implement information security updates. | We have taken this into consideration throughout the product's design, development, and installation. | +| The protection of sensitive information requires support for sufficient access control and appropriate restriction to system settings and assets for important data. | We have taken this into consideration throughout the product's design, development, and installation. | +| The design should address possible adverse system interactions with the inclusion of appropriate resilience and robustness measures. | We have taken this into consideration throughout the product's design, development, and installation. | +| Instructions for users related to information security should include how to safely:Install SaMD in appropriate operating environments (e.g., OS, integration of other software);Manage authentication mechanisms; andUpdate Security Software/spyware,operating environments,and other systems and applications, etc. | We have taken this into consideration throughout the product's design, development, and installation. | + diff --git a/rdm/init_files/documents/software_design_specification.md b/rdm/init_files/product_qms/software_design_specification.md similarity index 95% rename from rdm/init_files/documents/software_design_specification.md rename to rdm/init_files/product_qms/software_design_specification.md index 5f895cb..ba52307 100644 --- a/rdm/init_files/documents/software_design_specification.md +++ b/rdm/init_files/product_qms/software_design_specification.md @@ -103,7 +103,7 @@ Use something like: `![Screen One](../images/uimockups/example-ui-mockup-001.png Which produces: -![Screen One](../images/uimockups/example-ui-mockup-001.png) +![Screen One](images/uimockups/example-ui-mockup-001.png) ## Screen Two (SVG) @@ -111,7 +111,7 @@ Use something like: `![Screen Two](../images/uimockups/example-ui-mockup-002.svg Which produces: -![Screen Two](../images/uimockups/example-ui-mockup-002.svg) +![Screen Two](images/uimockups/example-ui-mockup-002.svg) ## Screen Three (JPG) @@ -119,4 +119,4 @@ Use something like: `![Screen Three](../images/uimockups/example-ui-mockup-003.j Which produces: -![Screen Three](../images/uimockups/example-ui-mockup-003.jpg) +![Screen Three](images/uimockups/example-ui-mockup-003.jpg) diff --git a/rdm/init_files/documents/software_plan.md b/rdm/init_files/product_qms/software_plan.md similarity index 97% rename from rdm/init_files/documents/software_plan.md rename to rdm/init_files/product_qms/software_plan.md index e2e3024..116a20a 100644 --- a/rdm/init_files/documents/software_plan.md +++ b/rdm/init_files/product_qms/software_plan.md @@ -114,10 +114,12 @@ This section of the software plan describes the various activities involved with ## Activity Diagram -![Overview of life-cycle processes](../images/lifecycle-processes.svg) +![Overview of life-cycle processes](images/lifecycle-processes.svg) ## Planning +The purpose of the design activity is to define the architecture, components, and interfaces of the software system based on requirements. [[IMDRF.N23:8.2, 21.CFR.820.30.b]] + **Input:** System requirements and risk controls Setup a Git repository on GitHub. All software activity outputs will be stored in this Git repository, the associated GitHub issues, or the associated GitHub pull requests, unless explicitly noted otherwise [[62304:5.1.1.b]]. The software developers working on the project are responsible for keeping all software activity outputs within version control at the times specified in the activity descriptions [[62304:5.1.9.c, 62304:5.1.9.d, and 62304:5.1.9.e]]. @@ -169,10 +171,10 @@ See [the appendices](#requirements-analysis) for additional information. **Verification:** Ensure software requirements: {% if not system.is_software_only_device %} -- implement system requirements and are labeled with system requirement ids [[62304:5.2.6.a 62304:5.2.6.f]] +- implement system requirements and are labeled with system requirement ids [[62304:5.2.6.a 62304:5.2.6.f, 21.CFR.820.30.c]] - implement risk controls {%- endif %} -- don't contradict each other [[62304:5.2.6.b]] +- don't contradict each other [[62304:5.2.6.b, 21.CFR.820.30.c]] - have unambiguous descriptions [[62304:5.2.6.c]] - are stated in terms that permit establishment of test criteria and performance of tests to determine whether the test criteria have been met [[62304:5.2.6.d]]. @@ -281,7 +283,7 @@ To organize and prioritize the development work, change requests are assigned to Once a change request is assigned to a milestone, it has been "approved" and may be worked on by a developer. The project lead will then assign developers to change requests to divide up the work. Software developers may also assign themselves to change requests, so long as it is not assigned to another developer and they don't have other outstanding tickets they can work on. -The project lead should coordinate with the business owner regarding which change requests to include in a release. When planning a release: +The project lead should coordinate with the business owner regarding which change requests to include in a release [[21.CFR.820.30.i]]. When planning a release: - Consider outstanding problem reports [[62304:9.4]]. - Look through historical problem reports and attempt to identify any adverse trends. For example, some software items may have many problem reports associated with them [[62304:9.6 and 14971:9.a]] @@ -318,7 +320,7 @@ Once you have completed the detailed design, open a pull request and assign the ## Unit Implementation and Testing -[[:This activity addresses 62304:5.5.1]] +[[:This activity addresses 62304:5.5.1 and 21.CFR.820.30.f]] **Input:** {% if system.safety_class == 'C' %}Detailed software item designs{% else %}SDS{% endif %} and software requirements @@ -356,7 +358,7 @@ When work on a change branch is nearing completion, a pull request should be cre **Output:** Code and documentation changes, stored in un-merged Git branches with corresponding approved pull requests -**Verification:** Code review by at least on other developer. +**Verification:** Code review by at least on other developer. [[21.CFR.820.30.e]] Code review should ensure the code changes made in the Git branch: @@ -442,7 +444,7 @@ The purpose of the archive is to provide a means to re-test problems which may o **Input:** Implemented and verified change requests for the current milestone -When a new version of the software is released, the Git commit corresponding to the state of the code should be [tagged](https://git-scm.com/book/en/v2/Git-Basics-Tagging) with the version number. +When a new version of the software is released, the Git commit corresponding to the state of the code should be [tagged](https://git-scm.com/book/en/v2/Git-Basics-Tagging) with the version number [[21.CFR.820.60]]. Archived releases shall be kept until there are no longer supported devices being used that run the version of the software. @@ -480,7 +482,7 @@ Feedback from users, internal testers, and software developers will be recorded A problem report should be created whenever: 1. a user reports a problem while using a released version of the software system, or -2. when an internal user reports a new problem that has been found during software development or maintenance on the master Git branch [[62304:5.1.1.e and 62304:5.1.9.f]]. Note that small software bugs and test-failures, especially recently introduced bugs discovered by software developer working on the project, do not require a problem report. Problem reports provide a useful historical record of bugs, which can be used to identify software items which are especially risky. +2. when an internal user reports a new problem that has been found during software development or maintenance on a released version [[62304:5.1.1.e and 62304:5.1.9.f]]. Note that small software bugs and test-failures, especially recently introduced bugs discovered by software developer working on the project, do not require a problem report. Problem reports provide a useful historical record of bugs, which can be used to identify software items which are especially risky. When creating a new problem report, include in the description: @@ -523,7 +525,7 @@ Writing software requirements is an art and a science; one must find balance bet {% if not system.is_software_only_device %} The distinction between system requirements and software requirements can be challenging. System requirements describe the requirements of the entire system, including software and hardware. Software requirements must be traceable to all of the system requirements that they help fulfill. Software requirements are usually more detailed than the system requirements they refer to. Many system requirements will be fulfilled using both hardware and software. {% endif %} -The distinction between software requirements and the specifications is {% if not system.is_software_only_device %}also {% endif %}typically challenging. Requirements should: +The distinction between software requirements and the specifications is {% if not system.is_software_only_device %}also {% endif %}typically challenging. Requirements should [[IMDRF.N23:8.1]]: - not imply solution - be verifiable diff --git a/rdm/init_files/documents/software_requirements_specification.md b/rdm/init_files/product_qms/software_requirements_specification.md similarity index 100% rename from rdm/init_files/documents/software_requirements_specification.md rename to rdm/init_files/product_qms/software_requirements_specification.md diff --git a/rdm/init_files/documents/test_record.md b/rdm/init_files/product_qms/test_record.md similarity index 100% rename from rdm/init_files/documents/test_record.md rename to rdm/init_files/product_qms/test_record.md diff --git a/rdm/init_files/product_qms/verification_and_validation_plan.md b/rdm/init_files/product_qms/verification_and_validation_plan.md new file mode 100644 index 0000000..9eae202 --- /dev/null +++ b/rdm/init_files/product_qms/verification_and_validation_plan.md @@ -0,0 +1,81 @@ +--- +id: VVP-001 +revision: 1 +title: Verification and Validation Plan +--- + +# Approvals + +By signing below, the individual indicates he or she has read, understood, and approved the contents of this document. + +| Name | Role | Date | +| ---- | ---- | ---- | +| | | | +| | | | + +# Revision History + +| Date | Version | Change Description | +| ---- | ------- | ------------------ | +| | | | +| | | | + + + +# Verification and Validation Plan + +## Introduction + +This document summarizes validation and verification activities. The results of the validation and verification activities can be found in the Test Report document. The Traceability Analysis Report maps these activities to the requirements defined in the Software Requirements Specification. + +## Definitions + +Verification means confirmation by examination and provision of objective evidence that specified requirements have been fulfilled. In other words, “Did we build the thing right?” + + + +Validation means establishing by objective evidence that device specifications conform with user needs and intended uses. In other words, “Did we build the right thing?” + + + +An end-to-end test examines the functionality of an application through its standard user interface without peering into its internal structures or workings. + + + +A unit test examines an individual software unit that typically cannot be broken down any further. + + + +An integration test examines multiple software units for defects in the interfaces and interactions between them. + + + +A software item is any identifiable part of a computer program. + + + +A software system is an integrated collection of software items organized to accomplish a specific function or set of functions. + + + +A software unit is a software item that is not subdivided into other software items. + + + +Regression testing is the process of re-running functional and non-functional tests to ensure that previously developed and tested software still performs after a change. + +## Verification + +Software verification begins with the design reviews, code reviews, and adherence to software standards defined in the Software Plan. These activities are reported in the Revision Level History. [[21.CFR.820.30.f]] + +Software verification continues with verification tests run on a continuous basis during the development process to detect any regressions. All tests are automatically run against each proposed software revision before the revision is accepted, a process known as Continuous Integration or CI. + +Verification tests include unit tests, integration tests, and end-to-end tests, which are summarized below. A detailed list of verification tests along with their results for the current release is found in the Automatic Verification Test Report. + +TODO: Document how verification tests are to be run. + +## Validation + +Summative validation occurs after a software release candidate has passed all verification testing. In these system-level tests, the software is deployed to a validation testing environment which is as close to the intended deployment environment as possible. Anonymized image data and the full user interface are used to confirm that the software conforms to its intended use, including reporting of results. [[21.CFR.820.30.g]] + +Details and results of these validation tests are contained in the Test Report. \ No newline at end of file diff --git a/tox.ini b/tox.ini index 41d0855..957be29 100644 --- a/tox.ini +++ b/tox.ini @@ -1,5 +1,5 @@ [tox] -envlist = py35,py36,py37 +envlist = py35,py36,py37,py38 [testenv] extras = test @@ -7,6 +7,7 @@ basepython = py35: python3.5 py36: python3.6 py37: python3.7 + py38: python3.8 deps = readme_renderer flake8