Okay…maybe not all problems
You’re a busy person engaged in clinical research. If I gave you a magic wand and told you that you could fix one problem in the industry, it’s possible — or should I say probable? — that API standardization may not be on the top of your list.
It is on the top of mine.
Here are 5 reasons why I believe the lack of integration standardization in clinical research is the root cause of some of the most common industry frustrations and problems.
Reason #5: Too much technology
How many times have you heard site users lament about needing to remember logins for 50+ systems which are constantly changing as new studies start and others close? In addition to these logins, how are CRCs supposed to remember complex details about 10+ protocols and the systems associated with each, what data belongs in each system, and the workflows to transfer duplicative data into multiple systems?
Technology vendors are trying their best to solve problems, but the flood of solutions in our market and the lack of integration standards have resulted in a situation where vendors have seemingly made things harder and more complex for sites. Therefore, vendors need to collaborate to create better, integrated experiences. Integrations reduce the possibility of errors, reduce the burden of duplicative entry, and create a workflow assisted by technology. Integration requests tend to almost always come for an individual study; however, it would behoove us to think bigger.
When we integrate for a single study, the integration may ease the burden for that study but all progress is lost when the study ends. Worst case scenario, we integrate two systems for a study and add on more complex, technical workflows without adequately considering what to do when something goes wrong (more about this in Reason 3). When we standardize our integrations, progress made on one study accelerates progress on the next.
Reason #4: Non-standard workflows
A CRC’s job is extremely complex. Much of the technical complexity of studies stems from non-standard workflows. Imagine a world in which you create a patient in the same system for every study you run. That patient is automatically sent to all other systems that need to know about patients via an integration. Beautiful, isn’t it?
A world in which this is possible is not as far-fetched as it may seem. All we would need is an industry-standard integration to manage patients. With a standard, all vendors would speak the same language. Setting up a standard integration could be as easy as entering credentials, flipping a switch, and maybe a configuration setting or two. Standardization of APIs may sound farfetched but is possible. Standard APIs are heavily used in other highly regulated fields like healthcare and banking.
Contrast that with the situation today: if a vendor has integration capabilities, their integrations tend to be proprietary and optimized for their system, not the industry. With standardization, all companies will need to put in additional work to support the industry standard. However, you (yes, YOU) can promote and support integration standardization. It’s a winning proposition for all parties involved once the movement obtains critical mass. More about that later.
Reason #3: Supportability
Automatically syncing patients across all systems may sound magical until your integration inevitably breaks and you’re not sure who to call. Was it Ghostbusters or were they recently acquired? Integrations are challenging and error-prone. System downtimes, miscommunications, and fat-fingering site names always happen and we must be prepared to quickly resolve issues that arise. This means investing in proactive error alerting and tooling so that errors can be resolved without technical expertise. You may believe this is table stakes but I regret to inform you, that integrations are often released without support tools.
When we prioritize study-specific integrations, timelines tend to be tight. Good integrations and integration tools take time to build in a robust and reusable way. Vendors are asked to make the integration work; the creation of management tools tends to be an oversight. We, as an industry, would be much better off focusing on standard integrations with standard toolsets.
As an aside, if you are in a position to request integrations from a vendor, be sure to understand how errors will be handled for that integration. An ideal response will include standard alerting and tooling provided by the vendor. A less-than-ideal response is that the vendor’s engineers can be engaged to troubleshoot and develop tools on the fly to resolve.
Reason #2: Timelines
You don’t need to be in the industry long to realize that study timelines tend to always be tight. Adding integrations to the mix adds complexity and time. As stated above, good integrations need time to scope, develop, and test. Integration tools must be created ahead of time so that you can search integration transactions, view errors, and resolve issues without technical expertise. Unfortunately, the development of a robust integration is rarely possible in the average study timeline.
Creating integration standards resolves the issue of time. Technical planning, requirements gathering, engineering, and testing can be done outside of study timelines when standards are used. In a world with standards, two unrelated vendors can come together for a study and configure, not develop, an integration together. Setup should take a matter of minutes and testing should be straightforward.
Reason #1: Unexpected costs
The number one reason for standardizing integrations is that it saves all parties money. In a world with standards, vendors only need to develop and maintain one set of integrations. These integrations will work with all other vendors using the standards, perhaps with some simple configuration options. Today vendors are maintaining separate APIs for each vendor integration they do – or worse yet, per study.
Costs are high because integrations are happening on a per-study basis. Working with vendor partners to create an integrated solution that is reusable across your portfolio of studies means a better return on investment. Not only will this save money, but it will also save time on every study.
Where do we go from here?
I’m hoping that if someone gives you a magic wand to solve one issue in the clinical research industry, you may wish for an industry-wide integration standard. If someone finds a genie that grants them three wishes, let me know; until then, we need to take matters into our own hands. The good news is there are plenty of ways to get involved or advocate for integration standards.
If you’d like to keep in the loop about integration standards, you can join the Clinical Research Interoperability Standards Initiative (CRISI) organization. CRISI is an organization open to vendors, CROs, sponsors, and sites to help define interoperability standards. The team is beginning with three fundamental constructs: patient, site, and study. This would allow any two vendors using the standards to share study and site build or patients across systems. CRISI has ambitions beyond these three APIs, but these concepts are nearly ubiquitous across systems today. If you are interested in learning more about CRISI, you can reach out to me (sadamkiewicz@clinone.com).
If joining CRISI isn’t for you, you can be a standards advocate. Push for reusable, robust integrations. Ensure that the integrations you invest the time and money in come with tools to troubleshoot, are easy to set up, and can be managed by non-technical staff. Ensure systems you commonly work with (e.g. CTMS or EDC) are integrated with other commonly used systems. Require that your integrations proactively alert users of issues so that end users are not scrambling to understand who they need to call. Above all, understand that there is a better way. In an industry so competitive, collaboration between competitors can feel foreign; however, some of the industry’s biggest issues will only be solved when we come together.
