On March 14th, protocol version 1.3 approved a change to the visit 4 window, from Day 28 plus or minus 3 days to Day 28 plus or minus 5 days, and added a safety follow-up call at Day 90. The eTMF was updated that week, but the EDC database remained unchanged until Day 47 of enrollment, when monitoring identified queries on compliant visit 4 records. By then, 11 patients had been assessed under the old window. The discrepancy led to a protocol deviation report, a partial lock for affected records, and three days of targeted CDM review.
Many study teams encounter some form of this incident. Protocol documents are controlled in eTMF systems with version histories, approval workflows, and audit trails. EDC databases are managed separately, often by another team, with a separate change control process and internal version scheme. The gap between document version and database version is operational, not theoretical, and it creates downstream consequences when no one manages it.
Two Versioning Systems Running in Parallel
eTMF version control treats the protocol as a regulatory document. Each approved version carries an effective date, a change summary, and approval signatures. The eTMF knows that version 1.3 replaced version 1.2 on March 14th. It does not know whether the corresponding EDC window change was implemented before or after that date, or whether it was implemented at all.
EDC versioning tracks the study build as a configurable system. Most EDC platforms provide some change control, such as a formal audit trail in Medidata Rave or version history in Veeva Vault EDC. These records show what changed in the database and when. They do not show whether a protocol amendment required the change, which protocol version authorized it, or whether every affected object was updated.
The link between the systems depends on the study team's process. After an amendment is approved, someone must interpret it, identify the required EDC changes, implement them, and check that the work is complete. This process is manual, varies by organization, and offers no automated confirmation that every protocol-mandated change reached the database.
What Amendment Implementation Misses
The most frequent missed changes result from underestimating scope. A data manager receives an amendment summary and implements the explicitly listed items. The summary may not list secondary effects, including edit checks tied to a changed window, derived variables dependent on the assessment schedule, or cross-visit calculations built around the original timepoints.
Take a visit window change. The summary states: "Visit 4 assessment window modified from Day 28 +/- 3 to Day 28 +/- 5." Updating the EDC visit window field addresses the direct change. It may not address the edit check for dates outside the window, the related check on the laboratory form, the visit date compliance variable used in the primary analysis dataset, or the schedule deviation coding rule in the data management plan. Each item depends on the window definition, but none may be obvious from the amendment summary.
A second category is timing drift. Amendment work competes with active query resolution, data review, and team coordination. A data manager may plan implementation for the following week, then be pulled into a more urgent issue. The eTMF records approval while the database remains unchanged for another two weeks. Data collected during that interval may be technically non-compliant with the approved protocol version.
Why the Gap Is Wider Than It Appears
Teams often minimize the version gap because each delay is short and appears manageable. A one-week lag on a window change may not create an immediate crisis. The risk accumulates over a study with three or four amendments, each carrying a one to two week implementation lag and some missed secondary changes. The database can become a hybrid of the original protocol and partial implementations of later amendments.
During a monitoring visit or audit, the database is reviewed against the current approved protocol version. A hybrid database does not map cleanly to one version. The discrepancies then require explanation, documentation, and sometimes deviation reports. The EDC audit trail shows when database changes occurred, but not which protocol version authorized them or whether implementation was complete.
We are not saying that partial amendment implementation is always detectable or consequential. In some studies, the gap is small and the affected data are sparse enough to have no material analytical effect. In studies with tight compliance windows, composite endpoints requiring consistent measurement timing, or regulatory filings subject to close audit trail review, however, the gap between document and database version is a real risk factor.
The Structural Problem: Amendments Change the Protocol Level
The underlying problem is that a protocol amendment changes a document, while an EDC amendment changes a system. No shared representation necessarily connects them. When a protocol section changes, its database implications remain implicit in the text rather than being listed in a machine-readable form. A data manager must interpret the amended section, identify affected database objects, and determine the appropriate change for each. This repeats the interpretive work of the original build, but only for the changed section.
When the original build comes from a structured digitization process, amendment work can use that same process. The amended protocol section generates a diff against the structured representation of the original. The diff shows which parsed objects changed and how. The data manager reviews that output instead of rereading the full protocol to determine scope. Secondary implications, including edit checks, derived variables, and related forms, are surfaced by the diff rather than reconstructed from memory.
This is the version control model Concordare is pursuing in its early-access pilot program. It does not replace data manager judgment about whether a proposed database change is appropriate. It reduces the manual work of locating the change scope. That scope-finding step is where gaps arise, and it is the part that can be addressed with better tooling.
What Good Protocol Versioning Looks Like in Practice
Teams with strong version management usually handle several steps differently from teams where the gap grows over time.
First, amendment impact assessment is formal rather than informal. When an amendment arrives, the team explicitly identifies the changed protocol sections, the EDC objects affected by each change, and the secondary implications. The assessment is documented and reviewed before database changes begin. It becomes the implementation specification.
Second, implementation has a defined completion criterion. The EDC change is not complete when the primary objects are updated. It is complete when the impact assessment has been checked against the implemented changes. That verification can catch missed secondary effects before they generate queries.
Third, the eTMF version and EDC change are linked explicitly. EDC change control records reference the amendment number and effective date. The eTMF amendment record references the EDC change order. Cross-references connect the systems instead of relying on memory about when work occurred.
These practices are straightforward in principle but difficult to maintain under study pressure. An amendment may arrive during UAT, a high-query-volume period, or a lead data manager's conference attendance. The documented process can become a quick fix that is implemented and noted informally. That is when the version gap expands.
The protocol versioning problem is not simply a matter of discipline or carelessness. It reflects a tooling gap: the protocol document and EDC database have no native connection. Until that connection is available, teams must manage the relationship manually, leaving them exposed to delayed implementation, incomplete scope, and downstream compliance issues.