Using software to elicit user needs for clinical research visit scheduling.

User needs understanding is critical for developing useful and usable clinical research decision support. Existing methods largely depend on self-reporting and often fail to elicit implicit or fine-grained user needs. We hypothesized that functional software would address this problem by presenting to users existing technology while simultaneously encouraging users to optimize workflow. Using clinical research visit scheduling as an example, we used a piece of software under development that was called IMPACT to reveal user needs iteratively. The identified user needs explained why most clinical research coordinators still rely on paper to schedule clinical research visits. The common user needs themes such as information completeness for software to be useful may generalize to other clinical decision support. This paper contributes valuable firsthand knowledge about user needs for decision support for clinical research visit scheduling among clinical research coordinators and a generalizable methodology for collecting and analyzing software usage data to inform user needs elicitation.

Introduction

Analysis of user needs is necessary in order to develop useful and usable software. Methods, such as focus groups, structured interviews, and ethnographic studies, have been developed for this purpose. However, most of these methods rely on the accounts of intended users based on their experiences with their current work environment so that any new resulting software is more likely to mimic the current work processes rather than offer users a way to explore potential options. A priori requirements engineering also fails to satisfy fine-grained user needs to inform user interface design, whose usability can influence user adoption and user-perceived usefulness of software.

Specifically, user needs understanding is an important problem for the field of clinical research informatics. As Califf pointed out, clinical research sites are the underappreciated components of the nation’s clinical research enterprise1. Randomized controlled trials (RCTs) are the gold standard for generating high-quality medical evidence. Although Clinical Research Coordinators (CRCs) play a central role in RCTs by coordinating various clinical research activities, they often receive limited technological support2,3. This is because their needs for technological support for improving their work efficiency remain largely unknown and therefore unaddressed. Most existing Clinical Trial Management Systems (CTMSs), e.g., Velos eResearch4 and AllScripts’ Study Manager5, were developed to streamline billing or data management, and thus offer limited support for the workflow of CRCs. The frequent requirement to manage multiple RCTs simultaneously adds to the complexity of the CRCs’ workflow.

Of all research activities, visit scheduling is one of the most frequent and time-consuming. To schedule research visits, CRCs must synthesize information from multiple sources, including study calendars, rooms, equipment, and personnel. Despite the availability of scheduling support provided by the existing CTMSs, anecdotally we learned that most CRCs still either rely on paper-based calendaring systems for visit scheduling or perform much manual work around inadequate scheduling software.

We hypothesize that a piece of interactive software could engage users and help them specify their implicit needs thoroughly and hence increase the usability and usefulness of software designed for these users. Through a test of this hypothesis, this paper intends to make two major scientific contributions. First, this paper summarizes the user needs for clinical research visit scheduling decision support and answer this research question, “what is lacking in existing software for clinical research visit scheduling?” Second, the paper illustrates a mixed-methods approach to collecting and analyzing software usage data to help designers understand vague and implicit user needs. This methodology may generalize beyond clinical research visit scheduling to other application domains.

Next we report our experience of using scheduling decision support software to enable CRCs to articulate their implicit and vague user needs for clinical research visit scheduling. Columbia University Medical Center’s Institutional Review Board approved this study.

Methods

1. Software Description

To streamline the workflow for scheduling clinical research visits with research resource allocation and optimization, we developed a web-based scheduling system that we called the Integrated Model for Patient Care and Clinical Trials (IMPACT)6. IMPACT aims to ease the cognitive burden for CRCs for scheduling research visits by automatically synthesizing and computing resource availabilities and recommending suitable dates and times for these visits6. CRCs can schedule a research visit, edit task lists, or receive an email or in-system reminder (e.g., “no breakfast before the screening visit”). They can also choose from a knowledge base of common tasks when scheduling a research visit. When a CRC schedules a visit, IMPACT presents a protocol-determined target window; IMPACT calculates the duration of the visit from its protocol-specified tasks. IMPACT’s resource optimizer presents to the CRC a list of recommended dates and times from which to choose. CRCs can also add PRN (pro re nata, Latin for “as needed”) visits not specified by protocols6.

2. Research Processes

Using a previously developed evaluation framework that mixed software log-analysis, a think-aloud protocol, and a survey7, we recruited CRCs periodically to assess if the software under development meet their user needs. In this paper, we use one recent formative evaluation to illustrate such evaluation processes. In the latest evaluation, we recruited 12 CRCs, 5 men and 7 women with diverse research backgrounds in our institution, to participate in a 30-min scenario-based study section each. Nine CRCs were experienced (2–8 years), while three had between 15 and 20 years of experience. Six CRCs were cardiology specialists, three were behavioral cardiologists two were cancer specialists, and one was a diabetes specialist. The CRCs received no compensation. We asked each CRC to use IMPACT to perform six tasks identified from prior studies of CRCs’ workflow6: log in, find a patient, schedule a visit, view visit details, reschedule the visit, and update visit statuses. Throughout their 30-min IMPACT session, CRCs were encouraged to talk about their difficulties and “wish lists” regarding IMPACT’s interface design and functionalities. We used ATracker8, an iPad v.2.0 application, to record task-completion-times. Because ATracker records tasks in one-minute units, we recorded all tasks shorter than 1 minute as 0.5 minutes in our analyses. We also counted the steps for performing each task. Furthermore, IMPACT’s software log recorded user transitions among the IMPACT screens during each session. We analyzed user action transition frequencies and visualized the results using Cytoscape9, with directional arrow width indicating the frequencies of transitions.

Results

1. User Action Frequencies

Table 1 shows the frequencies of the user actions.

Table 1.

Frequency of use of each function by CRCs, sorted by overall frequency of use

Function	CRC ID												Overall
	1	2	3	4	5	6	7	8	9	10	11	12
View calendar	34	36	27	30	49	18	25	12	27	15	27	23	323
View visit	9	12	5	9	19	6	8	5	7	5	6	8	99
Calculate time range	4	4	4	6	7	4	5	3	4	3	3	6	53
Log in	1	1	1	4	5	1	1	1	1	2	1	1	20
Schedule visit	3	3	3	4	5	8	5	3	4	3	3	6	50
Reschedule visit	2	1	1	2	3	2	2	1	1	1	1		17
Log out	1	1	1	2	3	2	1	1	1	1	1	1	16
Schedule personal event				1	1								2
View reminder(s)					1		1						2
Change password	1												1
Total	55	58	42	58	93	41	48	26	45	30	42	45	583

Viewing the current calendar was the most frequently used function, followed first by viewing details of individual visits and then by calculating available time ranges for each visit. This result shows that CRCs spent a significant amount of time retrieving information from the calendar; therefore, effective information presentation on the calendar view represents a critical intervention opportunity for improving the efficiency of CRCs during visits scheduling. In contrast, reminders about upcoming visits or their required preparations were rarely viewed. One possible explanation is that CRCs would prefer to receive and read these reminders later when they have more time, rather than when they are not busy using the system.

2. User Action Transition Graph

To better understand how CRCs used the most frequently used function, “viewing calendar”, we created an action transition graph to show the action transition frequency between action pairs (Figure 1). Each node is an action; directional arrow thickness represents the frequency of the action transition. The support for each transition10 was calculated as the transition frequency divided by the total number of the users (N=12). Numerical labels are shown for arrows with support of at least 1. Users started by logging in and then transitioning from the entry page to the calendar page. A transition with a support of 1 indicates that, on average, each user in the study performed the transition. In general, viewing the calendar was the nexus linking all other actions for visits scheduling. Users navigated from the calendar page to other pages and then back again. The next most frequent action was viewing a visit. After viewing a visit, users typically returned to the calendar. Users also frequently moved between viewing the calendar and interacting with the research resource optimizer. The “resource optimizer” is a feature unique to IMPACT. In contrast, the aforementioned related scheduling software such as Microsoft Outlook, Velos, AllScripts, and WebCAMP support only calendar views and visit views. This feature ranks available time slots for scheduling a research visit6 based on resource availability and the protocol-determined visit window.

Figure 1.

The Action Transition Graph of the usage of the different functions in IMPACT. Each arrow represents a common transition; its thickness indicates the frequency of this transition.

3. User Need for Standardization across Clinical Trials

During the “think aloud” session, we were able to capture some user rationales behind certain user preferences for technological support for visits scheduling. We learned that most of the CRCs maintain paper-based systems to schedule visits for their research patients. One such CRC explained that this choice was primarily motivated by the lack of uniformity among sponsor-provided software for visit scheduling and clinical trial management. As is typical, this CRC manages patients for multiple trials with different sponsors simultaneously.

This CRC stated, “. Different database sets a lot of the times. You’re not using the same database to keep their schedule appointments or their entries. So, depending on what day utilize, you sort of attempt to streamline your work according to the particular trial you’re working on. So, since it’s an–if it’s an outside vendor, you just–you are at the emergency, you see what they utilize what they use and then streamline yourself accordingly. So, that’s a lot of things. ’. If I’m working with Duke, for instance, they have a way of doing their things. If I’m working with Medtronics, they have a method of their own. And IVRS has their own method’. Everyone thinks they’re doing better than the other guy.”

Another CRC said, “Yeah. for example, for the month of January, we saw 20 patients. How many patients we–was eligible for being enrolled, which one screen fail or just how many randomization that day for that specific study. If done, that will be great. You know, ’.”

A third CRC commented, “What happens when you add another study then? If this–the IMPACT system would have study like ABC and D and then when–then when you’re with different tasks, That would be the only thing I would think that, you know, you–and that’s the problem. –, you know what I mean? So, you have to be on multiple studies and you have lot of scheduled things. So, I have the studies that have different–…” [we intercepted], “may be it’s easier if they had all of these–all this trial information was in there and then you could just search the patient and they would already know what trial they were on. We’ll probably make scheduling easier if the person called.” [The CRC responded,] “Right, right. So say, one’s study, whatever that one I just did. That had all those tasks. Then I have another study that’s just–schedule the–a glucose tolerance test and then schedule a radiology procedure that’s like four hours in the afternoon that has all these other things that I have to do, you know. So, it would be good to know, you know, what–if it helps you put in that person’s study number, then you can have the list and the other list and if things are incomplete.”

Most existing CTMSs are study-specific; however, most CRCs are usually responsible for managing patient scheduling for more than one clinical trial. This explains why many CRCs find it easier to integrate information across patients or across different clinical trials by using a paper-based system. On paper, they can easily draw tables to have an overview of the schedules for all the rooms, personnel, and other research resources. In contrast, aggregating such information electronically is not easy given that different trials have disparate data collection and scheduling software. This finding reveals an implicit user need for supporting cross-study information integration involves multiple trials, CRCs, and patients.

4. User Need for Convenient Information Access and Highlighting

We were able to fine-tune user interface design details based on user feedback, which was only possible by using a software to prompt the users for input. For example, our resource optimizer automatically calculates the time required by a visit by adding up the time required to perform each of the visit’s tasks, such as physical exam, blood draw, and mental test. Our software displays time duration in minutes, so that we displayed a duration of 260 minutes for a randomization visit requiring a 30-minute physical exam, a 15-minute blood draw, and a 215-minute mental test. In this case, our testers expressed a preference for the more intuitive display of 4 hours and 20 minutes.

In addition, the users requested other small modifications to the user interface, such as more highlighting: “The system itself is currently straightforward but just little things like highlighting and stuff would be really helpful. …I didn’t realize before that, that when I selected the date, that in the calendar itself it was highlighted, if I had the … would have seen, but normally where I click, I expect that to be highlighted.” Also sometimes users prefer to use mouse to using keyboard, “How would you do that with the mouse?”

Furthermore, the testers asked for rationale for the availability of all time slots. Clearly users do not like “black box” reasoning done for them behind the scene but would rather prefer transparency in decision support. We learned these design principles from the users. Before the study, we mistakenly assumed that users prefer to read less information and did not expect them to need explanations for the availability of all time slots.

One CRC described how he would prefer to have everything (e.g., protocol-specific information, patient-specific details, calendar information, etc.) in one screen by stating that, “One screen with the ability to do multiple entries or dropdown menu allows me to click, and that one screen–let’s say there’s a dropdown menu here and now I can add this, this, this. It’s right on that same menu, you know…If I already have this date here, the screen dates already there. I should be able to dropdown now, add the randomization day.”

“…So, I mean, Schedule, randomization, everything can be done in one shot; don’t have to be bouncing back and forth. When this gets full like that, I mean, I could see where it becomes problematic if you got multiple patients and multiple coordinators on one day.”

“…(Without IMPACT), the names of the coordinators click, click, click, and all of a sudden, the dates that they’re available. (With IMPACT), I can auto write from there the randomization day right from there, the follow-up visit. ’ And then when I say okay, schedule or accept or whatever, you know, bounce me back to the calendar and I could see all the different entries just on the calendar, just to make sure that everything is okay…I could have done this randomization screening is–the screening, there’s randomization, there’s follow-up visit. Anything that I would have needed to do, I could have done from that very first screening rather than go back to these multiple steps, .”

5. User Need for Fault-tolerant Designs

One common software usability measure is the number of steps (e.g., mouse clicks or page transitions) it takes to complete a task. A lot of applications have purposefully used “one click” feature to speed up the task completion. Our users shared with us their concerns regarding the advantages and disadvantages of enabling “one-click” actions: “Is there anything that I can lose a lot of information? So I guess not. I hesitate for fear of making mistakes I cannot correct. …If I have to make a lot of changes, obviously, then it’s worse; there’s a lot of clicking to do. But I try to be very careful when I’m anyway, but if you were to just drop something on it, it wouldn’t just delete a ton of events.”

Another CRC had a similar comment when being asked, “…if you were to improve anything about the IMPACT system, what would it be?” The answer was “May be the schedule thing… be able to go back (undo).”

6. User Need for Separation of Concerns

We became aware of two user needs that we had not previously known, which is that CRCs prefer to have separate time calculation for themselves and for patients and separated calendars for clinical trial tasks and personal events. One CRC stated, “…our site has a lot of chemotherapy, so those infusions last a really long time. ’. It’s great to be able to tell patients that, but in terms of like hours scheduling, it doesn’t–because we don’t have to do anything toward the infusion so– I don’t know It’s not really–’…. I think that’s what I’m having kind of like a weird thing like raping my brain around and this is, like, really more our time, not really the patient’s time.”

Another CRC revealed that he created a calendar for every clinical trial study and moved all events related to that study into that calendar so that he could still see all the events, private or work related, but mentally he separated private events from work. IMPACT was designed to read and write into a CRC’s calendar to schedule research visits. We confirmed with CRCs that this design was not what they preferred; instead, they prefer IMPACT to read their calendar to know their availability, write to a study-specific shared calendar, and allow them to view this calendar. We would not have been able to detect this user need without the use of the IMPACT as a probing tool to engage users to think about the tradeoffs between information integration and privacy preservation.

7. User Need for Mobility Support

IMPACT was designed as a web-based application. One CRC suggested a mobile version. “I would say the biggest one that will be easiest for me would be to be able to use the system on my phone as well. Just because also for the portability and be able to look at it and change it as needed, to not only–be bound to this computer can be sometimes cumbersome.”

8. User Needs for Workflow Support

Our previous design for IMPACT allowed users to schedule a single visit but prohibited them from adding subsequent visits until that visit was completed. One user requested the flexibility of scheduling multiple prospective visits simultaneously: “Is it possible to, like, pre-populate visit, let’s say, you know, I have someone who has to come in every three months, if I put their baseline visit in, will it give me tentative visits in the future? And then I can change those to when the patient can specifically come in. That would be really helpful.”

IMPACT was first designed to generate reminders only for visits that had been scheduled. One asked us to implement a reminder for prospective visits whenever a suitable visit window becomes available, “So there’s not, like, a reminder of when a window comes up?” We therefore learned the user need for receiving more real-time reminders about potential opportunities to schedule new visits.

Moreover, when there is a cancellation or delay of a scheduled visit, the CRCs also expressed their needs to receive reminders immediately so that they can adjust their appointments accordingly. This is sort of “real-time” plan adaptation that we did not included in our initial design. It turned out that this feature would have very practical utility for CRCs since cancellations or delays are common in clinical research settings and usually headache causes and cost drivers for CRCs.

9. User Need for Information Completeness and Currency

Our test users also provide insights regarding hidden conditions required for a design feature to be useful. For example, one CRC stated, “Yeah, I do like this integrated calendar feature. This is a–I could get used to that. And it would be nice if everybody like God get their Outlook calendars , cause then you can see everything.” If users do not update their calendars and make all constraints electronically available, IMPACT will be helpless in terms of synthesizing temporal constraints from user calendars.

Discussion

This paper illustrates how important user needs for clinical research visit scheduling that another method would likely have missed could be acquired by using functional software to prompt users. These user-needs require thorough considerations of a socio-technical approach to engage users and to design useful user interfaces. More importantly, most of these user-requested features are unavailable in existing scheduling software and CTMSs. It was only through insightful input from users that we understood their need for certain views with information specific to only one user and one trial, and other views with information about many users and trials. Their insights into the incompleteness of information in personal calendars help us to define the best practices expected from users to make IMPACT successful. Their insights into the tradeoffs in “one-click” design also helped us think more about the need for an “undo” option for immediate error rectification. Support for existing behaviors such as using their familiar methods (e.g., a computer mouse) or mobile devices, and scheduling multiple visits, are important. Features that address these needs are being incorporated into the next version of IMPACT, which has evolved from a single-study system, typical of existing CTMS scheduling modules, to a multi-study, multi-CRC collaborative system.

“Paperless office” has been one of the “Holy Grails” chased by computer scientists since early 1980s11. However, after several decades, paper proves to be a flexible, extraordinary, and nearly indispensible tool for performing many office tasks12, including clinical research visit scheduling for clinical research staff. Paper is easy for adding new tables or illustrations, highlighting important information, striking out outdated information, rectifying mistaken information, or moving around and sharing information with different people. Reflecting on the user needs for mobility support and effective information display for IMPACT design, we realized the sophistication of paper use by clinical research coordinators warrants further studies so that we can incorporate implicit user needs or dependency on paper into the design of IMPACT. Any workflow support system design would face adoption obstacles if only mimicking the paper-based workflow or falling short of the existing paper-based system. To win users designers must provide a solution that is superior to the existing paper-based system; otherwise the effort spent for change management would not be worthwhile and the users would not easily buy in the new system.

A common dilemma for clinical decision support or expert systems is “how much information should be presented to users and what should be presented?” Initially we designed the time slot recommendation feature without providing explanations about why certain slots were unavailable under the assumption that users needed solutions more than explanations. The results of this study showed that our assumption was false. The participants in this study taught us that clinical research staff appreciate time-saving advices from expert systems such as IMPACT but also prefer transparency in the logic behind such advices. Therefore, black box decision support may lose users or cost users extra effort to find out “why”. Meanwhile, as designers of IMPACT, we are also concerned if the users truly have the time to review all the rationale behind the automatically calculated available slots based on the availability of protocols, personnel, rooms, equipment, patient preferences, and so on many temporal constraints. Therefore, an unsolved question remains, “should user needs be completely defined by users? designers? Or both?”

Since users needs are so complex, one-time user needs elicitation is often insufficient. Reusable methodologies are needed to elicit users needs iteratively. This paper contributes some data collection and analytical techniques for this purpose. The usage log-based action transition graph effectively told us on what tasks users spend more time than others and detect inefficient tasks.

This study has inherent limitations. First, we included a small group of clinical research users from only one institution. A separate study is warranted to test the generalizability of these reported users needs in heterogeneous clinical research settings in different institutions. We believe the knowledge reported here is sufficient to inform the design of user surveys to collect more user needs for research visit scheduling at a larger scale including more institutions. Second, we reported implicit or previously unknown user needs for research visit scheduling but did not demonstrate the clinical impact of such user needs. Ideally data are preferred to show a system design informed by these user-needs leads to better clinical outcomes than a system not informed by these user needs. However, comparative effectiveness research on clinical decision support systems is challenging. Since IMPACT is still going through iterative designs and evaluations, we hope we can validate these user needs when we perform a field trial of IMPACT using real clinical trials and clinical staff and report the results afterwards.

Conclusions

This paper contributes valuable firsthand knowledge about user needs for decision support for clinical research visit scheduling among clinical research coordinators and a generalizable methodology for collecting and analyzing software usage data to inform user needs elicitation. Functional software is a powerful tool and effectively supplements existing methods for eliciting user needs and for arriving at a useful socio-technical design. Future studies can test if these user needs for scheduling clinical research visits may generalize beyond our institution.