CAPA Plan - Response to ICON Audit

Document Information

Field	Value
Document Title	Corrective and Preventive Action Plan - ICON Audit Response
Document Reference	CAPA-ICON-2026-001
Audit ID	IA-10766
Audit Date	16-20 February 2026
Audit Type	Routine/Surveillance
Auditor	Mori Miharu, Principal Auditor, Technology Quality Assurance, ICON
Auditee Organization	AI Labs Legit Health
Vendor Contact	Saray Ugidos, Quality and Regulatory Affairs Manager, AI Labs
Target Response Date	10 April 2026
Document Date	April 2026
Status	Submitted for Client Review
Version	1.0

---

Purpose and Scope

This Corrective and Preventive Action (CAPA) Plan has been prepared by AI Labs Legit Health in response to the audit conducted by ICON (Audit ID: IA-10766) on 16-20 February 2026. The purpose of this document is to:

1. Acknowledge and address all findings identified during the audit
2. Provide root cause analysis for each finding
3. Detail corrective and preventive actions with clear ownership and timelines
4. Demonstrate our commitment to continuous improvement

This CAPA Plan covers all findings from the ICON audit and applies to Quality Management, Product Development, Regulatory Affairs, and IT departments.

---

Finding Summary

Rating	Count	Description
Critical	0	-
Major	1	SDLC and CSV deliverables for mobile/web application not available (AF-20551)
Minor	1	Technical documentation of the medical device not available at the time of audit (AF-20553)
Other	1	Document control process to be enhanced (AF-20554)
Total	3

---

MAJOR FINDING

AF-20551 — SDLC and CSV deliverables for mobile/web application

Field	Value
Global Category	System controls
Sub-Category	Development, Validation & Testing
Severity	Major

References:

• EU MDR Annex I sections 17.3, 17.4, 23
• EU MDR Article 10(4), 10(11)
• EU MDR Annex II section 1.1(j)
• ISO 13485 clauses 7.3, 7.1, 4.2
• ICH GCP E6 R3 sections 3.16, 4

Finding Description:

SDLC and CSV deliverables for a system component (mobile application or web application) were not available at the time of the audit. Although the vendor demonstrated that their QMS is structured in alignment with ISO 13485, objective evidence demonstrating the data input and output processes at the end-user interface level was not available. The SDLC and CSV deliverables relevant to the end-user interface (mobile and/or web application) had not been established or made available.

Areas requiring follow-up:

1. Clarification of the mobile device provisioning model (BYOD vs vendor-provided)
2. Definition of the mobile application development lifecycle (core SDLC/CSV controls + study-specific configuration management)
3. Updates to the QMS to formally incorporate mobile and web application development activities
4. Documentation of end-to-end data flow (input at mobile/web level → AI processing → output presentation)

---

Investigation Summary (incl. Root Cause)

Root Cause: Legit Health's QMS and procedural framework were originally designed around the core AI medical device (backend API and AI models). The clinical trial web application (delivered as a Progressive Web App — PWA) was treated as a service delivery channel managed under GP-009 (Sales) rather than as a formal software component requiring dedicated SDLC/CSV documentation.

At the time of the audit, the following already existed but were not consolidated into a single, auditable framework:

• Data flow documentation existed in SP-009-005 (Implementation Plan Helpers for Clinical Trials) showing the end-to-end flow from participant login through CloudFront, S3, EBS, AI services, RDS, to data transfer endpoints.
• System architecture for the core medical device (API/AI backend) was documented in R-TF-012-029 (Software Architecture Description). However, R-TF-012-029 covers the medical device product, not the clinical trial WebApp — which is a separate service delivery platform. A dedicated architecture document for the clinical trial WebApp did not exist.
• Project-specific BYOD documentation existed in project records, describing the BYOD model, WebApp access via browser URL, image capture workflow, and anonymization — but this was project-specific rather than procedural.
• Integration workflows were documented in SP-009-006 covering Iframe and JSON-only integration patterns with detailed sequence diagrams.

The root cause is the absence of a general procedure that mandates, for every clinical trial project with a CRO, a standardized set of SDLC/CSV deliverables covering the frontend WebApp as a system component. The knowledge and capability existed within the engineering and quality teams; the procedural framework to enforce consistent documentation per project did not.

Clarification on the WebApp architecture: The Legit Health clinical trial WebApp is delivered as a Progressive Web App (PWA) — a web application accessed via a standard browser URL (e.g., studyname.clinicaltrials.legit.health). It is not a native mobile application and does not require installation from an app store. From a technical perspective, it constitutes a web application, as noted by the Lead Auditor. This architecture simplifies device provisioning and eliminates app distribution complexities, while still requiring proper documentation of the runtime environment (browser, OS, camera, screen) since these are implicit system dependencies.

---

Response to Regulatory References

The following table provides a point-by-point response to each regulatory reference cited in the finding:

EU MDR Annex I, Section 17.3 — Software used in combination with mobile computing platforms shall be designed taking into account the specific features of the mobile platform (e.g., screen size, contrast ratio) and the external factors related to their use (varying environment as regards level of light or noise).

MDR 17.3 Requirement	Response
Screen size	Minimum screen size of ≥ 5.5 inches defined in SP-009-011 to ensure adequate lesion visualization and UI interaction. The PWA's responsive design adapts to the device screen dimensions.
Contrast ratio	Image capture environmental guidance in SP-009-011 requires screen brightness sufficient for image review in the capture environment. The WebApp uses high-contrast UI elements designed for clinical settings.
Varying light levels	SP-009-011 mandates image capture environmental guidance for each project: adequate, even lighting; avoidance of direct sunlight, shadows, or flash; diffuse natural or artificial light preferred. These instructions must be provided to users via the study protocol or user instructions.
Camera considerations	Minimum rear camera resolution of ≥ 12 MP defined. The built-in Dermatological Image Quality Assessment (DIQA) system automatically evaluates image quality at capture time and rejects images that do not meet quality thresholds (blur, exposure, framing), mitigating the risk of substandard images due to device or environmental conditions.

EU MDR Annex I, Section 17.4 — Manufacturers shall set out minimum requirements concerning hardware, IT networks characteristics and IT security measures, including protection against unauthorised access, necessary to run the software as intended.

MDR 17.4 Requirement	Response
Minimum hardware	SP-009-011 defines minimum handset specifications per project: rear camera ≥ 12 MP, screen ≥ 5.5 inches, iOS ≥ 16 or Android ≥ 12, Safari ≥ 16 or Chrome ≥ 110. These specifications are documented and communicated to the sponsor/CRO for inclusion in the study protocol.
IT network characteristics	Stable internet connection (Wi-Fi or mobile data) required for image upload. The WebApp communicates exclusively via HTTPS/TLS 1.2+ with the Legit Health cloud infrastructure (CloudFront CDN → backend → AI services). Network requirements are documented in the project-specific data flow diagram.
IT security measures	All data transmission is encrypted via HTTPS/TLS 1.2+. Session-based authentication with secure credentials. No clinical data is stored locally on the device (no local persistence). Access is role-based and provisioned per user. The WebApp operates within Legit Health's cloud infrastructure (hosted on AWS). Protection against unauthorised access is enforced via authentication, authorization, and audit logging.
OS version requirements	Minimum OS versions (iOS ≥ 16, Android ≥ 12) ensure that devices have current security patches and support modern browser security features (e.g., Content Security Policy, Secure Contexts).

EU MDR Article 10(4) — Manufacturers shall draw up and keep up to date technical documentation to allow conformity assessment.

Requirement	Response
Technical documentation for WebApp	SP-009-011 mandates a complete study documentation package for each clinical trial project, including: device provisioning model, end-to-end data flow diagram, system architecture diagram, study-specific configuration document, validation report, and user instructions. These documents are maintained in the QMS (Docusaurus-based, version-controlled in Git) and are available for conformity assessment.
Handset requirements documentation	Minimum handset specifications are documented in SP-009-011 and instantiated per project in the project record (R-009-001).
BYOD rationale	Each project record must include a formal justification for the chosen provisioning model (BYOD or vendor-provided), documenting the rationale and risk considerations.

EU MDR Annex II, Section 1.1(j) — A general description of the key functional elements, including software if appropriate, its composition, its functionality, and where relevant, labelled pictorial representations (diagrams, drawings).

Requirement	Response
Key functional elements	The clinical trial WebApp is now explicitly scoped as a functional component of the system in SP-009-011 and in the project-specific system architecture diagram. The WebApp's role (image capture, data input, result presentation) is documented alongside the backend API, AI processing services, and data storage components.
Diagrams	SP-009-011 mandates a project-specific end-to-end data flow diagram and system architecture diagram for each clinical trial. These diagrams illustrate all system components (WebApp, CloudFront, backend, AI, RDS, S3), their interfaces, and data flows. A general template diagram is provided in SP-009-011 and SP-009-005, and each project instantiates it with project-specific details.
Handset/app dependencies	The WebApp's dependency on the device browser, camera, OS, and network is documented in the minimum handset specifications table in SP-009-011 and in each project record.

EU MDR Article 10(11) + Annex I, Section 23 — Information supplied with the device (instructions to users/patients).

Requirement	Response
Handset requirements communicated to users	SP-009-011 requires that minimum handset specifications are incorporated into the study protocol or other appropriate study documentation and provided as instructions to site staff, clinicians, or trial subjects.
Image capture instructions	Image capture environmental guidance (lighting, distance, background, focus, orientation) must be provided to users. This guidance is defined in SP-009-011 and must be included in the study-specific user instructions.
User instructions	SP-009-011 mandates project-specific user instructions for each clinical trial, including device requirements, image capture guidance, and study-specific operational information. These are generated as part of the study documentation package (Phase 4).

ISO 13485 Clause 7.3 (Design and Development) and Clause 7.1 (Planning of Product Realisation)

Requirement	Response
WebApp SDLC	SP-009-011 Phase 3 defines the core WebApp development controls: version control (Git), code review (pull requests), automated testing (CI/CD), cross-browser and cross-device testing, controlled deployments with rollback, and change control (GP-023). These controls apply to the core WebApp platform.
Study-specific configuration management	SP-009-011 Phase 3.2 defines study-specific configuration management: study URL, access control, feature toggles, scoring system configuration, anonymization settings, data transfer configuration, and image requirements. Each study's configuration is documented and version-controlled.
User environment planning	The BYOD provisioning model, minimum handset specifications, and environmental guidance address ISO 13485 Clause 7.1's requirement to plan for the user environment in which the product will be used.

ISO 13485 Clause 4.2 (Documentation Requirements)

Requirement	Response
Documentation availability	SP-009-011 Phase 4 defines the complete study documentation package that must be produced before go-live. Phase 5 establishes a mandatory Technical Readiness Review where all documents are verified as complete and accessible. All documents are maintained in the QMS with version control and audit trail.

ICH GCP E6 R3 Section 3.16 (Computerised Systems) and Section 4 (Data Governance)

Requirement	Response
Fitness-for-purpose	The WebApp's purpose, scope, and capabilities are defined per project in the feature scope document (SP-009-011 Phase 1.2). Validation evidence (Phase 3.3) demonstrates fitness-for-purpose through functional testing, image capture testing, DIQA validation, and data transfer validation.
Risk-based validation	Validation activities are scoped based on the study's feature set and risk profile. Core WebApp controls are validated once; study-specific configurations are validated per project.
Data lifecycle	The end-to-end data flow diagram (SP-009-011 Phase 2) documents the complete data lifecycle: capture → upload → processing → storage → transfer → output. Data integrity is ensured through HTTPS encryption, database-level audit trails, and controlled data transfer protocols (sFTP, S3, REST API) as defined in the Data Transfer Agreement.
Sponsor oversight	Project-specific dashboards, data export capabilities (CSV with filters), and scheduled data transfers enable sponsor/CRO oversight of the clinical data. Access controls ensure appropriate visibility per user role.

---

Corrective Action

A new specific procedure SP-009-011 "Clinical Trial Project Setup and Technical Deliverables for CRO Engagements" has been created under GP-009 to formalize the requirements for every clinical trial project. This procedure is organized in 5 phases and mandates that each project must produce the following deliverables before go-live:

Phase 1 — Project Scoping and Device Provisioning:

1. Device Provisioning Model Document — Formal documentation of whether a BYOD or vendor-provided model is adopted, with justification. For BYOD (the standard approach), minimum handset specifications are defined in compliance with EU MDR Annex I Sections 17.3 and 17.4:

   Specification	Minimum Requirement	Regulatory Basis
   Rear camera resolution	≥ 12 MP	MDR 17.4 (minimum hardware)
   Operating system (iOS)	iOS ≥ 16	MDR 17.4 (IT security)
   Operating system (Android)	Android ≥ 12	MDR 17.4 (IT security)
   Screen size	≥ 5.5 inches	MDR 17.3 (screen size)
   Browser (iOS)	Safari ≥ 16	MDR 17.4 (minimum hardware)
   Browser (Android)	Chrome ≥ 110	MDR 17.4 (minimum hardware)
   Network	Stable internet (Wi-Fi/mobile data)	MDR 17.4 (IT networks)
   IT security	HTTPS/TLS 1.2+, session auth, no local persistence	MDR 17.4 (protection against unauthorised access)

2. Image Capture Environmental Guidance — Per MDR 17.3 (external factors related to mobile platform use):

   Guidance Area	Requirement
   Lighting	Adequate, even lighting; avoid direct sunlight, shadows, or flash
   Distance	15-30 cm from lesion (unless otherwise specified by scoring system)
   Background	Neutral, uncluttered; plain skin surface visible around lesion
   Focus	Ensure lesion is in sharp focus; use autofocus tap if available
   Orientation	Device held parallel to skin surface to avoid perspective distortion
   Screen brightness	Sufficient for image review in the capture environment

   These specifications and instructions must be incorporated into the study protocol or other appropriate study documentation and provided to site staff, clinicians, or trial subjects, per EU MDR Article 10(11) and Annex I Section 23.

3. WebApp Feature Scope Document — Features included/excluded per study, study-specific configurations.

Phase 2 — End-to-End Data Flow Documentation:

4. Project-Specific End-to-End Data Flow Diagram — Complete data journey from image capture (mobile/web app) → upload (HTTPS/TLS) → CDN (CloudFront) → backend processing → AI analysis → optional anonymization → secure storage (RDS + S3) → data transfer to sponsor/CRO → output presentation (dashboards, reports). This addresses EU MDR Annex II Section 1.1(j) and ICH GCP E6 R3 Section 4.

5. System Architecture Diagram — All system components (WebApp, backend API, AI services, storage, CDN), data input/output interfaces, security boundaries, and integration points with sponsor/CRO systems. Documented within the clinical trial project record, separate from the core medical device architecture.

Phase 3 — WebApp SDLC and CSV Controls:

6. Core WebApp Development Controls — Version control (Git), code review (pull requests), automated testing (CI/CD), cross-browser/device testing, controlled deployments with rollback, change control (GP-023). Addresses ISO 13485 Clause 7.3.

7. Study-Specific Configuration Management — URL, access control, feature toggles, scoring systems, anonymization, data transfer, image requirements — all documented and version-controlled per study.

8. Validation Evidence — Functional testing, image capture/upload testing, DIQA validation, data transfer validation, access control testing, anonymization testing (if applicable). Addresses ICH GCP E6 R3 Section 3.16 (risk-based validation).

Phase 4 — Study Documentation Package:

9. Complete Study Documentation Package per EU MDR Article 10(4):
   • Device provisioning model with handset specifications
   • End-to-end data flow diagram
   • System architecture diagram
   • Study configuration document
   • Validation report
   • User instructions (image capture guidelines, device requirements)
   • Data Transfer Agreement
   • Project-specific user instructions
   • PACS/DICOM clarification statement

Phase 5 — Technical Readiness Review:

10. Mandatory go-live gate — All deliverables verified as complete via T-009-006 (Clinical Trial Technical Readiness Checklist). Requires approval from JD-004 (Quality Manager), JD-005 (Technical Manager), and JD-013 (Project Manager). No clinical trial may proceed to production without all three approvals.

Action By: Saray Ugidos, Quality and Regulatory Affairs Manager

Target Completion Date: 30 May 2026

---

Preventive Action

1. Procedural gate in project lifecycle: SP-009-011 establishes a mandatory Technical Readiness Review checkpoint before any clinical trial go-live. This review verifies that all SDLC/CSV deliverables listed in the procedure have been completed and approved. No project can proceed to production without passing this gate. This prevents the recurrence of undocumented system components by making documentation a prerequisite for deployment.

2. Checklist template: A new template T-009-006 Clinical Trial Technical Readiness Checklist has been created as part of SP-009-011, providing a standardized checklist of all required deliverables per project. The checklist explicitly maps each deliverable to the applicable regulatory requirement (EU MDR, ISO 13485, ICH GCP E6 R3), ensuring traceability and preventing omissions regardless of the team executing the project.

3. DIQA as built-in quality control: The Dermatological Image Quality Assessment (DIQA) system operates as an automated preventive control at the point of image capture. It evaluates image quality in real time and rejects images that do not meet quality thresholds (blur, exposure, framing), mitigating risks arising from uncontrolled BYOD environments (varying devices, lighting conditions). This addresses MDR 17.3 concerns about external factors by providing a technical safeguard independent of user compliance with instructions.

4. Periodic review: Clinical trial project documentation will be reviewed during the annual quality planning review (GP-002) to ensure continued compliance and to incorporate lessons learned from completed projects. Any changes to minimum handset specifications (e.g., new OS versions, new browser versions) will be evaluated and updated as part of this review.

5. Training: Relevant personnel (JD-003, JD-005, JD-007, JD-013) will receive training on SP-009-011 requirements to ensure consistent application across all future clinical trial projects.

Action By: Saray Ugidos, Quality and Regulatory Affairs Manager

Target Completion Date: 30 May 2026

---

MINOR FINDING

AF-20553 — Technical documentation not available at time of audit

Field	Value
Global Category	System controls
Sub-Category	Development, Validation & Testing
Severity	Minor

References:

• EU MDR Article 10(4), 10(11)
• EU MDR Annex I chapter II section 17, chapter III section 23
• EU MDR Annex II section 1.1(j)
• ICH GCP E6 R3 sections 3.16, 4

Finding Description:

The following technical documentation was not available at the time of the audit:

• End-to-end data flow diagram illustrating the journey of data from photos captured by the mobile app, through the AI system, to the final output display
• System architecture diagram including data input and output interfaces
• A final, approved IFU (Instructions for Use); although a draft version was available, it was not considered regulatory inspection ready

Additionally, it was recommended to clarify in the IFU and study documents that:

• Legit.Health system does not function as a PACS system
• DICOM handling, if required, would occur outside the validated scope of the Legit.Health system

---

Investigation Summary (incl. Root Cause)

Root Cause: The documentation existed in various locations within the QMS but was not consolidated or readily presentable during the audit:

1. End-to-end data flow: A general clinical trial data flow was documented in SP-009-005, and project-specific flows existed in project records. However, there was no single consolidated end-to-end diagram covering the complete path from the mobile/web application through AI processing to output — the existing diagrams focused on either the backend architecture or the clinical trial infrastructure separately.

2. System architecture diagram: R-TF-012-029 (Software Architecture Description) covers the core medical device (API/AI backend) — which is a separate product from the clinical trial WebApp. The clinical trial WebApp is a service delivery platform, not part of the medical device itself. A dedicated system architecture diagram for the clinical trial WebApp (covering the frontend, its interaction with the backend API, and data I/O interfaces) was not available as a standalone document.

3. User instructions for clinical trials: At the time of the audit, project-specific user instructions (covering device requirements, image capture guidance, and study-specific operational information) had not been formalized as a standard deliverable. Instructions existed informally within project communications but were not produced as a controlled document within the QMS.

4. PACS/DICOM clarification: The GMDN code documentation referenced PACS/DICOM compatibility with permissive language ("may be compatible with"), which could create ambiguity. An explicit statement was needed.

The root cause is fragmentation of documentation across multiple QMS locations and the absence of a presentation-ready package for audit purposes.

---

Corrective Action

1. Consolidated end-to-end data flow: SP-009-011 now mandates a project-specific end-to-end data flow diagram as a required deliverable for every clinical trial project. This diagram is generated as part of the project setup phase — i.e., once the contract is signed and the project record (R-009-001 project entry) is created, the end-to-end data flow diagram becomes one of the mandatory deliverables that must be completed before the Technical Readiness Review (go-live gate). The diagram must cover the complete journey: image capture (mobile/web) → upload → CloudFront/CDN → backend processing → AI analysis → optional anonymization → secure storage → data transfer to sponsor/CRO → output presentation. A general reference template is provided in SP-009-005 and SP-009-011, and each project instantiates it with project-specific details (endpoints, data transfer method, anonymization scope, etc.).

2. Clinical trial WebApp system architecture: SP-009-011 (Phase 2.2) now mandates a dedicated system architecture diagram for each clinical trial project. Like the data flow diagram, this is a project setup deliverable — generated when the project is created and completed before go-live. The diagram must cover: all system components involved (WebApp frontend, backend API, AI services, storage, CDN), data input interfaces (image capture, questionnaire input), data output interfaces (dashboards, data transfers, reports), security boundaries and access controls, and integration points with sponsor/CRO systems. This is a clinical trial service delivery architecture, separate from the core medical device architecture. A general reference architecture is provided in SP-009-011 and SP-009-005, and each project instantiates it with project-specific details.

3. Project-specific user instructions: SP-009-011 (Phase 4) now mandates that each clinical trial project produces project-specific user instructions as a controlled deliverable. These instructions cover device requirements, image capture guidance, and study-specific operational information, and are included in the study documentation package verified during the Technical Readiness Review.

4. PACS/DICOM clarification: SP-009-011 mandates that each clinical trial project generates project-specific study instructions as part of the study documentation package. These study instructions will include the following statement where applicable: "The Legit.Health system does not function as a Picture Archiving and Communication System (PACS). DICOM (Digital Imaging and Communications in Medicine) handling, if required by the study protocol, must occur outside the validated scope of the Legit.Health system, at the sponsor, CRO, or integration layer." This approach ensures the clarification is provided in the correct context (study-level documentation provided to the CRO/sponsor).

Action By: Saray Ugidos, Quality and Regulatory Affairs Manager

Target Completion Date: 30 May 2026

---

Preventive Action

1. Technical Readiness Checklist (T-009-006): A new template has been created as part of SP-009-011 — the T-009-006 Clinical Trial Technical Readiness Checklist. This checklist enumerates all mandatory deliverables for each clinical trial project and must be completed and approved before go-live. It serves as both a project setup guide and an audit-ready documentation index, ensuring that all technical documents (data flow, architecture, study instructions, validation evidence, PACS/DICOM clarification, etc.) are present and accessible in a single location within the project record (R-009-001). The checklist maps each deliverable to the applicable regulatory requirement.

2. Pre-audit preparation: The completed T-009-006 checklist for each active project serves as a ready-made index for auditors, eliminating the fragmentation issue that led to this finding. During audit preparation, the project team simply presents the completed checklist with links to all deliverables.

3. Annual documentation review: Technical documentation for active clinical trial projects will be reviewed during the annual quality planning review (GP-002) to ensure completeness and currency.

Action By: Saray Ugidos, Quality and Regulatory Affairs Manager

Target Completion Date: 30 May 2026

---

OTHER FINDING

AF-20554 — Document control process to be enhanced

Field	Value
Global Category	Other
Sub-Category	Other
Severity	Other (informational)

References:

• ICH GCP E6 R3

Finding Description:

The reviewed documents do not display reviewer and approver identification for electronic signatures on the documents. In particular, the full name, role, and responsibility (job title) of the personnel performing review or approval activities are not displayed on the document itself. It was explained that document review and approval activities are managed through version control "commits" within Git, with modifications traceable via the associated audit trail.

Recommendations:

1. Document version number and effective date should be displayed on the document itself
2. Explicit "review" step and separate "approval" step should be incorporated into the document workflow
3. Electronic signatures should display the signatory's full name and job title directly on the document
4. Exact date and time of electronic signatures, including the applicable time zone, should be displayed on the document

---

Acknowledgement

As per ICON's audit finding classification, "Other" findings are presented for information and do not require a written response from the auditee.

Legit Health acknowledges the recommendations made by the auditor regarding the enhancement of the document control process. Our current system (GP-001 Control of documents) uses a Git-based workflow with GPG-signed commits as electronic signatures, an explicit 3-step workflow (Author → Reviewer → Approver), and a full audit trail compliant with 21 CFR Part 11.

We understand the auditor's preference for displaying reviewer/approver identification, version numbers, effective dates, and electronic signature details directly on the face of the document rather than solely within the Git audit trail. We will take these recommendations into consideration for future enhancements of our document control system.

At this time, no immediate implementation is planned, as the current system provides full traceability and data integrity through the Git-based audit trail.

---

Implementation Timeline

Finding	Severity	Corrective Action Target	Preventive Action Target	Status
AF-20551	Major	30 May 2026	30 May 2026	In Progress
AF-20553	Minor	30 May 2026	30 May 2026	In Progress
AF-20554	Other	—	—	Acknowledged — no action needed

---

Associated Documents

Document Reference	Title
GP-001	Control of documents
GP-002	Quality planning
GP-009	Sales
GP-023	Change control management
SP-009-005	Implementation Plan Helpers for Clinical Trials
SP-009-006	Integration Workflow Helpers
SP-009-011	Clinical Trial Project Setup and Technical Deliverables for CRO Engagements
T-009-006	Clinical Trial Technical Readiness Checklist