Transforming Patient Data with Interactive Responsive Technology (IRT) Data Integration

What is Interactive Responsive Technology (IRT) data integration?

By definition, Interactive Responsive Technology (IRT) data integration is a mechanism to combine data from multiple source systems and add interoperability between systems. IRT is a vital trial data source and, therefore, directly responsible for sending/receiving data from one application to another.
Clinical data integrations are often required as combining data from more than one eClinical system adds the necessary context needed to transform data into valuable and actionable information. Integrations also help build a more holistic view of all data for the end user.

How is IRT data sent?

Safe data transmission can use several communication protocols, file formats, and authentication methods. While Almac Clinical Technologies’ IX®S3 IRT system can accommodate all commonly used transmission methods, selecting suitable technical parameters depends on the systems’ capabilities involved in the integration.

Almac Clinical Technologies’ standards include as much automation and self-healing capabilities for data transmission as possible. We also strive for the most secure methods possible between the two integrated systems. These standards ensure the timely delivery of adequately protected data and require no manual intervention.

Sometimes the destination system, source system, or operational process IXRS 3 is integrating with does not possess the capabilities to meet these standards. Almac Clinical Technologies can accommodate these integrations once the associated risks are identified and accepted.

What types of IRT data integrations are most used?

IRT data integrations are contracts between two systems. Therefore, the delivery team must consider both systems’ capabilities in selecting the correct interface that works well with both sides of the integration.

Common examples of the systems IRT integrates with:

• Electronic Data Capture (EDC)
• Clinical Trial Management System (CTMS)
• Clinical Supplies
• Optimization
• Central Labs
• Clinical Assessment

Common integrations technical interfaces used:

• Web APIs (REST)
• Web services (SOAP)
• Secure file transfer (SSH, TLS)
• Web portal posting (HTTPS)

What considerations should be made?

Key considerations should be made when determining the data integration needs of your trial.

Generating Business Value

System interoperability and data sharing are two primary high-level purposes for integrations.

System interoperability is easiest defined as sending data between systems to drive action in the destination system. These integrations often have the highest business value as they do much more than sync data between systems. A simple example of system interoperability is screening a patient in IRT and sending the relevant data to create the patient and required eCRFs in the EDC system. In this model, each system owns and maintains its data.

Data sharing is syncing data between systems, most often to support reporting use cases. The shared data may also be required for actions in the destination system to occur but does not directly initiate those actions. If these integrations are carefully specified, it is easier to understand which system owns the data and is responsible for corrections and maintenance. For example, when a human makes a mistake in one system, these data-sharing integrations propagate those errors to other systems with little warning. These scenarios often require manual data changes in one or more systems.

Information Security

As with any secure system, credentials and authorization is a component of data integrations. It is important to consider that the ‘sender’ of a data integration is an application, such as the IXRS3 application. All account credentials are stored in a secure location, and access is restricted to staff who are trained on Data Services policies and procedures. 

Providing account types for data integrations that have the same settings enforced as other individual user types is not ideal. For example, an account that is set to expire every 30 days by an end user will be managed during user log in attempts. For a data integration, an individual is not manually logging in. Accounts with these same settings will result in delays in receipt of data due to file failures, and additional support for managing password resets and account lock outs. These integrations should use service accounts that follow with the security policies for service accounts set by your organization’s information security professionals.

Data

Defining the exact data to be sent is critical to the success of the integration. Inclusion of additional data that is of no value to the specific analysis being performed will subsequently require additional processing to exclude the data.

Data may or may not be editable. When data can be edited, ensuring to account for how edits will be sent is important. Even properly working integrations will amplify human data entry errors by propagating the wrongly entered data across integrated systems. It is important to ensure that the systems have clear roles and responsibilities for correcting and editing data.

File Type Extension

Almac can submit data in all commonly required file types. Ensure to consider the file type that is required by the receiving system and/or the individual who will be receiving and analyzing the data. Receiving the data in the appropriate file type will avoid any unnecessary file type conversions.

Frequency

How often is the data needed? This may depend on the type of data, whether it be unblinded or blinded.

File Types

Data integrations will either contain:

• Cumulative (all data)
• Incremental (all data since latest file)
• Transactional (one message per IRT transaction).