Data Entry Déjà Vu: The Trouble With Repeating Study Forms

There is a deceptively simple feature on some data-entry forms: + New.

Need to enter another tumor? Click New. Another medication? New. Another adverse event? New. Another assessment? New.

Sometimes that's exactly as simple as it sounds.

When “New” Really Is New

Suppose we're assessing pain, dizziness, lightheadedness, and vertigo several times during a clinic visit. We complete Assessment 1, then later Assessment 2 and Assessment 3. Each assessment is independent. Nothing from Assessment 1 carries forward into Assessment 2, and the values entered previously don't constrain what can be entered next.

Every time we click + New, we get a blank form and make another observation. We might limit how many assessments can be created, but beyond that there may be very little for the system to figure out. + New really does just mean new.

Data Entry Déjà Vu

Now suppose the repeating form represents a tumor. The participant already has several tumors in the study. You find a tumor in today's source information and reach for + New.

But first: Have I entered this before?

Maybe it's a new tumor. Maybe it's one that's already in the system. Now the problem isn't simply whether we're allowed to repeat the form. We need some way to establish which tumor we're talking about.

What Makes Something New?

Sometimes establishing identity is straightforward. A tumor might be assigned a unique Tumor ID. Seizure types might be identified as A, B, C, and D, with each identifier allowed only once. In database terms, we might use a primary key, one field or a combination of fields that uniquely identifies an instance.

But deciding whether something is new doesn't always reduce to finding an exact duplicate.

Consider medication use. Someone can start and stop the same medication several times. Medication A from January through March, again from June through August, and again from November through December can represent three perfectly legitimate periods of use.

Now suppose the participant already has Medication A, 10 mg, January 1 through June 30, and someone tries to enter Medication A, 20 mg, March 15 through April 30. The start dates are different. The end dates are different. A simple rule looking for an identical Medication + Begin Date + End Date wouldn't find a duplicate.

But if the way we're representing these data assumes that a participant can't simultaneously be taking two different doses of Medication A, the new entry still isn't allowed. The question isn't just “Have these exact values been entered before?” It becomes “Does what I'm entering conflict with something already here?”

We'll come back to the mechanics of dates and overlapping events in Part 3. The important point here is that deciding whether something is new can require understanding its relationship to what has already been entered.

What If We Don't Know Yet?

Sometimes an instance needs to be created before we know enough to fully identify it.

An imaging study may reveal a lesion before its location or classification has been completely characterized. A seizure may have been observed but not yet classified. An adverse event may still be under evaluation. The event is real and we need somewhere to collect information about it, but some of the information we would normally use to distinguish it from other instances isn't available yet.

That creates another opportunity for duplicates. One person creates the unidentified instance today. Someone else encounters it tomorrow and doesn't recognize it as the same thing.

A repeating form therefore must accommodate not only what eventually makes an instance unique, but what happens while that information is still incomplete.

The Computer Has to Know. So Does the Person.

Even when the system has a perfect identifier, the person entering the data still must recognize the correct instance.

Suppose the database identifies a tumor as Tumor 0073. That may work perfectly for the computer, but 0073 may mean very little to the coordinator reading today's clinical note. They may recognize it much more readily as Left frontal lobe, onset 3/12/25.

Those are two different jobs. One set of information allows the system to distinguish one instance from another. Another helps the person recognize the thing they're looking for.

There may even be a third job. Someone entering clinical information might need location and onset date to recognize the tumor. Someone pulling specimens may care much more about specimen ID and freezer location. It's the same tumor, but the information that helps someone work with it changes with the task.

The rules themselves can also extend beyond a single pair of instances. A study might allow only one primary tumor, for example. Another design might allow only one active dose of a medication at a time. In cases like these, deciding whether another instance can be created requires looking at the collection as a whole. The question becomes “Is this allowed given everything else we've already collected?”

When “New” Starts Something Else

Getting the original instance right becomes even more important when creating it causes other data collection to happen.

Consider adverse events. A mild headache might require weekly follow-up, while a serious adverse event might require daily follow-up. Creating the adverse event therefore does more than add another form. That particular adverse event becomes the anchor for its own data-collection schedule.

The follow-up assessments may themselves be independent observations. Each one might collect symptoms, physical findings, functional status, organ-system findings, or resolution. Those assessments don't establish the identity of the adverse event. They happen because that particular adverse event exists.

Now imagine discovering three days later that AE #3 wasn't new at all. It was the same adverse event as AE #2.

The problem is no longer simply deleting a duplicate row. What happens to the follow-up assessments attached to it? Can the two instances be merged? Can data be reassigned from one to the other? What happens to future scheduled collection?

The same problem can appear in other ways. A tumor gets entered twice. Two differently described events later turn out to be the same event. A procedure gets associated with Tumor 2 when it actually belonged to Tumor 1.

Preventing those mistakes is important. So is deciding how to recover when one gets through.

Before Clicking “New”

At its simplest, a repeating form really can be + New → blank form → another observation. The more useful question is whether that's actually the structure of the data we're collecting.

Before configuring a repeating form, I'd want to know whether the instances are independent, what makes one different from another, whether the same thing can legitimately occur more than once, and whether an instance can exist before everything needed to identify it is known. I'd also want to know whether a new instance can conflict with existing information without being an exact duplicate, what helps the person recognize the correct existing instance, and whether creating one instance causes other data collection to follow.

And because someone will eventually click + New when they shouldn't, I'd want to know what happens then.