Integrations

Clinical.ly Research Suite is an API-first platform

and we eat our own dog food.1

APIs2 used by the web application (app.clinical.ly) are the same APIs available for consumption by Clinical.ly customers and 3rd parties to whom the customer grants access.3 CRS APIs are the primary means to accomplish all integrations. The platform is designed with security first in mind. To prevent inadvertent or malicious lateral movement (customers accessing each other’s data), each customer is provisioned a dedicated database that is not connected to the database of different customers. This approach ensures that a customer cannot access data from another customer without explicit consent & granting appropriate access. Integration Frameworks enable managing the communication and movement of data between disparate applications by providing a model of how data flows between the applications or how data changes in one application affect the data in other application(s). CRS supports a multitude of integration approaches, aka frameworks. Below is a list of several common frameworks and a brief description of how CRS accomplishes integration.

Native Integration

Native integration refers to integrating modern applications built with API first approach and in which APIs are “first-class citizens”.4

CRS seamlessly integrates with those applications by allowing customers to utilize CRS APIs to push/pull data & documents as well as issue API calls driven by events in the system. CRS calls external (customers’) APIs via even driven webhook callbacks. Additionally, callbacks may be scheduled via standard cron format.

Legacy System Integration

Legacy systems are monolithic desktop or web applications. These applications frequently do not expose APIs or cannot call external APIs. CRS integrates with legacy applications by allowing customers to extract data into machine-readable formats, e.g., CSV, JSON, XML.5 Said extracts could run on a schedule or triggered by events in CRS, e.g., document upload, study creation, etc. Once the extract is generated, the customer may manually import the data into the legacy system or if the system offers data import automation, CRS could automatically trigger the import once the data is available.

Enterprise Application Integration

EAI integration recognizes the complexity of enterprise-scale applications and the workflows (ETLs) that may be required to accomplish integration. CRS can call external APIs provided by the customer, thereby allowing customers to trigger in-house workflows either on a schedule or as a response to events raised in CRS.

Data Warehousing

(Common Storage Integration or Data Integration)

The data warehousing approach applies to customers who take a data-first approach and utilize a data warehouse, data lake, or other aggregation approaches. Depending on the customers’ specific needs, they may utilize a combination of the NI, EAI, or LSI frameworks.

We recommend extracting data at the lowest “grain,” thereby enabling the customer to take full advantage of their data warehouse to aggregate the extracted data based on their unique requirements. Data is returned in individual files for a time period specified by the caller, e.g., all data since begging of time, trailing # weeks/days, etc.

The right integration approach is entirely up to the customer.

Clinical.ly works with each customer to understand their unique requirements and capabilities. When deciding on the right integration strategy, it’s essential to consider that systems and capabilities are constantly evolving. To retain maximum flexibility and avoid vendor lock-in, we strongly recommend taking a separation of concerns6 approach to your integration strategy.

Our data team works with our customers to identify the purpose and function of each point of integration and ensure that we maintain a clear delineation between connections, thereby ensuring when the time comes to evolve, our customers know where their data comes from and how it’s consumed.

Endnotes

  1. https://en.wikipedia.org/wiki/Eating_your_own_dog_food
  2. CRS exposes REST APIs over HTTPS/2. For security reasons CRS does not support HTTPS/1.1.
  3. Due to the nature of the data stored in CRS, it is the customers’ responsibility to ensure a BAA is in place with 3rd parties to whom they grant access.
  4. https://en.wikipedia.org/wiki/First-class_citizen
  5. https://en.wikipedia.org/wiki/Cron
Clinical.ly is pleased to announce our CEO, Henry Kravchenko, is joining the advisory board of the Clinical Research...
We are excited to attend MAGI West this weekend in Las Vegas, see old friends and make new...
Everyone at Clinical.ly is excited to attend and sponsor the 10th annual SCRS Global Site Solutions Summit in Hollywood,...