IEC 62304 for machine learning: mapping software lifecycle to ML development.

i. Why the mapping is hard

IEC 62304 rests on three assumptions that held true for all medical device software when the standard was written in 2006. Machine learning violates all three.

Assumption 1: Software behavior is deterministic. For traditional software, the same input produces the same output every time. IEC 62304’s verification framework — “does the software unit produce the expected output for a given input?” — is built on this foundation. ML models are probabilistic. A classifier that outputs “89% probability of malignancy” is performing correctly, but its output is not predictable from any single input in the way a deterministic function’s is.

Assumption 2: Requirements are functional specifications. Traditional requirements read like contracts: “the system shall display heart rate in beats per minute with ±2 BPM accuracy.” ML requirements are performance targets: “the model shall achieve ≥90% sensitivity and ≥85% specificity for detecting diabetic retinopathy.” These are statistical claims verified against datasets, not functional specifications verified against test cases.

Assumption 3: Software is static until explicitly changed. IEC 62304 assumes software does not change unless a developer changes it. ML models are designed to change. The learned parameters of a neural network are “code” that was never written by a human — it was generated by an optimization process acting on data.

The answer is not to abandon IEC 62304 or treat it as inapplicable. It is to find the right mapping — to identify which parts of the ML development process correspond to which 62304 activities, and to document them accordingly.

ii. The mental model that makes it work

The single most useful conceptual move for mapping IEC 62304 to ML development:

Treat the ML pipeline as a software system (governed by 62304) that produces a model (which is a software item within that system).

The training code — data ingestion, preprocessing, augmentation, model architecture definition, training loop, hyperparameter configuration — is deterministic software. The same script with the same data and the same random seed produces the same model. This code fits neatly into 62304’s framework.

The trained model — the learned weights and parameters — is a generated artifact, like a compiled binary. It is produced by the training pipeline and consumed by the inference engine. It has its own verification approach (performance testing against held-out data) and its own version management requirements.

The inference engine — the code that loads the trained model, accepts input, runs it through the model, and produces output — is again deterministic software. Same input, same model, same output. Standard 62304 applies.

When you internalize this decomposition, the mapping becomes mechanical rather than philosophical.

iii. Software development planning for ML

IEC 62304 Clause 5.1 requires a software development plan. For ML, this plan needs to cover activities that 62304 did not anticipate but that follow its structure naturally.

Data-related activities (not in 62304 but essential): data acquisition strategy and source identification, data quality criteria and acceptance procedures, annotation/labeling methodology and quality control, dataset splitting strategy (training/validation/test), and bias assessment approach.

ML-specific development activities: model architecture selection and justification, training procedure (loss function, optimizer, hyperparameter search), validation strategy during development, performance metric selection and threshold definition, and robustness and edge-case testing approach.

Standard 62304 activities (applied to all deterministic components): software architecture and decomposition, coding standards, unit/integration/system testing approach, configuration management strategy, and documentation level assignments for each software item.

The plan should explicitly identify which activities are ML-specific, which are standard software development, and how they connect.

iv. Software requirements for ML

IEC 62304 Clause 5.2 requires software requirements including functional, performance, interface, and regulatory requirements. For ML, performance requirements are statistical rather than absolute.

How to write 62304-compliant requirements for ML components:

Traditional requirement:

REQ-001: The system shall calculate heart rate from PPG signal
         with accuracy of ±2 BPM.
         Verification: Unit test with reference signal dataset.

ML requirement (wrong approach):

REQ-001: The model shall detect diabetic retinopathy.
         Verification: ???

ML requirement (right approach):

REQ-001: The model shall classify fundus images as
         "referable DR" or "non-referable" with:
         - Sensitivity ≥ 90% (95% CI lower bound ≥ 85%)
         - Specificity ≥ 85% (95% CI lower bound ≥ 80%)
         - measured on a held-out test set of ≥ 1,000 images
           representative of the intended patient population.
         Verification: Performance evaluation per VP-001.

REQ-002: Model performance shall not degrade by > 5%
         (absolute) for any demographic subgroup defined
         in the bias assessment plan (DAP-001).
         Verification: Subgroup analysis per VP-001.

The key differences: the requirement specifies measurable performance criteria, defines the statistical confidence expected, specifies the verification methodology, and references the dataset requirements. This is not a workaround — it is what 62304 already requires, applied to the specific performance characteristics of an ML system.

v. Software architecture for ML

IEC 62304 Clause 5.3 requires a software architecture that decomposes the system into software items. For ML:

Each software item gets its own documentation level assignment, V&V approach, and change management.

vi. Software detailed design for ML

IEC 62304 Clause 5.4 requires detailed design — enough detail that the software could be implemented from the design documentation. For deterministic components, this is standard: module interfaces, data flows, algorithms, error handling.

For ML components, detailed design means documenting the choices that define how the model is built:

• Model architecture: why this architecture (CNN, transformer, ensemble) for this clinical task. Not just “we used ResNet-50” but “we selected ResNet-50 because [clinical justification, performance benchmarks, reference literature].”
• Loss function and optimization: what loss function, what optimizer, what learning rate schedule, and why these choices are appropriate for the clinical objective.
• Hyperparameters: all tunable parameters documented with their selected values and the method used to select them (grid search, Bayesian optimization, expert judgment).
• Regularization strategy: dropout, weight decay, data augmentation approaches — documented as design decisions with rationale.

These are design decisions in the same way that choosing a sorting algorithm or a database schema is a design decision in traditional software. They need to be documented, reviewed, and justified — particularly because the clinical performance of the model depends on them.

vii. Unit implementation and verification

IEC 62304 Clause 5.5 covers implementation and verification of software units. For ML systems, the approach splits by component type.

Deterministic components (data pipeline, inference engine, output layer): standard unit testing.

# Unit test: preprocessing module
def test_image_resize():
    input_image = load_test_image("sample_fundus.png")
    output = preprocess(input_image)
    assert output.shape == (224, 224, 3)
    assert output.min() >= 0.0
    assert output.max() <= 1.0

# Training-serving consistency check
def test_preprocessing_consistency():
    """Training and inference preprocessing must
    produce identical outputs for identical inputs."""
    image = load_test_image("sample_fundus.png")
    train_output = training_preprocess(image)
    infer_output = inference_preprocess(image)
    assert np.allclose(train_output, infer_output, atol=1e-6)

ML model: traditional unit verification does not apply to a neural network — you cannot write a unit test for a learned weight matrix. Instead, verification at this level means confirming the model architecture matches the detailed design specification (correct layers, activations, input/output dimensions), confirming the training process converged, and confirming the trained model produces outputs in the expected format and range. Full performance verification happens at system testing (Section ix).

viii. Integration and integration testing

IEC 62304 Clause 5.6 covers integration of software items and integration testing. For ML systems, this is where training-serving skew gets tested explicitly.

# End-to-end pipeline validation
def test_end_to_end_pipeline():
    raw_input = load_raw_clinical_image("test_001.dcm")
    result = full_pipeline.predict(raw_input)
    assert result.label in ["referable", "non-referable"]
    assert 0.0 <= result.confidence <= 1.0

# Training-serving skew detection
def test_no_training_serving_skew():
    test_images = load_test_set("integration_tests/")
    for img in test_images:
        train_out = training_pipeline.preprocess(img)
        infer_out = inference_pipeline.preprocess(img)
        assert np.allclose(train_out, infer_out)

# Edge case / error handling
def test_edge_case_handling():
    corrupt = load_corrupt_image("truncated.dcm")
    result = full_pipeline.predict(corrupt)
    assert result.error_code == "INVALID_INPUT"
    assert result.label is None  # no clinical prediction

Integration testing for ML also includes testing data flow integrity through the entire pipeline — confirming that data transformations are applied in the correct order, that metadata is preserved, and that the system handles missing or malformed inputs according to the design specification.

ix. System testing

IEC 62304 Clause 5.7 requires system testing — verification that the integrated software system meets its specified requirements. For ML, this is where clinical performance validation happens.

System testing for ML means running the complete system (not just the model in isolation) against a held-out test set and measuring:

• Primary performance metrics (sensitivity, specificity, AUC) against defined thresholds
• Subgroup analysis — performance broken down by clinically relevant subgroups
• Robustness testing — performance under degraded conditions (noisy inputs, low-resolution, edge cases)
• Out-of-distribution detection — how the system behaves with inputs outside its training distribution
• Operating point analysis — performance across a range of decision thresholds to confirm the selected operating point is appropriate

This system testing maps directly to what FDA expects in the AI/ML section of a 510(k) submission. When your 62304 system test report and your FDA clinical performance report are built from the same underlying testing, the documentation is consistent and efficient — one body of evidence serving both purposes.

x. Configuration management for ML

IEC 62304 Clause 5.8 (and Clause 8) requires configuration management. This is where ML creates the most novel challenges. Beyond standard source code versioning, you need to track:

• Training data — the exact version (which records, what preprocessing, what annotation revision)
• Model weights — often hundreds of megabytes or gigabytes, cannot be stored in standard git
• Hyperparameters — the full training configuration (learning rate, batch size, epochs, architecture variant, random seed)
• Training environment — framework versions (TensorFlow 2.15.0, PyTorch 2.2.1), CUDA version, hardware specification
• Random seeds — for reproducibility of training runs

Standard git handles source code but not large binary artifacts. Practical solutions include tools like DVC (Data Version Control), MLflow, or Weights & Biases for experiment tracking, combined with artifact storage (S3, GCS, Azure Blob) for large files. The specific tool matters less than the principle: every training run must be fully reproducible from the versioned configuration.

xi. Software changes and the retraining question

IEC 62304 Clause 6 and Clause 9 govern software changes. The central question: does retraining the model constitute a “software change” under 62304?

The answer: yes, with nuance. Retraining produces a new model artifact with potentially different performance characteristics. Under 62304, any modification that could affect safety or performance requires evaluation through change management.

However, if you filed a PCCP with your 510(k), certain types of retraining are pre-authorized — provided they follow the Algorithm Change Protocol you committed to:

• Retraining on new data from the same distribution → likely covered by PCCP
• Retraining with a new architecture or fundamentally different data → likely requires a new 510(k)
• Fine-tuning decision thresholds within pre-specified ranges → likely covered by PCCP
• Expanding to a new patient population or clinical indication → requires a new 510(k)

Your 62304 change management procedure and your PCCP should reference each other. The change management procedure defines how changes are evaluated. The PCCP defines which changes are pre-authorized. Together, they give you a clear framework for managing model updates. For teams that plan to retrain regularly, this intersection is one of the most important topics to discuss in your FDA Pre-Sub.

xii. Documentation levels

FDA’s 2023 guidance “Content of Premarket Submissions for Device Software Functions” replaced the old “level of concern” framework with “documentation level.” The documentation level determines how much detail FDA expects in your 62304-based software documentation.

Most AI SaMD that provides clinical recommendations or diagnostic support falls into the Enhanced Documentation category, which requires the most detailed documentation across all 62304 clauses. For ML-specific components, Enhanced Documentation means: full training data description, complete model architecture documentation with design rationale, detailed hyperparameter documentation, full performance testing results with subgroup analysis, robustness test results, complete configuration management records, and PCCP documentation if applicable.

The documentation level applies to the system, but the depth for individual software items should be proportional to their contribution to clinical risk. The trained model and inference engine (directly involved in clinical output) warrant deeper documentation than a logging module or administrative interface.

xiii. Common questions

Can we use agile development and still comply with IEC 62304?

Yes. IEC 62304 prescribes what to document, not when. Agile teams can work in sprints, iterate on model architectures, and refactor code — as long as the required documentation exists by the time the software is verified and released.

Does our training data count as a “software item” under 62304?

Not exactly — training data is not software. But it is a critical input to the software development process that 62304 expects to be controlled. Your configuration management procedures should cover training data versioning and traceability. In practice, treat training data with the same rigor you would apply to source code.

How do we handle third-party ML frameworks (TensorFlow, PyTorch)?

Under 62304, third-party software is a SOUP (Software of Unknown Provenance). Your risk management process should evaluate the risks associated with using the framework, and your configuration management should track the specific version deployed. For ML frameworks specifically, version changes can affect model training behavior (floating-point precision, default parameter initialization, optimizer behavior). Document the framework version as part of your training environment specification and evaluate framework updates through your change management process.

What about pre-trained foundation models or transfer learning?

A pre-trained model used as the starting point for your device (e.g., ResNet pre-trained on ImageNet, then fine-tuned on clinical data) is also SOUP. Document: where the pre-trained weights came from, what data they were trained on (to the extent known), and how your fine-tuning process modified them. The risk assessment should consider the implications of using weights learned from non-clinical data in a clinical context.

Does 62304 apply differently for locked vs. continuously learning algorithms?

Yes, in practice. A locked algorithm (trained once, deployed as-is) fits 62304 naturally — it is a static software item that does not change until explicitly retrained through a controlled change process. A continuously learning algorithm (one that updates its parameters during deployment) is much harder to reconcile with 62304, because the software is changing without a traditional change management process. FDA’s current position is cautious about continuously learning algorithms — most cleared AI SaMD to date uses locked algorithms with periodic, controlled retraining. If you are building a continuously learning system, this is a high-priority Pre-Sub topic.

Do we need separate 62304 documentation for cloud infrastructure?

The cloud infrastructure supporting your SaMD is not typically documented under 62304 — it is infrastructure, not medical device software. However, it should be covered by your ISMS (ISO 27001/SOC 2) and by FDA’s cybersecurity documentation requirements. Your 62304 documentation should specify the deployment environment requirements, and your infrastructure documentation should demonstrate those requirements are met.

Closing

IEC 62304 was not designed for machine learning, but it was not designed to exclude it either. The standard provides a framework for controlled, documented, verifiable software development — and ML development benefits from exactly that discipline.

The mapping is not always intuitive. Training data governance, probabilistic verification, model versioning, and the retraining question all require thoughtful adaptation of 62304’s concepts. But the underlying principle is the same: know what you built, know how you tested it, know that it works, and be able to prove it.

Get the mental model right — pipeline as system, model as artifact — and the documentation follows.