Bryan Clayton

Since the humble beginnings of Interactive Voice Response Systems (IVRS) software, designers have spent countless hours with product strategists, sponsor organizations, and product end users to develop the perfect product. Inevitably, the conversation consistently comes back to a simple philosophical debate—should software solutions be configurable or customizable?

In truth, that debate was actually ended by the market and the progression of modern Interactive Response Technology (IRT) systems. Like IVRS, today’s eClinical solutions are required to be mainly configurable, but with the intellectual capacity and capital for customization.

Configuration itself is a noble concept; moreover, the ability for an end user to select options from a pre-defined list of features without the need for back-end support is important.

Imagine an all-too-common situation where a sponsor organization needs to make a small change to the protocol. Wording of a question in the inclusion criteria has created some ambiguity, and some potential randomizations have been missed. After a minor protocol revision, would you expect that an authorized user would be able to log in to the system and modify the question text? Or, would you expect that a sponsor would need to reach out to the software provider and request additional support?  

Creating an architecture where authenticated, authorized end users are able to manage their own software will lead to decreased revision time, decreased support cost, and increased software usability. The successful implementation of this configuration will also allow for full auditability in support of regulatory requirements.  

But configuration is not free from risk. Consider if your configurable solution should allow for authorized agents to provision access to unblinding functionality. Successful implementation of configurable systems should include conversations about the level of risk your organization is willing to assume.

Ultimately, there will come a time when sponsor organizations need more that the standard configurations that are available from an out-of-the-box type of solution. In these situations, it’s important to highlight the intellectual and capital capacity of the software company in addition to the solution they offer. 

It’s easy to think of scenarios in which your management team directs you to switch your trial from double blind to open label. After protocol revisions are completed and approved, will your eClinical company have the knowledge and insight to assist with this change? This is where the intellectual capacity argument reaches critical mass.  

Consider the experience of your eClinical provider’s project management team and be sure they have robust experience and understanding of how unanticipated changes in eClinical systems can impact all parts of a trial’s success. Go beyond industry knowledge and consider the more rudimentary questions that need attention. Consider the availability of your provider to make these mid-stream changes. In this example, the required change may need rapid execution. Does your eClinical partner have the head count and availability to react today, next week, next month? Or will this important change be put in line three months from now? 

Invite industry experts to the protocol-writing table

In addition to the provider’s ability to configure and customize, there is a growing trend to include industry experts at the start of the clinical process. Sponsors are finding value in inviting these experts to the protocol-writing table on a consultation basis.

This is more than good sense; it’s a best practice. By involving an eClinical advocate early, sponsor organizations cut costs by reducing the need for duplicate software systems. For example, the randomization event can sometimes be wrapped within the eCRF or eCOA. That’s a six-digit savings simply by crafting the eClinical approach early on. Expert partners can also mitigate risk by working alongside your data management group on the data path for study lock. 

When choosing a partner, consider their experience across multiple systems. Avoid those who can only provide a single perspective. Instead, seek out providers who are able to suggest several solutions and who recommend a best path forward. These considerations will help save you save system configuration dollars, cut time spent on specification and management, and ensure higher data quality at database lock.

Carefully consider your needs and you’ll quickly agree that the configuration vs. customization debate is over. 

Director, Product Strategy and Innovation, Y-Prime

Articles

Inevitably, the conversation consistently comes back to a simple philosophical debate?should software solutions be configurable or customizable?

Bryan Clayton

Articles

Configuration or Customization: Is the Software Solutions Debate Already Over?