Skip to main content

Data transfer

Every study moves data twice: images towards the analysis, and results back to the sponsor or CRO. How the first leg happens depends on whether the images are captured during the study or already exist in an archive. The second leg, the delivery of results, follows the same structure in both cases.

This page describes both use cases. File and folder names are illustrative: the exact medium, schedule, naming, columns and permitted values of each study are fixed in its Data Transfer Specification (DTS), agreed with the sponsor or CRO before the first transfer.

Two use cases, one transfer model​

Prospective studiesRetrospective studies
Where images come fromCaptured during the study in clinicaltrials.legit.health, by site staff or by subjects at homeAn existing archive, captured before the engagement
Who moves the imagesNo upload needed: the images are already on the platformThe sponsor or CRO uploads the archive to the Secure Storage Bucket, typically as one zip
How results are deliveredScheduled deliveries to the Secure Storage Bucket, sFTP or REST APIOne consolidated delivery, downloaded from the same bucket
FrequencyRecurring, as fixed in the DTS (for example, monthly)Typically one-off, after the complete dataset is declared
FormatFrom a single visible_signs_data CSV to every dataset, plus segmentation overlays and a reconciliation fileUpload: a zip with index.csv and the images. Delivery: from a single visible_signs_data CSV to every dataset, plus overlays

Select your study type​

The data flow, the upload and the delivery differ between the two use cases. Choose yours below to see its details.

Data flow​

  1. Image capture: site staff or subjects capture images in clinicaltrials.legit.health.
  2. AI analysis: quality control, scoring and, where the protocol requires it, anonymisation run on the Legit.Health platform.
  3. Scheduled delivery: results are written to the Secure Storage Bucket on the schedule the DTS sets.
  4. Download: the sponsor's or CRO's IT team loads each delivery into the EDC or data warehouse.

Delivery structure​

Every file follows the pattern YYYY-MM-DD-<study_code>-<delivery_id>-<dataset>.csv. Each delivery carries its own delivery_id, identical across its files, so files from two deliveries can never be mixed.

Simplest delivery: a single visible_signs_data file per delivery.

secure-storage-bucket/DEMO01/
├── 2026-07-31-DEMO01-9b2f4c1e-5d7a-4e3b-8c6f-2a1d0e7b3c95-visible_signs_data.csv
├── 2026-08-31-DEMO01-<next delivery_id>-visible_signs_data.csv
└── ...

Complete delivery: every dataset, the segmentation overlays and a reconciliation file that lists what the delivery contains, so the receiving system can confirm it is complete.

secure-storage-bucket/DEMO01/
├── 2026-07-31-DEMO01-9b2f4c1e-5d7a-4e3b-8c6f-2a1d0e7b3c95-framing_data.csv
├── 2026-07-31-DEMO01-9b2f4c1e-5d7a-4e3b-8c6f-2a1d0e7b3c95-bsa_data.csv
├── 2026-07-31-DEMO01-9b2f4c1e-5d7a-4e3b-8c6f-2a1d0e7b3c95-global_scoring_system_data.csv
├── 2026-07-31-DEMO01-9b2f4c1e-5d7a-4e3b-8c6f-2a1d0e7b3c95-visible_signs_data.csv
├── 2026-07-31-DEMO01-9b2f4c1e-5d7a-4e3b-8c6f-2a1d0e7b3c95-diagnosis_support_data.csv
├── 2026-07-31-DEMO01-9b2f4c1e-5d7a-4e3b-8c6f-2a1d0e7b3c95-segmentation_images.zip
├── 2026-07-31-DEMO01-9b2f4c1e-5d7a-4e3b-8c6f-2a1d0e7b3c95-reconciliation.csv
├── 2026-08-31-DEMO01-<next delivery_id>-framing_data.csv
└── ...

Datasets​

Both use cases draw on the same datasets. A study can take the simplest delivery, visible_signs_data alone, or any combination up to the complete set.

DatasetWhat the file holdsGrain
framing_dataEvery standardised view received, its segmentation overlay, and which regions were framed completelyOne row per visit
bsa_dataPer-region affected body surface area, beside the photographs it was derived fromOne row per visit
global_scoring_system_dataPer-region area and severity contributions, and the global score of the scoring systemOne row per visit
visible_signs_dataThe graded visible signs of the scoring systemOne row per photograph and sign
diagnosis_support_dataThe ranked candidate conditions, with their probability and ICD-11 codeOne row per photograph and candidate
segmentation_imagesA zip archive with one overlay per photograph and scoring systemOne image per photograph

Example: visible_signs_data in a psoriasis study​

Each row grades one visible sign of one photograph on the scale of the scoring system (0 to 4 for the PASI signs erythema, desquamation and induration) and carries the image quality score of the photograph. The rows below are the results for trunk-closeup.jpg from the retrospective index.csv example, so timestamp is the visit date that file declared. Delivered files are comma-separated.

study_code,site_code,subject_code,visit_code,diagnostic_report_id,timestamp,expected_condition,expected_condition_icd_11_code,original_filename,original_image_path,original_segmentation_image_path,body_site,body_site_framing,visible_sign,value,image_quality
DEMO01,SITE-001,pt-017,v1,4e7a1c90-2b3d-4f8e-9a61-7c5d2e8f0b13,2025-03-11T00:00:00Z,psoriasis,EA90,trunk-closeup.jpg,<photograph path>,<overlay path>,trunk,closeup,erythema,2,87
DEMO01,SITE-001,pt-017,v1,4e7a1c90-2b3d-4f8e-9a61-7c5d2e8f0b13,2025-03-11T00:00:00Z,psoriasis,EA90,trunk-closeup.jpg,<photograph path>,<overlay path>,trunk,closeup,desquamation,1,87
DEMO01,SITE-001,pt-017,v1,4e7a1c90-2b3d-4f8e-9a61-7c5d2e8f0b13,2025-03-11T00:00:00Z,psoriasis,EA90,trunk-closeup.jpg,<photograph path>,<overlay path>,trunk,closeup,induration,2,87

Key columns​

Every file starts with the same eight key columns, so each row joins back to the clinical database without a lookup table: study_code, site_code, subject_code, visit_code, diagnostic_report_id, timestamp, expected_condition and expected_condition_icd_11_code.

Transfer security​

SafeguardHow it works
Personal, named credentialsOne credential per named individual, never shared, and revoked when that person leaves the study
Access gated by the Data Transfer AgreementCredentials are issued only once the agreement is signed, so no data moves ahead of it
Encryption at rest and in transitAES-256 at rest; TLS 1.3 by default in transit, never below TLS 1.2
Reconciliation on every transferThe receiving party reconciles the file count before the transfer is treated as received

For certifications, data residency and audit trails, see Compliance & Security.