Skip to main content
QMSQMS
QMS
  • Welcome to your QMS
  • Quality Manual
  • Procedures
    • GP-001 Control of documents
    • GP-002 Quality planning
    • GP-003 Audits
    • GP-004 Vigilance system
    • GP-005 Human Resources and Training
    • GP-006 Non-conformity, Corrective and Preventive actions
    • GP-007 Post-market surveillance
    • GP-009 Sales
      • Deprecated
      • Templates
      • Specific procedures
        • SP-009-001 How to use the CRM
        • SP-009-002 Contracts
        • SP-009-003 How to share performance metrics
        • SP-009-004 Implementation plan helpers
        • SP-009-005 Implementation plan helpers for Clinical Trials
        • SP-009-006 Integration workflow helpers
        • SP-009-007 Scoring Systems Catalog
        • SP-009-008 Conditions List & Visual Assets
        • SP-009-009 Service Provision Guidelines for Intermediaries
        • Copypasters
        • SP-009-010 Customer KPI Definition and Alignment Helpers
        • SP-009-011 Clinical Trial Project Setup and Technical Deliverables for CRO Engagements
    • GP-010 Purchases and suppliers evaluation
    • GP-011 Provision of service
    • GP-012 Design, redesign and development
    • GP-013 Risk management
    • GP-014 Feedback and complaints
    • GP-015 Clinical evaluation
    • GP-016 Traceability and identification
    • GP-017 Technical assistance service
    • GP-018 Infrastructure and facilities
    • GP-019 Non-product software validation
    • GP-020 QMS Data analysis
    • GP-021 Communications
    • GP-022 Document translation
    • GP-023 Change control management
    • GP-024 Predetermined Change Control Plan
    • GP-025 Usability and Human Factors Engineering
    • GP-026 Market-specific product requirements
    • GP-027 Corporate Governance
    • GP-028 AI Development
    • GP-029 Software Delivery and Commissioning
    • GP-030 Cyber Security Management
    • GP-031 Training Data Governance
    • GP-032 CE Mark Process (MDR)
    • GP-050 Data Protection
    • GP-051 Security violations
    • GP-052 Data Privacy Impact Assessment (DPIA)
    • GP-100 Business Continuity (BCP) and Disaster Recovery plans (DRP)
    • GP-101 Information security
    • GP-110 Esquema Nacional de Seguridad
    • GP-200 Remote Data Acquisition in Clinical Investigations
    • GP-600 Equality Planning
  • Records
  • Legit.Health Plus Version 1.1.0.0
  • Legit.Health Plus Version 1.1.0.1
  • Legit.Health version 2.1 (Legacy MDD)
  • Legit.Health US Version 1.1.0.0
  • Legit.Health Utilities
  • Licenses and accreditations
  • Applicable Standards and Regulations
  • BSI Non-Conformities
  • Pricing
  • Public tenders
  • Trainings
  • Procedures
  • GP-009 Sales
  • Specific procedures
  • SP-009-011 Clinical Trial Project Setup and Technical Deliverables for CRO Engagements

SP-009-011 Clinical Trial Project Setup and Technical Deliverables for CRO Engagements

Purpose​

This specific procedure defines the mandatory technical deliverables and setup steps that must be completed for every clinical trial project involving a Contract Research Organization (CRO) or pharmaceutical sponsor. It ensures that the clinical trial web application (WebApp), delivered as a Progressive Web App (PWA), is properly documented as a system component with appropriate SDLC/CSV controls, end-to-end data flow documentation, and device provisioning specifications.

Scope​

This procedure applies to all clinical trial projects where Legit Health provides:

  • A clinical trial WebApp (PWA) for image capture, severity assessment, or data collection
  • Integration with CRO/sponsor systems for data transfer
  • Any frontend component used by site staff, clinicians, or trial subjects

This procedure does not cover:

  • The core AI medical device SDLC (covered by GP-012)
  • General sales and contracting processes (covered by GP-009, SP-009-001, SP-009-002)
  • Non-clinical trial integrations (covered by SP-009-004)

Responsibilities​

RoleResponsibility
JD-003 Design and Development ManagerEnsures SDLC/CSV deliverables are completed for the WebApp component
JD-004 Quality Manager & PRRCReviews and approves the Technical Readiness Checklist before go-live
JD-005 Technical Manager & PRRCOversees technical implementation and validates system architecture documentation
JD-007 Technology ManagerLeads WebApp development, configuration management, and deployment
JD-013 Project ManagerCoordinates project deliverables, timelines, and stakeholder communication

Definitions​

TermDefinition
PWAProgressive Web App — a web application that uses modern web technologies to deliver app-like experiences through a browser, without requiring native app installation
BYODBring Your Own Device — a provisioning model where end users (site staff, clinicians, or subjects) use their own personal devices to access the WebApp
CSVComputer System Validation — the documented process of ensuring a computerized system does exactly what it is designed to do in a consistent and reproducible manner
SDLCSoftware Development Lifecycle — the process of planning, creating, testing, and deploying software
DTAData Transfer Agreement — defines the method, format, frequency, and security requirements for transferring clinical data to the sponsor/CRO
Technical Readiness ReviewMandatory checkpoint before go-live where all deliverables in this procedure are verified as complete

Procedure​

Phase 1 — Project Scoping and Device Provisioning​

At the beginning of every clinical trial project, the Project Manager (JD-013) and the Technology Manager (JD-007) must define and document the following:

1.1 Device Provisioning Model​

A formal document must be created specifying the provisioning model for the project. The two options are:

Option A — BYOD (standard approach):

This is the default and most common model. Site staff or trial subjects use their own devices to access the WebApp via a browser URL. When BYOD is selected, the following minimum handset specifications must be documented and communicated to the sponsor/CRO for inclusion in the study protocol:

SpecificationMinimum Requirement
Rear camera resolution≥ 12 MP
Operating system (iOS)iOS ≥ 16
Operating system (Android)Android ≥ 12
Screen size≥ 5.5 inches
Browser (iOS)Safari ≥ 16
Browser (Android)Chrome ≥ 110
NetworkStable internet connection (Wi-Fi or mobile data) for image upload
StorageSufficient free storage for browser cache during image capture session
IT securityHTTPS/TLS 1.2+ for all data transmission; session-based authentication; no local data persistence on device; protection against unauthorised access

In addition, the following image capture environmental guidance must be provided to users (per EU MDR Annex I Section 17.3 — consideration of external factors related to mobile platform use):

Guidance AreaRequirement
LightingAdequate, even lighting; avoid direct sunlight, shadows, or flash; diffuse natural or artificial light preferred
Distance15-30 cm from the lesion (unless otherwise specified by the scoring system)
BackgroundNeutral, uncluttered background; plain skin surface visible around the lesion
FocusEnsure the lesion is in sharp focus before capturing; use autofocus tap if available
OrientationDevice held parallel to the skin surface to avoid perspective distortion
Screen brightnessSufficient 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 as instructions to site staff, clinicians, or trial subjects, in compliance with EU MDR Article 10(11) and Annex I Section 23 (information supplied with the device).

Option B — Vendor-provided devices:

If the sponsor requires vendor-provided handsets, the following must additionally be documented:

  • Device model and specifications
  • Device provisioning and distribution plan
  • Device management and recovery procedures
  • Pre-installed software/configuration

The provisioning model document must include a justification for the chosen approach.

1.2 WebApp Feature Scope​

For each project, a feature scope document must define:

  • Features included (e.g., image capture, DIQA, anonymization, severity assessment, data export)
  • Features excluded (with justification)
  • Study-specific configurations (scoring systems, number of images, body areas)

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

2.1 Project-Specific Data Flow Diagram​

A project-specific end-to-end data flow diagram must be created for each clinical trial. This diagram must cover the complete data journey:

The general template above (also defined in SP-009-005) must be adapted per project with:

  • Project-specific URLs and endpoints
  • Specific data transfer method and frequency (as per DTA)
  • Anonymization scope and type (as per study protocol)
  • Any project-specific processing steps

2.2 System Architecture Diagram​

Each project record must include or reference a system architecture diagram showing:

  • All system components involved (WebApp, backend, AI services, storage, CDN)
  • Data input interfaces (image capture, questionnaire input)
  • Data output interfaces (dashboards, data transfers, reports)
  • Security boundaries and access controls
  • Integration points with sponsor/CRO systems

This diagram documents the clinical trial WebApp service delivery architecture, which is separate from the core medical device architecture. A general reference architecture is provided in SP-009-005 (Implementation Plan Helpers for Clinical Trials) and must be instantiated with project-specific details.

Phase 3 — WebApp SDLC and CSV Controls​

3.1 Core WebApp Development Controls​

The clinical trial WebApp follows these development controls:

ControlDescription
Version controlAll WebApp source code is managed in Git with branch-based development
Code reviewAll changes require peer review via pull request before merging
Automated testingUnit tests, integration tests, and end-to-end tests are executed in CI/CD pipeline
Cross-browser testingWebApp is tested on target browsers (Safari ≥ 16, Chrome ≥ 110) before deployment
Cross-device testingWebApp is tested on representative devices (iOS and Android) before deployment
Image upload validationImage upload and DIQA functionality is verified before each deployment
DeploymentProduction deployments follow a controlled release process with rollback capability
Change controlAll changes to the production WebApp follow the change control process (GP-023)

3.2 Study-Specific Configuration Management​

For each clinical trial, the following study-specific configurations must be documented:

ConfigurationDescription
Study URLUnique URL for the study (e.g., studyname.clinicaltrials.legit.health)
Access controlUser provisioning method, authentication mechanism, role-based access
Feature togglesStudy-specific features enabled/disabled
Scoring systemsConfigured scoring systems for the study (reference SP-009-007)
Anonymization settingsAnonymization type and scope per study protocol
Data transfer configurationTransfer method, frequency, format, destination (per DTA)
Image requirementsNumber of images per visit, body areas, capture instructions

3.3 Validation Evidence​

Before go-live, the following validation evidence must be produced:

  1. Functional testing results — Verification that all study-specific features work as configured
  2. Image capture and upload testing — Verification on target devices and browsers
  3. DIQA validation — Verification that image quality control correctly accepts/rejects images
  4. Data transfer validation — End-to-end verification that data reaches the sponsor/CRO in the correct format
  5. Access control testing — Verification that user roles and permissions are correctly configured
  6. Anonymization testing (if applicable) — Verification that anonymization is applied correctly

Phase 4 — Study Documentation Package​

4.1 Required Study Documents​

Each clinical trial project must produce or reference the following documents before go-live:

DocumentDescriptionResponsibility
Device Provisioning ModelBYOD vs vendor-provided, with handset specificationsJD-013 + JD-007
End-to-End Data Flow DiagramProject-specific data flowJD-007
System Architecture DiagramProject-specific clinical trial service delivery architectureJD-007
Study Configuration DocumentAll study-specific configurationsJD-013 + JD-007
Validation ReportCSV evidence for the study-specific setupJD-007
User InstructionsImage capture guidelines, device requirements for site staff/subjectsJD-013
Data Transfer AgreementTransfer method, format, frequency, securityJD-013 + JD-005
User InstructionsProject-specific user instructions (device requirements, image capture guidance, study-specific operational information)JD-013 + JD-004

4.2 PACS/DICOM Clarification​

All study documentation and IFU references must include the following statement:

"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."

Phase 5 — Technical Readiness Review​

5.1 Readiness Gate​

Before any clinical trial goes live, a Technical Readiness Review must be conducted. This review is a mandatory gate and must be documented using T-009-006 Clinical Trial Technical Readiness Checklist.

The review must verify:

  • Device provisioning model documented and communicated to sponsor
  • Minimum handset specifications defined (if BYOD)
  • End-to-end data flow diagram completed
  • System architecture diagram completed or referenced
  • WebApp study-specific configuration documented
  • Validation evidence completed (functional, image capture, data transfer, access control)
  • User instructions prepared
  • Data Transfer Agreement signed
  • Project-specific user instructions prepared and approved
  • PACS/DICOM clarification included in study documentation
  • Anonymization settings configured and tested (if applicable)

5.2 Approval​

The Technical Readiness Review must be approved by:

  • JD-004 Quality Manager & PRRC — Confirms QMS compliance
  • JD-005 Technical Manager & PRRC — Confirms technical readiness
  • JD-013 Project Manager — Confirms all project deliverables are complete

No clinical trial may proceed to production without all three approvals.

Outputs​

OutputDescription
R-009-001Project record containing all study-specific deliverables
T-009-006Completed Technical Readiness Checklist
Data flow diagramProject-specific end-to-end data flow
Validation reportCSV evidence for study-specific setup

Associated Documents​

ReferenceTitle
GP-009Sales
GP-023Change control management
SP-009-004Implementation Plan Helpers
SP-009-005Implementation Plan Helpers for Clinical Trials
SP-009-006Integration Workflow Helpers
SP-009-007Scoring Systems Catalog
T-009-006Clinical Trial Technical Readiness Checklist
Previous
SP-009-010 Customer KPI Definition and Alignment Helpers
Next
GP-010 Purchases and suppliers evaluation
  • Purpose
  • Scope
  • Responsibilities
  • Definitions
  • Procedure
    • Phase 1 — Project Scoping and Device Provisioning
      • 1.1 Device Provisioning Model
      • 1.2 WebApp Feature Scope
    • Phase 2 — End-to-End Data Flow Documentation
      • 2.1 Project-Specific Data Flow Diagram
      • 2.2 System Architecture Diagram
    • Phase 3 — WebApp SDLC and CSV Controls
      • 3.1 Core WebApp Development Controls
      • 3.2 Study-Specific Configuration Management
      • 3.3 Validation Evidence
    • Phase 4 — Study Documentation Package
      • 4.1 Required Study Documents
      • 4.2 PACS/DICOM Clarification
    • Phase 5 — Technical Readiness Review
      • 5.1 Readiness Gate
      • 5.2 Approval
  • Outputs
  • Associated Documents
All the information contained in this QMS is confidential. The recipient agrees not to transmit or reproduce the information, neither by himself nor by third parties, through whichever means, without obtaining the prior written permission of Legit.Health (AI Labs Group S.L.)