What the QSR + GMLP Documentation Gap Audit actually produces

Subpart B (Quality System): General QMS procedures implied by DHF/V&V structure — PARTIAL; AI-specific CAPA/monitoring integration into QMS not evidenced. Subpart C (Design Controls): See detailed 820.30 mapping below — PARTIAL, key gaps in validation scope and change-control linkage. Subpart E (Purchasing Controls): No vendor qualification records identified for cloud inference hosting, data annotation/labeling vendors, or ECG cart/HL7 interface suppliers — LIKELY MISSING. Third-party data and cloud dependencies make this high-relevance. Subpart F (Identification/Traceability): SRS/SDS exist but traceability from training dataset version → model version → cleared algorithm version not documented — PARTIAL. Subpart G (Production/Process Controls): Software build/configuration management presumably covered under IEC 62304 process but not explicitly confirmed — PARTIAL. Subpart I (Acceptance Activities): V&V test reports present — LIKELY PRESENT, though subgroup-specific acceptance criteria unclear. Subpart J (Nonconforming Product): CAPA process explicitly noted as not updated for AI drift/performance-degradation signals — LIKELY MISSING for AI-specific nonconformance triggers. Subpart L (Handling/Storage/Distribution): Limited applicability for cloud SaMD; software distribution/version control to hospital sites not detailed — PARTIAL. Subpart M (Records): Complaint log template exists — PARTIAL; unclear if records capture model-version-linked adverse events. Subpart N (Servicing): Cloud service update/servicing procedures not described — PARTIAL/unclear. Subpart O (Statistical Techniques): No documented statistical sampling/subgroup analysis plan — LIKELY MISSING, directly tied to representativeness gap noted in inputs. Note: specific subsection numbers for Subparts E/F/G/I/J/L/M/N/O are [citation not in controlled table — verify]; only §820.30 subsections are cited with precision below.

P0-1: Retraining/model-update SOP tied to PCCP triggers absent. Citation: §820.30(i) Design changes. Expected: documented change-control procedure specifying modification triggers, retraining thresholds, re-verification/validation criteria consistent with the submitted PCCP. Current: algorithm change protocol exists but not tied to formal SOP or drift triggers. Next step: draft PCCP-linked change-control SOP; align with §820.30(g) validation criteria for each anticipated modification. Owner: Regulatory Affairs + Engineering. P0-2: Training/test data provenance and demographic representativeness undocumented. Citation: §820.30(c) Design input; §820.30(g) Design validation. Expected: dataset lineage records, inclusion/exclusion criteria, demographic/clinical stratification analysis supporting design inputs and validation. Current: not documented per inputs. Next step: compile data provenance report and subgroup performance analysis (sex, age, race/ethnicity, ECG confounders e.g. LBBB, pacemakers) before submission or major PCCP-triggered change. Owner: Clinical + Engineering, reviewed by Regulatory Affairs. P0-3: Real-world performance monitoring plan and cybersecurity postmarket surveillance insufficient. Expected: documented monitoring plan covering model drift, cybersecurity vulnerability management, and incident response for cloud-hosted inference service. Current: monitoring plan described as limited; cybersecurity postmarket process not evidenced. Citation for premarket cybersecurity content: [citation not in controlled table — verify]. Next step: develop monitoring/cybersecurity SOP referencing current FDA premarket cybersecurity guidance; integrate into CAPA. Owner: QA + Engineering (security) + Regulatory Affairs. P1-1: CAPA process not updated for AI-specific nonconformance (drift, subgroup degradation). Expected: CAPA procedure addressing AI performance drift as a nonconformance trigger (Subpart J concept — specific citation [citation not in controlled table — verify]). Next step: revise CAPA SOP; define drift detection thresholds feeding CAPA intake. Owner: QA. P1-2: Vendor qualification records for cloud hosting/data annotation/HL7 integration vendors (Subpart E concept — citation [citation not in controlled table — verify]). Next step: establish supplier qualification file per vendor category. Owner: QA/Supply Chain. P1-3: Traceability from dataset version to model version to cleared algorithm version. Citation: §820.30(j) Design history file. Next step: build traceability matrix within DHF. Owner: Engineering. P1-4: Usability/human-factors documentation (IEC 62366) for triage alert presentation not evidenced. Next step: confirm usability engineering file exists or generate one, linked to §820.30(g) validation. Owner: Clinical/Human Factors. P2-1: Multidisciplinary team composition and reference-standard adjudication methodology documentation — formalize as supporting record. Owner: Regulatory Affairs. P2-2: Records/complaint log enhancement to capture model-version metadata for postmarket signal traceability. Owner: QA. PCCP READINESS: Algorithm updates (e.g., retraining on new ECG data, threshold tuning) appear within a plausible modification space for a PCCP per the current PCCP final guidance, but readiness is undermined by absent retraining SOP (P0-1), undocumented data provenance (P0-2), and no monitoring plan (P0-3). A PCCP submission would additionally require: predefined performance acceptance criteria per modification type, subgroup-specific acceptance thresholds, verification protocol for each change type, and a documented monitoring/reporting cadence — none of which are confirmed present.