Finished for whom?
An operator submits a research result and sees it move into a completed queue. A reviewer opens the same result and finds an unresolved question about its source. The scientist waiting to use it sees a green status badge. Each screen makes sense in isolation. Together, they imply that the work is further along than it is.
Consider a representative laboratory application used by operators, scientists, reviewers, and administrators. This is an illustrative product-design case, not a report of a particular laboratory or a measured implementation. The team wants to simplify each person's workspace without creating separate accounts of what happened.
The design problem begins with the word completed. For the operator, it means the entry was submitted. For the reviewer, it means the supporting information was checked. For the scientist, it may imply that the result is available for an analysis. One status cannot safely carry all those meanings without further explanation.
The useful boundary is between the record and the work people perform around it. Keep the result's identity and history shared. Give each responsibility its own action, owner, and completion condition.
What stays the same across screens
In this example, the result has a stable identifier within its project, a revision, a source reference, and a history of changes. A review decision points to the revision examined. A request for clarification points to the same result but has a separate lifecycle. Resolving that request does not silently rewrite the measurement.
The operator's view can put entry errors and submission controls first. The reviewer needs the current question, the relevant evidence, and changes since the last examination. The scientist needs the value, its context, and whether the intended use is available. An administrator may need to reassign an overdue task without seeing the underlying scientific content.
These views can differ substantially. Where they display the same fact, however, they should use the same definition and identify the same revision. A compact queue might show “Entry submitted · Review pending.” The detail page can explain why review is pending. Neither should collapse that distinction into a green “Complete.”
This does not demand one database table or one giant object. It calls for explicit relationships between records. The W3C PROV Data Model distinguishes attribution of an entity from responsibility for an activity and delegation between agents. That distinction is useful here: entering a result, checking it, and acting on someone else's behalf are different relationships. PROV supplies a conceptual vocabulary, not a ready-made approval policy.
A correction while someone is reviewing
Suppose a reviewer opens revision 7 of result R-214. While the page remains open, the operator corrects its source reference, creating revision 8. The displayed measurement is unchanged, but the reviewer now has different evidence to inspect.
If the reviewer presses Approve and the application attaches that decision to whichever revision is current, the record claims more than the person actually checked. Refreshing the page periodically does not solve the moment between reading and submitting an action.
For this workflow, the approval request should include the revision the reviewer examined. The server checks that revision as part of recording the decision. If relevant content changed, it preserves the reviewer's draft explanation and asks them to inspect the difference before proceeding. Recording the decision and checking its target must happen together; an earlier check followed by an unconditional save leaves the same race open.
There is an established technical pattern for detecting stale writes. In the explicitly versioned HL7 FHIR R4 REST API, a client can submit an If-Match header with the version it read. A mismatch produces a 412 response instead of updating the resource. This is a concrete example of version-aware updates, not a requirement to adopt FHIR for this research application. An approval stored separately from the result still needs an application-level check across those records.
The recovery message matters as much as the rejection. “Source reference changed since you opened this result” tells the reviewer what to examine. “Something went wrong” encourages another click. The interface should retain unfinished notes while clearly distinguishing them from a recorded decision.
Assign work without copying the result
A clarification request needs an accountable destination. Sending a notification to everyone with a reviewer role leaves open whether anyone has accepted the work. Copying the result into a personal queue creates another question: will the copy follow subsequent corrections?
A shared queue can instead contain tasks that reference the result. Claiming a task records its owner. Reassignment changes that responsibility while preserving the request and its history. The result retains its identity throughout.
The FHIR R4 Task resource illustrates this separation with distinct fields for the task's focus, requester, owner, and status. Its model helps explain why the person requesting work and the person responsible for performing it need not be the same. The particular claim, timeout, and escalation rules in this case remain product decisions.
A notification should link to that task. When opened, the application checks access and loads its current state. If someone else has resolved it, the destination explains that outcome instead of presenting an obsolete action. Delivery of a notification is not evidence that the recipient accepted responsibility. Acceptance belongs in the task record.
For sensitive work, the message can say that attention is needed without carrying the measurement or subject details. The authorized destination supplies the context. This also reduces the chance that an old message becomes a competing reference after a correction.
Different views still need enforceable boundaries
Hiding a button makes a screen simpler; the server must independently decide whether the requested action is allowed. In this design, viewing a result, correcting it, reviewing it, and reassigning a task are separate capabilities. Their availability depends on the user's current responsibility and the record's state.
Role-specific presentation should not manufacture scientific meaning from missing information. If a scientist cannot see a supporting attachment, the interface must not imply that no attachment exists. Depending on the access policy, it can show an appropriately limited explanation or withhold the dependent action entirely. Even disclosing that an attachment exists may need permission.
There is also a boundary to sharing one live record. A submitted package or a formally retained export may need a fixed snapshot. That snapshot should identify its source revision and creation context. Later corrections can link back to it without changing what the recipient originally received. Controlled snapshots serve a different purpose from accidental copies created to make a dashboard easier to build.
Start with fewer views than roles
Separate dashboards are not automatically the better choice. A small team with overlapping duties may work well with one detail page and a few task filters. That approach keeps terminology visible to everyone and costs less to maintain.
Dedicated views become worthwhile when people repeatedly have to search past irrelevant information to make their own decision. They also introduce maintenance work: every added summary, cache, and status label can drift from the shared definition. Begin with the common record and vary the order of information before building separate representations.
A useful acceptance session follows one record through an uncomfortable day. Two reviewers try to claim the same task. An operator corrects its source while a review is open. A person loses access before following a notification. Someone reopens a snapshot after the live result changes. The team should be able to explain who can act, what revision they are acting on, and what evidence the action leaves in each case.
Success would mean that conflicting claims cannot both become current, stale decisions are caught, and restricted information stays restricted. These are behaviors to verify, not outcomes established by this illustrative case. The final test is simple: when two people describe the same result differently, can the product show that they have different responsibilities rather than different facts?