Acme Movers: Repeating Forms That Ship Data Forward

Once we've decided that something is not new, we have a different problem. What should the person see when they encounter it again?

Consider a participant with Seizure Type A. When the seizure type is first entered, we might collect its onset date, frequency, and severity. At a later visit, we're still collecting information about Seizure Type A. Its identity hasn't changed, but some of the information about it may have. The onset date is still March 12. Frequency may have gone from twice a day to four times a day. Severity may have changed from moderate to severe.

We're back at the same form and the same seizure type, but that doesn't mean every field should behave the same way.

Blank, Previous, or Prepopulated?

Suppose we're entering seizure frequency at the follow-up visit. There are at least three ways the form could greet us.

It could give us a blank field and ask us to enter today's value.

It could show us the previous value for reference, while leaving today's field blank.

Or it could prepopulate today's field with the previous value, leaving us to change it if necessary.

Those may look like small interface decisions. They aren't. Each changes what the person must do and, potentially, what an entered value means.

A blank field says: make a new observation.

Showing the previous value says: make a new observation, but here's some context.

Prepopulating the previous value says something different: start with what we already know and decide whether it still applies.

Previous Isn't the Same as Current

Showing a previous value can make data entry easier. It can also influence what gets entered next.

If yesterday's seizure frequency is sitting directly beside today's field, the person no longer has to remember it or go looking for it. That may be useful when the task involves determining whether something has changed.

But if today's value is supposed to be a genuinely independent observation, showing yesterday's answer may be less helpful. We may not want the previous observation influencing the next one.

Imagine an imaging assessment in which a radiologist is supposed to independently evaluate a new MRI. Automatically filling the previous result into the current assessment would change the task. Even displaying it prominently might not be desirable if the protocol calls for an independent assessment.

Carrying Data Forward

Other situations benefit from carrying data forward. Consider a medication list. At the first visit, a participant has eight medications. At the next visit, seven are unchanged, one has been discontinued, and one new medication has been added.

We could present eight blank medication forms and ask someone to recreate the list from scratch.

Or we could start with what was known previously and ask the person to determine what has changed.

In that situation, carrying information forward can eliminate a lot of unnecessary work. But it also creates a dependency between one point in time and the next.

The current list is no longer simply a collection of independently entered observations. Some of it came from what was recorded before.

That distinction becomes important when the past changes.

What Happens When Yesterday Changes?

Suppose Medication A was entered at Visit 1 and carried forward through Visits 2, 3, and 4.

Later, someone discovers that the Visit 1 dose was entered incorrectly.

If each visit was an independent observation, correcting Visit 1 doesn't necessarily tell us anything about Visits 2, 3, or 4. Those values were observed and entered separately.

But if the dose at Visit 2 was carried forward from Visit 1, Visit 3 from Visit 2, and Visit 4 from Visit 3, the history is connected. Correcting the original value raises another question: What should happen downstream?

That doesn't necessarily mean every later value should automatically change. Perhaps the participant's dose really did change. But the correction may mean those later records need to be reviewed.

Carry-Forward Isn't Reconciliation

There's another distinction worth making. Suppose the medication list from the previous visit appears automatically at today's visit. Nothing has changed.

From the data alone, those two situations can look identical:

• Nobody reviewed the medication list.
• Someone reviewed every medication and confirmed that nothing had changed.

Operationally, they're very different.

That's where reconciliation becomes useful. Rather than treating the absence of edits as evidence that the information is still correct, the form can ask the person to confirm it.

Medication list reviewed and confirmed: Yes
Reviewed by: J. Smith
Date: September 6, 2026

Now the system knows that the previous information wasn't simply copied forward. Someone actually looked at it.

No change and no review are not the same thing.

The Form Changes the Task

All of these approaches can be appropriate. The choice affects more than how many keystrokes someone makes. It determines what we're asking the person to do.

A blank field asks them to observe and enter.

A previous value shown for reference asks them to observe with context.

A prepopulated value asks them to review and change if necessary.

A reconciliation step asks them to verify.

Those are different tasks and affects what happens when something earlier in that chain changes.