Medical device software classification

Example 1 Device log export item

1 · Simple software item | Software item within a medical-device software system

A small item does not automatically become Class A. Its own no-injury hypothesis must be separated from the parent class and verified segregation.

Software profile and medical purpose

Software ServiceView diagnostic-device log export item

A small read-only export item inside a diagnostic instrument’s controlled software system. It formats an already captured service-log snapshot for engineering analysis after use. It has no clinical display, live command, configuration-write or therapy function.

Intended medical use Export a historical service-log snapshot from a defined medical-device software item for engineering analysis, without influencing patient operation.

Indications and limitations This is an item-level assessment within an established medical-device software system, not an independently marketed medical application. It must not be used for clinical interpretation or return-to-service authorization.

Software boundary and architecture

Scope rationale Scope is the export item within the controlled parent medical-device software system. It is not general manufacturing/QMS software. Parent lifecycle obligations and classification inheritance apply.

Included and excluded functions Include snapshot parsing, formatting and file export. Exclude live acquisition, interpretation, clinical display, configuration changes and return-to-service decisions. The no-harm item screen is conditional on this boundary being real and complete.

Software inputs Immutable historical diagnostic-log snapshot and nonclinical export metadata.

Software outputs Engineering diagnostic file with source version and export time; no clinical result or device command.

Interfaces Defined read-only snapshot API and export destination. Investigate shared memory, scheduler, disk and permissions for propagation into the parent.

Parent system Illustrative diagnostic-instrument software system, parent IEC 62304 Class C.

Parent software class C

Decomposition and segregation Proposed read-only interface and resource isolation are not yet verified. Demonstrate no write path, control path or resource interference before proposing a lower item class. Parent Class C remains in this tool.

Software classification result

The documented scenarios report no possible injury or damage to health. The item inherits parent Class C in this conservative screen; its own documented harm screen is A. Segregation proposals do not automatically lower the inherited class. Validate completeness using the applicable licensed IEC 62304 method. No class reduction is made for proposed controls or human review.

• Item harm screen: A under a restricted no-injury hypothesis.

• Tool result: preliminary Class C inherited from the parent. Proposed segregation does not automatically lower it.

• The software item is assessed within its medical-device system; no independent medical-device claim is made for a generic log viewer.

Detailed software workflow

Software controls and failure scenarios

• Retain parent Class C until a justified different item classification is established through the formal process.

• Verify decomposition, one-way data flow, permissions and shared-resource independence.

• Keep the service export separate from clinical interpretation and return-to-service decisions.

Foreseeable misuse An engineer treats the export as a clinical record, introduces live command access, or uses an unverified file to authorize service release.

Risk 1 Diagnostic export is malformed

Failure sequence A parser mislabels a historical software event and the exported engineering file cannot be interpreted.

Hazardous situation Service staff have incomplete engineering information; clinical functions do not consume the export within the stated boundary.

Possible health harm No health injury in the assumed isolated item boundary; engineering rework is possible. Failure propagation must still be investigated.

Maximum severity none

Proposed controls Identify source version and schema; reject unsupported data and display an explicit export failure.

Verification challenge Use truncated, unexpected-version and invalid-encoding snapshots; verify explicit rejection and preservation of the original data.

Residual risk and gaps No medical harm conclusion is approved. Verify the isolation assumptions and retain parent class until formal assessment.

Traceability SV-REQ-1 proposed → SV-DES-1 proposed → SV-VAL-1 planned intended-user validation; not executed

Risk 2 Export destination unavailable

Failure sequence The destination is full or inaccessible and a save operation fails.

Hazardous situation The engineer does not receive a usable file; no clinical state changes within the proposed isolated boundary.

Possible health harm No health injury in the bounded hypothesis. A shared-resource impact would invalidate that hypothesis and require reanalysis.

Maximum severity none

Proposed controls Bound export resources, use an isolated destination, fail explicitly and preserve parent operation.

Verification challenge Exercise full destination, permission loss and cancellation; measure parent resource behavior and prove absence of a clinical-state write path.

Residual risk and gaps Isolation and resource evidence pending; Class C inherited from the parent.

Traceability SV-REQ-2 proposed → SV-DES-2 proposed → SV-VAL-2 planned intended-user validation; not executed

No-injury hypothesis For the narrowly stated isolated export behavior, a formatting or file failure has no clinical output or patient-control consequence. This is an item-level hypothesis, not proof of isolation; if resource or interface effects can reach clinical functions, rework the harm analysis. The tool retains the parent Class C.

Human review Describe the reviewer, information available, expected decision and realistic error conditions. No unmeasured class reduction is credited.

External controls No class reduction is credited to proposed external controls.

Independence and effectiveness Control effectiveness remains to be demonstrated. Proposed requirements and tests are not completed evidence.

Proposed tests and expected results

All tests are planned and not executed. Approve the acceptance criteria before execution and retain actual observations, deviations and software/configuration identity.

Worked software change assessment

Trigger A proposed enhancement reads live data rather than a historical snapshot.

Impact assessment Reassess timing, shared resources, input ownership, clinical dependence and access privileges.

Verification and regression Repeat propagation and interference tests, including clinical-operation concurrency and abnormal inputs.

Responsible review Software safety lead determines whether the item boundary and parent risk analysis must change.

Software lifecycle evidence

Configuration baseline Proposed export item SV-1.0, snapshot schema 1.0 and parent software baseline DI-3.0. Record parser library, permissions and resource limits.

SOUP and dependencies Identify each third-party component, version, intended role, known anomalies and safety impact; retain supplier and verification evidence.

Cybersecurity and safety Evaluate unauthorized access, altered inputs, dependency vulnerabilities and loss of service against the software safety analysis. Verify relevant protections and recovery.

Problem resolution Record the affected software version, investigate the failure, assess safety impact, control the correction and retain regression evidence before release.

Operational feedback Collect software incidents and user feedback, identify affected versions, trend safety-relevant failures and feed findings into risk and change management.

Overall residual risk Residual-risk acceptance is pending actual control verification, intended-use validation and the responsible organization’s review.

Assigned next steps

Software architect Establish actual decomposition and isolate all clinical/control interfaces. Expected deliverable: Approved boundary and interface design.

Verification lead Challenge permissions, shared resources and failure propagation. Expected deliverable: Independence and interference evidence.

Software safety lead Review any proposal for a different item class under the licensed standard. Expected deliverable: Formal item-classification rationale.

Example 2 Hand rehabilitation guidance

2 · Bounded therapeutic software | Standalone medical-device software (SaMD)

Class B depends on a supported conclusion that only non-serious injury is possible across the actual scope and foreseeable misuse.

Software profile and medical purpose

Software RehabGuide supervised hand-exercise software

A bounded software application guides the timing and sequence of low-intensity hand-mobility exercises selected by a therapist for stable, minor musculoskeletal conditions. It does not diagnose disease, set resistance, control equipment or provide emergency advice.

Intended medical use Guide a clinician-selected, low-intensity hand-mobility routine for eligible adults, using timing cues and session records.

Indications and limitations Illustrative assessment restricted to stable minor hand stiffness in eligible adults. Acute injury, postoperative care, impaired sensation, unstable conditions and unsupervised high-load exercise are outside the intended scope and require separate evaluation.

Software boundary and architecture

Scope rationale The software itself guides a therapeutic medical purpose and does not depend on being part of a hardware medical device. This example assumes medical-device software scope pending formal review.

Included and excluded functions Include routine selection, timing cues, pause/resume and session records. Exclude diagnosis, exercise load selection, equipment control and acute or high-risk rehabilitation.

Software inputs Therapist-selected supported routine, participant/session identity and explicit start/pause actions.

Software outputs Exercise timing/sequence cues and a completed-session record; no force command or diagnosis.

Interfaces Application timing service, local session store and authenticated therapist profile; no connected exercise actuator.

Software classification result

The documented scenarios report possible non-serious injury and no serious injury. Validate completeness using the applicable licensed IEC 62304 method. No class reduction is made for proposed controls or human review.

• Preliminary Class B follows the two documented non-serious-injury scenarios.

• This is a restricted teaching case, not a class assignment for rehabilitation applications in general.

• Therapist presence is not treated as an automatic class-reduction control.

Detailed software workflow

Software controls and failure scenarios

• Approve the restricted clinical scope and maximum-harm rationale.

• Verify timing, state transitions, session identity and stop behavior.

• Reassess the safety class before broadening population, exercise load or autonomy.

Foreseeable misuse A user selects an excluded high-risk condition, repeats a session unnecessarily or treats a completion record as evidence of clinical improvement.

Risk 1 Exercise timing or sequence incorrect

Failure sequence Timer or state defect prolongs a low-intensity exercise or repeats a step.

Hazardous situation The eligible user performs more of the bounded routine than intended.

Possible health harm Temporary hand discomfort or non-serious strain in the stated population. Serious-harm possibility has not been ruled out for broader use.

Maximum severity minor

Proposed controls Use controlled routine definitions, visible session state, bounded timing and accessible pause/stop behavior.

Verification challenge Challenge timing drift, background/resume, repeated taps and step-order faults against approved clinical timing requirements.

Residual risk and gaps Clinical confirmation of the non-serious maximum-harm assumption and actual timing evidence remain open.

Traceability RG-REQ-1 proposed → RG-DES-1 proposed → RG-VAL-1 planned intended-user validation; not executed

Risk 2 Wrong routine or duplicate session selected

Failure sequence An identity or resume defect associates the wrong supported routine with the active session.

Hazardous situation The user follows a mismatched low-intensity routine or repeats an already completed sequence.

Possible health harm Transient discomfort or non-serious strain under the restricted intended use; excluded populations require reassessment.

Maximum severity minor

Proposed controls Show user/routine identity before start, bind the session to one version and make repeats explicit.

Verification challenge Swap identities, restore an old session and attempt duplicate start; verify the visible routine and recorded history.

Residual risk and gaps Usability and foreseeable-misuse validation are pending. Do not generalize this Class B screen to all rehabilitation software.

Traceability RG-REQ-2 proposed → RG-DES-2 proposed → RG-VAL-2 planned intended-user validation; not executed

Human review Therapist assesses suitability and configures the routine. This is part of the stated intended-use setting; no automatic reduction from serious harm is credited to supervision.

External controls No class reduction is credited to proposed external controls.

Independence and effectiveness Control effectiveness remains to be demonstrated. Proposed requirements and tests are not completed evidence.

Proposed tests and expected results

All tests are planned and not executed. Approve the acceptance criteria before execution and retain actual observations, deviations and software/configuration identity.

Worked software change assessment

Trigger The routine library expands to postoperative patients or higher-load exercises.

Impact assessment This changes the clinical scope and possible harm; prior Class B assumptions cannot be reused.

Verification and regression Obtain a new clinical risk analysis, revised timing/load requirements and representative-user validation.

Responsible review Clinical and software safety leads reassess classification, including serious-harm scenarios.

Software lifecycle evidence

Configuration baseline Proposed RehabGuide 1.0, routine library 1.0, timing engine 1.0 and supported OS baseline. Lock approved routine definitions.

SOUP and dependencies Identify each third-party component, version, intended role, known anomalies and safety impact; retain supplier and verification evidence.

Cybersecurity and safety Evaluate unauthorized access, altered inputs, dependency vulnerabilities and loss of service against the software safety analysis. Verify relevant protections and recovery.

Problem resolution Record the affected software version, investigate the failure, assess safety impact, control the correction and retain regression evidence before release.

Operational feedback Collect software incidents and user feedback, identify affected versions, trend safety-relevant failures and feed findings into risk and change management.

Overall residual risk Class B is only a preliminary result for the restricted scenario. The clinical reviewer must determine whether serious harm is reasonably possible under actual use and foreseeable misuse; if so, revise to Class C.

Assigned next steps

Clinical lead Validate eligibility, exclusions and foreseeable misuse against maximum harm. Expected deliverable: Clinical scope and harm rationale.

Software verification lead Execute timing, state, identity and resume challenges. Expected deliverable: Evidence linked to RG requirements.

Quality and safety leads Review software class and residual risk after evidence is available. Expected deliverable: Formal classification and release review.

Example 3 AI assisted ECG analysis

3 · AI diagnostic support | Standalone medical-device software (SaMD)

Human review and AI confidence do not automatically lower software class when missed or mismatched clinical information can contribute to serious harm.

Software profile and medical purpose

Software RhythmReview ECG analysis software

Standalone software analyzes compatible recorded adult ECG signals and proposes arrhythmia annotations for qualified clinicians to review. The workflow displays the underlying waveform, input-quality flags and model version. It is not an emergency alarm, autonomous treatment controller or sole diagnostic authority.

Intended medical use Assist qualified clinicians in retrospective assessment of adult ECG recordings by presenting proposed rhythm annotations together with the source signal for review.

Indications and limitations Illustrative scope: adult recorded ECG review using explicitly supported acquisition formats. Pediatric, real-time alarm and autonomous-treatment uses are excluded pending separate assessment.

Software boundary and architecture

Scope rationale The standalone software interprets physiological signals for a medical purpose. The example assesses the complete software function, including preprocessing, model execution, clinical review and reporting.

Included and excluded functions Include ingestion, preprocessing, model inference, review interface, identity linkage and report export. Exclude acquisition hardware, emergency alarms and autonomous treatment.

Software inputs Supported adult ECG recordings, patient/study identifiers, acquisition metadata and locked model configuration.

Software outputs Proposed rhythm annotations, input-quality status, linked source waveform and clinician-reviewed report.

Interfaces Acquisition-file interface, authenticated review workspace, inference runtime and report receiving system.

Software classification result

At least one software failure can contribute to death or serious injury. Validate completeness using the applicable licensed IEC 62304 method. No class reduction is made for proposed controls or human review.

• Preliminary Class C follows missed-rhythm and incorrect-identity harm scenarios.

• The classification concerns software safety; no FDA device class or marketing route is assigned.

• A clinician reviewing output is a control whose effectiveness needs evidence, not a class-reduction shortcut.

Detailed software workflow

Software controls and failure scenarios

• Baseline the clinical claims, supported inputs, model and preprocessing together.

• Separate development/training data from independent evaluation data.

• Link model performance, identity integrity, usability and configuration controls to serious-harm scenarios.

• Use the full medical-device software lifecycle and formal review for a Class C candidate.

Foreseeable misuse A reviewer accepts all annotations without inspecting the waveform, applies the model to an unsupported recording, or relies on it during a time-critical emergency outside scope.

Risk 1 Clinically important rhythm missed

Failure sequence Poor-quality or underrepresented input produces a false-negative annotation; a reviewer accepts the incomplete interpretation.

Hazardous situation A patient is assessed without recognition of a relevant rhythm abnormality.

Possible health harm Delayed treatment or inappropriate management with potential serious injury or death.

Maximum severity serious

Proposed controls Define supported inputs, reject inadequate quality, validate performance across the intended-use population and present the waveform with limitations and required clinical review.

Verification challenge Challenge artifacts, missing channels, rare patterns and distribution shifts. Evaluate prespecified performance metrics with uncertainty against clinically justified acceptance criteria; assess reviewer behavior.

Residual risk and gaps Class C retained. The proposed controls and clinician review do not establish acceptable residual risk or justify a class reduction.

Traceability RR-REQ-001 (proposed) → RR-DES-001 (proposed) → RR-VAL-001: representative intended-user workflow validation; not executed.

Risk 2 Wrong patient or wrong time analysis attached

Failure sequence An integration associates the algorithm output with a different patient or an earlier encounter.

Hazardous situation A clinician acts on an interpretation that does not correspond to the selected patient and study.

Possible health harm Unnecessary or delayed treatment with possible serious injury.

Maximum severity serious

Proposed controls Bind output to immutable input and patient/study identifiers; show source timestamps and require matching before finalization.

Verification challenge Swap identifiers and records, replay old outputs and simulate asynchronous completion. Verify that mismatched output cannot be finalized under another study.

Residual risk and gaps Interface and usability evidence remain open; do not rely on a reviewer’s memory of patient context.

Traceability RR-REQ-002 (proposed) → RR-DES-002 (proposed) → RR-VAL-002: representative intended-user workflow validation; not executed.

Risk 3 Model or preprocessing mismatch

Failure sequence A release deploys a model with incompatible preprocessing or labeling, creating systematically incorrect output.

Hazardous situation Many patients receive misleading interpretations before the defect is recognized.

Possible health harm Potential widespread diagnostic error and serious injury.

Maximum severity serious

Proposed controls Use signed versioned artifacts, compatibility checks, release manifests, known-answer tests and a controlled rollback/containment process.

Verification challenge Attempt incompatible model/preprocessor combinations, corrupt artifacts and partial deployment; verify blocking and rollback with representative records.

Residual risk and gaps Configuration-control and monitoring evidence are required before release.

Traceability RR-REQ-003 (proposed) → RR-DES-003 (proposed) → RR-VAL-003: representative intended-user workflow validation; not executed.

Human review The proposed reviewer sees raw waveform, annotations, quality flags and uncertainty/limitations. Specify qualifications, realistic review time and mandatory correction/confirmation steps. Validate recognition of seeded false negatives, false positives and wrong-patient cases. No unmeasured reduction of IEC class is claimed.

External controls No class reduction is credited to proposed external controls.

Independence and effectiveness Control effectiveness remains to be demonstrated. Proposed requirements and tests are not completed evidence.

Proposed tests and expected results

All tests are planned and not executed. Approve the acceptance criteria before execution and retain actual observations, deviations and software/configuration identity.

Worked software change assessment

Trigger Model update adds a rhythm category and introduces data from a new acquisition platform.

Impact assessment This changes outputs, supported inputs and possible failure modes. Revisit indications, labeling, hazards, subgroup performance, interfaces and regulatory submission impact.

Verification and regression Use an independent locked evaluation set, input-format challenges, all prior safety regressions and realistic reviewer validation; retain the prior model for controlled rollback.

Responsible review Regulatory Affairs must assess the marketing-authorization impact before release; a model version increment is not merely an IT patch.

Software lifecycle evidence

Configuration baseline Proposed application 1.0, model RR-0.9, inference settings 1.0, preprocessing PP-1, label dictionary 1.0 and dataset manifests. Lock training/validation/test separation, SOUP/runtime versions, supported formats and deployment configuration.

SOUP and dependencies Baseline the numerical, signal-processing, inference, file-parser and operating-system components. Assess known anomalies and model/runtime compatibility.

Cybersecurity and safety Assess altered waveforms, identity substitution, unauthorized report access, model artifact tampering and service interruption. Connect security controls to affected safety requirements.

Problem resolution Triage reports against patient safety, identify affected model/application versions and records, consider containment, investigate data or algorithm defects, update risks and requirements, verify corrections and assess applicable reporting/CAPA obligations.

Operational feedback Monitor complaints, missed/incorrect annotations, data-quality failures, supported acquisition formats, cybersecurity issues and performance drift. Review subgroup and site trends where supported by an approved data plan.

Overall residual risk Residual-risk acceptance is pending actual control verification, intended-use validation and the responsible organization’s review.

Assigned next steps

Clinical and software safety leads Approve intended-use claims and complete serious-harm analysis. Expected deliverable: Clinical/safety requirements and classification rationale.

Model and verification leads Execute independent performance, interface and model-compatibility evidence plans. Expected deliverable: Locked datasets, protocol and observed results.

Quality lead Review validation, unresolved anomalies and the released software baseline. Expected deliverable: Traceable release recommendation.

Example 4 Infusion control firmware

4 · Embedded therapy control | Software within a medical device

Classify the control software and its failure propagation. Device implantation, mechanical design and marketing pathways are outside this software assessment.

Software profile and medical purpose

Software DoseFlow infusion-control firmware

Embedded software validates authorized infusion settings, schedules delivery commands, monitors state and handles faults in a medical infusion device. This assessment covers software behavior and interfaces, with the physical device evaluated through its separate system process.

Intended medical use Execute clinician-authorized infusion parameters and safety-state behavior within a defined medical infusion device.

Indications and limitations The clinical team must establish the supported therapy, population, parameter ranges and use conditions. No example dose or treatment instruction is supplied.

Software boundary and architecture

Scope rationale The software is integral to a medical device and performs therapy-control and fault-handling functions. The classification boundary is the complete controller firmware system.

Included and excluded functions Include settings validation, command interpretation, timing, delivery-state management, diagnostics, fault notifications and update/recovery logic. Exclude mechanical design while retaining all safety-relevant hardware interfaces in the analysis.

Software inputs Authorized settings, device identity, timing/state signals, sensor/diagnostic status and update artifacts.

Software outputs Delivery-control commands, acknowledged settings, software state, fault notifications and versioned event records.

Interfaces Clinician programming interface, device I/O, diagnostic inputs, external safety mechanisms, boot/update boundary and service interface.

Parent system Illustrative medical infusion device; controller firmware is the software system being assessed.

Software classification result

At least one software failure can contribute to death or serious injury. Validate completeness using the applicable licensed IEC 62304 method. No class reduction is made for proposed controls or human review.

• Preliminary Class C follows possible serious injury or death from erroneous therapy-control software.

• Class is assigned to the defined controller software system; this does not classify or approve the entire physical device.

• External supervision and clinician checks remain evidence-dependent controls.

Detailed software workflow

Software controls and failure scenarios

• Define and verify the software state machine, scheduling assumptions and fault responses.

• Use independent measurements for control-output and timing verification against system requirements.

• Prove command identity, authorization, atomic application and unambiguous acknowledgment.

• Retain full firmware/build configuration, SOUP and update/recovery evidence.

Foreseeable misuse Wrong identity or settings, repeated commands after an uncertain acknowledgment, unauthorized programming, ignored faults or incompatible software updates.

Risk 1 Excessive therapy delivery

Failure sequence A unit conversion, scheduling or command-interpretation defect produces delivery beyond the intended prescribed setting.

Hazardous situation The infusion device delivers more therapy than intended.

Possible health harm Severe toxicity, serious injury or death depending on the therapy.

Maximum severity serious

Proposed controls Use unambiguous units and parameter bounds, authenticated commands with read-back, independently justified supervisory controls and controlled delivery-state transitions.

Verification challenge Challenge each supported unit/parameter boundary, invalid transitions, duplicate commands, overflow and corrupted settings. Verify delivery behavior with an independent measurement method against approved system requirements.

Residual risk and gaps Class C retained; software checks and clinician confirmation do not establish independence or eliminate serious harm.

Traceability DF-REQ-1 proposed → DF-DES-1 proposed → DF-VAL-1 planned intended-user validation; not executed

Risk 2 Therapy interrupted without effective detection

Failure sequence A scheduling, battery, sensor or communication fault stops delivery and the fault handling fails to produce the required notification.

Hazardous situation The patient receives insufficient or no intended therapy before effective intervention.

Possible health harm Loss of treatment, serious deterioration or death depending on therapy and patient condition.

Maximum severity serious

Proposed controls Define system-specific fault detection, validated notification and recovery behavior, and follow-up instructions tied to clinical hazards.

Verification challenge Inject power, timing, memory, sensor and communication faults across operational states. Measure detection/response against clinically justified requirements and verify safe recovery.

Residual risk and gaps Clinical time-to-harm assumptions, notification effectiveness and failure coverage need evidence before acceptance.

Traceability DF-REQ-2 proposed → DF-DES-2 proposed → DF-VAL-2 planned intended-user validation; not executed

Risk 3 Unauthorized or wrong device programming

Failure sequence A communication/authentication or identity defect allows a command to be accepted by the wrong device or by an unauthorized actor.

Hazardous situation Therapy parameters change without the intended clinician’s authorized decision for the correct device.

Possible health harm Inappropriate delivery with potential serious injury or death.

Maximum severity serious

Proposed controls Bind programmer authorization to device identity, protect command integrity/freshness, verify acknowledged settings and control access/recovery paths.

Verification challenge Attempt replay, tampering, identity substitution, interrupted sessions and recovery-mode abuse. Verify rejected commands cannot alter therapy state.

Residual risk and gaps Security, usability and fail-safe behavior must be assessed jointly; no residual-risk acceptance is implied.

Traceability DF-REQ-3 proposed → DF-DES-3 proposed → DF-VAL-3 planned intended-user validation; not executed

Human review Users must verify identity and acknowledged settings. This does not establish protection against run-time state or timing failures.

External controls Independent hardware supervision may be proposed. Verify independence, coverage and common-cause vulnerabilities; no class reduction is applied here.

Independence and effectiveness Control effectiveness remains to be demonstrated. Proposed requirements and tests are not completed evidence.

Proposed tests and expected results

All tests are planned and not executed. Approve the acceptance criteria before execution and retain actual observations, deviations and software/configuration identity.

Worked software change assessment

Trigger A software change alters repeated-command or interrupted-session handling.

Impact assessment Reassess duplicate execution, timing, state transitions, recovery, security and user understanding.

Verification and regression Repeat command, fault-injection, timing, control-output, update and usability regressions on the final integrated software.

Responsible review Software safety and system owners review affected hazards and release constraints before deployment.

Software lifecycle evidence

Configuration baseline Proposed DoseFlow DF-1.0, bootloader BL-1.0, parameter schema 1.0, RTOS and driver baselines, interface versions and compiler/build configuration.

SOUP and dependencies Assess RTOS, drivers, communication stacks, cryptographic libraries and bootloader dependencies against scheduling, integrity and recovery requirements.

Cybersecurity and safety Assess tampering, replay, unauthorized commands, service-mode misuse and compromised updates together with the software safety state machine.

Problem resolution Record the affected software version, investigate the failure, assess safety impact, control the correction and retain regression evidence before release.

Operational feedback Collect software incidents and user feedback, identify affected versions, trend safety-relevant failures and feed findings into risk and change management.

Overall residual risk Residual-risk acceptance is pending actual control verification, intended-use validation and the responsible organization’s review.

Assigned next steps

Software architect Finalize software boundaries, state transitions and interface contracts. Expected deliverable: Approved architecture and detailed design.

Verification lead Execute fault, timing, command and update/recovery challenges. Expected deliverable: Traceable verification evidence.

Software safety and Quality leads Resolve residual risks and anomalies against formal acceptance criteria. Expected deliverable: Software classification and release decision.

Example 5 Radiotherapy planning software

5 · Complex treatment planning | Standalone medical-device software (SaMD)

A standalone application can carry serious therapy risk through its outputs even when it never controls the treatment hardware.

Software profile and medical purpose

Software PlanWise radiotherapy planning software

Standalone clinical software imports patient images and structure sets, supports treatment-plan preparation, computes a dose distribution using a controlled calculation engine and exports an approved plan. It does not directly actuate a treatment-delivery device.

Intended medical use Support qualified clinical professionals in creating, reviewing and exporting radiotherapy treatment plans within a defined clinical scope.

Indications and limitations Supported treatment techniques, anatomical sites, image formats and calculation limits must be explicitly specified and clinically validated. No clinical dose recommendations or patient treatment parameters are supplied in this example.

Software boundary and architecture

Scope rationale The software itself performs medical treatment-planning functions independently of being part of a hardware medical device. The whole planning software system is assessed.

Included and excluded functions Include patient/study linkage, image geometry handling, structure management, plan configuration, calculation, review/approval, export and versioned change control. Exclude image acquisition and physical treatment delivery, while analyzing interface error propagation.

Software inputs Patient/study identifiers, supported image and structure datasets, clinical plan inputs, validated calculation configuration and reference data.

Software outputs Calculated distributions, plan metrics, review/approval state and an exported versioned treatment plan.

Interfaces Medical-image import, identity service, calculation workers, plan database, review clients and downstream plan recipient.

Software classification result

At least one software failure can contribute to death or serious injury. Validate completeness using the applicable licensed IEC 62304 method. No class reduction is made for proposed controls or human review.

• Preliminary Class C follows geometry, calculation and plan-version failures with potential serious harm.

• No physical treatment-delivery or implantation assessment is included. The focus is software information integrity and lifecycle evidence.

• Software complexity and AI use do not determine the class; the possible harm and assessed boundary do.

Detailed software workflow

Software controls and failure scenarios

• Control clinical scope, geometry, calculation inputs and versioned algorithms.

• Use independent calculation/geometry references with approved quantitative criteria.

• Bind patient, study, calculation configuration, approval and export to the same immutable plan version.

• Validate realistic clinical review, concurrency, degraded service and recovery.

Foreseeable misuse Mix studies or coordinates, reuse a stale approved plan, calculate outside validated limits, bypass review or interpret partial calculations as final.

Risk 1 Wrong patient or coordinate mapping

Failure sequence Image/structure import associates data with the wrong patient, frame or orientation; the plan is prepared against the mismatched geometry.

Hazardous situation A plan represents the wrong anatomy or spatial relationship.

Possible health harm Incorrect treatment information can lead to serious injury or death if used downstream.

Maximum severity serious

Proposed controls Bind all objects to patient/study/frame identity, validate geometry consistency and block unexplained transformations.

Verification challenge Challenge swapped identifiers, laterality, orientation, mismatched frames and missing metadata with independently prepared reference cases.

Residual risk and gaps Clinical workflow and geometry-validation effectiveness need evidence before acceptance.

Traceability PW-REQ-1 proposed → PW-DES-1 proposed → PW-VAL-1 planned intended-user validation; not executed

Risk 2 Incorrect or incomplete calculation presented as final

Failure sequence A numerical/configuration defect, unsupported input or worker interruption produces an incorrect distribution that appears complete.

Hazardous situation The reviewer receives misleading treatment-plan information.

Possible health harm Downstream over-treatment, under-treatment or wrong-location treatment can cause serious injury or death.

Maximum severity serious

Proposed controls Validate supported domains, lock calculation configuration, distinguish incomplete results and use independent reference comparisons.

Verification challenge Use independent reference datasets, boundary and unsupported-domain cases, worker interruption and cross-platform reproducibility tests against approved criteria.

Residual risk and gaps Quantitative acceptance limits and reference evidence must be established by qualified clinical/physics reviewers.

Traceability PW-REQ-2 proposed → PW-DES-2 proposed → PW-VAL-2 planned intended-user validation; not executed

Risk 3 Stale or altered plan exported

Failure sequence A concurrency, approval-state or export defect transmits a plan version that differs from the reviewed version.

Hazardous situation The receiving workflow obtains incorrect or unapproved treatment information.

Possible health harm Incorrect downstream treatment with potential serious injury or death.

Maximum severity serious

Proposed controls Make approved versions immutable, revoke approval after edits, bind export to content identity and reconcile recipient acknowledgment.

Verification challenge Edit during approval/export, replay old messages, corrupt payloads and interrupt receipt; prove end-to-end identity and state consistency.

Residual risk and gaps Interface conformance, concurrency, recovery and representative-user validation remain open.

Traceability PW-REQ-3 proposed → PW-DES-3 proposed → PW-VAL-3 planned intended-user validation; not executed

Human review Qualified reviewers inspect patient identity, image/structure consistency, plan metrics and independent checks. Effectiveness needs validation; reviewer presence does not lower Class C.

External controls No class reduction is credited to proposed external controls.

Independence and effectiveness Control effectiveness remains to be demonstrated. Proposed requirements and tests are not completed evidence.

Proposed tests and expected results

All tests are planned and not executed. Approve the acceptance criteria before execution and retain actual observations, deviations and software/configuration identity.

Worked software change assessment

Trigger A numerical-library upgrade changes calculation behavior or parallel execution.

Impact assessment Identify affected validated domains, precision, reproducibility, geometry handling and archived plan interpretation.

Verification and regression Repeat reference, boundary, performance, concurrency and end-to-end planning regressions on the final baseline.

Responsible review Software safety, clinical physics and Quality owners review the safety impact and release evidence before deployment.

Software lifecycle evidence

Configuration baseline Proposed PlanWise 1.0, geometry library GL-1, calculation engine CE-1, clinical configuration CC-1, import/export schema 1.0 and validated execution environment.

SOUP and dependencies Assess image/geometry libraries, numerical solvers, GPU/CPU execution dependencies, database, operating system and export libraries for known anomalies and reproducibility.

Cybersecurity and safety Assess altered patient/plan data, unauthorized approval, calculation-worker compromise, artifact tampering and downtime. Bind plan integrity and authorization to immutable software/configuration versions.

Problem resolution Record the affected software version, investigate the failure, assess safety impact, control the correction and retain regression evidence before release.

Operational feedback Collect software incidents and user feedback, identify affected versions, trend safety-relevant failures and feed findings into risk and change management.

Overall residual risk No overall residual-risk acceptance is claimed. Clinical, calculation, interface, independent-check and intended-user evidence remain required.

Assigned next steps

Clinical physics lead Define supported clinical domains and independent acceptance criteria. Expected deliverable: Approved reference/validation protocol.

Software architect Establish geometry, calculation, approval and export contracts. Expected deliverable: Controlled architecture and interface requirements.

Verification and validation leads Execute independent calculations and full clinical-workflow challenges. Expected deliverable: Traceable software evidence and anomalies.

Software safety and Quality leads Review class, residual risk and release readiness. Expected deliverable: Formal software classification and release review.