IEC 62304 for Spectroscopy Software: Lifecycle Requirements

You have built a spectroscopy-based diagnostic. The ML model works. The clinical workflow is solid. The HL7 integration is tested. Now your regulatory consultant tells you that your software needs to conform to IEC 62304, and you have no idea what that means for your development process, your timeline, or your team.

IEC 62304 is the international standard for medical device software lifecycle processes. If your spectroscopy software is - or will become - Software as a Medical Device, this standard governs how you develop, verify, release, and maintain it. The FDA recognizes it as a consensus standard. The EU requires it for IVDR compliance. Every major regulatory pathway for diagnostic software leads through IEC 62304.

This article is the practical guide. Not the regulatory consultant's version that quotes clause numbers for 40 pages, but the engineering team's version that tells you what you actually need to build, document, and maintain - with spectroscopy-specific examples throughout.

This article is educational and does not constitute legal or regulatory advice - consult qualified regulatory professionals for your specific situation.

What IEC 62304 is (and is not)

IEC 62304 is a process standard, not a product standard. It does not tell you what your software should do. It tells you how to develop, document, and maintain software that does what it does safely.

The standard defines requirements for:

• Planning software development
• Specifying and analyzing requirements
• Designing software architecture
• Implementing and verifying software units
• Integrating and testing the complete system
• Releasing software
• Maintaining software post-release

What IEC 62304 does not cover:

• Product-level validation (does the software solve the right clinical problem?) - that is IEC 82304-1
• Risk management methodology - that is ISO 14971 (though IEC 62304 references it heavily)
• Quality management systems - that is ISO 13485 / 21 CFR Part 820
• Cybersecurity - that is IEC 81001-5-1

IEC 62304 is one piece of the regulatory puzzle. But it is the piece that governs your daily engineering work - your development workflow, your documentation, your testing, your release process. Get this right and the rest of the compliance program has a foundation. Get it wrong and everything built on top is unstable.

Current edition

The version in force is IEC 62304:2006 + Amendment 1:2015 (Edition 1.1). This is what the FDA recognizes as a consensus standard and what Notified Bodies audit against today.

Edition 2 is expected to publish in late 2026. The most significant change: the current three safety classes (A, B, C) are replaced by two rigor levels (Level I and Level II), with current Class B and Class C merged into Level II. This effectively elevates all Class B software to Class C documentation requirements. Regulatory adoption will lag publication by 2-3 years, but if your software will be in active development in 2028-2029, you should be aware of what is coming.

For this article, all requirements reference Edition 1.1 - the current enforceable standard.

Software safety classification

The first and most consequential IEC 62304 decision is your software safety class. The class determines the rigor of every subsequent process requirement. Classify too low and you face regulatory findings. Classify too high and you drown in unnecessary documentation.

The three classes

Class A - No injury possible. The software cannot contribute to a hazardous situation, or if it can, the resulting injury is negligible. For spectroscopy systems: administrative modules, audit log viewers, report formatting, data archival functions that are not in the diagnostic decision path. Minimal documentation requirements.

Class B - Non-serious injury possible. The software can contribute to a hazardous situation, but the most severe resulting injury is non-serious (reversible, no permanent impairment). For spectroscopy systems: clinical decision support tools where the clinician independently verifies the result before acting. The spectral classification informs the diagnosis but does not drive it autonomously. Moderate documentation requirements.

Class C - Serious injury or death possible. The software can contribute to a hazardous situation that could result in serious injury or death. For spectroscopy systems: autonomous diagnostic outputs where the clinician relies on the classification result without meaningful independent verification - identifying a drug-resistant pathogen (wrong antibiotic could be fatal), classifying tissue as benign when it is malignant (delayed cancer treatment). Full documentation requirements.

How to classify spectroscopy diagnostic software

Classification follows a decision tree driven by ISO 14971 risk management, with one critical rule: you must assume software failure probability is 100% when classifying. This is not a probabilistic assessment - it is a worst-case analysis. What happens if the software fails completely?

Step 1: Can software failure contribute to a hazardous situation?

  Your spectral classifier outputs "Negative" when the sample
  is actually positive. Does this create a hazard?

  NO  → Class A (unlikely for diagnostic software)
  YES → Continue to Step 2

Step 2: Can the hazard be controlled by measures EXTERNAL
        to the software?

  Does a pathologist independently review the result?
  Does a confirmatory test always follow?
  Does hardware prevent the hazardous outcome?

  Note: only controls EXTERNAL to the failing software count.
  A confidence score displayed by the same software does not
  count - if the software is failing, its confidence score
  is also unreliable.

  YES (and residual risk is acceptable) → Class A
  NO  → Continue to Step 3

Step 3: What is the severity of the potential injury?

  Non-serious (reversible, no permanent harm)  → Class B
  Serious (permanent harm or death possible)   → Class C

Where spectroscopy diagnostics typically land

Most spectroscopy diagnostic software lands in Class B or Class C. Here is how specific applications typically classify:

A critical nuance: your software system as a whole takes the classification of its highest-class component unless you can demonstrate architectural segregation - separate processes, memory protection, hardware partitioning - proving that a failure in one component cannot propagate to safety-critical components. If your spectral classifier (Class C) runs in the same process as your audit log viewer (Class A), the entire system is Class C.

Required processes by safety class

IEC 62304 scales documentation requirements by safety class. Here is what each class requires, with spectroscopy-specific examples.

Software development planning (all classes)

Every safety class requires a Software Development Plan (SDP) before development begins. This is the foundation document that describes how you will build, verify, and release the software.

For a spectroscopy diagnostic platform, your SDP should cover:

• Safety class determination with rationale - document why each software component is classified as A, B, or C. Reference your ISO 14971 hazard analysis.
• Development methodology - Waterfall, Agile, or hybrid - IEC 62304 is methodology-agnostic. If using Agile sprints, reference AAMI TIR45 (2023) for the mapping between sprint-based development and IEC 62304 activities.
• Tools and environment - Python version, ML frameworks, spectrometer SDKs, testing tools, CI/CD pipeline. Every tool that touches safety-critical code should be identified.
• SOUP management approach - how you will identify, evaluate, and monitor third-party libraries (NumPy, SciPy, scikit-learn, PyTorch, React, FastAPI - all SOUP).
• Configuration management - Git branching strategy, artifact versioning, document control. Your Git history is part of your design history file.
• Problem resolution process - how bugs are reported, triaged, risk-assessed, fixed, verified, and closed.

The SDP is a living document. Update it when your development process changes - do not create it once and forget it.

Software requirements analysis (all classes)

All classes require a formal Software Requirements Specification (SRS) with numbered, traceable, testable requirements. This is the backbone of your IEC 62304 compliance - every subsequent activity traces back to requirements.

For spectroscopy diagnostic software, your SRS should include categories like:

Functional requirements:

• The system shall acquire spectra from [instrument type] via [protocol/SDK]
• The system shall preprocess acquired spectra using [baseline correction algorithm] and [normalization method]
• The system shall classify preprocessed spectra using [model type] and output [classification categories]
• The system shall generate [HL7v2 ORU^R01 / FHIR DiagnosticReport] messages containing classification results

Performance requirements:

• The system shall acquire a spectrum with minimum spectral resolution of [X] cm⁻¹
• The system shall complete classification within [Y] seconds of spectrum acquisition
• The classification model shall achieve minimum sensitivity of [X]% and specificity of [Y]% against [reference method]
• The system shall maintain classification accuracy across [temperature range], [humidity range], [instrument configurations]

Safety requirements (from ISO 14971 risk controls):

• The system shall reject spectra with signal-to-noise ratio below [threshold] and prompt the operator to repeat the measurement
• The system shall display a confidence score alongside every classification result
• The system shall flag low-confidence classifications (below [threshold]) for mandatory manual review
• The system shall prevent release of results that have not passed quality control checks

Interface requirements:

• The system shall communicate with [Bruker OPUS via DDE / Horiba LabSpec via SDK / Thermo OMNIC via API]
• The system shall transmit results to [LIS name] via [HL7v2 / FHIR R4]
• The system shall authenticate users via [mechanism] before permitting access to patient data

Every requirement must be testable - you must be able to write a test that proves the requirement is met. "The system shall be user-friendly" is not a testable requirement. "The system shall complete the sample-to-result workflow in fewer than [N] operator interactions" is.

Software architectural design (Class B and C)

Class A software does not require architecture documentation. Class B and C require a documented architecture showing:

• Software components/modules and their relationships
• Data flow between components
• External interfaces (instrument, LIS, database)
• How safety-critical interactions are handled at the design level

For a spectroscopy diagnostic platform, a practical architecture document describes:

┌─────────────────────────────────────────────────┐
│               Clinician UI Layer                 │
│         (React - Class A or B)                   │
│  Patient context, result display, QC alerts      │
├─────────────────────────────────────────────────┤
│            Application Service Layer             │
│         (FastAPI - Class B)                      │
│  Workflow orchestration, user auth, audit trail  │
├─────────────────────────────────────────────────┤
│           Classification Layer                   │
│         (Python - Class B or C)                  │
│  Preprocessing, ML inference, confidence scoring │
├─────────────────────────────────────────────────┤
│           Instrument Adapter Layer               │
│         (Python - Class A)                       │
│  Spectrum acquisition, instrument control        │
├─────────────────────────────────────────────────┤
│            Integration Layer                     │
│         (Python - Class A or B)                  │
│  HL7v2 message generation, FHIR resources        │
├─────────────────────────────────────────────────┤
│              Data Layer                          │
│         (PostgreSQL - Class B)                   │
│  Patient records, spectra, results, audit log    │
└─────────────────────────────────────────────────┘

Each layer gets its own safety classification. The architecture document must explain how failures in one layer are contained - does a crash in the instrument adapter layer propagate to the classification layer? Does a database timeout cause the UI to display a stale result? These are the safety arguments that auditors examine.

Software detailed design (Class C only)

Class A and B software do not require detailed design documentation under Edition 1.1. Class C requires full detailed design specifications for each software unit - algorithm descriptions, data structures, interface definitions, and logic descriptions detailed enough that a different engineer could implement them correctly.

For spectroscopy ML classifiers at Class C, this means documenting:

• The preprocessing pipeline: each transformation (baseline correction, smoothing, normalization, derivative) with mathematical specification
• The model architecture: layer structure, activation functions, input/output dimensions
• The classification logic: how model output maps to clinical categories
• The confidence scoring algorithm: how confidence is computed and what thresholds trigger manual review
• Edge case handling: what happens with out-of-distribution spectra, instrument errors, corrupted data

This is substantial work. It is also the requirement that most frequently surprises engineering teams who assumed they were Class B and discover they are Class C.

Unit implementation and verification (all classes, varying rigor)

Class A: Implementation required; formal unit verification (unit testing or code review) is not explicitly mandated, though system testing must cover all requirements.

Class B: Unit verification required - unit testing, code review, or a combination. Tests must be documented with pass/fail results.

Class C: Unit testing must be "sufficiently rigorous that failures would be detected." Acceptance criteria and coverage metrics must be defined and met. For spectroscopy classification code, this means:

• Unit tests for each preprocessing function with known-good spectral inputs and expected outputs
• Unit tests for the classification interface with synthetic spectra spanning each category
• Unit tests for confidence scoring boundary conditions
• Unit tests for error handling paths (corrupted spectra, missing metadata, instrument timeouts)

Integration testing (Class B and C)

Staged integration with documented test plans and reports. For spectroscopy systems, integration testing verifies:

• Instrument adapter → preprocessing → classification pipeline works end-to-end
• Classification result → HL7 message generation → LIS transmission is correct
• Patient context → spectrum association → result → audit trail maintains data integrity
• Error propagation: instrument failure is handled gracefully without producing a false result

System testing (all classes)

Full system testing against the SRS is required for all classes - including Class A. This is one of the most important changes introduced by Amendment 1:2015. Every requirement in your SRS must have a corresponding system test with documented results.

For spectroscopy diagnostic software, system testing includes:

• End-to-end workflow tests: patient registration → spectrum acquisition → classification → result display → HL7 transmission
• Performance tests: classification latency, throughput under load
• Safety tests: every risk control in your ISO 14971 analysis has a corresponding verification test
• Boundary tests: spectra at the edge of classification boundaries, confidence scores near thresholds
• Negative tests: invalid inputs, instrument disconnection, network failures, database timeouts

Software release (all classes)

Formal release process for all classes: versioning, release identification, release notes, finalized user documentation, configuration baseline of all development artifacts, and formal release approval.

Your release record should capture the exact state of every artifact - code (Git SHA), requirements document version, test report version, risk management file version, SOUP list version. An auditor should be able to reconstruct the complete state of your system at any historical release.

SOUP: Managing your dependencies

SOUP - Software of Unknown Provenance - is any software not developed specifically for your medical device. This includes everything from the operating system kernel to NumPy to React. Open source does not exempt software from being SOUP - the "unknown provenance" refers to the development process, not the source code availability.

For a typical spectroscopy diagnostic platform, your SOUP inventory might include:

What you must document for each SOUP item

For Class B and C software, each SOUP item requires:

1. Identification - name, version, maintainer, license
2. Functional requirements - what does this SOUP do in your system? Not what it can do in general - what specific functions does your device use?
3. Known anomaly evaluation - review the CVE database, the library's issue tracker, and release notes. Document whether known bugs affect your device's intended use. A NumPy floating-point precision issue might be irrelevant for image display but critical for spectral classification accuracy.
4. Risk analysis - what happens if this SOUP fails? Crashes? Returns incorrect results? Has a security vulnerability? Document the failure modes and your risk controls.
5. Verification - how do you verify that this SOUP meets your requirements? Integration testing, boundary testing, comparison to reference implementations.
6. Post-market monitoring plan - how will you track new vulnerabilities and updates? Subscribe to security advisories, monitor GitHub releases, schedule periodic CVE reviews.

The practical tool: use pip freeze or your Poetry/npm lock file as the starting point for your SOUP inventory. Every pinned dependency - including transitive dependencies - needs an entry. For a Python scientific computing stack, this easily reaches 50-100 entries.

SOUP management is the requirement that most consistently surprises teams new to IEC 62304. The ongoing monitoring obligation - tracking CVEs, evaluating patches, documenting update decisions - is a permanent operational commitment, not a one-time documentation exercise.

Risk management integration

IEC 62304 and ISO 14971 are deeply intertwined. ISO 14971 governs your overall device risk management - hazard identification, risk estimation, risk evaluation, risk control. IEC 62304 Clause 7 extends this framework specifically to software.

The integration workflow:

1. ISO 14971 hazard analysis identifies device-level hazards. For a spectroscopy diagnostic: false negative (missed pathogen), false positive (unnecessary treatment), wrong classification (wrong pathogen → wrong antibiotic), delayed result (treatment delay), data breach (patient information exposure).

2. Software-specific hazard analysis - for each device-level hazard, identify software causes. What software failures could lead to a false negative? Model misclassification, preprocessing error, data corruption during transmission, race condition in result display, incorrect HL7 field mapping.

3. Risk controls assigned to software become requirements in the SRS. "The system shall reject spectra with SNR below threshold X" is a risk control that mitigates "incorrect classification due to low-quality input spectrum."

4. Traceability - each risk control traces from the hazard analysis → SRS requirement → architectural design element → code implementation → test case → test result. This traceability chain is typically what auditors examine first.

5. Residual risk documentation - after all controls are implemented, document the residual risk for each hazard. For ML classifiers, this includes the model's known false positive and false negative rates, performance degradation under edge conditions, and the clinical workflow's ability to catch errors.

Spectroscopy-specific risk scenarios

Here are the risk scenarios that come up repeatedly in spectroscopy diagnostic software:

Low-confidence classification. Your ML model returns a classification with 52% confidence. What happens? If the system displays this as a definitive result, the clinician may act on unreliable information. Risk control: confidence threshold below which results are flagged for mandatory manual review.

Out-of-distribution spectrum. The system receives a spectrum from a sample type it was not trained on - a different biological matrix, a contaminated sample, a new pathogen not in the training set. The model will still output a classification, but it may be meaningless. Risk control: distribution monitoring that detects and flags spectra significantly different from the training distribution.

Cross-instrument variation. The model was trained on spectra from Bruker Alpha II instruments. A deployment site uses a Bruker Alpha III with slightly different optical characteristics. Classification accuracy may degrade. Risk control: instrument-specific validation requirements and performance monitoring per instrument.

Preprocessing failure. Baseline correction fails silently - the algorithm runs but produces an incorrect baseline due to an unusual spectral feature. The corrected spectrum is fed to the classifier, which produces a confident but wrong result. Risk control: preprocessing validation checks (spectral range verification, baseline residual analysis) before classification.

Model retraining drift. The model is retrained on new data to improve performance. The retraining inadvertently degrades performance on a previously well-classified sample type. Risk control: regression testing against a locked validation set before any model update is deployed. Under IEC 62304, model retraining is a design change requiring the full change control process.

Maintenance and change management

IEC 62304 does not end at release. Clause 6 (Software Maintenance) imposes ongoing obligations for the entire deployed lifetime of your software.

Every change requires impact assessment

Post-market changes - bug fixes, feature updates, model retraining, dependency updates, UI modifications - all require:

1. Change request documentation - what is changing and why
2. Impact assessment - does this change affect safety-critical functionality? Could it introduce new hazards? Does it affect other components?
3. Risk re-evaluation - update the ISO 14971 risk analysis if the change introduces or modifies hazards
4. Implementation - make the change following the same development process as the original development (appropriate to the safety class of the affected component)
5. Verification - test the change, run regression tests, verify that the change does what it should and does not break what it should not
6. Release - follow the formal release process: updated version number, release notes, configuration baseline

"Minor bug fix" is not an exemption. If your software is Class B or C, every change - no matter how small - goes through this process. Unauthorized changes are a frequent audit finding and can constitute a regulatory violation.

Model retraining is a design change

For spectroscopy diagnostic software with ML components, this is the requirement with the most operational impact. Retraining your classification model - even with the same architecture on additional data - is a design change under IEC 62304.

This means:

• Documented change request with rationale for retraining
• Risk assessment of the retrained model (could new training data introduce bias? degrade performance on existing sample types?)
• Verification - performance evaluation against locked validation datasets, comparison to prior model version
• Regression testing - the retrained model must not degrade on any previously validated sample type
• Updated documentation - training data description, performance metrics, model version
• Formal release through the standard release process

If you plan to retrain frequently, design your change control process to handle this efficiently. Pre-define your validation protocol, your acceptance criteria, and your regression test suite so that each retraining cycle is a documented execution of an established process rather than a bespoke evaluation.

For companies pursuing FDA clearance, the Predetermined Change Control Plan (PCCP) framework allows you to pre-define anticipated algorithm modifications in your submission, enabling post-clearance updates within pre-approved bounds without requiring a new submission for each retrain.

SOUP updates

When a third-party library releases a security patch or version update, you face a decision: update (accepting the risk of new bugs) or stay on the current version (accepting the risk of known vulnerabilities). Both choices must be documented with rationale.

For critical security patches (actively exploited CVEs), update promptly and document the emergency change. For routine version updates, batch them into planned maintenance cycles with appropriate verification.

The minimum viable checklist for startups

If you are a spectroscopy diagnostic startup facing IEC 62304 for the first time, here is what you actually need - organized by when you need it.

Before development starts

• Software safety classification completed (ISO 14971 hazard analysis → IEC 62304 class determination)
• Software Development Plan written (10-15 pages: methodology, tools, SOUP approach, configuration management, problem resolution)
• Risk management plan established (integrating IEC 62304 Clause 7 with ISO 14971)
• Configuration management in place (Git repository with branching strategy, artifact versioning)
• SOUP identification started (initial dependency inventory from lock files)

During development

• Software Requirements Specification maintained (numbered, traceable, testable requirements - this is the backbone)
• Traceability matrix built incrementally (requirement → design → code → test - build this as you go, not retroactively)
• Architecture document created (Class B/C: component diagram, data flows, safety arguments)
• Detailed design documented (Class C only: algorithm specifications, data structures, interface definitions)
• Unit test evidence collected (Class B/C: documented test cases with pass/fail results)
• Integration test evidence collected (Class B/C: staged integration with documented results)
• SOUP evaluation completed (each dependency: version, functional requirements, CVE review, risk analysis)

Before first regulatory submission

• System test plan and report completed (all SRS requirements covered with documented results)
• Traceability matrix complete (every requirement traces to test evidence)
• SOUP list finalized (every dependency documented with anomaly evaluation and risk assessment)
• Software release record prepared (version baseline, release notes, sign-off)
• Risk management file integrated (ISO 14971 + IEC 62304 Clause 7, all software risk controls verified)

What can be deferred (Class B only)

• Detailed design documents (required only for Class C under Edition 1.1 - but note that Edition 2 will require them for all Level II software)
• Formal unit test plans with coverage metrics (unit-level testing evidence is good practice but less prescriptive for Class B)

What cannot be deferred regardless of class

• Version control for all artifacts (code and documents)
• Change control process for any modification after baseline
• Post-market problem resolution process (must exist before first clinical use)
• SOUP monitoring plan (ongoing CVE surveillance)

Free resources

OpenRegulatory (openregulatory.com) publishes complete free templates for IEC 62304, ISO 14971, and ISO 13485 under open-source licenses, available on GitHub. These templates have been used by over 100 companies through CE marking and FDA submissions. They are a legitimate starting point - not a substitute for regulatory expertise, but a substantial acceleration.

AAMI TIR45:2023 provides explicit justification for Agile/sprint-based development mapped to IEC 62304 activities. If your team works in sprints, cite TIR45 in your Software Development Plan to pre-emptively address auditor concerns about iterative development.

Common mistakes to avoid

These are the pitfalls we see repeatedly in spectroscopy diagnostic software teams encountering IEC 62304 for the first time.

Classifying too late. Teams start development, build the product, then discover they need IEC 62304 compliance. Retroactively reconstructing requirements traceability, design rationale, and test evidence is expensive and unreliable. Safety classification should happen before the first line of production code - something we address in detail in our guide on transitioning research spectroscopy to clinical products.

Traceability gaps. The single most common audit finding. Requirements exist. Code exists. Tests exist. But the documented links between them - the traceability matrix - are missing or incomplete. Auditors check this first. Build traceability incrementally as you develop; it cannot be reliably reconstructed after the fact.

Misclassifying the ML model. Treating the spectral classifier as Class A because "it just outputs a number" ignores the clinical consequence of that number. If a clinician acts on the classification result without meaningful independent verification, the classifier is driving a clinical decision. That is Class B or C, not A.

Ignoring SOUP risk analysis. Creating a SOUP spreadsheet with names and versions but no risk analysis. Each SOUP item needs a documented assessment: what happens if it fails, and what are your controls? NumPy returning incorrect floating-point results in your spectral preprocessing is a different risk profile than a logging library failing to write to disk.

Architecture-code disconnect. The architecture document describes clean modular layers. The codebase has grown differently. The safety arguments in the architecture document - "failures in the instrument layer cannot propagate to the classification layer" - are not backed by the actual implementation. Auditors will check. Keep the architecture document synchronized with the code.

Treating maintenance as exempt. A "quick bug fix" bypasses change control. A "minor UI update" skips regression testing. Under IEC 62304, every post-release change requires impact assessment, risk evaluation, verification, and documentation. This is not optional for Class B and C software.

Not planning for model retraining. The ML model works great today. In six months, you want to retrain on additional data. Under IEC 62304, that is a design change requiring the full change control process. If you do not plan for this, your first retraining cycle will be a painful surprise. Design the retraining validation protocol before you need it.

What Edition 2 changes (and why you should care now)

IEC 62304 Edition 2 is expected to publish in late 2026. Regulatory enforcement will not begin until 2028-2029 at the earliest, but the changes are significant enough to affect architectural decisions you make today.

The biggest change: Class B and C merge into Level II. Current Class B software - which requires architecture documentation but not detailed design, which requires unit verification but with less rigor - will need full Level II documentation. If your spectroscopy diagnostic software is currently Class B, it will need Class C-level documentation under Edition 2.

New AI/ML provisions. Edition 2 introduces Clause 5.1.15 (mandatory for both rigor levels), requiring an "AI Plan" covering:

• Data governance
• Model development phases
• Performance metrics
• Post-deployment monitoring
• Bias evaluation
• Version control for datasets and model retraining procedures

Expanded scope. Edition 2 covers "health software" broadly, not just medical device software. This affects the relationship with IEC 82304-1 and may bring software that is currently out of scope into the standard's purview.

What to do now: If your software will be in active development through 2028, build to Edition 2 Level II requirements from the start. The incremental cost of adding detailed design documentation and comprehensive unit testing now is far lower than retrofitting it later under regulatory pressure. For ML components, start documenting your data governance and model lifecycle processes in the format Edition 2 will require.

How this connects to your regulatory strategy

IEC 62304 is not an isolated compliance exercise. It is the software process foundation that supports every regulatory pathway for spectroscopy diagnostics.

FDA De Novo / 510(k): The FDA recognizes IEC 62304 as a consensus standard. A Declaration of Conformity to IEC 62304 in your submission signals to reviewers that your software development process is sound, streamlining the review. Your SaMD classification determines whether this pathway applies.

EU IVDR: IEC 62304 conformity is effectively required for IVDR technical documentation. Your Notified Body will audit your software lifecycle processes against this standard. Combined with AI Act requirements, the documentation burden is substantial but manageable if you build IEC 62304 processes from day one.

LDT pathway: If you are deploying as a Laboratory Developed Test, IEC 62304 is not legally required. But building to IEC 62304 processes gives you the foundation for a future FDA submission, demonstrates software quality to clinical partners, and protects against the legislative environment shifting toward enhanced LDT oversight.

The companies that treat IEC 62304 as a development discipline rather than a documentation exercise reach the market. The companies that treat it as a regulatory checkbox to be filled in before submission do not - because the documentation they produce does not reflect how the software was actually built, and auditors can tell.

Build your clinical workflow software with IEC 62304 in mind from the first commit, or use a platform that already has compliance built in. The spectroscopy diagnostic companies that do this will have a permanent structural advantage over those that try to bolt compliance onto an existing codebase.