When Device Storage Fills: Test Recording, Warnings, and Export Separately

Where Storage Exhaustion Sits in FDA's Software Expectations

Consider the scenario that surfaces late in many data-logging medical device programs: your device writes patient physiological waveforms, diagnostic assay results, or therapy delivery logs to local non-volatile storage. Six weeks before premarket submission, the test lead asks a deceptively simple question: when onboard storage fills, does the device warn before reaching capacity, continue recording, overwrite the oldest records, or halt—and what objective verification evidence will satisfy both the FDA premarket reviewer and a Quality Management System Regulation (QMSR) auditor?

The direct answer is to treat full device storage as a predictable, specified operating boundary rather than an anomaly, and to split verification into three independent test claims: (1) recording behavior at and beyond 100% capacity, (2) user warning threshold, persistence, and clearance, and (3) export integrity and post-purge return to service. In FDA's June 14, 2023 final guidance, Content of Premarket Submissions for Device Software Functions (finalized after a November 4, 2021 draft and superseding FDA's May 2005 premarket software guidance), the definition of a product "function" uses storage as its example: "A product with an intended use to store, transfer, and analyze data has three functions: (1) storage, (2) transfer, and (3) analysis." When onboard storage serves the device's intended use, as it does in a recorder or meter that keeps results for later review, it is a distinct function with its own requirements and failure modes rather than an implementation detail. This article addresses that case: storage that is part of the device's own software.

Under that June 2023 framework, the SRS typically specifies error definition and handling alongside "all ranges, limits, defaults, and specific values that the software will accept." The guidance's footnotes list memory devices among hardware requirements, and say software performance and functional requirements may also include "error and interrupt handling, fault detection, tolerance, and recovery characteristics, safety requirements, and timing and memory requirements." Meanwhile, FDA's January 11, 2002 final guidance, General Principles of Software Validation (GPSV, Version 2.0), whose sections other than the superseded Section 6 FDA says still reflect its current thinking, lists among the elements that system-level software testing addresses "Responses to stress conditions, e.g., behavior under maximum load, continuous use" and "Effectiveness of recovery procedures, including disaster recovery" (Section 5.2.5). A full storage partition is exactly that kind of maximum-load, continuous-use condition, and freeing it is a recovery procedure.

A predictable weak spot at the storage boundary is collapsing three separate verification questions into a single happy-path check: a test injects a mock flag to confirm that a "Memory 90% Full" banner renders on the screen, the requirement is marked passed, and nobody tests what actually happens when the file system or flash partition receives its first write command at 100% capacity—or whether offloading records over USB or Bluetooth clears the warning and resumes recording without corrupting the sequence index. Just as edge-case verification for medical device power interruptions and state survival or daylight-saving repeated-hour timestamps requires isolating each state transition, storage-exhaustion testing only holds up under scrutiny when recording continuity, user alerting, and export recovery are specified and verified separately.

Choose the Boundary Behavior Before Writing Any Test

You cannot write a valid pass/fail test case for full storage until your product team decides what "correct" behavior is for the device's specific clinical context. In medical device design controls, there is no universal rule stating that every device must overwrite old records or that every device must lock out new measurements when memory fills. Shipped devices legitimately implement contrasting boundary architectures because their clinical workflows and hazard profiles differ.

Comparing two current, publicly available manufacturer operator manuals illustrates why boundary behavior must be derived from intended use rather than assumed by software engineers:

• Delete-Oldest Overwrite with Cloud History (Over-the-Counter Home Glucose Monitoring): The Livongo Blood Glucose Monitoring System Owner's Manual (PL00497_E_G2.4) describes an over-the-counter meter that stores 1,000 results on board. When meter memory is full, the oldest result is deleted from onboard memory. The meter has an embedded cellular module, and the manual says past results remain accessible from the member account "as long as your meter uploads your information"; readings that could not be sent are stored and sent later once a reliable signal is available. A full memory therefore does not stop a new reading from being saved, but the long-term history depends on uploads succeeding. That dependency is exactly what a wrap test should probe.

• Capacity-Limited Sessions and Operator-Controlled Erase (Ambulatory ECG Recording): By contrast, the Norav Medical NR Recorder Operation Manual (UM_NR_2.9, 2023) treats an ambulatory ECG recording as a discrete study. In Holter modes, the recording hours offered in the Record Settings menu are limited to what the memory card can hold (an "SD card too small" message sends the user back to that setting), and the recorder switches off automatically when the set recording duration is reached. If the recorder finds a saved recording that has not yet been downloaded, it shows a warning and offers to erase the old record before preparing for a new one. In the multi-patient ECG+ mode of the NR-1207-3, a record control menu separates Stop ECG, Shutdown, and Overwrite Record, and the manual warns that Overwrite Record cleans the memory card and erases previously recorded ECG traces. Our reading of that design: silently overwriting the start of a diagnostic study would destroy evidence the reviewing physician needs, so every destructive step is an explicit operator decision.

When evaluating which boundary behavior belongs in your SRS and risk management file, map the candidate architecture against the clinical hazard of losing historical records versus the clinical hazard of refusing a new measurement or therapy session:

Do not expect this architectural choice to change the device's FDA documentation level. Under the June 2023 Device Software Functions Guidance, Enhanced Documentation applies when a failure or flaw of any device software function could present a hazardous situation with a probable risk of death or serious injury, and FDA says those risks "should be assessed prior to implementation of risk control measures." The boundary behavior is a risk control; it belongs in the SRS and risk file whichever level applies. A footnote in the same guidance also cautions that "Applying unrealistically low probability estimates to software failures could result in unrealistic risk evaluation and subsequently lead to inappropriate risk control measures," and suggests that in some instances it may be prudent to focus on identifying the failures that could cause hazardous situations instead of estimating probability. A storage-boundary risk file falls into that trap when it argues that "the user will always export data before memory fills, so the probability of reaching 100% capacity is negligible." Because software behaves deterministically once the fill boundary is reached, assuming perfect user housekeeping is not a valid software risk control. If an unhandled full-storage condition could halt therapy, suppress a clinical alarm, or silently discard a diagnostic trace, the boundary behavior is a safety-relevant control that must be specified in the SRS and verified through objective testing.

flowchart TD
    A["Device Writes Clinical or Operational Records"] --> B{"Storage Crosses Warning Threshold?"}
    B -- "Yes (Suite B)" --> C["Raise Non-Blocking Capacity Warning & Log Event"]
    C --> D{"Storage Reaches 100% Specified Limit?"}
    B -- "No" --> A
    D -- "No" --> A
    D -- "Yes (Suite A)" --> E{"Execute Specified SRS Boundary Policy"}
    E -- "Policy 1: FIFO Wrap" --> F["Delete Oldest Record Deterministically & Preserve Sequence Integrity"]
    E -- "Policy 2: Stop & Close" --> G["Close Active File Cleanly, Lock Further Writes & Persist Full Alert"]
    E -- "Policy 3: Pre-Run Interlock" --> H["Complete Active Run in Reserved Headroom & Block New Run Until Export"]
    E -- "Policy 4: Therapy Priority" --> I["Continue Therapy Uninterrupted & Isolate Storage Exception"]
    F --> J["Operator Initiates Export & Space Recovery (Suite C)"]
    G --> J
    H --> J
    I --> J
    J --> K["Verify Exported Checksums, Clear Warning State & Confirm Return to Service"]

Build a Synthetic Capacity-Boundary Dataset

Once the SRS defines the exact storage limit and boundary policy, the engineering team faces a practical execution problem: if a medical device is designed to store 90 days of patient telemetry or 10,000 assay records, waiting 90 days on a laboratory bench to observe a single boundary transition is incompatible with agile verification cycles and regression testing. Conversely, if a tester simply mocks a boolean variable (`isStorageFull = true`) in unit code, the test completely bypasses the file system, flash translation layer, database index, and block-allocation math where real boundary failures actually occur.

To bridge that gap in line with GPSV's system-level testing elements ("behavior under maximum load, continuous use" and recovery effectiveness) and, by analogy, its loop-coverage criterion of "zero, one, two, and many iterations covering initialization, typical running and termination (boundary) conditions," teams need a synthetic capacity-boundary dataset. The goal is to bring the real physical partition, EEPROM array, SD card, or embedded SQLite/flash store to an exact, mathematically computed byte or record count below the limit, and then drive the final boundary transitions using the device's production write path.

Step 1: Compute the Exact Storage Geometry and Reserve Headroom

Before generating test records, document the storage math in the verification protocol so a reviewer can see why your boundary numbers are exact rather than arbitrary:

1. Partition Usable Bytes vs. Logical Record Cap: Determine whether the software enforces an application-level record count limit (for example, exactly N_max = 1,000 patient result records), a byte-quota limit on a file-system directory, or raw physical partition exhaustion. If the device relies on a third-party flash file system or embedded database engine, treat that component under your SOUP (Software of Unknown Provenance) IEC 62304 controls, accounting for file-system metadata overhead, journal files, write-ahead logs (WAL), and flash block erase units.

2. Record Payload and Index Overhead: Calculate the exact byte footprint of a single stored record (B_rec), including header metadata, monotonic sequence ID, UTC timestamp, CRC/hash, and index entry. If record sizes vary (for example, compressed physiological waveforms), define both the nominal record size and the worst-case maximum uncompressed record size.

3. Deterministic Pre-Fill Image Construction: Instead of running normal acquisition for weeks, generate a golden pre-fill dataset (or use an authenticated manufacturing/test harness command that invokes the real storage driver) to populate storage up to N_warn - 2 records, where N_warn is the SRS-specified warning threshold. Verify the pre-fill state via cryptographic hash and record count before starting the live system-level test.

4. Live Acquisition Across the Boundary: Switch the device into its normal production operating mode (with test harnesses disabled) and drive the remaining writes across the warning threshold (N_warn), the exact full boundary (N_max), and the first write attempted past full (N_max + 1) using simulated sensor inputs or patient simulator waveforms.

Suite A: Synthetic Capacity-Boundary Dataset & Recording States (Editorial Proposal)

The following table defines Suite A, an editorial test-case framework covering the six boundary fill states that system-level verification should exercise. Each team must adapt the exact record counts and byte calculations to its own SRS limits:

Notice why State A-03 (N_max) and State A-04 (N_max + 1) must be tested as distinct steps. A classic off-by-one defect at this boundary: the last available slot has room for the record header but not for the trailing checksum or file-system journal commit, so record N_max itself is corrupted even though the software intended to stop cleanly at N_max. Testing both the exact boundary write and the first over-boundary write exposes that class of defect directly. It is the storage-level analogue of the loop-coverage criterion in FDA's 2002 GPSV, which asks for zero, one, two, and many iterations including termination boundaries.

To make Suite A reproducible across firmware builds, document the exact construction of the pre-fill image inside your system-level test protocol. Specifically, record the partition geometry, the seed or script version used to synthesize Records 1 through N_warn - 2, and the SHA-256 digest of the pre-filled storage image prior to executing the live boundary writes. Recording the pre-test image hash proves that the partition was genuinely populated at the physical block and file-system index layers before live sensor inputs drove the final transitions across N_warn, N_max, and N_max + 1.

Alert Test Cases: Threshold, Content, and Clearance

When storage approaches and reaches capacity, the user interface is often a primary risk control—informing the patient, nurse, or biomedical technician that data must be offloaded or that recording has stopped. In the June 2023 Device Software Functions Guidance, the SRS FDA describes typically specifies user interaction, error definition and handling, and safety-related requirements derived from a risk assessment. Yet alert testing can easily stop at checking whether a string resource exists in the UI table.

A defensible alert verification suite (Suite B) must test four independent dimensions of the warning lifecycle: threshold accuracy (when the alert triggers), content and priority appropriateness (distinguishing an informational capacity notice from a physiological patient alarm so operators are neither misled nor desensitized), persistence across operating states (ensuring the warning does not vanish while the device is still full), and deterministic clearance (confirming the warning clears if and only if usable storage is actually restored above the hysteresis threshold).

When writing the underlying SRS requirement for the warning threshold, specify the trigger in both physical storage units (record count or available kilobytes/megabytes) and user-actionable operational units (such as remaining hours of continuous waveform capture or remaining spot-check measurements). A bedside nurse or home-use patient cannot translate "4.2 MB remaining" into clinical lead time, whereas an advisory linked to remaining operating capacity directly supports the risk control. In addition, specify a clearance hysteresis band—requiring free space to rise above the trigger point (or requiring an explicit export/purge action) before clearing the advisory—so minor file-system metadata fluctuations do not cause the warning banner to flicker on and off.

Case B-03 is especially revealing during system integration testing. Some embedded designs track record counts in volatile RAM and only increment the counter when a new record is written. If the device reboots while storage is 100% full and the startup routine forgets to query actual non-volatile storage occupancy, the UI comes up clean with no warning—only to fail silently on the first clinical measurement. Pairing Case B-03 with your power-recovery verification protocol closes that gap before submission.

Recovery and Export Test Cases: Free Space Without Losing Evidence

FDA's January 2002 GPSV lists "Effectiveness of recovery procedures, including disaster recovery" among the elements system-level software testing addresses, and FDA's June 2023 Device Software Functions Guidance lists "fault detection, tolerance, and recovery characteristics" among what software performance and functional requirements may include. When device storage fills up, recovery is not achieved merely by formatting the flash chip. It is achieved only when recorded clinical evidence is safely transferred (when required by intended use), space is reclaimed without corrupting remaining or subsequent data, and the device returns to normal recording service.

Consider the hazard illustrated by the Norav NR recorder manual (UM_NR_2.9), where, in the multi-patient ECG+ mode, the Overwrite Record command cleans the memory card and erases previously recorded ECG traces to restart recording. In an ambulatory ECG workflow, if a device erased or overwrote prior traces before the clinician exported the completed study, or if a failed export still triggered an automatic post-transfer purge, the diagnostic evidence from the patient's wearing period would be permanently lost. Even on a delete-oldest device like the Livongo blood glucose meter, the manual's promise that past results remain accessible is conditional on the meter uploading, so recovery depends on uploads reaching the account before the oldest onboard results are deleted.

Therefore, Suite C (Recovery and Export Verification) must test the entire chain from data offload through space reclamation and return to service:

Pay particular attention to Case C-01 and Case C-05. A recurring design trap is an export module that tries to create a temporary ZIP archive, staging file, or SQLite journal on the same storage partition that is already 100% full. When the export routine fails with ENOSPC (No space left on device), the user is trapped: they cannot record new data because storage is full, and they cannot free storage because exporting requires free space. Reserving a dedicated, non-user-accessible staging buffer or streaming exports directly from RAM—and proving it works at exactly 100% user-storage occupancy via Case C-01—prevents a field lockout in which the only way to free space is a destructive erase.

Similarly, Case C-05 requires objective record-level evidence that neither circular wrap nor manual space reclamation introduces silent gaps or duplicate records. To make that proof unambiguous in your test report, verify four record attributes across the boundary: (1) a strictly monotonic 64-bit sequence counter that never resets to zero when the storage ring wraps or purges, (2) unambiguous timestamps (see our guide to verifying device timestamps across daylight-saving transitions), (3) per-record payload checksums (such as CRC-32 or SHA-256) verified after export, and (4) an audit-trail entry recording the exact sequence range removed during any manual purge or automated ring-buffer wrap.

Package the Evidence: SRS, Risk File, and System-Level Protocols

Executing Suites A, B, and C on the bench only helps your regulatory submission and quality audit if the resulting records match FDA and international lifecycle structure. As detailed in our broader guide to medical device software verification vs. validation under FDA and IEC 62304, reviewers look for unbroken traceability from the hazard in the risk file, to the quantitative limit in the SRS, to the system-level test protocol and objective pass/fail report.

1. Premarket Submission Packaging (June 2023 Device Software Functions Guidance)

Under FDA's June 2023 Content of Premarket Submissions for Device Software Functions guidance, the level of test detail submitted in a 510(k), De Novo, or PMA depends on whether the device requires Basic Documentation or Enhanced Documentation:

• At both Basic and Enhanced Documentation levels: FDA's Table 1 recommends an SRS (where memory requirements, accepted storage ranges and limits, error handling, and fault-recovery characteristics belong), a risk management file (plan, a risk assessment demonstrating that risks have been appropriately mitigated, and a report), a system and software architecture diagram showing data flow, a summary description of testing at the unit, integration, and system levels, and the system-level test protocol and system-level test report. The guidance describes that protocol as including expected results derived from software requirements, observed results, and pass/fail determination. Because Suites A, B, and C verify observable device-level behavior (recording at capacity, user alerts, and export/recovery), they belong in the system-level verification protocol.

• Additional deliverables at the Enhanced Documentation level: When a failure or flaw of a device software function could present a hazardous situation with a probable risk of death or serious injury (assessed before risk controls), FDA recommends adding unit-level and integration-level test protocols and reports and a Software Design Specification (SDS) showing how the design implements the SRS. For storage, that means the unit and integration protocols covering ring-buffer pointer arithmetic, flash error return codes, and file-system-full exception handlers, plus SDS detail on storage partitioning and task isolation. At the Basic level FDA does not recommend submitting the SDS; the sponsor documents that information in the design history file, and FDA may request it during review.

2. Connecting IEC 62304 Software Records to the Device File Under the QMSR

Since February 2, 2026, FDA's amended 21 CFR Part 820 has been in effect as the Quality Management System Regulation (QMSR), which incorporates ISO 13485:2016 (and Clause 3 of ISO 9000:2015) by reference. On the same date FDA stopped using the Quality System Inspection Technique (QSIT) for device inspections. FDA's QMSR page points to design and development requirements under 21 CFR 820.10(c) and ISO 13485 Clause 7.3 (Design and development) and its subclauses. The QMSR preface added to the June 2023 software guidance notes that the QMSR does not use terms such as "Design Controls" and "Design Validation"; their elements now sit in ISO 13485 Clause 7.3. Design verification records must show that design outputs meet design input requirements, with traceability retained in the design and development file.

At the same time, teams structuring their software lifecycle around IEC 62304:2006+AMD1:2015 CSV (the consolidated edition of Medical device software — Software life cycle processes, which carries a 2028 stability date) must account for a critical scope boundary stated in the standard's own abstract: while IEC 62304 defines lifecycle requirements for the development and maintenance of medical device software (whether standalone SaMD or embedded in hardware), IEC 62304 does not cover final validation and release of the medical device itself, even when the device consists entirely of software. As we explain in our IEC 62304 software lifecycle implementation guide, your storage-capacity boundary verification cannot live solely as an isolated software unit test ticket—it must trace upward into the device-level design verification and validation file under ISO 13485 Clause 7.

Limits of This Test Set and When to Re-Run It

To keep your verification strategy rigorous and audit-ready, document both what this synthetic boundary method proves and where its boundaries lie:

• Editorial Proposal vs. Binding Law: FDA guidance documents represent the agency's nonbinding recommendations, and no FDA guidance names a mandatory "storage full" test. Suites A, B, and C are an editorial framework synthesized from FDA's general expectations in the June 2023 software-functions guidance and January 2002 GPSV. Every manufacturer must tailor fill percentages, record sizes, warning lead times, and pass criteria to its specific device classification, clinical risk profile, and intended use.

• Synthetic Fill Does Not Replace Long-Duration Soak or Flash Wear Testing: Pre-filling a partition to N_max - 1 deterministically proves logical boundary behavior, UI warning transitions, and export recovery math. However, it does not test multi-month physical flash memory aging, NAND wear-leveling amplification, bad-block remapping under thermal stress, or real-time clock drift over weeks of continuous operation. Where hardware endurance is a risk contributor, pair deterministic boundary tests with hardware accelerated life or soak testing.

• Single-Device Manual Examples Cannot Be Generalized: The Livongo blood glucose meter manual and Norav Holter recorder manual illustrate two contrasting boundary philosophies in current public labeling. They must never be cited as regulatory precedents allowing another manufacturer to omit risk controls or adopt a 1,000-record limit without device-specific human-factors and clinical risk justification.

When to Re-Run Storage Boundary Verification

Under ISO 13485 Clause 7.3.9 (Control of Design and Development Changes) as incorporated by the FDA QMSR, and under IEC 62304 software maintenance processes, re-execute Suites A, B, and C whenever any of the following engineering or regulatory triggers occur:

1. Record Schema or Payload Size Changes: Adding a single new telemetry channel, diagnostic metadata field, or cryptographic signature changes B_rec, shifting the byte alignment of N_warn and N_max and potentially re-introducing partial-write truncation at the partition boundary.

2. Non-Volatile Memory Hardware or SOUP File-System Updates: Replacing an EOL flash chip, changing SD card vendors, or upgrading an embedded RTOS file system or SQLite version changes block-erase geometry and ENOSPC error-return behavior.

3. Export Transport or Compression Changes: Modifying USB/BLE packet sizes, cloud sync retry logic, or archive compression alters peak RAM and temporary staging space required during Case C-01 and Case C-02.

4. Standards or Guidance Updates: Re-evaluate your documentation mapping upon any revision to FDA's June 2023 premarket software guidance, updates to FDA's QMSR or CSA guidance lines, or publication/recognition transition of IEC 62304 Edition 2 (following the current consolidated edition 2006+AMD1:2015, which carries a 2028 stability date).