By Bill Cooney
August 16, 2010 | Commentary | In the past decade, clinical trial technology has undergone considerable evolution in its design, capability and deployment. From the early days of remote data capture, to full-suite clinical trial management solutions, this technologic evolution is redefining clinical research. Nevertheless, clinical research technology has suffered from significant resistance at the study site level, and this can be traced to a deficit in one basic element: user-centered design.
Early systems focused on making the best use of emerging digital technology to accomplish study tasks, usually mirroring the paper-based equivalent. For example, early electronic data capture (EDC) systems attempted to replicate the paper case report form in an on-screen version. The problem is that digital media is inherently different from paper media, so that mere replication of paper is seldom an effective approach. In making the conversion from paper to on-screen forms, developers used common tools such as drill-down menus, drop-down boxes and mandatory pathways, adding user complexity along the way. Most developers have failed to focus on making the online case report form (CRF) easy to use for the study site, and unfortunately, few systems have moved beyond this approach in their attempt to automate study processes.
It’s not hard to understand why end users receive little consideration in the design of clinical trial software. The widely-accepted practice of clinical software development follows the waterfall approach to development, which is used to ensure software can be validated. User requirements are created, systems are built and tested by those creating them, and a stamp of approval is given indicating that the system does what the user requirements say it should. Upon closer inspection, we see that user requirements are drafted by clinical trial business analysts, and functional requirements are created by the IT department. Neither group tends to focus on instructional design and the needs of end-users at study sites.
The result is a system that’s functionally clean and tidy, and that provides study managers with the data and reports they want. But end users are confronted with a system that’s counter-intuitive, requires a slew of training, is difficult to access, and creates more, not less, work than the paper equivalent. It’s little wonder that such systems have encountered significant resistance, even rejection, when they’ve been deployed.
A Better Way
It is quite possible to develop study systems that address the needs of all parties, including those persons inputting data at study sites. Consider, for instance, how Apple differs from Microsoft by emphasizing intuitive use and value for the customer, whereas Microsoft prioritizes IT system functionality. Apple’s strategy of placing end-users over IT has been wildly successful and set a new standard that others are scrambling to replicate.
The lesson from this is along the lines of “give the people what they want.” When developing its technologies and products, Apple stresses delivering an intuitive user experience and clear value to the customer. Its computer systems place secondary priority on the specifications of IT technicians, and the control and reporting desired by management. The Apple approach is working because their products are more productive for end users, which leads to systems that work in the real world, driving success for all other system stakeholders.
In our consumer marketing-driven economy, the primacy of the customer or end user is a familiar concept, but one that is easily forgotten when developing study systems. The people controlling development of study systems are IT and study management professionals, who typically focus on their own parochial needs and forget the importance of the end user in system design.
IT Can Learn from ID
To build intuitive systems in clinical research, developers can learn from the field of training, which has defined Instructional Design (ID) as the process of systematically analyzing, designing and delivering systems for target users. Most ID models use some form of the ADDIE process: Analyze, Design, Develop, Implement, and Evaluate. This model is not far from the traditional waterfall approach to software development, but starts with an emphasis on target user requirements, and ends with an Evaluate step that ensures utility for target users.
Using the ID model, a sample population of the intended audience is used to provide feedback on the system content and design. Initial reviews are focused on providing general feedback, and intermediate reviews are conducted by designers observing target users completing activities on the system. Observations are made to determine if intended pathways on the screen are followed by target users, if mouse clicks are made as anticipated, and if users understand how to compete assigned tasks. Feedback is collected and the system is revised based on this user input. The focus on the user in the ID model may seem somewhat obvious, but if the software development process is not grounded in user needs, user requirements can be quickly obscured by IT issues and the desires of study managers to get the data and reports they want.
The ID model and the primacy of the end-user will not fix every challenge in the design and deployment of clinical trial technology. There are also major challenges in converging and simplifying technologies, and in lowering costs so that drug development leads to affordable healthcare products. But the ID approach is among the most accessible and obvious options to improve clinical trial technology.
The clinical research industry has and continues to invest vast funds in developing clinical trial technologies. To improve clinical trial software, IT developers can readily borrow from the valuable work of the training industry, and deliver more practical and effective solutions. Involving end users in IT development is not optional, it is essential.
Bill Cooney is the founder and president of MedPoint Communications.