Choosing memory for medical devices comes down to three questions. Will the part survive the environment inside your enclosure, will the data still be there and unaltered at the end of its service life, and will you still be able to buy the same part when the device goes through its next production run? This guide works through each of those in turn, from the failure modes that actually show up in the field to the standards you will be asked to evidence.
What makes medical device memory different
The difference is not performance; it is consequence. A commercial microSD card that drops a sector in a laptop is an annoyance. The same failure in an infusion pump, a ventilator, or a patient monitor is a safety event, a field action, and a regulatory conversation you did not want to have.
That changes what you are buying. You are not buying capacity and transfer speed, you are buying predictable behaviour across a known operating envelope, a documented endurance figure you can put in a design file, and a supply commitment that outlasts the device. Consumer parts are built around a consumer refresh cycle. Medical devices tend to stay in service for far longer than that, and the memory has to keep up for the whole of it.
Most designs that fail in the field were specified perfectly sensibly. A commercial part met every number on the datasheet at the time. What tends to catch people out is the gap between a datasheet figure measured at 25 degrees Celsius and the reality of a sealed enclosure that runs warm and gets wiped down with disinfectant several times a day.
Michael recommends sending us the duty cycle and the operating temperature range before you send a part number. Those two figures rule out more options than anything else on the specification, and they are the two that most enquiries leave out.
Where memory actually fails inside a medical device
Flash memory in a medical device fails in a small number of predictable ways, and every one of them has a design answer.
Data corruption from electrical noise. Medical environments are crowded with electronic equipment, and electromagnetic interference can disturb data held in flash and EEPROM. Error detection and correction codes catch and repair most of it, but no scheme is absolute, so the interference has to be designed out at the enclosure and layout level as well as handled in the memory.
Wear out. Flash cells have a finite number of program and erase cycles. A device that logs continuously, or writes a settings file on every state change, will get through those cycles faster than anyone expected during design review. Wear levelling spreads the writes across the array and buys back a great deal of life, but it only works if the endurance rating was right in the first place.
Loss of power during a write. Flash is non-volatile, so it holds data with the power off, but an abrupt loss of power partway through a write can still leave a record incomplete or corrupted. Power fail protection, whether that is a supercapacitor on the drive or a hold-up circuit in your design, is what turns a half-written record into a clean rollback.
Charge leakage over time. Stored charge dissipates slowly, which matters when a device has to hold calibration data or a patient record for the whole of its service life rather than until the next sync. Retention rating, not endurance rating, is the number to look at for that job.
Temperature and humidity cycling. Anything mounted near a heat source, or on a trolley that moves between a warm ward and a cold store, gets thermally cycled every day of its life. Industrial-rated parts hold their specification across a far wider temperature band than commercial ones, and that is usually the cheapest reliability improvement available.
Matching the memory type to the job
Different jobs inside the same device want different memory. Putting everything on one part is where a lot of avoidable trouble starts.
| The job | What suits it | Why |
|---|---|---|
| Calibration constants, machine settings, serial numbers | Serial EEPROM or NOR flash | Small, byte alterable, very high endurance, decades of retention |
| Firmware and application storage | eMMC or industrial SSD | Managed NAND with wear levelling and ECC built in |
| Continuous patient data logging | Industrial SSD or industrial microSD | Sustained write endurance and power fail handling |
| Records that must never be altered after capture | WORM or read-only media | Immutability enforced in hardware rather than in software |
| Portable transfer of data or settings between units | Rugged removable token | Physical form factor security and a sealed connector |
Serial memory is the part most often under-specified. If you are weighing up which of the two to design in, the comparison of flash memory and EEPROM sets out where each one earns its place. If your device holds calibration constants or configuration data that has to be readable years after the last firmware update, Datakey serial memory covers EEPROM and NOR flash from 1 Kbit to 64 Mbit across SPI, I2C and Microwire, which is the right shape of part for that job. For firmware and bulk storage, Flexxon industrial SSDs and Flexxon eMMC give you managed NAND with the endurance figures documented rather than implied, and industrial SD and microSD cards cover the removable logging case.
Where a device or a settings key has to be carried between units, the physical connector matters as much as the silicon. Datakey RUGGEDrive tokens use a proprietary form factor with a unique mating receptacle, so a standard USB stick will not physically fit the port, and the receptacles are rated for 50,000 insertion cycles. That removes a whole class of problems in a clinical setting, where a device sits in a corridor and anybody can walk up to it. The NCSC makes the same point in general terms in its guidance on using peripherals securely, which treats an exposed interface as a route in rather than simply a convenience.
The environment your memory really lives in
Medical equipment gets cleaned aggressively and often, and some of it goes through sterilisation. The memory component itself is not being autoclaved, but the enclosure it sits inside is, and the thermal and humidity cycling that puts through the assembly is real. Repeated wipe-downs with alcohol or chlorine-based cleaners drive designers towards sealed enclosures, and a sealed enclosure runs hotter than an open one, which pushes the memory further up its temperature range on every duty cycle.
The practical consequence is that the operating temperature range you specify should reflect the inside of the box on a bad day, not the room the box sits in. This is exactly the same problem as an outdoor cabinet in an agriculture or construction application, and it is solved the same way, with an industrial temperature part and a realistic thermal model.
Where the device is portable and the connector is exposed, IP67-rated panel-mount receptacles keep moisture and cleaning fluid out of the interface. That matters more in a clinical setting than most specifications acknowledge.
Keeping patient records intact and unalterable
Data integrity in a medical device is not only about avoiding corruption. It is about being able to demonstrate, later, that a record has not been changed since it was captured. Software permissions can be reconfigured, and audit logs can be edited by anyone with enough access. Hardware-level immutability cannot.
That is the gap the Flexxon security range is built to close, and it is the primary product route for anyone reading this page with a data integrity problem.
ROM, or read-only mode. Once the administrator writes the data and locks the device, the contents cannot be modified. Only the administrator can enable or disable the read-only setting. This suits reference data, validated software images, and anything that should be identical on every unit in the field.
WORM, or write once read many. Data can be written once and read as many times as needed, but never altered or deleted afterwards. For records subject to regulatory scrutiny, that immutability is the whole point, because an auditor can verify the record without having to trust the access control that sat in front of it. There is a fuller explanation of how write once read many storage works if you want the detail. Secure SD and microSD cards are available in read-only, WORM and AES-encrypted formats.
X-MASK. Sensitive data is masked so that it is unreadable to an unauthorised user while remaining usable for authorised purposes, with encryption applied on top. X-MASK also keeps audit trails and access logs, which matters when you have to show an auditor not only that a record is intact but who opened it and when.
X-SIGN. A digital signature technology from Flexxon that applies a cryptographic seal to data. Verification uses a public key to confirm that the content has not changed since it was signed, which gives you a chain of custody for electronic health records, prescriptions, and other documents where authenticity has to be provable rather than assumed.
Underneath all four of those sits a physical layer. Flexxon drives carry sensors that recognise and block physical attacks, including chip scraping. That matters more than it first looks, because an attacker who gets at the silicon directly bypasses the controller, and with it every protection the controller was enforcing. Immutability that can be lifted off the chip in a workshop is not immutability. Portable equipment in a clinical setting goes missing more often than anyone plans for.
None of that replaces your wider security design. Hardware immutability is one control among several, and it works alongside access control, encryption, and a documented process covering who is allowed to write what.
Michael recommends asking early whether a record needs to be immutable or merely protected, because the answer changes the part. Protected means encryption and access control; immutable means WORM or read-only, and retrofitting immutability after the architecture is fixed is far more painful than designing it in.
Where immutability and the right to erasure pull against each other
This is worth settling before you commit to WORM, because it catches people late. Immutable storage is built so a record can never be altered or deleted. UK data protection law gives individuals a right to erasure of their personal data in defined circumstances. Those two things point in opposite directions, and the conflict is practical rather than theoretical.
The usual way through is to keep personal data off the immutable media in the first place. Write the clinical or audit record that genuinely has to be tamper-evident to WORM, hold identifying data separately where it can be amended or erased, and link the two. The integrity requirement and the erasure obligation are then each met by the part of the system designed for it.
How you balance the two obligations is a question for your data protection officer rather than for a memory supplier, and the ICO guidance on encryption and data storage is the right starting point. What Nexus can tell you is exactly what the media will and will not do, and that is the part that has to be right before the rest of it can be.
Standards you will be asked about
You will not be asked to certify the memory on its own. You will be asked to show that the component was selected, validated and controlled as part of a compliant system.
| Standard or regulation | What it covers | Why it touches your memory choice |
|---|---|---|
| ISO 13485 | Quality management systems for medical devices | Component selection and supplier control have to be documented and repeatable |
| UK Medical Devices Regulations 2002 (SI 2002 No 618, as amended) | UK market requirements, overseen by the MHRA | Requires quality systems and validation covering all components |
| EU MDR 2017/745 | EU general safety and performance requirements | Demands evidence on data integrity, reliability and security for embedded systems |
| IEC 62304 | Medical device software life cycle | Relevant where software running on the memory is risk classified |
| IEC 60601 | Basic safety and essential performance of medical electrical equipment | Sets the electrical and EMC context the memory has to work inside |
| RoHS and WEEE | Hazardous substances and end of life | Component-level compliance you will be asked to evidence |
The MHRA is the authoritative source for UK requirements, and it is worth going there directly rather than relying on a summary. That does not replace your own regulatory advice, and Nexus does not give it.
The obsolescence problem, and why it costs more than the part
Here is the failure mode that does not show up in any test. Your device passes validation, ships, and sells steadily for eight years. In year four, the memory manufacturer issues an end-of-life notice on the exact part you designed in. The replacement is functionally similar, but it is not identical, and now you are back through requalification on a product that was working perfectly well.
The cost of that is not the price difference on the part. It is the engineering time, the documentation, the test campaign, and the delay. That is why long-term availability belongs on the specification alongside endurance and temperature, and why it is worth asking a supplier for a written commitment rather than an assurance.
This is where a value added distributor is a different proposition from a catalogue. You get long-term supply commitments from the manufacturers Nexus represents, early sight of end-of-life notices, and an applications engineer who has specified the part before rather than a link to the datasheet you have already read. Nexus has supplied secure and rugged memory since 1987, which is long enough to have watched three generations of memory come and go. Nexus is the appointed Flexxon partner for the UK, Ireland, Germany, Switzerland and Austria, and supplies across the UK, Ireland, the DACH region, Benelux and Scandinavia.
Michael recommends asking for the last time order and last time delivery policy in writing before you design a part in. A verbal assurance about long-term availability is not something you can put in a design history file, and it is not something you can hold anyone to in year four.
Frequently asked questions
Can I use a commercial microSD card in a medical device if I test it properly?
You can test a specific batch, but you cannot control what you get next time. Commercial card manufacturers change the NAND, the controller, and the firmware without changing the part number, so the card you validated may not be the card you receive six months later. That silent change is the reason industrial parts exist, and it is a much bigger risk than the raw endurance difference.
How do I work out the endurance rating I actually need?
Take the bytes written per day by the worst-case use of the device, multiply by the service life in days, and compare that against the drive writes or program and erase cycles the part is rated for. The number people usually get wrong is the write amplification from small frequent writes, so if your device writes a few hundred bytes very often, size for far more than the raw data volume suggests.
Does WORM memory meet my regulatory record keeping requirements on its own?
It supports them; it does not satisfy them by itself. WORM gives you hardware-enforced immutability, which is strong evidence that a record has not been altered, but your obligations also cover retention periods, access control, retrieval, and disposal. Treat it as one control inside a documented process rather than as a compliance answer.
What should I send when I ask for a recommendation?
Operating temperature range, duty cycle, expected service life, the interface you are designing to, the mechanical space you have, and whether any of the data has to be immutable. Those six things get you a useful answer straight away. A part number on its own usually gets you a question back.
Are samples available before we commit to a design?
Yes. A sample tells you things a datasheet cannot, particularly around thermal behaviour in your actual enclosure and how the part behaves at the edges of its range. It is worth doing before the layout is fixed rather than after.
Talk it through before you commit
If you are specifying memory for a medical device and you want a straight answer rather than a catalogue, get in touch with the Nexus team. Send the temperature range, the duty cycle and the service life, and you will get a recommendation from an applications engineer who has specified this class of part before.
If you are earlier in the process, the Flexxon security range is the place to start for anything with a data integrity requirement, and you can request a Flexxon sample or download the product brochure without any commitment. If you want the sector view rather than the product view, the healthcare and medical data storage page covers how this applies across the sector.