Why source traceability matters in medical document workflows
A score or suggested code is only the beginning of a review workflow. A reviewer also needs to know which document, page, section and passage influenced the result - and what happened after the result was shown.
Traceability answers three different questions
Source: which document version, page, section or structured field contained the input?
Reason: which supporting, conflicting or missing evidence influenced the finding?
Action: who or what created, changed, approved, rejected or deferred the result?
Evidence coordinates should be part of the output contract
Do not add citations as presentation decoration after inference. Define source identifiers and coordinates alongside every material output. Depending on the input, this may include document ID and version, page and bounding box, section and sentence ID, or a stable reference to a structured resource.
Provenance and audit events are related but not identical
HL7 describes Provenance as information about the entities, processes and agents involved in producing or influencing a resource. It distinguishes that record from AuditEvent, which is commonly created as access or other events occur. A product design may need both the origin of a result and the history of how people and systems acted on it.
A review-ready minimum
Stable document and version identifier.
Exact supporting or conflicting source location.
Finding type, confidence or explicit uncertainty state.
Model, rule or workflow version when material.
Reviewer action, actor, timestamp and reason.
Export that preserves these relationships downstream.
What traceability does not prove
A visible citation does not by itself prove that a result is correct, complete, compliant or clinically appropriate. It reduces search friction and supports investigation. Qualified reviewers, evaluation data and use-case-specific controls remain necessary.