Who Does What: Sites, Sponsors, Vendors and Statistics

Part of Clinical Data Management and Integrity: What Data Management Owns.

About 5 minutes. Free, in your language, no account needed.

Why this matters

Data problems are rarely technical. They are almost always a question about who was supposed to do something, and the answer is usually that two parties each believed it was the other's.

Mapping the responsibilities explicitly is unglamorous and prevents more data loss than any edit check.

The site

The site owns the source. It records what happened, and only it can say what happened.

It also owns the accuracy of what it enters and the honesty of its answers to queries. A site that answers a query by changing a value to whatever will close it has not answered the query, and this happens when queries are framed as obstacles to clear rather than as questions to answer.

What the site does not own is the design of the instrument, the mapping, or the analysis. A site that finds a form impossible to complete correctly is reporting a defect, not failing.

The sponsor's data management function

Owns the instrument's design, the edit check specification, the query process, the reconciliation plan, the coding, the mapping, and the lock.

It also owns something less obvious and more important: knowing which data matters. A function that treats all fields as equally important will allocate its effort by volume rather than by consequence, and will therefore spend most of it on the fields that matter least, because there are more of them.

The vendors

Laboratories, imaging providers, electronic outcome systems, device manufacturers, interactive response technology and central reading services each hold part of the study's data.

Each relationship needs three things written down before data flows, and the absence of any of them is a predictable source of failure.

A transfer specification: what fields, in what format, with what identifiers, at what frequency.

A reconciliation method: how the sponsor confirms that what was sent is what arrived, and that what should have been sent was.

A defined escalation: who is called when a transfer does not arrive, and how quickly.

The oversight obligation sits with the sponsor. A vendor may perform the work; the sponsor remains answerable for it and must be able to evidence that it oversaw it.

Statistics

Defines what the analysis needs. This is the input that should drive instrument design and frequently arrives after it, which is the single most consequential sequencing error in study start-up.

The statistical analysis plan should exist in draft before the case report form is finalized. When it does not, the form is designed against the protocol's description of the endpoints, which is usually less precise than the analysis requires, and the gap surfaces at lock when it cannot be fixed.

The handoffs that fail

Site to data management: a query answered by changing a value with no explanation, leaving the database correct and the reason absent.

Vendor to data management: a transfer that arrives short and is not detected because reconciliation compares what arrived against itself rather than against what was expected.

Statistics to data management: an analysis requirement that was never expressed as a data requirement, so a needed variable was never collected.

Safety to data management: a serious adverse event recorded in the safety database and never in the clinical database, or recorded with a different date or term.

Each of these has the same shape. Two parties, each doing their own work correctly, and nothing spanning the gap.

In practice

A data manager sets up a study and writes a one-page responsibility matrix: nineteen data sources down the side, and four columns across the top for who produces, who receives, who reconciles, and who escalates.

Filling it in takes two days, mostly spent asking people questions they have not been asked before.

Three cells come back empty. One vendor's data has no named reconciler. One source has no named escalation contact. And the electronic outcome data has no named recipient at all, because the vendor believed it was transferring to the clinical database directly and the database team believed the vendor was sending files to a location they would collect.

Nothing has gone wrong yet, because no data has flowed. All three would have become incidents within two months.

What this looks like when it goes wrong

A study's serious adverse events are entered by site staff into the safety system, and separately into the clinical database as adverse events.

The two are reconciled monthly, comparing counts. Counts match every month.

At lock, a line-by-line comparison shows that for eleven events the onset dates differ between the two systems, and for three the reported term differs materially, one recorded as "cardiac failure" in one system and "dyspnea" in the other.

The counts matched every month because counting is not reconciling. A count confirms that the same number of things exist in two places, which is compatible with them being different things.

The reconciliation was performed faithfully for fourteen months and could not have detected the problem it existed to detect.

Key takeaways