All insights

The DTS is where trials stall — and it's no one's job

Your RTSM is live. Your EDC is live. On paper, the hard parts are done. Then UAT opens, a randomization field doesn't land where the EDC expects it, and a go-live date that felt safe starts sliding while two vendors discuss whose problem it is.

The thing that broke wasn't the RTSM and it wasn't the EDC. It was the Data Transfer Specification — the DTS — the document that says which fields move between them, when they move, in what format, and what happens when something is wrong. The DTS is the contract between two systems. And in most studies, no one owns it the way a contract deserves to be owned.

Why the seam goes unowned

Look at how responsibility is actually scoped on a typical study. The RTSM vendor owns their platform and the data they emit. The EDC vendor owns their platform and the data they ingest. Both are right about their own half. Neither is contractually on the hook for the join — and neither is incentivized to go looking for trouble on the other side of it.

So the DTS lands on the sponsor or CRO, usually with a data manager or project manager as its de facto owner. These are capable people. But reviewing an integration spec for the failure modes that actually bite is a different skill from running data management — it's vendor-side knowledge of where these specs quietly go wrong. Without it, a DTS gets read for what it says, not for what it leaves unsaid.

A DTS gets read for what it says. The trouble lives in what it leaves unsaid.

What "incomplete" actually looks like

An incomplete DTS rarely looks incomplete. It looks finished. The mappings are listed, the formats are specified, everyone signs off. The gaps are in the corners:

  • Error handling that's described but not defined. "Records that fail validation are rejected" — rejected how, surfaced to whom, reprocessed when?
  • Mappings that are right in steady state but silent on edge cases. What happens to a randomization that's later reversed? A screen failure after dispensation?
  • Triggers and timing assumptions nobody wrote down. The integration works because two systems happen to fire in an order no spec actually guarantees.
  • Fields the EDC treats as read-only that a future amendment will need to change — a problem that's invisible until the amendment arrives.

None of these stop sign-off. All of them surface later — at UAT if you're lucky, in production reconciliation if you're not.

Catching it before UAT, not during

UAT is supposed to be where you confirm the integration works, not where you discover what the spec forgot. When the DTS gets its first serious read during testing, every finding competes with the go-live clock, and the cheap fixes from three weeks ago are now expensive ones.

An independent pre-UAT review moves that read earlier, when findings are still just edits to a document. It checks the spec for completeness, mapping accuracy, error handling, and regulatory readiness, and hands back a prioritized list — each item tagged with severity and an owner — so the fixes happen on your schedule instead of UAT's.

It's a small, low-risk engagement on purpose. The point isn't to take the DTS away from your team; it's to give the seam the one thing it's usually missing — someone whose only job is to interrogate it before it's too late to be cheap.