Find the Gaps Between Clinical Systems

Consent-version reconciliation begins with a precise statement of intent: for each subject consent event, confirm that the recorded form version was approved and effective for the subject’s site and country at the event time. That sentence already exposes the required data. The rule needs the study, subject, site, country, consent date and time, form version, approval status, effective date, retirement date if applicable, and the relationship between a central template and any localized form.

The eTMF side may contain several related documents: the master informed consent form, country adaptation, translated version, IRB or ethics approval, site activation evidence, and superseded versions. The rule must select the authoritative approval and effective period for the specific site. A filename match is not enough. The source record’s metadata, lifecycle, version, approval reference, and site or country association are part of the evidence.

The EDC side may record first consent date, re-consent date, consent version, and subject status. An eConsent system may provide stronger execution evidence, including the exact presented version and signature audit trail. When both sources exist, the rule defines their roles rather than treating them as interchangeable. EDC may be the operational subject-event source while eConsent is the execution source. The reconciliation output can state which source established each fact.

Timing logic requires care. A newly approved form may have a future effective date. A site may need documented activation before use. A subject may sign shortly before a synchronization job completes. A protocol amendment may trigger re-consent rather than invalidate the original consent. The rule therefore includes effective-date semantics, time zone handling, allowed synchronization lag, re-consent requirements, and exceptions documented by the customer.

A positive discrepancy is presented in clinical language: the current site form, the subject event, the conflicting version, the relevant dates, and the affected subjects. The agent can create a task for the site CRA and study manager, but it does not decide whether re-consent is required or whether the event is reportable. Those conclusions depend on the protocol, sponsor procedure, ethics requirements, facts of the event, and authorized clinical or quality judgment.

The validation set for this rule includes current-version consents, valid historical consents, re-consents, events during an allowed transition, localized forms, missing versions, incorrectly mapped sites, delayed source updates, and known superseded-version use. Performance is reported at the event level. The most important measures are not only detection rate but also whether every flagged event contains enough evidence for a reviewer to reach the correct next step.

Remote and electronic consent workflows create evidence across several layers. The consent application may record presentation, acknowledgement, signatures, identity steps, timestamps, version, and audit history. EDC may record the subject’s consent date and version. The eTMF may hold the approved form, site-level approval, certificates, close-out package, or a reference to the authoritative repository. The required filing pattern depends on the sponsor’s process and applicable system design.

A reconciliation rule should therefore begin with the records-management decision. Which eConsent artifacts are essential records? Which remain in the validated consent system, which are transferred to the eTMF, and which are referenced? At what milestone should transfer occur? What evidence demonstrates completeness? Without those answers, a generic agent cannot responsibly declare a missing document.

Once the filing model is defined, the product compares executed events with expected evidence. It can identify a completed consent that lacks the required audit certificate, a certificate associated with the wrong site, a version mismatch between the execution record and approved form, or a transfer that has not completed after the accepted window. Each finding preserves the event identifier, subject pseudonym or approved key, site, version, execution time, source-system status, and expected artifact.

Privacy and minimum necessary access are central. Subject identity may not be required for the TMF operations use case. The reconciliation layer can operate on pseudonymous subject keys and retain only the fields needed to establish the discrepancy. Direct identifiers should remain in the source system unless the approved workflow requires them. The architecture documents where protected or personal data is decrypted, processed, logged, and retained.

The product does not convert a technical transfer failure into a clinical conclusion. A missing audit certificate may be caused by a connector backlog, source-system configuration, withdrawn event, or genuine evidence gap. The finding identifies what was expected and what each source reported. The accountable team then determines whether to retry transfer, correct mapping, request source evidence, document an exception, or initiate a broader quality process.

This pattern can be extended to other event-driven evidence such as eCOA end-of-study media, safety-letter distribution, monitoring visits, and final data packages. The reusable structure is an event in one system, an expected record or reference in another, an accepted timing window, identity mapping, and a cited exception workflow.

The reconciliation engine produces a structured finding rather than a generic alert. The finding includes the rule, severity, study scope, involved systems, records compared, statement of agreement or contradiction, source freshness, evidence links, policy reference, proposed owner, due date, and allowed dispositions. The narrative shown to the user is generated from those locked fields so the explanation cannot drift away from the evidence.

Ownership follows the process. A missing protocol signature page may belong to the site CRA. A consent-version discrepancy may require the study manager, data management, and quality input. A connector mapping failure may belong to clinical systems. The product can route work to different systems while keeping one reconciliation record that links the related tasks and final decision.

Severity is not a model sentiment score. It is derived from the customer’s approved risk logic, including subject impact, GCP relevance, inspection impact, recurrence, affected scope, and time. The model can summarize the facts, but the rule determines whether a condition is informational, a watch item, a workflow task, or a blocking escalation. If the required context is absent, the system states that severity cannot be resolved.

Closure requires evidence. A task marked complete in a work-management system does not automatically close the discrepancy. The rule reruns or verifies that the source records now agree, records the new evidence, and preserves the original state and disposition. A documented exception can close the item when policy allows, but the exception reason and approver remain attached.

Metrics distinguish detection from resolution. Useful measures include open findings by age, source, rule and study; time to acknowledgement; time to evidence; reopen rate; recurring mapping failures; confirmed discrepancy rate; false-positive rate; and contribution to readiness. Those measures show whether the system improves oversight or merely creates another queue.

At inspection time, the team can retrieve the finding history, source evidence, rule version, reviewer decisions, remediation, and closure proof. The product is not a substitute for the original records, but it makes the oversight process reconstructable. That is the standard a cross-system intelligence layer should meet.