Insulin Delivery CSV Data-Management and Chain-of-Custody Procedure

Field	Value
Official source covered	BionicLoop app exported insulin-delivery CSV
Supporting source	Clinical-gated exact-session recovery ZIP containing the CSV and matching algorithm files
Scout role	Corroborating monitoring and gap investigation; not the official insulin-delivery outcome source
Status	ZIP/CSV collection, transfer, and storage approved 2026-09-03; detailed operational procedure retained for controlled use
Date	2026-09-08

1. Purpose and Scope

This procedure controls collection, integrity review, transfer, retention, and use of the BionicLoop insulin-delivery CSV identified as the official insulin-delivery outcome source. It applies to every participant phone and algorithm session used for study data.

Adverse events and other required safety events are outside the CSV outcome record. The proposed study-document wording identifies the EDC/eCRF entered by study staff as the official safety-event record. Source information may come from participant report or assessment and medical-record review, and the investigator determines causality and relatedness to the study device and protocol. The study's controlled safety-reporting procedure remains the authority for those operations.

2. Roles

Function	Responsibility
Study site/clinical operator	Export the correct session, record the source identity and time, and transfer the original package without editing it
Data Management	Receive, hash, inventory, validate, query discrepancies, preserve originals, and produce analysis copies
Software Developer	Maintain the export definition, assist with technical reconstruction, and assess software anomalies without modifying source records
Sponsor	Approve cadence, destination, retention, access, reconciliation rules, and final data disposition

3. Collection Preconditions

Before export, the operator records:

• participant/subject identifier
• study phone/device identifier
• installed BionicLoop version/build and study-build designation
• algorithm session start time or epoch identity
• export date/time and time zone
• operator identity
• reason for collection: scheduled, treatment-period end, device transition, anomaly investigation, or study closeout

The exact routine export cadence and required treatment-period checkpoints must be defined in the approved protocol or data-management plan before first participant use.

4. Export and Original Record

1. Use the clinical-gated Recent Dose Steps export.
2. Select the intended algorithm session by its displayed start date/time.
3. Export the generated ZIP. The ZIP must contain the session CSV and may contain only the matching legacy algorithm artifacts; partial algorithm-file presence does not invalidate a complete CSV.
4. Do not open and resave, filter, rename internal files, or edit the original CSV.
5. Calculate SHA-256 for the original ZIP immediately after receipt in the controlled study repository.
6. Record the hash, original filename, byte size, source details, operator, collection time, receipt time, and controlled storage locator in the data inventory.

An empty archive, missing CSV, wrong participant/session, or archive that contains files from more than one algorithm session is not accepted as an official source record and requires a data query.

5. Integrity and Completeness Review

Data Management verifies and records:

• ZIP integrity and reproducible SHA-256
• filename/session identity against the operator record
• CSV header/schema identity and readable row structure
• expected session start/end coverage
• monotonic algorithm-step progression, with replay/attribution rows interpreted using their evidence fields rather than wall-clock order alone
• duplicate rows, missing ranges, impossible values, or unexplained session changes
• relevant reconciliation/evidence labels for canceled, interrupted, assumed, or fallback delivery
• comparison to pump records when required by the protocol/data plan

Observed gaps or discrepancies create a controlled data query. The original file remains immutable. Any corrected or derived dataset receives a new identifier, transformation record, preparer/reviewer, date, and link to the original hash.

6. Recovery and Corroboration

If the official CSV cannot be exported or appears incomplete:

1. preserve the phone and original session state where possible;
2. repeat the exact-session recovery export without resetting participant data;
3. use matching algorithm files, retained local evidence, pump history, and sequence-correlated Scout records to investigate the gap;
4. document every source and assumption in the data query;
5. do not silently substitute Scout telemetry for the official CSV.

7. Transfer, Access, and Retention

• Transfer only through the sponsor-approved protected study-data channel.
• Limit access to authorized study, Data Management, technical, and regulatory personnel with a documented need.
• Retain the immutable original ZIP, its hash/inventory record, data queries, and derived-dataset lineage for the period defined by the protocol, sponsor policy, and applicable IDE record-retention requirements.
• Record any copy, movement, or disposition that changes the controlled storage locator.

8. Approval Record

Approval	Controlled approval reference	Date
ZIP/CSV collection, transfer, and storage approach	Camille Powe, MD, controlled correspondence in the Bionic Loop Software - Final Approvals thread	2026-09-03
Software-package technical review	Edward R. Damiano, PhD, final software-package approval in the Bionic Loop Software - Final Approvals thread	2026-09-07 EDT

These controlled references replace handwritten signatures for this software-package procedure. Study operations retain responsibility for following the protocol/data-plan cadence and sponsor-controlled storage rules.