A clear medical summary can still be unclear about where its statements came from. The reader may not know whether the clinician actually gave an instruction, whether the software inferred it or whether it was added as general medical background. Plain language helps with comprehension; provenance helps the reader examine the basis of what they are being asked to understand.
This article, originally published in May 2026, is updated on 16 October 2026 to address a further problem: a summary can become the context for subsequent AI answers. An initial mistake may then travel into an appointment plan or another shared account, even when each later paragraph appears internally consistent.
The core principle remains the same. Patients and clinicians should be able to distinguish what was said, what was inferred and what still needs checking.
The Three-Source Problem
A patient-facing summary can combine three different kinds of material. First, it may represent statements made during the encounter. Second, it may contain an interpretation generated from the conversation. Third, it may add general medical information from another source.
Those categories are not a simple confidence ranking. A transcript-derived statement can be wrong because the words or speaker were misidentified. An explicitly labelled synthesis can be useful. A medical source can be authoritative but irrelevant to the patient's particular plan.
The important distinction is the role of the statement. "The clinician discussed this possibility" does not mean "the clinician diagnosed this condition". "This medicine can be used in this situation" does not mean "the patient was prescribed this medicine". "A review may be considered" does not mean "a review has been arranged".
A summary should preserve these differences rather than smooth them into a single confident narrative. Readability is not an adequate reason to remove uncertainty that affects what the patient should believe or do.
Why provenance matters to the clinical conversation
The clinician reviewing a patient-generated account needs to know what kind of disagreement they are seeing. The summary may misrepresent the original discussion. It may accurately reflect an earlier plan that has since changed. Or the patient may have interpreted an accurate sentence differently from its intended meaning.
Those situations require different responses. Correcting the prose is useful in the first, updating the chronology matters in the second, and clarifying understanding is central in the third. Treating every discrepancy as an AI hallucination would be as unhelpful as treating every polished summary as a faithful record.
A practical opening is: "Which part of this summary influenced what you did next?" That focuses the review on a consequential statement rather than inviting an unfocused examination of the entire document.
The source may then help resolve the issue. It might be an available transcript passage, a dated clinical letter or the current agreed plan. The summary itself should not be treated as the final authority simply because it is the most convenient version to read.
Patient notetakers make the distinction concrete
Mirror by Aide Health describes producing shareable summaries of face-to-face healthcare consultations. Advoca's chat feature describes using the person's stored information to inform later conversations. These are product descriptions, not findings that either platform has produced the hypothetical errors discussed here.
They illustrate why provenance has two separate jobs. It helps a person inspect the original summary, and it helps a later system understand the status of information it reuses.
A patient-owned record can be valuable precisely because it brings information together. That makes it important not to mistake aggregation for confirmation. Several summaries repeating the same claim may all descend from one mistaken interpretation.
What a transparent summary should show
The following is a proposed information design, not a validated clinical instrument or a claim that every listed field must appear in the main patient view.
| Element | What it should help the reader establish |
|---|---|
| Encounter and source date | Which discussion or document the statement represents |
| Speaker or origin | Whether it came from the patient, clinician, another person or software |
| Statement status | Whether it is a report, observation, possibility, agreed instruction or completed action |
| Supporting passage | A practical route to relevant source material where available and appropriate |
| External evidence | Whether the app added medical background beyond the encounter |
| Corrections and version | What changed and which account is current |
| Unresolved issues | Which questions remain open rather than being silently filled in |
A technical provenance record can support this design. HL7's FHIR Provenance resource represents aspects of information lineage. It does not prove that the original source was clinically correct or that a later interpretation is appropriate.
The user interface should therefore explain meaning, not merely expose metadata. A timestamp is useful only when readers understand whether it describes the encounter, the upload, the extraction or the latest correction.
When an Incorrect Summary Becomes the Context for the Next Answer
Consider a wholly hypothetical sequence. During an appointment, a clinician discusses a possible medicine change but decides that it should not start yet. A patient-facing summary mistakenly records that the new medicine has already been started.
Later, the patient asks the companion about a symptom. The assistant uses the stored summary and frames its answer around the supposedly active medicine. Before another appointment, it produces a preparation document listing the same medicine as part of the patient's current treatment.
The later outputs may appear consistent with each other. That consistency is not independent corroboration. They share the same incorrect premise, and repeated reuse can make that premise seem better established than it is.
The hypothetical error also changes category as it travels. It begins as a summary problem, becomes a contextual assumption in a new answer and then appears as a factual item for another clinician to review. A reader encountering only the final preparation document may have no reason to suspect the earlier misunderstanding.
This is not a reported incident involving Advoca, Mirror or another named product. It is a failure pathway that any record-reusing system should consider in its design and evaluation.
Correcting the original does not necessarily correct every derivative
Suppose the patient notices the mistake and edits the first summary. That may repair the visible source, but the later chat answer and exported appointment plan may already exist as separate artefacts.
A meaningful correction process should identify which later outputs depended on the changed statement. Some may need a warning; others may need regeneration or withdrawal from the current view. An externally shared copy may require a new communication rather than a silent local edit.
The service should not promise that every distributed copy can be recalled. It should explain what it can update, what remains outside its control and which steps the patient or clinical team may need to take.
A proposed correction record should distinguish the original claim, the reason for correction, the person providing it and whether it has been clinically confirmed. A patient report that an instruction was different is important information, but it should not automatically be presented as a clinician-authored amendment.
The objective is not to create a burdensome audit trail for every spelling change. It is to preserve the history of corrections that affect interpretation or action.
The clinical record and the patient-owned summary remain different
A correction in an app does not automatically amend the healthcare organisation's record. Equally, a corrected clinical record may not automatically update a patient-held export.
A clinician can help by documenting the current agreed position through the appropriate clinical process and making clear which earlier interpretation has been superseded. The patient then has an authoritative account to use when updating their own materials.
In the hypothetical medication example, a useful explanation would establish what the current plan actually is, rather than simply state that the app was wrong. The patient's next step depends on that plan, not on assigning blame to the summary generator.
Where an error may have influenced action, the clinical assessment should address what happened as well as what the document says. Repairing the wording is not the same as resolving every consequence.
Traceability should not become unnecessary data retention
Making a claim inspectable does not require every product to retain every recording indefinitely. Audio, transcripts, structured entries and clinical documents have different privacy and practical implications.
A proposed design should identify the information needed to explain a consequential statement and how long it is appropriate to retain it. Where a source is no longer available, the interface should make that limitation visible rather than imply that verification remains possible.
The relevant trade-off is not privacy versus all accountability. It is how to preserve useful attribution, versioning and correction without collecting or retaining more sensitive information than the service needs.
The Advoca consent article considers the separate question of secondary data uses. Knowing where a statement originated and knowing how a company may process the record are related but different forms of transparency.
A practical review before sharing or acting
A patient or clinician does not need to check every sentence with equal intensity. Focus first on diagnoses, medication changes, investigations, follow-up and statements about what has already occurred. Those are places where a change of wording can alter the apparent plan.
Then look for chronology and conditions. Was a possibility turned into a decision? Was "after the result" removed? Is a historical instruction presented as current? Does an absence of information look like an explicitly negative finding?
Finally, establish which version is being shared. A corrected account is less useful if an older export remains the one another person receives. These are editorial review prompts, not a guarantee that manual checking detects every error.
Why iatroX's citation-first approach is relevant, but different
iatroX's methodology describes source-linked clinical reference and its grounding and checking processes. That supports inspection of the evidence behind an answer. It does not establish that every answer is correct or that iatroX can certify the accuracy of a patient's recording.
Clinical-source provenance and encounter provenance are different. A guideline may support a general recommendation without proving that a particular clinician gave that recommendation during an appointment. A faithful transcript may establish what was said without proving that the advice was correct.
The useful shared principle is inspectability: preserve the basis, status and limits of a consequential statement. Plain English should make that understanding easier, not hide the difference between a record, an interpretation and an instruction.
Frequently asked questions
What does provenance mean in a patient AI summary?
It means being able to establish where a statement came from, how it was transformed and what status it has. That includes distinguishing encounter content from AI interpretation and external medical information.
Does a statement copied from a transcript automatically deserve the highest confidence?
No. Transcription, speaker attribution and context can still be wrong. Provenance helps the reader inspect the basis; it does not provide a universal ranking of correctness.
Does correcting the original summary automatically fix later AI answers?
Not necessarily. Later conversations and exported documents may be separate artefacts. A meaningful correction process should identify affected outputs and explain what can be updated or needs further action.