The concept of a disclaimer is rational - but I wonder how much protection it really offers the patient. Most people have neither the time nor the money to ask their physician for a second opinion on everything they learn from the Internet or their mobile device. In reality, therefore, it would be nice if the advice provided had some assurance of accuracy and some indication of adverse signs that should trigger an escalation to a physician (or the emergency room).
Actually, WLANS can be used clinically, if configured propoerly. Some patient monitoring vendors are using WLAN technology for wireless telemetry. The trick is to apply ythe technology appropriately. Steve Baker and Davis Hoaglund published an excellent paper on this. Additionally IEC 60601-1-2 provides guidance on medical grade WLAN deployment. What usually happens is that hospital IT sets themselves up as the hospital technical experts; my examples are indicative of what happens when the clinicians and hospital upper management actually believe them.
My runing joke on this is that when yopu say 'hertz' to hospital IT, the first thing that comes to their mind is 'rental car'.
These are examples of devices for home used applied inappropriately in a hospital setting. The wireless LAN being the perfect example. (I don't understand the first example, but it sounds like something similar.) It would be a shame if such inappropriate applications were enough to squelch this whole industry.
Thanks for chiming in, Greybeard1. These are great cautionary tales (or actually horrifying tales) from the field. You would think that hospitals are knowledgable enough to deal with the danger of using non-medical wireless devices...but apparently these things could happen.
i worked as a biomedical/clinical engineer for the VA for many years. Much of my focus was on medical technology related patient incidents, especially patient injuries or deaths with a national impact. One of the more consistent problems I ran into was that clinicians would start relying on non-medical technology for medical decisions - usually with devastating patient resullts.
1. A hospital bought a wireless communication system that interfaced with the patient alarm system. It was intended as secondary notification, since it had no escalation or follow-up process, but the nurses ended up using it as the primary system. As a result, when a patient alarm went off and the secondary system didn't escalate, the patient died.
2. Another hospital used a home built WLAN to communicate medication information via laptops on the med carts. The staff started using the laptops for charting and other clinical uses. This quickly overwhelmed the WLAN; when in-house IT tried to resolve the problem, they actually made it worse. The entire system collapsed, forcing the nurses to manage all the meds by hand.
I have many more
The point - it's well and good for vendors to criticize the FDA for being slow. From the clinical side - people will use an unapproved device for life critical decisions if they can - and he results are usually dangerous. Also, i recommend checking with the user community in the EU - the articles I've read indicate they wish the EU's approval process was more like the FDA's - Too many devices are approved that shouldn't be.
I suppose it is an advantage to know that any and all apps in medical use have gone through a proper process in order to determine whether they're appropriate for use in that way. But it's likely, as part of a trade-off, that American vendors and manufacturers will continue to complain as long as the US government gets in their way with painstaking regulations.
If all those medical apps are forced to have a statutory message saying
" The results provided by this App are indicative only. Please consult your doctor for the final diagnosis of the symptoms"
then majority of the concerns of a potential risk to the patients can be addressed. The patient using the app is always advised to visit a doctor to take the second opinion when the situation warrants.
And this regulation can be effected more quickly than the time consuming certification of the Apps.
A Book For All Reasons Bernard Cole1 Comment Robert Oshana's recent book "Software Engineering for Embedded Systems (Newnes/Elsevier)," written and edited with Mark Kraeling, is a 'book for all reasons.' At almost 1,200 pages, it ...