Understanding Data Integrations Designs for Clinical Trial Vendors

By David Pondelick
Technical Solutions Manager, Development

Entering accurate data into IRT, EDC, CTMS, eCOA, Drug Management Systems, Lab Systems, and more is hard.  Manually entering the same data accurately into many different systems is monotonous and prone to error.  Ensuring that the data is entered by hand into all relevant systems in a timely manner can be nearly impossible.  This is one of the places integrations can greatly simplify site user experience, better regulatory confidence in data gathered, and provide timely data distribution.  However, integrations done wrong can lead to headaches and low data confidence.

Who should be involved in integration design?

Communication is most accurate and efficient when it is direct.  While Sponsors should absolutely stay in the loop in integration implementation efforts, the Sponsor is responsible for the trial after all, introducing your vendor teams together to work on integrations directly will reduce misunderstandings and promote cohesion with the systems involved in your clinical trial.  Sponsors should always control what information is passed from vendor to vendor, but the details of how that happens are more valuable to the organizations integrating with one another.  This approach is valid even for integrations with Sponsor systems; there is likely an internal group, that acts as a vendor, responsible for managing and integrating those systems with clinical trial vendors.

What questions does the Sponsor need to answer?

Where should data originate, which system owns the data, and what other systems need it?

The sponsor owns the data collected in the trial and is responsible for ensuring only the systems that need access to that data have access to it.  Not every system needs every bit of collected information; in fact, some data is privileged by law (e.g. – Personal Identifiable Information) or by Sponsor policy (e.g. – trial results).  Some data may be unblinding and shouldn’t be stored in systems where blinded users could gain access to it.  Further, there generally isn’t value in storing information in systems that don’t need it for a specific purpose.

To reduce data discrepancies between systems and regulatory data reconciliation questions, one system should be designated as the “owner” (usually the originator) such that only that system can update the data it’s responsible for.  If data does need to be updated or removed, then it must be documented what is allowed to be updated as well as which other systems should receive that update.  Consider what should happen in those downstream systems when integrated data is updated.

How often does data need to be processed by other systems?

Some information is time sensitive in order to complete protocol processes appropriately (e.g. – labs taken in the morning providing information needed to dose a patient that evening).  Other information just needs to be distributed eventually (e.g. – patient demographic information for reporting).  Near real-time integrations are absolutely possible (we’ve built & maintained many for the IXRS), but they bring more complexity, potential pitfalls, and cost than scheduled/routine integrations.  Real-time integrations require nearly 100% uptime of both the sending and receiving system, a robust retry process, and real-time support; all things that are expensive for a vendor to ensure. When real-time isn’t a top priority, sponsors tend to rely on asynchronous integrations for their reliability and lower cost to implement & maintain.

Does your organization have security policies that apply to vendor integrations?

GCP (Good Clinical Practice) requires secure transmission & storage of clinical trial data.  Some sponsors have begun taking an active role in ensuring the integrations handling their data meet the latest security policies in order to get ahead of regulatory scrutiny around the protection of information.  Almac requires using modern TLS ciphers and we recommend using a strong authentication method; however, your organization may go further.  Ensure all your vendors can support your security needs.  Identifying account & password expiry rules will allow your vendors to be prepared for expiry and proactively plan password updates, preventing data from being stuck due to expiration.  Even if your organization doesn’t have specific security policies, it is best practice for vendors to have periodic security assessments of their systems in order to protect your data.

How can I make my vendor integrations easier?

If you are routinely having vendors integrate, consider requesting they standardize the process to your needs; already at Almac, we have several organizations in our Partner Network that we’ve built standard integrations with as well as with many additional organizations outside of that network.  Having the above questions answered before introducing your integrating vendors together will also significantly reduce the time it will take to design, develop, and test new integrations.  Remember that integrating vendors together takes time and letting your vendors know as soon as possible that the integration is a desire will help everyone better plan for your needs.

Ensuring your vendors have separate development/testing and production environments with separate user accounts allows for future changes to not impact production until everyone is ready for production to be updated.  Separate accounts also reduce the likelihood of non-production data from erroneously being sent/received into production systems.  Separating accounts per trial further reduces the opportunity for study data to impact other studies in unplanned ways.  Having development/testing environment(s) available for design and testing is critical for ensuring the best quality integration is designed and built.  Ensuring the production release of integrated systems are coordinated, reduces the need to backfill information later due to disparate system capabilities being live.

All vendors should have contacts identified to be informed when platform/application changes impact integrated systems.  Ensuring your integrated vendors are aware of those contacts, and proactively inform those contacts of upcoming changes or known issues, allows your vendors to be quicker in handling updates & issues without communication needing to be funneled through you.

Why trust Almac Clinical Technologies?

We’ve integrated the IXRS with just about every type of system imaginable (EDC, CTMS, Drug Manufacturing/Supply/Distribution/Optimization Management Systems, DCT, Central Labs, eCOA, Personalized Patient Care, Medication Compliance, and more) in just about every way possible (imports, exports, bidirectional; flat files, XML, JSON, SAS, Excel, proprietary formats; APIs, sftp, Google Drive, AWS; real-time, near real-time, hourly, daily, weekly, monthly, on demand; our capabilities are essentially endless) on hundreds of unique studies.  We have an experienced team of integration professionals made up of Solutions Leads, Developers, and Testers specifically trained in designing, developing, and testing integrations.  If a vendor is capable of being integrated with, then we can integrate with them.