A SaMD Audit Trail is a secure, tamper-evident, and chronologically sequenced record that captures every clinically significant event within a Software as a Medical Device's lifecycle. This includes the specific input data (e.g., a DICOM image), the model's raw output, any generated saliency map or explanation, the software version, and the user's final action. Its primary purpose is to provide a complete, reproducible history for post-market surveillance and adverse event investigation.
Glossary
SaMD Audit Trail

What is SaMD Audit Trail?
A secure, chronological record of all inputs, outputs, and explanations generated by a Software as a Medical Device, designed to support post-market surveillance, regulatory review, and forensic analysis of clinical AI decisions.
Under regulations like FDA 21 CFR Part 11 and EU MDR Annex II, a robust audit trail is mandatory for demonstrating accountability. It must log who accessed the system, what data was processed, and why a specific diagnostic suggestion was made, often by linking to a feature attribution method's output. This immutable record is critical for forensic analysis, enabling manufacturers to trace an incorrect diagnosis back to a specific model version, a corrupted input, or an overridden clinical decision.
Core Characteristics of an SaMD Audit Trail
A secure, chronological record of all inputs, outputs, and explanations generated by a Software as a Medical Device, designed to support post-market surveillance, regulatory review, and forensic analysis of clinical AI decisions.
Tamper-Proof Immutability
The audit trail must be cryptographically secured to prevent post-hoc modification or deletion. Once a clinical AI decision is logged, the record becomes append-only and immutable.
- Uses hash chaining to link sequential records, where each entry contains the hash of the previous entry
- Employs digital signatures to verify the identity of the system component that generated each log entry
- Implements write-once-read-many (WORM) storage policies at the infrastructure level
- Any alteration attempt must generate an immediate alert and leave a forensic trace
- Critical for demonstrating data integrity during FDA inspections and ISO 13485 audits
Complete Decision Provenance
Every clinical output must be traceable back through the entire inference pipeline to its originating inputs, model version, and explanation artifacts.
- Records the exact input data including DICOM headers, pixel data hashes, and preprocessing parameters
- Logs the model identifier, version, and checksum of the deployed neural network weights
- Captures all intermediate representations including feature vectors and attention maps
- Associates each prediction with its corresponding saliency map or feature attribution output
- Enables retrospective analysis: 'Why did the model flag this region as malignant on this specific study?'
Synchronized Timestamping
All events across distributed diagnostic system components must be recorded with precise, synchronized timestamps to reconstruct the exact sequence of clinical decision-making.
- Uses Network Time Protocol (NTP) or Precision Time Protocol (PTP) to synchronize clocks across all system nodes
- Timestamps recorded at millisecond granularity to resolve event ordering in high-throughput inference pipelines
- Includes both wall-clock time and monotonic system time to detect clock drift anomalies
- Logs the time of image acquisition, preprocessing completion, inference start/end, and result display
- Essential for correlating audit events with clinical workflows and identifying latency bottlenecks
Structured Explanation Logging
The audit trail must capture not just the diagnostic output, but the complete explanation artifacts that justify the model's decision to clinicians and regulators.
- Stores Grad-CAM heatmaps, SHAP value matrices, and Integrated Gradients attributions as structured data
- Records the specific explanation method and its version used for each prediction
- Logs counterfactual explanations showing what minimal changes would alter the diagnosis
- Captures uncertainty quantification metrics including epistemic and aleatoric uncertainty scores
- Enables post-market surveillance teams to verify that model decisions were based on clinically relevant anatomical regions, not confounding artifacts
Role-Based Access and Audit
Access to the audit trail itself must be governed by strict role-based controls, with all access events themselves logged to create a meta-audit trail.
- Implements role-based access control (RBAC) distinguishing radiologists, administrators, regulators, and service engineers
- All read access to audit records is logged with user identity, timestamp, and purpose of access
- Supports regulatory read-only modes where inspectors can query but never modify the audit trail
- Generates cryptographic proof of completeness to demonstrate that no records have been deleted
- Aligns with HIPAA audit control requirements and FDA's Postmarket Management of Cybersecurity in Medical Devices guidance
Automated Anomaly Detection
The audit trail infrastructure should include continuous monitoring that automatically flags deviations from expected clinical AI behavior for immediate investigation.
- Detects concept drift by monitoring shifts in feature attribution patterns over time
- Flags out-of-distribution inputs where the model's confidence and explanation patterns indicate unfamiliar data
- Monitors for attribution attacks where adversarial inputs produce correct classifications but misleading explanations
- Tracks explanation faithfulness scores over time to detect degradation in interpretability quality
- Generates automated alerts when saliency maps deviate from domain-specific anatomical priors
Frequently Asked Questions
Essential questions and answers about building, maintaining, and validating secure audit trails for Software as a Medical Device (SaMD) to satisfy regulatory requirements and support post-market surveillance.
A SaMD audit trail is a secure, chronological, and tamper-proof electronic record that captures all inputs, outputs, algorithmic decisions, and user interactions of a Software as a Medical Device. It is mandated by quality system regulations such as FDA 21 CFR Part 820 and ISO 13485 to provide a lifecycle history of device data. The primary purpose is to support post-market surveillance, enable forensic analysis of adverse events, and demonstrate during a regulatory inspection that the software performed as intended. Unlike a standard application log, a medical device audit trail must include unique user identification, timestamps, the specific clinical data processed, and the resulting diagnostic or therapeutic output, ensuring full traceability from data acquisition to clinical action.
Enabling Efficiency, Speed & Accuracy
Intelligent Analysis, Decision & Execution
We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.
Talk to Us
Search across company data
Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.
Useful when people spend too long searching or get different answers from different systems.

Automate internal workflows
Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.
Useful when repetitive work moves across multiple tools and teams.

Add AI to products and internal tools
Build assistants, guided actions, or decision support into the software your team or customers already use.
Useful when AI needs to be part of the product, not a separate tool.
Related Terms
Core concepts that form the regulatory and technical foundation for Software as a Medical Device audit trails.
Regulatory Explainability
The specific requirements for model transparency mandated by health authorities like the FDA or under EU MDR. An audit trail must capture not just the model's output, but the explanation (e.g., a saliency map) that justifies it. This ensures clinical AI decisions can be audited and validated for safety and efficacy during post-market surveillance.
Post-hoc Explainability
The approach of applying an interpretation method to a trained model after training is complete, without modifying the original architecture. An audit trail logs the output of these methods (like Grad-CAM or SHAP). This creates a forensic record of why a model made a decision at a specific point in time, which is critical for retrospective analysis.
Faithfulness Score
A quantitative metric evaluating the accuracy of an explanation by measuring how well the attributed importance scores correlate with the actual change in model output when features are perturbed. An audit trail must record this score to prove the logged explanation is not an interpretability illusion, but a true reflection of the model's reasoning process.
Attribution Attack
A malicious manipulation of an input designed to cause a model to produce a specific, incorrect explanation while maintaining its original, correct classification. A secure audit trail must be tamper-proof and log the raw input data to allow for forensic detection of such attacks, which undermine trust in the explanation system.
Clinician-in-the-Loop
A human-AI collaboration paradigm where a medical professional reviews AI-generated explanations to make a final diagnosis. The audit trail captures this human override or confirmation event, creating a complete chain of custody. This log is essential for determining liability and for trust calibration between the clinician and the AI system.
Counterfactual Explanation
An explanation describing the minimal change to an input that would alter the model's prediction to an alternative outcome. Logging counterfactuals in an audit trail provides clinicians with a 'what if' analysis. For example, 'If this region of the image were different, the diagnosis would be benign.' This supports deeper clinical review.

About the author
Prasad Kumkar
CEO & MD, Inference Systems
Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.
His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.
Partnered with leading AI, data, and software stack.
How We Work
Custom AI workflows for your Business
One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.
01
Review the use case
We understand the task, the users, and where AI can actually help.
Read more02
Pick the right approach
We define what needs search, automation, or product integration.
Read more03
Build the first useful version
We implement the part that proves the value first.
Read more04
Improve from there
We add the checks and visibility needed to keep it useful.
Read moreThe first call is a practical review of your use case and the right next step.
Talk to Us