The integration between your RTSM and your EDC usually looks finished before it is.
The data moves in a test, the vendor confirms their side, the statement of work closes, and everyone moves on to the next startup task. The integration is treated as done. Then first patient in arrives, real data starts flowing, and a field that was "mapped" turns out to be mapped to the wrong thing.
That is the pattern worth understanding. These failures rarely announce themselves during the build. They wait for live data, which means they surface at the most expensive possible moment, when a patient is enrolling or being dosed and the fix now competes with an active trial.
The reason they slip through is structural. Your RTSM vendor owns their side of the connection. Your EDC vendor owns theirs. The seam between the two systems is rarely anyone's primary responsibility, so it gets the least scrutiny and breaks the most. Below are five of the most common failure modes I see, what each one looks like, why it gets missed, and where to catch it.
1. Treatment arm names that do not match across systems
The randomization system labels the arms one way (Arm A and Arm B). The EDC expects another (coded values, or Treatment 1 and Treatment 2). The transfer "works" in the sense that data moves, so it passes a surface-level check. The values themselves never reconcile.
This one hides well because field-level testing confirms that something arrived in the right place. Nobody checks that the value is the right value until someone tries to analyze or reconcile by arm, and by then you are untangling live records.
Catch it with line-level value mapping, not just field-level mapping. Confirm that every coded value on the RTSM side has a defined, agreed counterpart on the EDC side, in writing, before UAT.
2. Site IDs that drift between systems
RTSM and EDC do not always use the same convention for identifying a site. One uses a site number, the other an object identifier or an investigator code. Leading zeros get dropped. A format assumption differs by one character.
A subject registers cleanly in the RTSM, the record transfers, and it lands under the wrong site in the EDC, or under no site at all. This surfaces at first enrollment, which is exactly when you cannot afford a data integrity question.
The site identifier is the join key between the two systems. Confirm it is genuinely the same key on both sides, including format and padding, and test it with a real registration before go-live.
3. Stratification factors that do not make the trip
Randomization stratifies on a handful of factors (prior therapy, region, biomarker status). The assignment comes across to the EDC, but the stratification values that drove it do not. Or they do come across, but nobody reconciles them against what randomization actually used.
The gap stays invisible until the statistics team asks for stratified data and discovers it cannot be reconstructed cleanly from the EDC. That is a late and stressful place to find out.
Decide deliberately which stratification fields transfer, specify them, and reconcile them against the randomization record. If a factor matters to the analysis, it belongs in the transfer design, not as an afterthought.
4. Dispensation data that arrives but cannot be reconciled
Kit and bottle assignments flow from the RTSM to the EDC, and on inspection the data is present. The problem is granularity and timing: what arrives does not match what drug accountability actually needs to reconcile against.
This surfaces at the first dispensing visit or the first accountability check, and the stakes are higher here than anywhere else on the list. Dispensation errors carry mis-dispensation and accountability risk, the kind of finding that turns into a serious deviation.
Design the dispensation transfer backward from what accountability has to reconcile, not forward from what the RTSM happens to export. The two are not the same, and the difference is where the gaps live.
5. Triggers that fire at the wrong moment
The integration is built as a scheduled batch when the workflow needs something closer to real time, or the reverse. Or a trigger condition is set so a transfer fires before the data it depends on actually exists.
The result is data that is missing, late, or out of order once real events start happening on a real timeline. It passes a happy-path test because the test feeds events in the tidy order the integration expects. Live trials are not tidy.
Map each trigger to the actual clinical workflow, and then test the unhappy paths: events arriving out of order, a transfer that fails and retries, a correction that lands after the original. Most integration testing covers the happy path and stops. The defects live in the rest.
Why lean integrations still need a careful one
There is a school of thought, and a good one, that says keep RTSM-to-EDC transfers lean. Move the critical handful of data points and keep reconciliation as its own ongoing discipline rather than a closeout scramble. I agree with it.
But lean is a statement about how many transfers you keep, not how carefully you specify them. A five-transfer integration that gets one treatment-arm mapping wrong is just as broken as a fifteen-transfer one. If anything, the case for getting the few transfers exactly right is stronger when there are only a few, because each one carries more weight. Lean is correct. Lean and unchecked is a different thing.
The cheapest place to catch all five
Every failure above is cheapest to catch in the same place: the Data Transfer Specification, before UAT, weeks before any live data exists. At that point a fix is a redline on a document. At first patient in, the same fix is a change request against a running study, with patients waiting.
This is the entire argument for treating the integration spec as a design artifact rather than a checkbox, and for putting a set of eyes on it that is not the RTSM vendor or the EDC vendor, neither of whom owns the seam. An independent read of the DTS before UAT is a small, contained step, and it is the lowest-risk way I know to surface these patterns while they are still cheap to fix.
If you are standing up an RTSM-EDC integration on a cross-vendor stack and no one on your team owns the seam between the two systems, that is worth a conversation. I offer a 30-minute discovery call at no cost to talk through where your integration stands.