Summary
Manual data entry of tumors and other repeating clinical events remain a part of many research projects. A number of user-interface and design related factors complicate data entry. This article examines the requirements and related functionality associated with solving these data entry challenges. Examples are provided using a tumor registry.
Riding The Wave
A wave of new technologies, devices, treatments, and information systems is creating an exciting pipeline of tumor-related research projects. Automated data collection (e.g., devices) and extraction (e.g., electronic medical record) is becoming increasingly common, however, many research projects include a manual data entry component due to the high costs of incomplete, missing or inaccurate data.
When there is a manual component, the goal is to minimize the data entry burden and ensure accurate, timely and complete data. Unfortunately, numerous user-interface (UI) and design-related factors complicate tumor data entry, particularly when designing systems applicable across multiple diseases. This article highlights some of the main design challenges. Less emphasis is placed on UI challenges since exceptional UI design is immediately obvious when seen rather than described. Other data entry issues are discussed elsewhere (e.g., Form Design Best Practices; Utilizing Data In Clinical Decisions; Patient Data Entry Incentives).
Similar Puzzle Pieces
Tumors are one example from a broader collection of clinical research event-types that share many data entry UI and design-related challenges. Other examples from this collection include diagnoses, adverse events, seizures, irritable bowel flare, etc. There are also interventions associated with these events that have similar data entry factors (e.g., medications, surgery, etc.). There is considerable variation across this collection, but the main overlapping requirements are:
When and how many?
Unpredictable event timing and number
Over what time period?
A time range when the event is applicable
What's its name?
Variable values are used to identify events
The various event-types are distinguished by requirement specifics and workflow assumptions which, in turn, can be used to simplify the UI and validate data entry. This is done by developing core infrastructure to address overlapping requirements, and then adding configuration options to accommodate specific event-type needs. To give the reader a high-level sense of what’s involved and what can be done, summary notes on some of the main requirements, configuration options and related functionality are provided below. The more generic term “Event” is used, as opposed to a specific event-type (e.g., tumor), to emphasize the applicability across disease populations and research projects.
Before describing the requirements, a brief detour to mention the importance of visually displaying events and patient data entry.
Seeing Is Entering
Counterintuitively, one of the most important components of manual data entry has nothing to do with fingers striking the keyboard, but instead the eyes. That is, being able to visualize clinical events over time is a key component to ensuring accurate data entry. A visual display provides a quick and easy way to determine whether or not all relevant events have been captured. There are a number of different ways to visualize data, various examples have been discussed in other articles (see here). Moreover, visualizing the data provides a powerful incentive to enter data in a timely fashion (see here). In the example image above, notice it is easy to appreciate the timing of various clinical events. In this case bolded endpoints indicate events with an effective range, as opposed to onset date only. The user can zoom in and out of the visual display to set the time range.
Engaging Patients
Patient reported outcomes (PRO) are a common part of clinical studies and registries. One part of solving the data entry puzzle is to allow patients to enter data themselves. However, if the ONLY thing patients can do is enter data, then incomplete data and high dropouts rates surely follow, particularly for long-term follow-up. Engaging patients in the process involves a broad range of functionality that have been described in other articles (e.g., “Patient Disease Surveys: Turning Giants Into Windmills”) and, thus are only briefly listed here.
Simple, intuitive data entry
Incentives for completing forms (e.g., earn points, exchange points for gift cards).
Secure messaging with staff to address questions, comments, etc.
Personalized Content (e.g., multimedia information based on patient's own data).
The Requirements
The main requirements for capture of tumors and other clinical events are as follows.
Create Multiple Events
For nearly all event-types (e.g., tumors), any number of events can be created, each with a start date. When applicable, a minimum/maximum event number and / or a specified date range within which all events must be created are helpful configuration options.
Prevent Duplicate Events
Since multiple events can be created, a mechanism is needed to ensure all entered events are unique. Similar to a “Primary Key” in database design, users select which variable values will be used to determine whether the event is unique (e.g., tumor location and onset date).
Identify Correct Event
Since the unique event variable values may not be intuitive (e.g., a number), users select which variable values will be used in the UI display to help staff identify the correct event for data entry.
Set Workflow Display Characteristics
To the extent data can be used in day-to-day operations (e.g., clinical decisions), staff are much more likely to enter and keep data entry up to date. Thus, users select which variable values will appear in various UI configurations to help facilitate workflow and completion of common tasks (e.g., the variable columns of a table).
Global vs Targeted Events
Users need to be able to establish between event relationships, global vs. specific. For example, a chemotherapy agent targets all tumors, whereas a surgical procedure may target a specific tumor.
Time Range
On the surface, an event’s time range is a straight-forward concept, just set the begin and end time. Beneath this layer, however, are numerous differences in event-type requirements and assumptions about workflow. Moreover, there is no guarantee data entry happens in a serial, time-based manner. Even with just these two factors, it quickly becomes complex to manage all the issues surrounding an event’s time range and validating data entry. To get a sense of some of the issues, consider the following:
There is a difference between the end of an event and ending data capture about the event.
Events may not have an end date (e.g., epilepsy seizure type).
Begin/end date may or may not be associated with the study/clinic visit date (e.g., pathological diagnosis date vs. medication start date).
Is the date entered inclusive or exclusive?
Future dates are possible (e.g., A planned dose change 2 weeks after the clinic visit).
All the remaining requirements and functionality discussed below are related to appropriate configuration of the event time range.
Open / Start
In addition to a configurable name (e.g., open, start, begin), users need to accommodate two event scenarios.
Linked To Visit Date – The event begin is not directly entered, instead it is linked to the clinic / study visit date.
Independent Of Visit Date – The event is directly entered and is not tied to the clinic / study visit date (e.g., medication begin date).
Close / End
In addition to a configurable name (e.g., close, end), users need to accommodate three event scenarios.
Data Capture End – Date data will no longer be entered about the event.
Event End – Date the event ends (e.g., medication no longer used).
No End – Event has no end date (e.g., epilepsy seizure type).
Manage Change vs. Repeat Data Entry
Event identifying variable values are ALWAYS only entered once and there are configuration options to accommodate three scenarios. Event forms are:
Blank at each clinic / study visit.
Pre-populated using the previous visit, but considered INDEPENDENT for data validation.
Reconciled at each clinic / study visit (i.e., only changes are entered), and are DEPENDENT for data validation on the previous visit (e.g., if historical data is edited, current data must be reconciled again).
Data Reconciliation
Users only enter data when there is a change, but must indicate the data has been reconciled at each visit, even if no changes (e.g., medication use).
The above are some of the main requirements, there are others related to specific event types (e.g., medication use). Look for more articles on this subject coming soon.