Software as a Medical Device After Launch: The Evidence Loop

Software release is not the end of a medical-device evidence program. The code can change. But so can the phones, operating systems, and scanners. So can the data pipelines, clinical workflows, and patient population. So can the prevalence, staffing, and adversarial threat around it. A product that met its requirements at authorization or conformity assessment can become less reliable without an obvious crash.

Post-launch control therefore needs a closed loop: define expected performance and hazards, collect signals, and investigate them. Assess reportability and risk, correct the product or process, and verify the correction. Communicate where necessary and update the benefit-risk record. The exact legal duties depend on jurisdiction, device status, classification, manufacturer role, and the facts of the event. A dashboard alone is not a post-market surveillance system.

Start with the exact regulated function#

Software as a Medical Device, or SaMD, performs one or more medical purposes without being part of a hardware medical device. Other software is embedded in a device or drives it. Some health software does not meet a device definition because its intended function is administrative, general wellness, reference information, or another non-device role, and labels vary across legal systems, so classification begins with intended purpose and function rather than a marketing category.

The intended use states who uses the software, for which population, and with what inputs. It states which output is produced, for what medical decision, and in which setting. Risk rises when output informs a critical decision, delay is dangerous, or the software acts without meaningful review. EU MDR software as a medical device explains the European framework, while how MDR Rule 11 classifies medical-device software focuses on classification.

Post-launch monitoring must stay anchored to this claim. A tool cleared to flag a limited finding on one imaging modality should not be evaluated as if it diagnoses every disease; at the same time, predictable off-label use can be a safety signal that calls for clearer labeling, design changes, training, or a new regulatory assessment.

Build version traceability before the first release#

When a complaint arrives, you need to reconstruct what happened. Minimum traceability may include application version, model weights, and threshold. It may include rules engine, configuration, and operating system. It may include hardware, input-source version, site, and interface. It may include time, output, user action, and relevant reference outcome. Privacy and security controls still apply, and collection should be proportionate to the risk.

A single public version number can conceal server-side changes. Cloud code, feature flags, and data mappings may alter behavior without an app-store update. So may terminology services, calibration layers, and customer-specific settings. Release records should connect each deployed configuration to verification, validation, risk-control evidence, and approved labeling.

Rollback needs the same discipline. Reverting code may not revert changed data, altered settings, queued outputs, or decisions already made, and a safe plan identifies which users and results were affected, whether retrospective review is needed, and how correction is verified.

Monitor clinical performance, not just uptime#

Availability, latency, memory, and crash rate are useful operational metrics. A system can be technically available while clinically wrong. Your monitoring should reflect the intended function and known hazards. Depending on the product, that may include sensitivity, specificity, and calibration. It may include false-alert burden, missed-event rate, and abstention or rejection. It may include time to action, clinician override, downstream confirmation, and patient outcome proxies.

Denominators are essential. Ten reported misses mean something different across one hundred and one million uses. Complaint counts alone understate failure because users may not recognize or report an error. Conversely, a spike in reports can result from improved reporting rather than worse performance.

Subgroup analysis can reveal a failure hidden by the aggregate. Relevant dimensions may include site, device, and acquisition protocol. They may include age, sex, and skin appearance. They may include disease severity, comorbidity, language, or workflow. Categories should be justified clinically, measured consistently, and reported with uncertainty. Small samples can produce unstable rates, so a monitoring plan can combine thresholds with case review rather than wait for a conventional significance test.

Outcome delay creates another challenge. Ground truth for cancer, deterioration, or long-term benefit may arrive weeks or months later. Leading indicators such as input drift, image rejection, and alert distribution can help. So can override patterns and discordant follow-up. But they are not substitutes for clinically meaningful confirmation.

Data drift, concept drift, and workflow drift differ#

Data drift means the distribution of inputs changes. A new scanner, laboratory assay, or coding convention may shift what the model receives. So may a phone camera, image compression, or referral population. Concept drift means the relation between inputs and the outcome changes, perhaps because treatment, diagnostic criteria, pathogen variants, or population risk changes, while workflow drift means people use the output differently from the validated pathway.

Not every distribution change harms performance, and no single drift statistic establishes clinical failure. Drift detection is a trigger for investigation. Analysts compare the changed feature with validation boundaries, performance outcomes, subgroup effects, and causal pathway. Monitoring the model's own confidence is insufficient because an overconfident model can fail on unfamiliar data.

Automation bias adds a human-system dimension. A correct alert can be ignored after repeated false alarms. A wrong recommendation can be accepted because the interface presents it as authoritative. Automation bias when clinicians trust AI too much explains why override rate is not a simple quality score.

Complaints and incidents need linked but distinct workflows#

A complaint alleges a deficiency in identity, quality, durability, or reliability after release. It can also allege a deficiency in safety, effectiveness, or performance. It should be logged, evaluated, and connected to device history and risk management. Duplicate complaints may reflect one systemic failure and should not be closed as isolated tickets without trend analysis.

An incident or adverse event analysis asks whether malfunction, use error, inadequate labeling, cybersecurity, or another device contribution led or could lead to harm. Serious reportability can apply even when a clinician intercepted the error. Root-cause uncertainty does not always justify delaying a required initial report.

In the United States, manufacturers have duties under 21 CFR Part 803 to report qualifying device-related deaths, serious injuries, and certain malfunctions to FDA within the applicable timelines. The detailed trigger and report type matter. Internal severity labels or contract terms do not replace the regulation.

Under 21 CFR Part 806, certain corrections and removals initiated to reduce a risk to health or remedy a violation that may present a risk to health must be reported to FDA, generally within 10 working days of initiation. Not every software patch is reportable, and a remote correction can still fall within the rule. You document your rationale, affected devices, risk, actions, and communication.

EU MDR makes surveillance a planned lifecycle process#

EU MDR Article 83 requires manufacturers to plan, establish, document, implement, maintain, and update a post-market surveillance system proportionate to device risk and appropriate for the device type. It actively and systematically gathers, records, and analyzes quality, performance, and safety data throughout the lifetime and feeds conclusions into corrective and preventive action.

Article 85 requires a post-market surveillance report for Class I devices, updated when necessary and made available to competent authorities on request; Article 86 requires periodic safety update reports for Class IIa, IIb, and III devices, with update frequency and availability rules that depend on class. Vigilance, field safety corrective action, and trend reporting connect to the same evidence loop. So do clinical evaluation, risk management, and technical documentation.

MDCG 2025-10 provides current guidance on post-market surveillance systems under MDR and IVDR. Guidance supports interpretation but does not replace the regulation or case-specific advice from a notified body, competent authority, or qualified regulatory professional.

Every change needs impact assessment#

A change request should state the problem, affected versions, and intended behavior. It should state risk analysis, verification, and validation. It should state cybersecurity effect, usability effect, and data impact. It should state labeling, deployment plan, rollback, and post-release monitoring. Then determine whether the change stays within your authorized or certified scope or needs a new submission, assessment, or notification.

For machine-learning software, retraining can change multiple error modes at once. Better average discrimination may worsen calibration, a vulnerable subgroup, or an important low-prevalence class. Validation needs a locked test plan and independence from tuning data. If the threshold changes, downstream capacity and false-alert consequences also need evaluation.

FDA's final 2025 guidance on predetermined change control plans for AI-enabled device software functions describes how a marketing submission can prospectively specify certain planned modifications, the methodology for developing, validating, and implementing them, and an impact assessment. An authorized plan is bounded. Changes outside it may require a different regulatory pathway. Monitoring and reporting duties continue after a change made under the plan.

Software documentation should distinguish current final guidance from draft recommendations. Draft FDA lifecycle guidance issued in January 2025 can inform thinking but should not be described as a binding final implementation requirement.

Cybersecurity is part of clinical safety#

A vulnerability can affect availability, integrity, confidentiality, or output. Threat monitoring, coordinated vulnerability disclosure, and software bills of materials where applicable belong in lifecycle management. So do patch assessment, access control, logging, and incident response. A security patch can introduce a clinical regression, and delaying a patch can leave a known hazard open. Both risks need controlled testing and prioritization.

Connected products also depend on hospitals, cloud providers, libraries, operating systems, and interfaces. Responsibility boundaries should be explicit, but a contract cannot make a predictable integration hazard disappear. Your users need actionable communication about mitigations, affected versions, installation sequence, downtime, and whether prior results require review.

Close the loop with effectiveness checks#

Corrective and preventive action is incomplete when a patch ships. The team verifies that the fix reached the affected population, removed the root cause, did not create new hazards, and reduced the field signal. Effectiveness criteria and observation period should be set before closure.

A mature review board combines engineering, clinical safety, and quality. It combines regulatory, security, and human factors. It combines statistics, support, and product operations. It separates evidence from urgency while allowing rapid escalation. Decisions, dissent, assumptions, and residual risk should be auditable.

The final test is whether post-launch evidence changes action. If a dashboard turns red but there is no owner, threshold, investigation path, or authority to pause deployment, monitoring is decorative. A functioning system can quarantine a version, notify users, report to authorities, initiate correction, update labeling, retrain within an authorized plan, or retire the function when benefit no longer outweighs risk.

References#

1. FDA mandatory medical-device reporting requirements
2. FDA device recalls, corrections, and removals
3. FDA final guidance on predetermined change control plans
4. EU Medical Device Regulation
5. MDCG 2025-10 post-market surveillance guidance
6. IMDRF SaMD risk-categorization principles