Reconciling eCOA and EDC: Participant, Visit, and Timestamp Conflicts

When electronic Clinical Outcome Assessment (eCOA) systems and Electronic Data Capture (EDC) systems disagree, trial teams must fix governing reconciliation rules before the first data transfer and treat every subsequent discrepancy as a prespecified exception with a named resolver. Discrepancies fall into three distinct operational categories: participant conflicts arising from separate screening, randomization, and hardware identifiers; visit conflicts caused by schedule-anchored assessment windows diverging from clinic calendar dates; and timestamp conflicts stemming from the temporal gap between offline participant completion and server synchronization.

Under ICH E6(R3) Annex 1 section 4.2.5, discussed further in the ICH E6(R3) endpoint implementation checklist, data reconciliation is the control expected to help electronic data and relevant metadata retain integrity when they move between computerized systems. FDA's 2013 electronic source guidance is conditional: when the participant transmits the instrument to a technology service provider, that service provider database is the source and the participant is the originator; when the instrument writes directly into the electronic case report form, the case report form is the source. EMA computerised-systems guidance treats data saved on the device as the participant's original electronic patient-reported outcome record. The EDC remains the record of site events. Transcribing or editing those eCOA entries inside the EDC breaks the source relationship and records a different originator and time. Both records should remain in their native systems, linked by prespecified cross-reference keys and originator-controlled change procedures.

Modern clinical trials routinely operate multi-system eClinical architectures where endpoint data originate across independent digital tools. In a typical trial setup, participants record symptom scores, pain diaries, or functional questionnaires directly into provisioned handheld devices or personal smartphones through a dedicated eCOA platform. Concurrently, clinical research coordinators and investigators enter physical examination findings, adverse events, concomitant medications, and laboratory scheduling into the EDC platform. While both systems describe the clinical trajectory of the same human subject, they operate under fundamentally different data models, technical environments, and operational schedules.

The structural separation between eCOA and EDC frequently generates data divergence across three foundational dimensions:

• Participant Identification: An eCOA device provisioned during pre-screening may capture data under a temporary screening number (such as S-101), while the EDC and Interactive Response Technology (IRT) systems transition the participant to a permanent randomization number (such as 0417) upon study enrollment.

• Visit Scheduling Architecture: eCOA diaries and assessments are triggered by calendar-day protocol schedules (such as Protocol Day 42 ± 3 days). Conversely, EDC visit forms are anchored to physical site appointments that may shift due to participant availability, site logistics, or weather delays.

• Temporal Measurement Dynamics: eCOA capture occurs contemporaneously in the participant's daily living environment, often while the handheld device is offline. The completion timestamp represents the physiological observation, whereas the central server upload timestamp reflects local network connectivity and synchronization latency.

Historically, trial sponsors treated the reconciliation of external vendor streams as an end-of-study cleanup task before database lock. ICH E6(R3) instead treats reconciliation as a control used as appropriate when data move between systems. Under Annex 1 section 4.2.5 (Data Transfer, Exchange and Migration), as applied in the ICH E6(R3) endpoint implementation checklist, validated processes and other appropriate processes such as reconciliation should be in place so electronic data, including relevant metadata, retain integrity and confidentiality when transferred. The exchange should be documented for traceability, and reconciliation should be implemented as appropriate to avoid data loss and unintended modifications. Section 4.2 also expects the sponsor to identify the data to be collected and the method of collection in the protocol, with further detail, including a data flow diagram, in a protocol-related document such as the data management plan.

Similarly, the EMA's Guideline on computerised systems and electronic data in clinical trials (adopted by the GCP Inspectors Working Group in March 2023) establishes that electronic data flow must be fully described in the protocol or related documentation. Sponsors must explicitly document which data elements are transferred, their technical format, originating and destination environments, authorized user access roles, transfer frequency, and specific quality control actions—explicitly naming validation, reconciliation, verification, and review.

A persistent industry misconception asserts that deploying modern 'native integration' or unified clinical suites eliminates the need for data reconciliation. Commercial software vendors often market automated application programming interface (API) pipelines as proof that data transfers no longer require manual oversight. However, regulatory texts refute this assumption. Transferring data via native API or direct database connector merely changes the mechanical transmission medium; it does not satisfy the requirement to ensure data consistency, identifier mapping, and metadata preservation. As highlighted in peer-reviewed eCOA development guidance published in the Journal of the Society for Clinical Data Management (JSCDM 2025;4:376), integrated architectures demand formal User Acceptance Testing (UAT) across both systems before go-live, including rigorous testing to verify that updates made on the eCOA server are faithfully reflected in the EDC.

flowchart TD
    subgraph ParticipantDomain ["Participant Domain (eCOA)"]
        A["Participant Entry on Handheld Device"] --> B["Device Local Encrypted Storage<br/>(Entry & Save Timestamps)"]
        B --> C["Cellular / Wi-Fi Upload Gateway<br/>(Transaction Timestamp)"]
        C --> D["eCOA Service Provider Server<br/>(Source when data are sent there)"]
    end

    subgraph SiteDomain ["Site & Investigator Domain (EDC)"]
        E["Clinic Site Visit & Assessment"] --> F["Investigator / CRC Data Entry"]
        F --> G["EDC Core Database<br/>(Clinic Event & Form Dates)"]
    end

    subgraph GovernanceLayer ["Clinical Data Management Layer"]
        D --> H["Scheduled Data Transfer Engine (DTA)"]
        G --> H
        H --> I["Reconciliation Engine & Rules Matrix"]
        I --> J{"Reconciliation Status"}
        J -->|"Match"| K["Clean Analytic Endpoint Dataset"]
        J -->|"Conflict Flagged"| L["Prespecified Exception Workflow"]
    end

    subgraph ExceptionPaths ["Resolution Pathways"]
        L --> M["Identifier Mismatch: DTA Mapping & Accountability Log"]
        L --> N["Visit Window Divergence: Protocol Window Evaluation"]
        L --> O["Timestamp Gap: Completion Time Anchor Retention"]
    end

Identifier discrepancies represent one of the most disruptive forms of eCOA-EDC misalignment. In longitudinal clinical trials, a single study participant interacts with multiple software systems that assign unique record keys at different milestones in the trial lifecycle. During pre-screening, the site may provision a handheld eCOA device or register an account under a screening identification number (for example, S-118-04). Once the participant passes eligibility criteria, the Interactive Response Technology (IRT/RTSM) assigns a permanent randomization number (such as 0417), while the physical device retains its factory serial number or vendor device ID.

When external eCOA datasets are transferred into the EDC or clinical data repository, automated matching algorithms that rely solely on subject identification numbers fail. If the eCOA feed carries S-118-04 while the EDC expects 0417, the reconciliation engine flags the record as an orphan participant. Left unaddressed, these orphan records prevent automated data merging, skew safety reporting, and threaten endpoint completeness at interim analyses.

Resolving identifier conflicts requires three prespecified governance controls established before study start:

1. Formal Cross-Reference Mapping Keys in the DTA: The Data Transfer Agreement must define a multi-key cross-reference table linking screening IDs, subject/randomization numbers, and device serial numbers. Data management pipelines must programmatically translate screening keys to randomization numbers based on authoritative IRT enrollment feeds rather than relying on ad hoc manual edits.

2. Regulatory Device Accountability Logs: EMA Guideline Annex A5.1.1.5 expects an accountability log of devices handed to participants that includes the device identification number so the device can be reconciled to a particular participant. Disbursement and return dates are operational fields a site procedure may add; the guideline's stated element is the device identification number. In the hypothetical case, that log is the record used to check whether the device carrying S-118-04 was assigned to participant 0417. It is inspection evidence of custody, not a substitute for the eCOA source record.

3. Strict Misprovisioning Correction Workflows: In real-world site operations, clinical coordinators occasionally commit provisioning errors, such as handing tablet A (configured for participant 101) to participant 102. When such errors occur, site personnel must never attempt to resolve the issue by transcribing or re-entering the participant's questionnaire responses under the correct ID. Re-entering responses obliterates the participant's original electronic touch events, destroys audit trail timestamps, and violates basic ALCOA+ principles.

Instead, misprovisioned device corrections must follow a formal, documented Data Change Request (DCR) process. As documented in peer-reviewed recommendations from the Journal of the Society for Clinical Data Management (Delong et al., JSCDM 2023;2(1):249), the site must file a technical realignment request with the eCOA vendor to re-link the device's historical database records to the proper participant identifier. The vendor executes the re-association in the backend database, generating a full audit trail record that documents the administrative justification, Principal Investigator sign-off, and exact time of reassignment.

Visit discrepancies occur when eCOA and EDC systems assign divergent visit labels or calendar dates to the same clinical evaluation. The root cause lies in contrasting scheduling architectures: eCOA systems are primarily schedule-anchored (governed by mathematical protocol day counters), whereas EDC systems are event-anchored (governed by physical clinic attendance).

Consider a protocol requiring a weekly patient-reported outcome questionnaire at Week 6. The protocol specifies that Week 6 corresponds to Protocol Day 42, with an allowable assessment window of ± 3 calendar days (Days 39 through 45). The participant completes their digital diary on Tuesday evening (Day 42). However, due to the investigator's clinical schedule, the participant attends their on-site clinic appointment on Thursday (Day 44), where the study coordinator creates EDC 'Visit 7 - Week 6' dated Day 44.

When the EDC data management system ingests the eCOA transfer, a naive reconciliation script compares the eCOA completion date (Tuesday) against the EDC visit date (Thursday) and generates an automated discrepancy query: 'Assessment date does not match visit date.' In inexperienced clinical teams, this triggers a cascade of unnecessary site queries, causing study coordinators to alter form dates or query participants about why their dates do not align.

Clinical data managers must operationalize the non-discrepancy principle: an eCOA assessment completed inside the protocol window is not a reconciliation discrepancy merely because its completion date differs from the clinic visit date. That rule is an operational classification, not a finding that the score is clinically or regulatorily meaningful. The calendar divergence does not constitute a data discrepancy; it reflects the expected operational separation between at-home patient reporting and on-site clinical evaluation.

To prevent systemic visit mismatches, trial teams must establish robust alignment rules before study initiation:

• Standardized DTA Visit Mapping Schemes: The DTA must include an exhaustive visit mapping matrix that explicitly pairs eCOA assessment schedule names (e.g., 'W6_PRO_DIARY') with EDC visit names (e.g., 'VISIT_07_WK06'). Ambiguous naming conventions or mismatched visit numbering between vendor systems guarantee automated query generation.

• Protocol and SAP Endpoint Window Definitions: The trial protocol and statistical analysis plan should define target days and operational windows for each endpoint that uses this assessment. The plan should state which timestamp anchors window classification. For this eCOA pattern, that anchor is the participant's completion date, not the clinic visit date. What a plan must lock before unblinding is covered in the statistical analysis plan article.

• Selective Query Thresholds: Reconciliation queries should be reserved strictly for genuine protocol breaches. Legitimate triggers include: (a) eCOA completions that fall completely outside the protocol-allowable window; (b) scheduled clinic visits with no corresponding eCOA assessment; or (c) duplicate eCOA submissions within a single visit interval that lack clear primary designation.

As highlighted in peer-reviewed recommendations in the Journal of the Society for Clinical Data Management (Amatya et al., JSCDM 2025;4:376), reviewing the temporal uploading pattern of eCOA devices is critical for operational surveillance. If devices consistently upload data only on the day of the site visit, it often signals that participants are completing questionnaires retrospectively in the clinic waiting room—violating protocol recall windows—or that participants lack cellular connectivity at home.

Timestamp conflicts introduce profound regulatory and evidentiary dilemmas into clinical data reconciliation. In modern eCOA architectures, an electronic observation is associated with multiple distinct temporal markers:

1. Participant Completion Timestamp: The exact local date, hour, minute, and second when the participant touched the device screen and finalized the questionnaire. This represents the true clinical observation time.

2. Local Storage Save Timestamp: The moment the encrypted assessment record was committed to the non-volatile physical memory of the handheld device.

3. Transmission / Synchronization Timestamp (Transaction Time): The date and time when the device established network connectivity (via cellular modem or Wi-Fi) and successfully transmitted the encrypted payload to the central vendor database.

4. EDC Ingestion / Visit Date: The administrative date recorded by the site coordinator or the automated timestamp generated when the batch transfer script loaded the data into the EDC.

When a participant completes an assessment offline—such as in an area with poor cellular coverage—a substantial temporal delay can occur between completion and server upload. For example, an assessment completed on Tuesday at 21:42 may not synchronize until Wednesday at 09:03 when the participant leaves home. When the data transfer arrives in the EDC, the data management team sees a transaction dated Wednesday, while the site's clinical record notes a Tuesday milestone.

Which timestamp anchors the endpoint? The cited guidance separates the observation from the transfer, and the protocol or statistical analysis plan still has to name the anchor. Under the FDA's 2013 guidance Electronic Source Data in Clinical Investigations (September 2013), when a participant uses a digital instrument to transmit data elements to a technology service provider database, the service provider database is the electronic source record. Furthermore, data element identifiers must capture who entered the data and exactly when it was entered. The participant is the legal data originator, and their completion timestamp represents the authentic clinical observation.

This principle is reinforced in Europe by EMA Guideline Annex A5.1.1 (ePRO). The EMA explicitly establishes that data saved on the device is the original record created by the trial participant. The guideline says locally stored data should not be edited or changed without the data originator's knowledge before saving, and that any changes should be acknowledged by the originator and documented in an audit trail. It expects the timestamp of data entry and the timestamp of saving to be recorded as metadata, and it expects the duration between local capture and upload—the transaction time—to be short and traceable.

From an audit trail perspective, 21 CFR 11.10(e) requires secure, computer-generated, time-stamped audit trails that independently record the date and time of operator entries and actions that create, modify, or delete electronic records, and record changes must not obscure previously recorded information. How trial teams assemble that eCOA evidence is covered in the Part 11 eCOA evidence guide. In its final October 2024 guidance, Electronic Systems, Electronic Records, and Electronic Signatures in Clinical Investigations: Questions and Answers, the FDA elaborates on these statutory expectations across three critical sections:

• Question 12 (Audit Trail Components): The guidance states that audit trail components include the date and time of entry or modification, the individual making the change (for example user ID and user role), and the old and new values, and that the audit trail should include the reason for the change. The decision to review audit trails should be based on a risk assessment of the investigation, the systems, and the controls in place. Audit trail documentation must be available for FDA inspection.

• Question 14 (System Date and Time Controls): Controls should be in place so the electronic system's date and time are correct. People with system administrator roles should be notified if a date or time discrepancy is detected, the ability to change the date or time should be limited to authorized administrators, and those changes should be documented. For investigations that span time zones, the sponsor should indicate the time zone of the stamp or state that times are recorded as Greenwich Mean Time. The guidance does not prescribe Network Time Protocol or automatic hardware alerts.

• Question 22 (Durable Repositories and Metadata): Clinical data captured by digital health technologies and all relevant associated metadata must be transmitted via a validated process to a durable electronic data repository (such as the EDC or cloud data platform). Complete audit trail metadata must accompany copies provided for regulatory review.

The critical operational conclusion is clear: delayed synchronization is operational latency, not missing data. An assessment stored securely in local device memory and uploaded after a network delay remains fully contemporaneous. Site coordinators and data managers must never attempt to 'back-fill' missing records, alter device clock settings, or manually re-enter delayed records into the EDC. The reconciliation pipeline must record the completion timestamp as the clinical observation anchor and retain the upload timestamp as technical traceability metadata.

To illustrate how these governance principles operate during active trial conduct, consider a clearly hypothetical clinical trial scenario involving an oncology study evaluating patient-reported symptom burden.

In this hypothetical scenario, participant randomization number 0417 is scheduled for a Week 6 endpoint evaluation. During pre-screening, the participant was provisioned a cellular-enabled tablet under screening identification number S-118-04. On Tuesday evening at 21:42 (Protocol Day 42), the participant completes their weekly symptom questionnaire at home. However, due to local cellular tower maintenance, the tablet buffers the encrypted response in local flash memory. The device successfully synchronizes with the vendor cloud server the following morning, Wednesday at 09:03. On Thursday morning (Protocol Day 44), the participant attends the clinic for routine bloodwork, physical exam, and EDC 'Visit 7 - Week 6' documentation.

When the weekly automated reconciliation job runs on Friday, participant 0417 flags three simultaneous discrepancy alerts across the eCOA-EDC data pipeline:

1. Identifier Mismatch Alert: The eCOA upload payload carries screening key S-118-04, whereas the EDC target domain expects randomization ID 0417.

2. Visit Mapping Mismatch Alert: The eCOA record contains 'Week 6 Assessment' completed on Tuesday, while EDC Visit 7 is logged on Thursday.

3. Timestamp Discrepancy Alert: The eCOA server receipt timestamp reads Wednesday 09:03, conflicting with the participant's Tuesday 21:42 completion timestamp and the site's Thursday visit date.

Table 1 defines the operational resolution matrix for participant 0417, detailing the detection signal, underlying root cause, assigned resolution owner, permitted record actions, and required audit documentation.

In traditional clinical data management, data discrepancies identified in EDC forms are resolved through automated or manual queries routed to site coordinators, who review hospital source notes and issue data corrections. However, this model completely collapses when applied to electronic Patient-Reported Outcomes. Site coordinators, investigators, clinical research associates, and data managers should not alter participant-entered eCOA data on their own authority.

Under FDA's 2013 eSource guidance and EMA Guideline Annex A5.1.1, the participant is the sole data originator for ePRO instruments. Modifying patient-reported symptom scores, quality-of-life assessments, or diary entries without documented originator involvement violates fundamental ALCOA+ principles (specifically Attributability, Originality, and Accuracy).

To establish an inspection-ready framework for handling incorrect or erroneous participant entries, the Society for Clinical Data Management published comprehensive consensus recommendations in the Journal of the Society for Clinical Data Management (Delong et al., JSCDM 2023;2(1):249). The consensus establishes clear procedural boundaries:

1. Originator-Initiated Data Change Requests (DCR): Changes to participant-entered data may only occur if the participant realizes an error was made (for example, accidentally selecting 'Severe Pain' instead of 'No Pain') and proactively communicates the error to site staff. The conversation must be documented contemporaneously in site medical notes, recording the date, time, and specific justification provided by the participant.

2. Principal Investigator Review and Sign-Off: Any request to modify participant-entered data requires formal review and written approval from the site Principal Investigator. The PI must attest that the participant requested the change and that supporting medical documentation corroborates the rationale.

3. Preservation of Recall Periods and Measurement Windows: Data change procedures must respect the psychometric recall period of the outcome measure. If a participant attempts to correct a 24-hour symptom recall diary two weeks later, the retrospective change is psychometrically invalid. In such cases, the original entry must stand, and the participant's clarifying statement should be captured as an explanatory note rather than an overwriting data change.

4. Structured Escalation and Dispute Resolution: If a sponsor or data management lead questions the clinical plausibility of a participant entry, they cannot unilaterally overwrite the record. If the site investigator and sponsor disagree regarding a proposed correction, the dispute must follow a documented decision path defined in the DMP, with unresolved discordance evaluated via statistical sensitivity analyses rather than arbitrary overrides.

When a valid DCR is approved, the change must be executed within the eCOA system by authorized vendor data management personnel. The system's audit trail must independently record the operator ID, timestamp, original value, revised value, and the full text of the participant-approved justification, ensuring complete transparency during regulatory audits.

Reconciliation exceptions should not be viewed merely as administrative chores to be cleared before database lock. Repeated identifier, window, or sync patterns can be inputs to centralized review. How endpoint risks become monitoring signals is covered in the risk-based monitoring article.

Under section 6.2.1 of the EMA computerised systems guideline, sponsors and responsible parties must maintain continuous oversight of delegated trial duties, explicitly citing the routine review of defined Key Performance Indicators (KPIs) and data reconciliations. Similarly, the FDA's 2024 Q&A guidance emphasizes that audit trail review should be ongoing, structured, and proportional to trial risks. Transforming reconciliation outputs into operational review signals allows clinical operations teams to intervene before systemic errors compromise trial integrity.

Clinical teams should track four critical reconciliation metrics throughout trial execution:

• Synchronization Latency (Transaction Gap): Monitoring the median duration between local data capture and server upload. An increasing transaction gap across a specific clinical site often reveals that site staff fail to instruct participants to connect tablets to Wi-Fi, or indicates regional telecommunication outages requiring site-based hot-spot provisioning.

• Identifier Mismatch Rates: Repeated orphan records or identifier mismatches from a specific site indicate poor device disbursement discipline, signaling an immediate need for clinical research associate (CRA) retraining on device accountability logs.

• Out-of-Window Assessment Velocity: A cluster of eCOA assessments completed outside protocol-allowable windows highlights participant scheduling burden, confusing diary alarm configurations, or protocol visit scheduling constraints that may warrant a protocol amendment.

• Data Change Request Frequency: Elevated DCR volumes from a specific site or language cohort may uncover poor participant onboarding, confusing questionnaire user interface layouts, or linguistic translation ambiguities that mislead participants.

As trial conduct nears completion, reconciliation procedures transition into rigid study close-out gates. In accordance with ICH E6(R3) Annex 1 section 4.2.6 (Finalisation of Data Sets Prior to Analysis), data finalization must follow pre-specified procedures that encompass the complete reconciliation of entered data, data sets, and relevant databases. The guideline's essential records inventory explicitly requires retention of data finalization documentation, including query resolutions, Serious Adverse Event (SAE) reconciliation records, and quality control reports.

The same JSCDM paper treats study close-out as requiring that eCOA data are synced and transmitted to the server, that outstanding queries are closed, that access is restricted, and that final transfers and archiving are completed. Those are consensus close-out checks, not a statute that blocks database lock, and they do not add a separate hardware de-provisioning requirement.

The most effective strategy for managing clinical data reconciliation is prevention. Establishing explicit data architecture, transfer specifications, and reconciliation rules before the first subject is enrolled eliminates the vast majority of cross-system discrepancies. Clinical teams must lock ten core governance assets across the Data Management Plan (DMP), Data Transfer Agreement (DTA), and Statistical Analysis Plan (SAP) prior to system go-live.

1. Comprehensive Data Flow Diagram (DMP): Develop an end-to-end diagram illustrating data movement from participant handheld devices through local memory, transmission gateways, vendor cloud repositories, and the EDC, as mandated by ICH E6(R3) 4.2 and EMA computerised systems guidelines.

2. Explicit Transfer Specifications (DTA): Define the exact dataset structure, variable naming conventions, file formats (e.g., SAS transport, CSV, CDISC ODM-XML), transmission encryption protocols (SFTP/HTTPS), transfer frequency (e.g., daily or weekly batch), and authorized recipient access lists.

3. Mandatory Pre-Go-Live Test Transfer (DTA): Conduct a full end-to-end dry run transfer using synthetic User Acceptance Testing (UAT) data immediately following DTA finalization. Verify that automated ingestion scripts parse variable types, handle null values, and map keys without syntax errors.

4. Multi-Key Identifier Mapping Specification (DTA): Establish programmatic translation rules linking screening numbers, permanent subject randomization keys, and hardware serial numbers, supported by on-site device accountability logs.

5. Visit Naming and Window Classification Matrix (DTA & SAP): Construct an exhaustive table pairing eCOA assessment labels with corresponding EDC visit forms. Define exact protocol day target dates and operational windows (± days) in the SAP to automate non-discrepant window evaluation.

6. Authoritative Timestamp Hierarchy (DMP & SAP): Explicitly designate the participant completion timestamp as the primary clinical observation anchor for efficacy analyses. Classify server synchronization timestamps as operational metadata and forbid manual backfilling.

7. Role-Based Discrepancy Resolution Matrix (DMP): Assign unequivocal responsibility for every discrepancy type. Specify which exceptions are resolved programmatically by data management, which require vendor intervention, and which require site CRA clarification, establishing strict resolution turnaround targets.

8. Native Integration Reflectance Testing (UAT & DMP): For platforms utilizing direct API integrations, conduct bidirectional UAT verifying that data updates, corrections, and query flags executed in the eCOA vendor database reflect accurately inside the EDC interface.

9. Originator Data Change Request SOP (DMP): Document formal procedures governing how participant error realizations are captured, reviewed by the Principal Investigator, and executed within the vendor audit trail, adhering to JSCDM 2023 consensus principles.

10. Protocol Amendment Maintenance and TMF Filing (DMP & SAP): Update the data management plan and transfer agreement when a protocol amendment changes visit schedules, questionnaires, or endpoint definitions. File final transfer agreements, test-transfer logs, reconciliation reports, and resolution records with the trial master file. Filing practice is covered in the TMF Reference Model article. Data-management artifacts, including the data management plan, sit in Zone 10 (Data Management). Zone 4 is IRB or IEC and other approvals.

By embedding these ten governance controls into the study's core operational contracts, clinical development teams transform cross-system reconciliation from a chaotic, reactive burden into an orderly, inspection-ready quality system that preserves data integrity from first participant entry to final regulatory dossier.