A recent Class I recall of a medical monitor with a hospital network connected central station stimulates some generalities about software, “fixes”, and connectivity.
A recent Class I recall of a medical monitor with a hospital network connected central station stimulates some generalities about software, “fixes”, and connectivity. (Class I recalls are defined by the FDA as a situation in which there is a reasonable probability that the use of, or exposure to, a violative product will cause serious adverse health consequences or death.)
The use of the product in question was given as:
- a networked solution system used to monitor a patient’s vital signs and therapy, control alarms, review Web-based diagnostic images, and access patient records. The number of monitored vital signs can be increased or decreased based on the patient’s needs
Curiously only one customer was identified as having received the product, or at least this particular version of the product. While the manufacturer and product in question is a matter of public record, and available at the link, I chose not to include it here because my objective is not to repeat the recall information, but to suggest the reasons for the recall, an associated labeling issue, and offer some general lessons.
More Read
The reason given for the recall had two seemingly separate parts. The first is that “The weight-based drug dosage calculation may indicate incorrect recommended values, including a drug dosage up to ten times the indicated dosage”. This sounds like a software problem yet the fix was not to “upgrade” the software but to suggest a workaround. (I love the term upgrade to when applied to fixing something that doesn’t actually work!) According to the FDA the firm’s letter stated that “users should enter the patient’s weight by way of the admin/demographics screen to ensure the drug dosage is calculated as intended.” (I did not find the firm’s letter on its website, but it might be one of those hidden page situations since I did find, with a struggle, two other recalls, though using the search term “recall” produced no results). Again speculating, the workaround sounds like a user dependent way to do something that was supposed to happen automatically. At least part of the value of automation is largely diminished, and opportunities for use error increased, when such additional demands are placed on the user.
The second reason given for the recall was that there may be a 5-10 second delay between the electrocardiogram and blood pressure curves (waveforms) at the central station. This is an interesting technical issue that may be related to software and/or communication protocols. In either case it illustrates that multiple data streams may only be useful if they are properly timed stamped, and then properly aligned at the receiver. Out-of-sync data when subsequently processed either by eye, or automatically, can give erroneous and misleading results that might appear to be correct, i.e. the results could be in the category of erroneous but believable.
For one or both reasons the FDA found that, “This product may cause serious adverse health consequences, including death.” Yet it should be noted that this was a voluntary recall, as most recalls are, despite the fact that people who surely know better reported this as “FDA recalls…”
The FDA announcement goes on to say that the company pointed out that the instructions for use state that: ”For primary monitoring and diagnosis of bedside patients, use the bedside monitor. Use the…Central Station only for remote assessment of a patient’s status.” This sentence seems to be illustrative of the fundamental problem of remote information receivers and integrators that carry a disclaimer that in sum says that you shouldn’t rely on them. But isn’t the ability to rely on it exactly why you bought it? Moreover, promotional materials available on the web do not appear to echo this disclaimer. For example it is stated that ”Applications…enhance patient care management by providing rapid assessment, decision support and clinical reporting.” Does that sound like it isn’t for primary diagnosis? Or does “Data accessible from the…Central Station includes real-time waveforms” sound like those waveforms shouldn’t be used for primary monitoring? For one more example it is said that “arrhythmia events are detected with an unprecedented degree of accuracy.” Accuracy is certainly a good thing, but detecting arrhythmias at the central station when only the beside monitor is to be used for “primary monitoring and diagnosis” appears to be less than highly useful.
Furthermore the statement that the central station is only for remote assessment seems both definitional and contradictory. It is obviously for remote assessment–because it is a central station and thus remote! But then what does “assessment of the patient’s status” mean if not monitoring and diagnosis?
The disclaimer game has been addressed in these pages before. Here it seems to involve a product that is being marketed, sold and bought for exactly the reasons that the manufacturer is saying it shouldn’t be used. I didn’t spot the disclaimer language in any of the promotional materials, but maybe it is there somewhere.
So, we have here an apparent example of software driven miscalculations, network transported data that is not time synchornized, and a reminder not to use the central station for primary assessment. Important examples to remember as we charge ahead with software driven networked solutions.
[The products in the photo with this post above are not associated with the recall discussed, and are for illustrative purposes only.]
