Multi-Site Research Data Governance: Preventing Drift

It's month 24 of a 36-month consortium. Three sites have collected data. Two sites updated their schema after pilot phase; the third didn't get the memo. The DMP committed to FAIR-aligned outputs but the consortium's shared dashboard pulls from a fourth canonical version maintained by the lead site. Final report writing starts in 8 weeks. The numbers in the dashboard, the numbers the partners report locally, and the numbers that will appear in the final report are about to disagree — and nobody is looking.

This is what multi site research data management failure actually looks like: not catastrophic, just slow drift. Each site does the right thing locally; the consortium-level coherence breaks down in the seams. By final review, reconciling the discrepancies takes weeks the project doesn't have.

This post is a governance framework for consortium-scale research data management. It covers the three places drift accumulates, the artefacts that prevent it, and the operating cadence that keeps a multi-site project's data coherent from kickoff to closeout.

The three drifts that derail consortia

After working with EU-funded consortia, multi-institution academic collaborations, and clinical research networks, the same three drift patterns appear in almost every multi-site project.

Drift 1: DMP-vs-data drift

The Data Management Plan was written at proposal time. It committed to specific schemas, specific quality controls, specific deposition targets. Twelve months in, the actual data has 5 fields nobody documented, the QA rules are applied inconsistently across sites, and the deposition target nobody updated when CORA's portal was renamed.

The DMP and the data have drifted apart. At review, the funder sees a pristine DMP and a messier reality, and either the DMP needs retroactive updating (annoying but recoverable) or the data needs retroactive cleanup (expensive). Either way, the gap exists because nothing forced the DMP and the data to stay in sync.

Drift 2: Site-to-site drift

Site A applies an exclusion criterion at ingestion. Site B applies the same criterion at analysis time. Site C applies a slightly different version of it because their PI interpreted the SOP differently. All three are reasonable; none of them produce comparable data.

Site-to-site drift is the most common and the most expensive. It compounds as the project goes on, and by closeout the consortium has either undocumented inter-site differences (bad for the report) or weeks of reconciliation work (bad for the timeline).

Drift 3: Operations-vs-reporting drift

The consortium runs a live dashboard. Site PIs use it weekly. The dashboard counts active enrolments using one definition; the final report uses another. Both are defensible — operations cares about who is currently in the cohort, reporting cares about who completed the protocol — but the two numbers will never match unless someone explicitly defines and documents both.

When operations and reporting drift, the consortium has to spend the last quarter explaining why the dashboard said 412 and the report says 387. That conversation is the difference between a clean closeout and a defensive one.

The governance artefacts that prevent drift

Multi-site consortia don't fail because they lack tooling. They fail because they lack governance — written agreements about who owns what, when changes happen, and how decisions are recorded.

The governance pack that actually works is small. It has six artefacts.

Artefact 1: A canonical schema document, version-controlled

Not the DMP, not a section of the DMP, not a Wikipedia-style description. The actual schema: column names, types, allowed values, units, required vs optional, controlled vocabularies. Versioned in the consortium's repository. Every site validates their data against this schema before submitting to the canonical store.

When the schema changes (and it will), the change is a pull request: documented, reviewed by the consortium data lead, version-bumped, communicated.

Artefact 2: A consortium data-flow diagram

A single picture showing: which sites collect what, where data flows, where the canonical merge happens, which derived datasets exist, where the dashboard reads from, where the final report sources figures from. Annotated with the responsible person at each box.

This diagram is the single most under-produced governance artefact in research consortia. It costs an afternoon to draw and saves weeks of "wait, where does that data live?" conversations.

Artefact 3: A versioned QA rule set

Quality controls — exclusion criteria, missing-data thresholds, outlier handling, data-cleaning rules — written as code that runs at ingestion. Same rules, same code, every site. Disagreements about rules become version-control conversations, not Slack threads that nobody can find six months later.

Artefact 4: A definitions registry

Every metric the consortium reports — "active participant", "completed protocol", "primary outcome" — has a precise definition with the SQL or pseudocode that produces it. Operations dashboards and final-report figures both pull from this registry.

When two metrics drift, the cause is always one of two things: same name pointing to different definitions, or same definition computed differently at two sites. The registry kills both.

Artefact 5: A change log

Every change to schema, QA rules, definitions, or DMP commitments is logged with: what changed, who decided, when, why. Version-controlled. Visible to all sites. Funder-auditable.

This is a 30-second-per-change cost that prevents the most expensive closeout question: "why did this number change between mid-term and final report?" With the change log, the answer is documented. Without it, the answer is "we don't know, it just did".

Artefact 6: The site-data DUA-DMP-DSA chain

The Data Use Agreement (DUA), the Data Management Plan (DMP), and the Data Sharing Agreement (DSA) are three documents that consortia treat separately and shouldn't. Each names the same data, the same parties, and the same obligations from a different angle. The chain matters: a DUA permits use, the DMP describes processing, the DSA governs distribution. When they disagree — and they often do, because they were drafted at different times by different lawyers — the consortium has a compliance gap nobody owns.

The fix: a single page that maps DUA terms to DMP commitments to DSA clauses. Every dataset in the consortium can be traced through all three documents from a single anchor.

The operating cadence

Governance artefacts without cadence are bookshelf documents. The cadence that keeps consortium data coherent is unfashionable but works.

Weekly (data lead + site data managers): schema and QA rule changes, ingestion failures, definition disputes. 30 minutes, structured agenda, decisions logged in the change log.

Monthly (consortium-wide): dashboard review, definition reconciliation between operations and reporting, upcoming reporting milestones. 60 minutes.

Quarterly (PI level): DMP-vs-data alignment review, FAIR-readiness check, deposition status, change-log audit. 60 minutes.

At each reporting milestone: schema freeze, QA rule freeze, definitions freeze. The data submitted to the funder reflects a specific frozen version of the governance pack. After the milestone, the freeze lifts and changes resume.

The cost of this cadence is roughly 2–3 hours/month for the consortium data lead and 30 minutes/month for site data managers. The benefit is that final reporting takes weeks, not the last quarter.

What this looks like in tooling

The governance framework above is tooling-agnostic. Most consortia we work with implement it with these stacks:

| Function | Practical choice | Why | |---|---|---| | Schema definition | YAML / JSON Schema / Pydantic models in a Git repo | Versioned, diff-able, machine-readable | | QA rules as code | Python (pandas + custom validators) or R (assertr / pointblank) | Same code runs at every site | | Canonical data store | Postgres / Parquet on a shared object store | Queryable, snapshottable, auditable | | Dashboards | Metabase / Grafana / Looker Studio | Read from canonical store, not site-local copies | | Documentation | Markdown in the same Git repo as code | Documentation lives where the work happens | | Change log | CHANGELOG.md or GitHub releases | Version-controlled, link-friendly for funder audits | | Workflow orchestration | Make / Snakemake / Airflow (only if scale demands) | Pick the simplest that handles your data volume |

The governance is what matters. The tooling is interchangeable.

When to bring in external capacity

A multi-site consortium engagement is the right move when:

• Three or more sites are collecting data with no consortium-level data lead in place
• The DMP committed to FAIR / open-data outputs but the implementation hasn't started
• Mid-term review is approaching and inter-site reconciliation has surfaced as a risk
• The consortium has budget for a research-data-management partner but no headcount to hire one
• Operations dashboards and reporting figures are about to need to agree

For smaller engagements (one site, no consortium dynamics), most of this framework is overkill — the simpler research data management patterns we've written about elsewhere are the right starting point. Multi-site is where governance complexity earns its keep.

A 90-minute consortium audit

Block 90 minutes with the consortium data lead (or, if there isn't one, with the lead-site PI). Score:

| Question | Score 0–2 | |---|---| | Is there a single canonical schema document, version-controlled? | | | Is there a data-flow diagram showing all sites + canonical merge points? | | | Are QA rules implemented as code that runs at every site? | | | Is there a definitions registry for every reported metric? | | | Is there a change log capturing schema / QA / definition changes? | | | Are DUA, DMP, and DSA documents mapped to a single per-dataset anchor? | | | Is there a weekly data-coordination meeting? | | | Is there a quarterly DMP-vs-data alignment review? | |

Total out of 16. Below 8: serious governance gap, expect drift to materialise at next reporting milestone. Below 4: bring in external capacity now.

Where Pragma fits

We deliver multi-site consortium governance setups for grant-funded research projects. Typical engagement: 6–10 weeks for a 3–5-site consortium. Output is the six governance artefacts above, the tooling implementation, and a documented operating cadence the consortium runs after we exit. We've done this work for EU-funded consortia and academic research collaborations across health, neuroscience, and policy domains.

If you have a multi-site consortium where data drift is starting to surface, that's the engagement we exist for.

Three things to do this week

1. Run the 90-minute audit above. Note your top three governance gaps.
2. For the highest-impact gap, write a one-paragraph spec for the artefact that closes it. Often the data-flow diagram or the definitions registry is the highest-leverage first move.
3. If three or more artefacts are missing and a reporting milestone is under 12 weeks away, request a scope review. We'll define the minimum-viable governance pack and the implementation sequence.

The consortium's data is going to be reported, eventually. Whether that reporting is clean or chaotic depends on whether the governance work happens upfront or in the last quarter. The framework above moves it upfront — at the lowest cost it'll ever have.