On this page
Asset Type
Manufacturer
Model
What This Guide Helps With
Troubleshoots an unrecognized parameter micro-module caused by seating, connector, module, configuration, host, contamination, or compatibility issues.
Step-by-Step Troubleshooting
1. Protect the Patient and Maintain Required Monitoring
If the missing parameter is clinically required, establish that measurement on another verified monitor or approved device before troubleshooting.
Do not repeatedly disconnect a parameter module while the patient depends on its measurement or alarms.
Expected outcome: Required patient monitoring continues independently while the module recognition problem is evaluated.
2. Confirm Which Module Is Not Recognized
Identify the exact CARESCAPE parameter micro-module involved and determine:
- Whether it is completely absent from the display.
- Whether it appears intermittently.
- Whether a recognition or communication message is displayed.
- Whether the issue began after docking, transport, cleaning, module exchange, or accessory replacement.
Expected outcome: The affected module and recognition failure are clearly identified.
3. Reseat the Parameter Micro-Module
With the device removed from patient dependence, remove and reinstall the micro-module using its normal external connection method.
Inspect for incomplete engagement or mechanical obstruction. Do not force the module.
Expected outcome: The module seats normally and is recognized. If recognition returns and the associated parameter functions correctly, perform final verification and stop troubleshooting.
4. Inspect Accessible Module and Monitor Connections
Inspect the accessible module interface and monitor connection for:
- Debris.
- Moisture.
- Bent or damaged contacts.
- Cracks or impact damage.
- Residue from cleaning.
- Foreign material preventing full insertion.
Follow approved cleaning practices if contamination is present.
Expected outcome: The external connection is clean, dry, undamaged, and capable of full engagement. If correction restores recognition, stop after functional verification.
5. Power-Cycle the Monitoring Setup When Clinically Safe
With the device off the patient and required monitoring provided elsewhere, perform a normal restart of the CARESCAPE ONE.
Do not use undocumented service menus or perform unauthorized configuration changes.
Expected outcome: The monitor initializes normally and recognizes the micro-module. If the restart clears the condition and the parameter functions normally, troubleshooting can stop.
6. Test With a Known-Good Compatible Micro-Module
Install a known-good compatible micro-module of the same intended type when available.
If the known-good module is recognized, the original module becomes the primary suspect. If neither is recognized, the problem may be with the CARESCAPE ONE interface, configuration, or related system.
Expected outcome: The failure follows either the module or the monitor, narrowing the fault without internal disassembly.
7. Test the Suspect Module on a Known-Good Compatible System
When available and clinically appropriate, install the suspect micro-module on another known-good compatible CARESCAPE system.
Expected outcome: A module that fails on multiple compatible systems should be removed from service. A module that works normally elsewhere shifts attention to the original monitor or interface.
8. Verify Supported Configuration
Confirm that the module is appropriate for the CARESCAPE ONE configuration in use and that no recent approved configuration or software change preceded the complaint.
Do not alter protected configuration simply to make a module appear.
Expected outcome: The module is confirmed appropriate for the intended system. Any suspected configuration issue is escalated through approved GE Healthcare or facility procedures.
9. Verify Parameter Function After Recognition
Once recognized, connect the appropriate approved simulator, test accessory, or nonpatient test setup and verify:
- Parameter appears correctly.
- Waveform or numeric data is present when applicable.
- Alarms can be generated and annunciated appropriately.
- The module remains recognized during normal handling.
Expected outcome: Stable recognition and correct parameter operation are confirmed. Troubleshooting can stop.
10. Escalate Persistent Recognition Failure
If known-good modules are not recognized after external connections, seating, restart, and configuration considerations have been checked, stop troubleshooting.
Expected outcome: The affected monitor or module is removed from clinical use and routed for qualified service.
If the Problem Persists
Common external causes have been ruled out. The remaining issue may involve the micro-module itself, the CARESCAPE ONE module interface, internal communication, software, configuration, or another service-level fault.
The affected equipment should be:
- Removed from service.
- Labeled Out of Service.
- Sent for repair or bench evaluation.
- Evaluated using appropriate GE Healthcare documentation and approved test equipment.
- Repaired or configured only by qualified personnel.
After repair, verify module recognition, parameter accuracy or functional performance as applicable, alarm operation, docking, and overall monitor function before return to service.
Knowing when to stop external troubleshooting is proper troubleshooting.
Clinical Use Tip
If a parameter module disappears during patient monitoring, establish that measurement on another verified device before testing or reseating modules.
Work Order Documentation (CCR Method)
CCR = Complaint, Cause, Resolution
Complaint
What was reported by the clinical staff.
Example:
"Staff reported the CARESCAPE ONE would not recognize the connected parameter micro-module."
Cause
What was observed during troubleshooting.
Example:
"Clinical Engineering found the micro-module was not fully seated in the external module interface."
Resolution
What action was taken.
Example:
"The module was removed and correctly reinstalled, then stable recognition, parameter operation, and alarm response were verified."
Helpful Details to Include (If Known)
- Exact micro-module involved.
- Recognition or communication message.
- Whether the problem was intermittent.
- Condition of external contacts.
- Whether reseating restored recognition.
- Known-good module test results.
- Suspect module test on another system.
- Recent software or configuration activity.
- Parameter functionality after recognition.
- Final alarm verification.
Final Thought
A module recognition complaint should first be treated as an interface, seating, module, compatibility, or configuration problem rather than an assumed internal failure. Maintain required monitoring, isolate the fault with known-good comparisons, and escalate when external checks no longer provide a safe path forward.
That is successful troubleshooting.