On this page
Asset Type
Manufacturer
Model
What This Guide Helps With
Troubleshoots incorrect time, missing patient information, or unavailable stored traces caused by setup, workflow, synchronization, connectivity, or storage-related problems.
Step-by-Step Troubleshooting
1. Protect Current Patient Monitoring and Data
Do not interrupt active fetal monitoring solely to investigate historical data or clock problems unless clinically necessary. If reliable documentation cannot be maintained, establish an alternate approved documentation or monitoring method.
Expected outcome: Current clinical monitoring and documentation continue safely while the data issue is investigated.
2. Define Exactly What Is Incorrect or Missing
Determine whether the problem involves the displayed date or time, patient identity, current recording, historical stored trace, transferred record, or multiple data elements.
Expected outcome: The scope of the data problem is clearly established.
3. Verify Current Monitor Operation
Confirm the Avalon FM20 is stable, not restarting, and able to acquire and display current fetal or maternal monitoring information.
Expected outcome: The problem is separated from a broader monitor instability issue.
4. Check the Current Clock Display
Compare the monitor's displayed date and time with the facility's approved reference. Determine whether the discrepancy appeared after a restart, power loss, transport, or network disconnection.
Expected outcome: Any time discrepancy is identified and documented before changes are made.
5. Verify Patient Identification Workflow
Confirm that the patient record was initiated, selected, admitted, discharged, or transferred according to the facility's approved workflow. Ensure the apparent missing data is not associated with a different patient record or episode.
Expected outcome: A workflow or patient-association issue is either identified or ruled out.
6. Confirm the Trace Was Actually Recorded
Determine whether the expected trace was displayed only in real time or was expected to be stored or transferred. Check available user-accessible record lists without deleting, overwriting, or altering data.
Expected outcome: Clinical Engineering establishes whether data was created, stored locally, or expected from an external system.
7. Check External Connectivity When Relevant
If patient identity, clock synchronization, or trace storage depends on another system, inspect external network connections, interface status, cables, and other accessible communication indicators.
Expected outcome: Obvious external connectivity problems are corrected or isolated for infrastructure escalation.
8. Compare With Another Verified Monitor or Location
When appropriate, determine whether another correctly configured monitor on the same infrastructure receives correct time, patient data, or data-transfer functionality.
Expected outcome: The problem is isolated to the individual monitor or to shared infrastructure.
9. Perform Controlled Functional Verification
Using non-patient test data where appropriate, verify correct date and time display, creation of a test record or trace using approved workflow, retrieval where supported, and expected data transfer without modifying protected records.
Expected outcome: Record handling operates normally and consistently. If successful, troubleshooting can stop after documenting the result.
10. Escalate Missing or Unreliable Clinical Data
If time repeatedly becomes incorrect, records cannot be retained or retrieved, or data transfer remains unreliable after external checks, remove the monitor from service when continued clinical use could compromise patient documentation.
Expected outcome: The device or infrastructure issue is formally escalated and unreliable data handling is not accepted for continued clinical use.
If the Problem Persists
Common workflow, clock, connectivity, patient-association, and accessible configuration issues have been evaluated. Remaining causes may involve internal storage, software, system configuration, time synchronization, network infrastructure, or the downstream clinical information system.
Remove the device from service when its data reliability affects safe clinical use, label it Out of Service, and send it for bench evaluation. Evaluate the monitor using appropriate Philips documentation and approved test equipment, and involve the responsible integration or IT team when infrastructure is implicated. Repairs and protected configuration changes should be performed only by qualified personnel.
Before return to service, verify clock accuracy, patient-record handling, trace storage or transfer as applicable, monitoring functions, and alarms. Knowing when a data problem requires escalation beyond the monitor is proper troubleshooting.
Clinical Use Tip
When investigating missing fetal traces, preserve existing records and document the affected patient, time period, monitor, and destination system before making configuration changes.
Work Order Documentation (CCR Method)
CCR = Complaint, Cause, Resolution
Complaint
What was reported by the clinical staff.
Example:
"Staff reported that fetal trace records from the Avalon FM20 were not appearing with the expected patient record."
Cause
What was observed during troubleshooting.
Example:
"Clinical Engineering found that the monitor was associated with an incorrect patient record while device communication and test trace storage operated normally."
Resolution
What action was taken.
Example:
"Clinical staff corrected the patient association using the approved workflow, and Clinical Engineering verified correct creation and retrieval of a subsequent test record without changing protected configuration."
Helpful Details to Include (If Known)
- Incorrect clock, patient record, or trace symptom
- Displayed date and time
- Approximate time the issue occurred
- Patient-record workflow observed
- Whether the trace existed locally
- Network or interface status
- Comparison with another monitor
- Rooms or ports tested
- Results of controlled test record
- Final device and data status
Final Thought
Clinical data issues require preservation of existing information, careful separation of device and infrastructure causes, verification before changing configuration, appropriate escalation, and precise documentation.
That is successful troubleshooting.