By Victor Kuznetsov, Founder and CTO, Veedma
LinkedIn: Victor Kuznetsov
LinkedIn: Veedma
A patient opens a portal and corrects an answer from an intake form. The old answer disappears, the new one takes its place, and the interface reports that the profile is up to date. That is normal behavior for a consumer application. In healthcare, it can erase the most important part of the event: what changed, who changed it, when it changed, and which decisions already relied on the earlier value.
This is not only a compliance concern. It is a workflow design problem. A correction can arrive before a clinician reviews an intake, after a note is drafted, or after a treatment decision is recorded. The same new value has a different operational meaning in each state. The safer design treats a correction as new clinical data with provenance, not as permission to overwrite history.
Keep the answer and the correction
The simplest data model stores one current value per question. It is also the model most likely to hide a consequential change. If a patient first reports no medication and later adds one, the system should not silently replace no with the medication name.
Store an immutable answer event and append the correction. Link the new event to the one it supersedes. Preserve the question version, original answer, corrected answer, effective time, recorded time, actor, source, and reason when one is available. The application can still render a clean current view, but the underlying record keeps the path that produced it.
This distinction already exists in healthcare data standards. HL7 FHIR QuestionnaireResponse separates the subject, author, source, authored time, and status of a response. Its statuses include amended and entered-in-error. Those fields are not user interface decoration. They are the minimum context another system needs before it can interpret an updated answer.
Route the change according to workflow state
A correction should not trigger the same action everywhere. Before clinical review, it may simply update the review packet. During review, it may need to invalidate a generated summary. After a clinician has signed a note or made a decision, it may require a new task, an amendment workflow, or direct notification.
That means the correction service must know more than the form identifier. It must know which downstream artifacts were derived from the old answer and the state of each artifact. A useful dependency record identifies which summaries, rules, or documents consumed the superseded answer, whether a person has already reviewed or signed them, and who owns the next action when the change is material. Without that dependency map, a portal can display the correct value while a clinician continues working from a stale summary.
Make provenance visible, not merely stored
An audit table that nobody sees does not make a workflow safer. The clinician view should show the current answer and surface material changes in context. A compact line such as Updated by patient after intake review is often more useful than a generic Last modified timestamp.
The same principle applies to integrations. HL7 FHIR Provenance is designed to describe how a resource came to be in its current state, including the activity, agents, and source entities involved. A receiving system should not have to infer that a record changed because two snapshots differ.
Send the amendment and its provenance together. Preserve stable identifiers so the receiver can connect the correction to the original response. If the receiver cannot represent that relationship, fail visibly or route the case for manual reconciliation. Silent flattening is the dangerous fallback.
Separate a portal edit from a formal record amendment
Patients should be able to point out incorrect or incomplete information. HHS explains that a patient may request an amendment and, if the request is denied, may add a statement of disagreement to the record. A portal control should therefore be honest about what it does.
Changing a self-reported intake answer, requesting an amendment to a designated record set, and disputing a denied amendment are different actions. Label them differently. Route them differently. Do not make a friendly Edit button imply that a signed clinical record was rewritten instantly.
The implementation test is straightforward. Given an answer that has already been reviewed, submit a correction and prove that the old value remains recoverable, the new value carries its source and timestamps, every derived artifact is identified, and the correct owner receives a task. Then prove that an export carries the same relationship.
A healthcare system should never make users choose between a clean interface and an honest record. Show the current answer. Preserve the history. Treat the correction itself as data.