Preserving Device Logs After a Serious Event

Why the information inside a medical device may be just as important as the device itself

Modern medical equipment remembers things.

Published August 12, 2026 · Revised September 6, 2026

Back to Biomed Basics

What This Page Explains

This page covers:

The Simple Version

Device logs may be circular, volatile, or changed by ordinary actions such as rebooting, charging, connecting to a network, running self-test, or starting a new case. After a serious event, follow the facility's incident and evidence-preservation process before routine troubleshooting. Do not assume the records will remain available.

  1. Follow your facility's incident process.
  2. Identify what information the device stores.
  3. Preserve what is currently visible.
  4. Avoid unnecessary rebooting, resetting, or updating.
  5. Record the device's displayed time.
  6. Export logs using the approved method.
  7. Keep the original files unchanged.
  8. Document how and when they were obtained.

Record the displayed clock, time zone, device identity, software version, current screen, connections, and condition received. Export through the approved method, preserve original files unchanged, calculate or retain integrity information when policy requires it, and document who collected what, when, and how. Work from a copy whenever possible.

What Is a Device Log?

A log is a record created by the equipment.

Different manufacturers use different names.

You may see:

These may contain very different information.

Do not assume:

I downloaded the log.

means you collected everything.

Alarm Logs

Alarm logs may show:

For example:

14:31:12 — High Airway Pressure

14:31:18 — Alarm cleared

That can help reconstruct the clinical event.

Error Logs

Error logs usually focus more on internal equipment problems.

Examples:

These may be more useful to a technician than the normal alarm history.

Event Logs

Event logs may include a broader range of activity.

For example:

Event logs can sometimes provide an approximate sequence of what happened.

Therapy Records

Some devices store information about therapy delivered.

Depending on the device, that might include:

These records can be particularly important after an event.

Handle them according to facility procedure.

Audit Trails

Some systems record user or configuration actions.

An audit trail may show:

Do not assume every medical device has a complete audit trail.

But when one exists, it can help explain changes.

Service Logs

Service logs may contain information not shown to clinical users.

Examples:

Access may require:

Do not enter service mode or run an extraction procedure after a serious incident until you understand whether doing so changes stored information.

Logs Can Be Volatile

Some information exists only temporarily.

It may disappear when:

This is volatile information.

If the device is displaying a meaningful message after an incident, document it before doing anything that might clear it.

Other Logs Are Stored

Many devices store logs in nonvolatile memory.

That means they remain after power is removed.

But even stored logs may eventually be:

Do not assume stored means permanent.

Log Rollover

Devices have limited storage.

Imagine an event log stores the most recent:

1,000 events.

When event 1,001 occurs, the oldest entry may disappear.

Now imagine repeatedly rebooting a device.

Each reboot generates:

You may be creating new entries that push older ones out.

This is another reason to minimize unnecessary interaction before log preservation.

Do Not “Test It a Few Times” First

Suppose a ventilator had a serious fault at:

10:14.

You immediately run five pre-use checks.

Now the log contains dozens of new events.

You have added noise to the timeline.

Worse, you may have overwritten older entries.

Preserve first.

Test later.

Rebooting Changes the Timeline

A reboot may create new entries such as:

That can make the log more difficult to interpret.

If you need to reboot the device, document when and why.

Then investigators can distinguish:

clinical event

from:

biomed testing event.

Record the Device Clock

Before exporting anything, record:

What time does the device think it is?

Compare it with an accurate reference clock.

Example:

Actual time:

15:20:00

Device displays:

15:13:42

The device is approximately:

6 minutes 18 seconds slow.

That information may be extremely important.

Do Not Correct the Clock Yet

If you change the clock before documenting the offset, you can make later log correlation much harder.

First record:

Then follow the approved process.

Why Clock Offset Matters

Imagine these records:

Nurse documentation:

14:52

Central monitor:

14:51

Infusion pump:

14:44

At first, the pump seems unrelated.

But if you discover the pump clock was seven minutes slow, those events may line up.

Time correlation can completely change your interpretation.

Time Zones Matter

Connected systems may store timestamps using:

Daylight-saving changes may also complicate things.

Do not assume all timestamps use the same clock.

Document what you know.

Screenshot What Is Visible

Before navigating away from an important screen, preserve it according to facility policy.

Useful information may include:

Once you leave the screen, you may not be able to return to it.

Avoid Patient Information Problems

Logs may contain protected health information.

Treat them accordingly.

Follow facility rules for:

Do not copy logs containing patient information onto random personal storage.

Use the Manufacturer-Approved Export Method

Depending on the device, logs may be exported using:

Use the documented method.

Do not improvise by removing internal storage or manipulating files unless that is part of an authorized procedure.

Use Approved Storage Media

Hospitals may restrict removable media for cybersecurity reasons.

Follow your organization's policy.

Do not plug a random personal USB drive into clinical equipment.

Preserve the Original Export

When logs are exported, preserve the original files.

Do not immediately:

If analysis requires manipulation, work from a copy when appropriate.

Keep the original extraction intact.

Record the File Information

Useful documentation may include:

For more formal investigations, your organization may have additional requirements.

Follow them.

Do Not Assume the Filename Date Is the Event Date

A file called:

log_2026-08-12

might mean:

Those are not always the same thing.

Open and interpret the content carefully.

Proprietary Logs

Some manufacturers store diagnostic data in formats that biomeds cannot easily read.

That is okay.

Do not modify the file trying to make it readable.

Preserve the original export.

Manufacturer technical support may have tools to interpret it.

Manufacturer Remote Analysis

Some manufacturers may ask you to:

Before sending anything, follow your facility's:

Logs may contain sensitive information.

The Device Is Only One Source

Medical-device logs are often only part of the picture.

Other systems may also contain useful records.

Examples:

A serious event may require correlating multiple systems.

Network Logs

Suppose a patient monitor reportedly disappeared from central monitoring.

The device log says:

14:12 — Network disconnected.

Network infrastructure may also show:

Those separate records can help determine where communication stopped.

Integration Logs

Suppose vital signs did not reach the EMR.

The bedside device may show everything correctly.

The integration platform may show:

That helps identify where the failure occurred.

Central Station Logs

A bedside monitor may have alarmed.

Did central monitoring receive the alarm?

Central logs may help answer that.

Again, device behavior and system behavior are different questions.

Preserve Logs Early

Some systems retain data for:

Others may overwrite continuously.

If an incident is serious, involve the appropriate system owners early.

Do not assume the data will still be available a month later.

Document When You Begin Testing

After logs are preserved, record when normal technical testing begins.

Example:

Original device logs exported at 11:42 before functional testing. Bench testing initiated at 12:05.

Now later entries can be separated from the original event.

Your Testing Will Create Logs

This is unavoidable.

Functional testing may generate:

That is fine once the original information has been preserved.

Just document the boundary between:

event-related data

and:

technician-generated test data.

Do Not Clear Logs When You Are Done

Even after downloading them, do not automatically clear the device.

The investigation may require:

Wait until the appropriate process says clearing or returning the device to service is acceptable.

Logs Are Evidence, Not Absolute Truth

This is important.

A log tells you what the device recorded.

That is not necessarily everything that happened.

A device may fail in a way that prevents it from recording the failure.

For example:

A complete sudden loss of power may leave no final entry saying:

Power suddenly disappeared.

The absence of a fault code does not automatically prove the device never failed.

Logs Require Interpretation

Suppose the device records:

Sensor Disconnect.

That tells you what the device detected.

Possible causes could include:

The log gives you a clue.

You still need troubleshooting.

Error Code Does Not Equal Cause

The same rule from normal troubleshooting applies.

A log entry may describe:

the condition detected

not:

the component that failed.

Do not overinterpret it.

Logs and Clinical Documentation May Disagree

That can happen.

Maybe:

Do not immediately decide one source is wrong.

Understand the time references first.

Real-World Example: Monitor Unexpectedly Reboots

Clinical staff report:

Monitor went black at approximately 14:30.

Before testing:

Record device time.

Export event log.

Log shows:

14:23:12 — AC disconnected.

14:23:12 — Battery communication fault.

14:23:15 — System startup.

Device clock is approximately seven minutes slow.

Now those events align closely with the reported time.

That does not automatically prove root cause.

But it gives you a much stronger troubleshooting direction.

Real-World Example: Ventilator Alarm Event

Ventilator involved in reported loss of ventilation.

Logs show:

10:02:11 — Low minute volume.

10:02:15 — Patient disconnect.

10:02:16 — High-priority alarm.

10:02:40 — Circuit restored.

Those events can help reconstruct what the ventilator detected and when.

You still need to evaluate:

But the timeline is valuable.

Real-World Example: Defibrillator

Defibrillator allegedly failed to deliver therapy.

Event record may show:

That data can be much more useful than simply firing the unit into an analyzer afterward.

Preserve it before testing.

Real-World Example: Infusion Pump

Possible over-infusion event.

Pump logs may contain:

Before resetting or reprogramming the pump, preserve that information.

Common Mistakes

Rebooting Before Looking at Logs

You may change or lose information.

Running Tests First

Preserve the original event before creating new events.

Correcting the Device Clock

Document the offset first.

Clearing Logs After Export

Keep them until the investigation process allows otherwise.

Using Personal USB Drives

Follow cybersecurity and privacy policy.

Editing the Original Export

Preserve the source files.

Assuming No Error Code Means No Failure

Logs have limits.

Treating an Error Code as a Root Cause

It may only describe a symptom.

A Useful Sequence

After a serious event, think:

Observe

What is currently displayed?

↓

Record

Time, settings, alarms, configuration.

↓

Preserve

Export logs using the approved method.

↓

Protect

Keep the original files intact.

↓

Correlate

Compare with other systems and timelines.

↓

Test

Begin technical troubleshooting after evidence is secured.

That order matters.

What Did You Actually Prove?

Suppose the log shows:

Battery Communication Lost.

You proved:

The device recorded a battery communication loss at that timestamp.

You did not automatically prove:

Logs are evidence.

Interpret them carefully.

Final Thoughts for Biomeds

Modern medical devices can tell you a lot about what happened.

But only if the information survives long enough for you to read it.

After a serious event, do not rush into normal troubleshooting.

Before rebooting.

Before recalibrating.

Before replacing parts.

Before updating software.

Ask:

What information is inside this device right now that I may not be able to get back?

Preserve that first.

Record the clock.

Capture the current screen.

Export the logs.

Protect the original files.

Document what you did.

Then troubleshoot.

Sometimes a failed component gives you the answer.

Other times, the answer is sitting quietly in an event log waiting for someone to look at it.

— Jake

Important Note

This page is an educational overview. Log preservation following a serious medical-device event should follow your healthcare organization's incident-response, privacy, cybersecurity, risk-management, legal, regulatory-reporting, and evidence-handling procedures. Do not access, export, alter, transmit, or disclose patient-associated or proprietary data outside your authorized scope.

Related Biomed Basics

Back to Biomed Basics