Worldwide eClinical solutions market – CDMS, EDC, CTMS, eCOA, Analytics, RTMS, eTMF, Safety, etc. – is currently estimated at $3 Billion a year by the analyst firm MarketAndMarkets. This number is expected to grow to a staggering $5.98 Billion a year with a 12.1% CAGR from 2015 to 2020, according to a recently released report by them.
Despite spending billions of dollars on these systems, the industry continues to struggle with implementing and using clinical systems. One of the main reasons is the lack of interoperability. While various eClinical systems such as CDMS, EDC, CTMS, eCOA and Safety handle different aspects of a clinical trial, they often track the same basic trial, investigator, site and patient information. The end result is a suboptimal scenario where the users need to manually enter the same information multiple times. In this case, the businesses are left with two unpleasant choices: either make users put up with these inefficiencies or take up the complex task of integrating these disparate systems.
Fortunately, this problem is not unique to the pharmaceutical industry and it can look to other industries for potential solutions. Other industries have successfully tackled this problem by making disparate systems interoperable through the usage of Application Programming Interfaces (APIs) and Webhooks. Traditional APIs (sometimes referred to as RESTful APIs) provide the most common and widely adopted model today. In this case, each application supports a standard set of published APIs that the other application uses to add, change, delete or query information. A common example of API usage is when investigators are automatically added in the EDC application by querying the investigator data from the CTMS system. The action of adding investigators can be triggered from either system by querying the CTMS system and updating the EDC system. APIs require new custom code to be written to implement the specific logic and exchange of the information.
Webhooks provide a more sophisticated method of communicating between systems as they allow for a real-time exchange of information between systems. The exchange of information is triggered based on a specific event and does not require a direct action from the user to trigger the exchange. Moreover, Webhooks do not require any custom code as the solutions that support Webhooks have built-in connectors that can snap together to create the integration.
In more technical terms, a Webhook (also called a web callback or HTTP push API) is a way for one application to provide other applications with real-time information. A Webhook delivers data to other applications as it happens, meaning you get data immediately. This is unlike typical APIs where you would need to poll for data very frequently in order to get it real-time. This makes Webhooks much more efficient for both provider and consumer.
Webhooks are sometimes referred to as “Reverse APIs,” as they give you what amounts to an API spec, and you must design an API for the Webhooks to use. The Webhooks will make an HTTP request to your app (typically a POST), and you will then be charged with interpreting it.
Imagine an EDC system is tracking milestones for a given investigator, and upon certain milestones the CTMS for the study needs to be notified so that the CTMS can send out payment to the investigator. The EDC provider could simply setup a Webhooks integration with the CTMS provider, where when these milestones are hit, a Webhooks trigger sends a notification to the CTMS application about what milestone was hit, and who the investigator was.
Chances are the clinical systems you are using today already support APIs. If you are lucky, they support Webhooks as well. However, for you to take advantage of Webhooks, both system need to support these standards. The next time you talk to your solution provider, ask them about their plans to support Webhooks.
In the meantime, here are some references if you are interested in learning more about how Webhooks work.
I imagine a future where all solutions implement APIs and Webhooks. In that future, when a new investigator is added to a study, any application associated with the study is instantly notified and updated. This could be apps directly related to the study like an eTMF, or an EDC, or even systems like a CRM. The best thing about this is that nowhere in this future am I writing any code to integrate systems.