EDC and RTSM Integration in Clinical Trials: What Actually Needs to Stay in Sync

EDC and RTSM support different but connected trial functions, so integration should not mean duplicating the same data across both systems. The key is to define which system owns each critical data point and when that information needs to be passed to the other system to support the next study activity.

That flow can include eligibility or stratification data before randomization, relevant randomization or treatment information returning to EDC, and later status updates such as discontinuation or completion informing RTSM. What moves between the systems depends on the study design, blinding requirements, and operational needs.

This article explains what should stay in sync, how EDC-RTSM data exchanges should be set up, how blinding affects what can be shared, where integrations can break down, and what sponsors and CROs should validate before go-live. 

EDC-RTSM integration is usually limited to the subject data and trial events that one system needs in order to perform a defined action in the other. The exact data flow varies by study, but the main integration points typically include: 

Not all of these elements need to move in every study. A randomization number may need to appear in EDC, while detailed inventory or shipment information may remain entirely within RTSM. Similarly, treatment information should only cross the interface where the receiving workflow and user roles are permitted to access it.

The integration design therefore needs a clear source of truth for every data element that crosses between the systems.

Once the required data exchanges are identified, the next step is deciding how an event in one system will trigger the required update or action in the other. The integration method can vary depending on the systems being used, the study design, and how quickly the information is needed.

Native or Unified Integration

When EDC and RTSM are part of the same platform or tightly integrated environment, the workflow can be configured within a common system architecture. This can reduce external interfaces, separate mappings, and handoffs between systems.

The underlying rules still need to be defined, however. The study must determine what event triggers the RTSM action, what information is made available in EDC, and which users can access it.

API-Based Integration

With an API-based setup, the systems exchange defined data or transactions through an API, often in response to a configured trial event. For example, completion of required data in EDC may send defined information to RTSM, or a successful randomization in RTSM may send the required outcome back to EDC.

API integrations can support near-real-time exchange, which is particularly important when the next trial action depends on the transferred information.

Scheduled or File-Based Integration

Some integrations transfer data at predefined intervals rather than immediately. This may be appropriate for information that is not time-critical, but it requires careful consideration when the data affects activities such as randomization, dosing, or dispensing.

A delay between the source event and the receiving system can otherwise delay the next study action or leave the systems temporarily working with different information.

Regardless of the integration method, every exchange should have a defined execution rule:

For example, if successful randomization in RTSM needs to update EDC, the configuration should specify the exact randomization event that triggers the exchange, the information returned to EDC, how quickly it should appear, and how the study team can confirm that the transfer was completed successfully.

The integration is therefore more than a connection between two applications. It is a set of predefined rules that determines when information moves, how it is handled, and what action follows once it reaches the other system.

These exchange rules also need to account for what information different users are permitted to receive, particularly in blinded studies. 

Blinding changes what information should cross between EDC and RTSM because the integration has to protect not only the data flow, but also who can see the result of that flow. Information that is operationally useful in RTSM may still be inappropriate to expose in EDC if it could reveal treatment assignment.

Treatment Allocation

RTSM may hold the actual treatment assignment, but EDC does not always need that information in an identifiable form. In a blinded study, the clinical workflow may only need confirmation that randomization or dispensing occurred, while the underlying treatment assignment remains restricted.

The integration should therefore transfer only the allocation information required by the downstream workflow.

Kit and Dispensing Information

Kit numbers, treatment codes, dose details, or dispensing information can also create a blinding risk if they indirectly reveal the assigned treatment.

Before this information is sent to EDC, the study team should determine whether it is actually required and whether the receiving users are permitted to see it.

User Roles, Screens, and Reports

Blinding controls need to extend beyond the interface itself. Even when the data transfer is technically correct, information can still be exposed through:

• EDC fields or forms
• dashboards
• reports
• exports
• audit or operational views
• downstream integrations

Access therefore needs to be controlled by role and study blinding requirements, not simply by which system contains the data.

Emergency Unblinding

Emergency unblinding should remain a controlled process with defined permissions and traceability. Revealing treatment assignment for an authorized reason should not automatically expose that information more broadly across EDC or other connected systems.

The principle is simple: EDC-RTSM integration should transfer only the information needed for the workflow while preserving the blind everywhere else.

Even when the integration is configured correctly, EDC and RTSM can become misaligned during study execution. Problems can arise when source data changes, subject activity does not follow the expected path, or a transaction is not processed consistently across both systems.

Incorrect or Changed Source Data

Data used by RTSM may be corrected after it has already been transferred from EDC. Stratification factors are a good example.

If an incorrect stratification value is corrected before randomization, RTSM should receive the updated value before allocation. If the correction happens after randomization, however, the original value may already have influenced the treatment allocation. Updating the EDC record does not mean the completed randomization should simply be recalculated.

The integration therefore needs to preserve both the corrected clinical data and the history of the decision that was made using the original value.

Subject Status Changes or Site Transfers 

Changes in subject status can affect what RTSM should allow next.

For example, if treatment discontinuation is recorded in EDC but the update does not reach RTSM, the subject may still appear active and eligible for another dispensing event. Similar issues can occur with withdrawal, completion, rescreening, or transfer to another site.

These events need clear rules for when the status becomes effective in RTSM and how subsequent randomization or supply activities should be handled.

Visit and Milestone Mismatches

RTSM actions are often linked to protocol-defined visits or treatment milestones, but subjects do not always follow the expected sequence.

A visit may be delayed, missed, repeated, or unscheduled. If the integration assumes that the expected visit sequence always occurs, the wrong dispensing or allocation action could be triggered.

This is why the integration should respond to the actual protocol-defined event or status required for the RTSM action, rather than relying only on the planned visit order.

Duplicate, Delayed, or Failed Transfers

Technical failures create a different type of risk.

Consider a randomization request sent from EDC to RTSM. The request reaches RTSM and the subject is successfully randomized, but the response back to EDC times out. If the site retries the action without knowing the first transaction succeeded, the integration needs to prevent a duplicate or conflicting transaction.

Similar issues can occur when:

• a message reaches the receiving system late;
• one system is temporarily unavailable;
• the same event is submitted more than once;
• a transfer cannot be processed because required information is missing.

The integration therefore needs clear rules for transaction acknowledgement, duplicate prevention, retry behavior, and recovery.

Silent Integration Failures

A visible error can be investigated. A silent failure is more difficult because users may continue working without realizing that EDC and RTSM no longer reflect the same trial event.

For example, EDC may show a subject as discontinued while RTSM never receives the update, or RTSM may complete a randomization while the result never appears where expected in EDC.

Study teams therefore need a way to identify unsuccessful or incomplete exchanges through alerts, integration logs, exception reports, or reconciliation checks rather than relying on users to discover discrepancies later.

Misalignment During Re-randomization or Protocol Changes 

Integration complexity also increases when the study itself changes.

A protocol may introduce another allocation point, change stratification criteria, modify dose rules, add treatment arms, or alter visit and dispensing requirements. Re-randomization creates a similar challenge because the integration must distinguish a later allocation event from the subject's original randomization.

In these situations, EDC, RTSM, and the integration rules need to remain aligned on which protocol version or allocation step applies to each subject. Otherwise, the systems may individually function as configured while still acting on different assumptions about the subject's current trial state.

The common issue across all of these scenarios is not simply whether data can move between EDC and RTSM. It is whether both systems continue to act on the correct subject information and trial event when the expected workflow changes or a transaction does not complete as planned.

Before go-live, validation should confirm not only that EDC and RTSM can exchange data, but that the entire integrated workflow behaves as intended under both normal and failure conditions. ICH E6(R3) specifically states that interfaces between computerized systems should be defined and validated, with validation proportionate to risk and intended use. Randomization and dosing are also identified as critical functionality. 

Key areas to validate include:

Data Mapping

Confirm that the correct source value reaches the correct destination field or workflow without transformation errors, truncation, or mismatched coding.

Trigger Logic

Verify that the exchange occurs only when the intended trial event takes place. For example, randomization should not become available simply because some eligibility data has been entered if the protocol requires all defined criteria to be complete.

Timing

Test whether information reaches the receiving system within the time needed for the next activity. This is particularly important where the exchange affects randomization, dosing, or dispensing.

Corrections and Updates

Test what happens when an authoritative value is corrected before and after it has been used by the receiving system. The integration should preserve the appropriate history rather than simply overwrite previous trial decisions.

Duplicate and Failed Transactions

Confirm how the integration behaves when the same transaction is submitted twice, a response times out, or one of the systems is temporarily unavailable.

The study team should be able to distinguish between:

• an action that never reached RTSM,
• an action that completed in RTSM but whose confirmation failed,
• and an actual duplicate request.

Access and Blinding

Validate that transferred information is visible only to the appropriate roles and that treatment or allocation information cannot be exposed through fields, screens, reports, exports, or downstream integrations.

ICH E6(R3) also requires access permissions to reflect users' duties, functions, and blinding arrangements. 

Auditability and Reconciliation

The study team should be able to determine:

what was transferred → when it was transferred → whether it was successfully processed → how any exception was resolved.

Reconciliation should also identify missing or inconsistent exchanges before they affect later trial activities.

Study-Specific Scenarios

Validation should include more than the expected subject pathway. Depending on the protocol, testing may need to cover:

• subject discontinuation or withdrawal,
• site transfers,
• missed or unscheduled visits,
• re-randomization,
• protocol amendments,
• changes to stratification or dosing rules.

ICH E6(R3) requires risk-based validation of both standard functionality and protocol-specific configurations, and subsequent system changes should also be validated based on risk.

The objective is not simply to prove that data can pass between EDC and RTSM. Validation should demonstrate that the integrated process behaves as intended, preserves traceability and blinding, and can recover appropriately when something does not happen as expected.

Once the integration approach is understood, the next step is to assess whether it will work reliably for the study being planned. The focus should be less on whether two systems can technically connect and more on how that connection will support the actual trial workflow.

Evaluate the Data Model

Look at whether ownership is clearly defined for eligibility, stratification, randomization, treatment, dispensing, and subject status data.

Evaluate the Workflow

Check how EDC events trigger RTSM actions and how RTSM outcomes return to the clinical workflow. The focus should be on whether the study can progress without duplicate entry or unnecessary manual intervention.

Evaluate Exception Handling

Understand how the integration handles corrected source data, delayed transactions, duplicate requests, subject status changes, and later allocation events.

Evaluate Blinding Controls

Confirm that treatment, kit, cohort, and allocation information is only exposed to the roles and systems that are permitted to receive it.

Evaluate Validation and Oversight

Review how mappings, triggers, permissions, failure scenarios, and study-specific configurations are validated and how the integration is monitored after go-live.

Evaluate the Remaining Operational Burden

Finally, look at what still requires manual work. A connected EDC and RTSM setup may still leave teams reconciling data, checking transaction status, or moving between systems.

The right EDC-RTSM integration is not simply the one that connects the two systems. It is the one that fits the protocol, keeps ownership clear, supports the required trial events, and reduces the amount of manual intervention needed to keep both workflows aligned.

EDC-RTSM integration works best when each system has a clear role and the exchange between them is driven by the needs of the study, not by the ability to move more data. The important decisions are what information should cross systems, when it should move, who is allowed to see it, and how changes or failures are handled.

For sponsors and CROs, the goal is a workflow in which clinical data, randomization, treatment allocation, and supply activities remain aligned without creating duplicate records, unnecessary reconciliation, or risks to blinding. When those rules are defined and validated upfront, EDC and RTSM can operate as connected parts of the same trial workflow rather than as separate systems that need to be continually reconciled.

Clinion’s Integrated EDC–RTSM for Connected Trial Workflows

Clinion provides a well-integrated EDC-RTSM system where subject data captured in EDC can directly support randomization, treatment allocation, and supply activities without being entered again in a separate system. This helps eliminate duplicate data entry and reduces the need for manual reconciliation, while keeping randomization and supply actions connected to the same subject record and protocol-defined workflow.

Clinical Trial Management Software: Understanding EDC, CTMS, RTSM, IRT | by Sasha Andrieiev
Integration Paves the Way | Applied Clinical Trials Online
The RTSM–EDC Integration Trap: Why Broken Workflows Still Undermine Trial Execution
Benefits Of Implementing EDC & Medical Coding With RTSM