On this page
Asset Type
Manufacturer
Model
What This Guide Helps With
Identifies causes for database corruption, missing historical data, or storage errors impacting central station performance or patient monitoring records.
Step-by-Step Troubleshooting
Ensure Patient Safety First
Confirm all patients are actively monitored at the bedside. If necessary, move monitoring to alternative devices before troubleshooting storage issues to avoid data gaps.
Check System Status and Alerts
Review the Sentinel’s status screens for any database or storage warnings. Look for red or amber alerts, disk space warnings, or RAID failures.
Verify Power and Connections
Ensure the central station has stable power and is not experiencing brownouts. Confirm all storage devices (internal or external) are securely connected. Unstable power can corrupt databases.
Check Available Storage Space
Confirm sufficient free disk space. A full database drive can prevent data writes and cause errors. Expected outcome: free space above the manufacturer’s recommended minimum.
Review Recent System Changes
Check for recent software updates, configuration changes, or unexpected shutdowns. These can cause database inconsistencies or partial writes.
Verify Network Storage (if applicable)
If the database resides on a network server, ensure network connectivity is stable and permissions allow read/write access. Look for latency or dropped packets that can affect storage operations.
Attempt a Soft Database Recovery (if supported)
Use Sentinel’s software tools to verify or repair the database. Expected outcome: database consistency check passes, or partial repair succeeds. Do not perform full reinstallation unless directed by escalation.
Check for Unusual Sounds, Heat, or Smells
Listen for abnormal disk activity (clicking, grinding) and check for excessive heat. These are signs of impending storage hardware failure and require immediate escalation.
If the Problem Persists
External and easily verifiable causes have been ruled out.
The database or storage subsystem is likely internally failed or corrupted beyond simple repair.
Action:
Remove the station from service.
Label as Out of Service.
Escalate for vendor repair or bench evaluation.
Knowing when to stop prevents further data loss and ensures patient safety.
Clinical Use Tip
Never troubleshoot storage or database issues on a live patient’s monitoring session.
Ensure continuous monitoring by transferring patients to a functioning station before performing recovery actions.
Work Order Documentation (CCR Method)
CCR = Complaint, Cause, Resolution
Complaint
What was reported by the clinical staff.
Example:
"Central station displaying database errors; historical patient data inaccessible."
Cause
What was observed during troubleshooting.
Example:
"Disk nearly full with corrupted database files; RAID warning present."
Resolution
What action was taken.
Example:
"Verified storage connections, freed disk space, attempted software database repair; station flagged Out of Service and sent for vendor evaluation."
Helpful Details to Include (If Known)
- Disk space available
- RAID status
- Database verification logs
- Error codes and timestamps
- Station operational status after attempted repair
Final Thought
Patient safety is paramount. Logical, stepwise checks—from power and connections to database integrity—reduce risk. Escalation is not failure; it protects patient care. Accurate CCR documentation supports continuity of service and regulatory compliance.
That is successful troubleshooting.