IEC 62304 is the international standard for medical device software development. If you are building BCI signal decoding software that will be embedded in a Class II rehabilitation device — or sold as a software accessory component to OEM device manufacturers — this standard is relevant to your development process regardless of whether you have a formal regulatory submission underway. Auditors, QA teams at device manufacturers, and hospital procurement committees increasingly ask for it.
What I want to do in this post is cut through the abstract standard language and describe what IEC 62304 compliance actually requires in concrete terms for a small team building BCI signal processing software. This is not a substitute for reading the standard, working with a regulatory consultant, or engaging a notified body (the standard is 60+ pages and this post is not). It is a practical orientation to what the standard asks for, where the effort concentration actually falls for software-only teams, and where the common misunderstandings are.
We are designing Synaptiq's development process to be consistent with IEC 62304 requirements. This post reflects that internal process. It does not constitute a claim that any specific Synaptiq software release has been reviewed or cleared under IEC 62304 or any regulatory body.
Software Safety Classification: Getting This Right First
IEC 62304 organizes all requirements around three software safety classes: A, B, and C. The class determines which lifecycle activities (testing, documentation, change control) are required. Getting the classification right matters because Class C imposes substantially more rigorous requirements than Class A, and incorrectly assigning Class A to software that should be Class C can invalidate your regulatory submission.
The classification criteria (per IEC 62304 §4.3) depend on the severity of injury that could result from a software failure:
- Class A: Software failure cannot contribute to a hazardous situation, or can contribute but cannot lead to any injury or damage to health.
- Class B: Software failure can contribute to a hazardous situation that may result in non-serious injury.
- Class C: Software failure can contribute to a hazardous situation that may result in serious injury or death.
For a BCI signal decoding component integrated into a rehabilitation exoskeleton: a misclassification that causes the exoskeleton to apply unexpected force to a patient's limb could cause a fall or joint injury. That is a hazardous situation that may result in non-serious to serious injury, depending on the patient's condition and the exoskeleton's actuator forces. Most BCI decode components integrated into powered exoskeletons will be classified Class B at minimum, and Class C if the actuator forces are high enough that unexpected activation could cause serious injury.
The classification analysis must be performed within a risk management framework per ISO 14971 — not standalone. The software safety class flows from the risk assessment. If ISO 14971 analysis identifies that software failure can result in serious injury, the software is Class C. The standard explicitly requires this integration between risk management and software lifecycle.
What Each Software Safety Class Requires
For Class A, IEC 62304 requires software development planning, requirements definition, architecture, and release documentation. No specific unit or integration testing requirements are mandated (though this does not mean testing is optional — it means the standard does not prescribe specific testing rigor for Class A).
For Class B, the above plus: software design and implementation requirements, unit testing, integration testing, and system testing. Crucially, Class B requires a software unit test for each software unit — meaning every distinct module of the BCI decode pipeline (preprocessing, feature extraction, classification, command generation) requires documented unit tests with pass/fail criteria. Software items that have not been unit tested cannot be released under Class B.
For Class C, Class B requirements plus: complete software unit verification (not just testing but full verification that each unit meets its specifications), additional testing rigor, and in some interpretations, formal methods or additional architectural analysis for the highest-risk software items.
For a BCI signal decoding SDK positioned as Class B, the practical documentation requirements are:
- Software Development Plan (SDP): How you develop, test, and release software. Must address the lifecycle activities required by your assigned class.
- Software Requirements Specification (SRS): What the software must do, with traceability to the device-level requirements and risk management output.
- Software Architecture Document: How the software is structured into items/units, and how that structure relates to safety class assignments.
- Software Unit Test Protocols and Reports: Test cases for each software unit, with recorded results.
- Software Integration and System Test Protocols and Reports: Testing of assembled software items and the complete software system.
- Software Bill of Materials (SBOM): All SOUP (Software of Unknown Provenance — third-party libraries) with version numbers and an assessment of their suitability for the intended use.
- Change Control Records: For every software change after release, evidence that the change was planned, implemented, and tested in accordance with the SDP.
The SOUP Problem for BCI Software
SOUP management is one of the most practically challenging aspects of IEC 62304 for small BCI software teams, and it deserves specific attention. SOUP is any pre-existing software component not developed under your quality management system — which includes virtually every open-source library used in a Python-based signal processing pipeline.
For a BCI decode pipeline built in Python, the SOUP list includes at minimum: NumPy, SciPy, MNE-Python, pyriemann, scikit-learn, and likely several others. For each SOUP item, IEC 62304 §8.1.2 requires you to:
- Identify the SOUP item (name, version)
- Evaluate the anomaly list (known bugs, CVEs) for issues relevant to intended use
- Document the functional requirements that the SOUP item must meet
- Document testing activities used to verify the SOUP item performs as required in your specific integration
This does not mean you need to re-verify NumPy from scratch. It means you need to verify that NumPy, as integrated in your decode pipeline, performs the operations your system requires correctly. For example: if your system relies on NumPy's linalg.eigh() to compute eigendecompositions of covariance matrices during CSP, your SOUP verification should include test cases confirming that eigh() produces correct results for covariance matrices of the dimensions and conditioning ranges your system uses.
The SOUP version must be pinned. Using unpinned dependencies (e.g., numpy>=1.20 without an upper bound) is problematic under IEC 62304 because a dependency update could introduce a regression that changes software behavior after release. Pin specific versions and document the rationale for any version updates as change control events.
Change Control After Release
Change control is the ongoing maintenance cost of IEC 62304 compliance that teams sometimes underestimate. Every change to released software — a bug fix, a performance optimization, a dependency version update — must go through a documented change evaluation process. The evaluation must assess:
- The nature of the change and which software items are affected
- Whether the change introduces any new risks requiring a risk management update (per ISO 14971)
- Which tests must be re-run to verify the change does not introduce regressions
- Regression testing results
For a signal processing library like the Synaptiq SDK, where numerical algorithm improvements are a regular development activity, this means every algorithm refinement must flow through change control. This is not bureaucratic overhead for its own sake — it is the mechanism by which a device manufacturer integrating your SDK can have confidence that a version bump does not silently degrade the behavior of the decode pipeline in their device.
Practical Recommendations for Small BCI Software Teams
Several things I have found genuinely useful for small teams approaching IEC 62304 for the first time:
Start with risk management, not documentation templates. The safety classification drives everything else. Work through ISO 14971 first, identify the hazardous situations associated with software failures, and let the classification fall out from that analysis. Do not start from a template that assumes a classification without analysis.
Define software unit boundaries early. The standard's testing requirements apply at the unit level. If you define overly large units (e.g., "the entire decode pipeline is one software item"), you have fewer units to test but each test is harder to design and less specific. Modular decomposition — preprocessing module, feature extraction module, classifier module, command output module — maps cleanly to the natural architecture of a signal processing pipeline and to discrete unit tests.
Version-control your test protocols alongside your code. Test cases are documents subject to change control just like source code. Storing them in the same repository under the same version control system makes it straightforward to reconstruct the exact test state corresponding to any released version.
Treat SOUP evaluation as a one-time cost, not an ongoing burden. Do the initial SOUP evaluation thoroughly when you first submit. Subsequent updates to SOUP items require a delta evaluation (what changed in this version? any known bugs relevant to our use?) rather than a full re-evaluation. With a well-maintained SOUP register, ongoing maintenance cost is manageable.
The investment in IEC 62304-aligned development is real, particularly for a small team. We are not saying it is trivial or that every startup should do it on day one. The case for doing it early is that the documentation discipline it imposes improves software quality independent of regulatory outcomes — unit tests catch regressions, change control creates a history of decision rationale, and SOUP management forces clarity about what your system depends on and why. For software that will eventually need regulatory documentation before OEM commercial deployment, building these practices from the start is substantially cheaper than retrofitting them to an undocumented codebase later.