| Catalog Number |
8118894 |
| Medical Device Problem Codes |
Insufficient Device Problem Information (3190); No Visual Prompts/Feedback (4021)
|
| Health Effect - Clinical Code |
No Clinical Signs, Symptoms or Conditions (4582)
|
| Date of Event |
04/08/2022
|
|
Type of Reportable Event
|
Malfunction
|
|
Additional Manufacturer Narrative
|
|
Csh investigation is currently in progress.Submitting an initial report to the us fda as there are currently insufficient facts available to make a reportability decision and at least 25 days has elapsed.Csh will submit a follow up with investigation update/findings within 30 days.
|
| |
|
Event or Problem Description
|
|
On 08-apr-22, carestream health (csh) was notified of an incident related to the drx revolution system: the incorrect patient was completed, but 2d barcode reader/software did verify the patient.There has been no injury, misdiagnosis or any patient safety impact.Csh investigation is currently in progress.Submitting an initial report to the us fda as there are currently insufficient facts available to make a reportability decision and at least 25 days has elapsed.
|
| |
|
Event or Problem Description
|
|
On 08-apr-22, carestream health (csh) was notified of an incident related to the drx revolution system: the incorrect patient was completed, but 2d barcode reader/software did verify the patient.There has been no injury, misdiagnosis or any patient safety impact.Csh investigation is currently in progress.Submitting an initial report to the us fda as there are currently insufficient facts available to make a reportability decision and at least 25 days has elapsed.Update: 24-may-22: software log investigation shows the tech selected a patient to work on from the worklist screen, referred to as patient (b)(6) here.Patient (b)(6) is the intended patient.This caused the system to navigate to the input screen acquisition page for patient (b)(6).At this point it is apparent the system is in an unknown state because the patient verification required message is not displayed as expected.
|
| |
|
Additional Manufacturer Narrative
|
|
Csh investigation is currently in progress.Submitting an initial report to the us fda as there are currently insufficient facts available to make a reportability decision and at least 25 days has elapsed.Csh will submit a follow up with investigation update/findings within 30 days.24-may-22: update: per csh investigation: evidence from sw log investigation shows the tech selected a patient to work on from the worklist screen, referred to as patient (b)(6).Patient (b)(6) is the intended patient.This caused the system to navigate to the input screen acquisition page for patient (b)(6).At this point it is apparent the system is in an unknown state because the patient verification required message is not displayed as expected.The tech then proceeded to scan the wrist band to perform verification against patient (b)(6).The tech inadvertently was scanning the wrist band of the incorrect patient, patient b.In this case the tech ignored much relevant information in going to patient (b)(6) that normally also should be used for verification, such as gender, age, and other facts like that patient b was not even scheduled for any procedure.Since the software was not in a state requiring verification, it proceeded to operate as if the patient (b)(6) wristband scan was requested for work, rather than verification.There was no patient b found so the software navigated to the worklist for selection of a patient again.The verification feature can be turned on or off depending on the site's preference.If the verification feature is turned on, the verification feature in conjunction with tech procedures for patient verification should be applied.If the verification feature is turned off, the techs should ensure they follow their procedures for patient verification.The tech then proceeded to select patient a again and request for verification was still not occurring.The tech was able to shoot images of patient (b)(6) and include them with patient (b)(6), as would be normal when request for verification is not occurring.The patient b images displayed with patient (b)(6) and were delivered to the pacs.Note: this is the same information as displayed at the acquisition screen on the console.In other words, the same images and patient shown to the tech on the drx-revolution console screen are the ones delivered to the radiologist at the pacs.In summary, it is apparent the system got into an unknown state where the required verification was not in an enabled state.It will likely never be determined how the system got into this state or what actions the tech took to result in the software being in this unknown state.Since this occurrence, carestream has not been able to duplicate these circumstances in the lab.In addition, we were unable to reproduce the issue during a site visit with an applications engineer at the site.The applications engineer worked with current representatives at the site to try similar scenarios and were unable to duplicate the issue.The tech initially involved when the issue occurred was not available to question or assist in trying to determine if any out of ordinary or abnormal workflow steps would be involved in the system getting into this state.To date we are unaware of any more occurrences of this issue at the site and the customer continues to use the system as normal and intended.To date csh has not been informed of any other occurrence of this failure mode on any other customer machines and will continue to monitor for similar incidents.The most likely potential cause for this unknown state could not be identified as it occurred in a single point in time and could not be simulated in the field or reproduced in the lab by carestream.Carestream has concluded this investigation.
|
| |
|
Search Alerts/Recalls
|