I wrote in the beginning of 2012 that perhaps that year was the year for mHealth to ‘breakout. ‘ I cited several proclamations and organizational activities to support that claim. mHealth and the use of remote monitoring as an integrated healthcare offering is still not as prevalent as one would think it would be two years later. Even in the Telemedicine & E-Health LinkedIn Group, one sees angst at the low adoption rate of the use of telehealth solutions. Inevitably, when I speak with my colleagues and other people involved in healthcare, economic and clinical effectiveness questions prevail. Two specific conversations I had with clinicians stand out. In one, the cardiologist had not seen enough evidence that the quality of care and cost would justify a large addition or change to the existing healthcare offerings. In another, the clinician reminded me that with chronic diseases, one is attempting to get patients to change their behavior, which is very difficult, regardless of any technology involved.
With the above in mind, I’d like to offer the following results from the Renewing Health (RH) project in Europe, a randomized control trial which endeavored to compare the use of remote monitoring technologies and workflows with traditional workflows in the management of chronic disease in both economic and clinical terms. While the final results of the whole study are due out this summer, Veneto, Italy, has presented their findings for congestive heart failure (CHF) and they are fairly impressive.Read More
Introduced in the House back in October was the wittily named Sensible Oversight for Technology which Advances Regulatory Efficiency Act of 2013 which has the acronym SOFTWARE. Not to be outdone on the creation of legislative acronyms, now comes the Senate version with a bill entitled Preventing Regulatory Overreach To Enhance Care Technology, which of course gives us PROTECT. Both of these bills seek to define and sub-define medically related software, and then to take part of what they have defined away from the FDA, and do something else with it that has not yet been clearly identified.
The premise of these bills is that the FDA inhibits entrepreneurs by peskily requiring, at least in some cases, that the developer meet regulations that are supposed to provide some measure of safety and efficacy before these products are used for or by the public. These issues arise in part because the definition of a medical device does not explicitly include or exclude software. This has allowed the occasional debate about whether and what kind of software is or is not a medical device. The FDA’s position is to simply look at the function of the software and the definition, and then to say that if what the software does meets the definition then it is a medical device. Debating this with the FDA is typically not a fruitful endeavor. Some other countries have explicitly included software, presumably to try to end the discussion. For example the UK explicitly includes “software” in its list of the multiple categories of things that may be a medical device.Read More
It’s useful to segment and analyze markets for developing company and product strategy or analyzing competitor’s actions. Such an exercise helps illuminate why companies and markets do what they do – and what they might do in the future. In getting ready for this year’s HIMSS in Orlando, I’ve been thinking about the point of care (PoC) market. At the first Medical Device Connectivity conference in 2009, I defined the PoC market as the workflow and data associated with direct patient care in nursing units, the ED, surgery and related areas. This contrasts with EMRs managing orders, diagnostics, capturing charges and generally documenting things for the medical/legal record. (You can download a PDF of the presentation here.)
Many devices and software applications used at the PoC are FDA regulated medical devices because they are directly used in the diagnosis or therapy of patients. Because the PoC is where direct patient care is delivered, most PoC solutions meet the FDA’s definition of a medical device. Imagine a layer cake:Read More
Challenges with alarm notification and fatigue have plagued the health care industry for decades. Long before alarm notification systems like Emergin (now Philips IntelliSpace Event Management) and GlobeStar Systems (ConnexAll) appeared, some hospitals addressed alarm issues with the original alarm notification system, monitoring techs. Monitoring techs remain an accepted and effective tool in the constant battle to reduce alarm fatigue and avoid failure-to-rescue events.
With the growing adoption of electronic alarm notification systems, is there still a role for monitoring techs? Are electronic alarm notification systems superior to flesh and bone monitoring techs? This blog post will explore monitoring techs as a solution and consider whether they might be a compliment to an alarm notification system, or whether an alarm notification system should take the place of monitor techs.Read More
We are encountering many hospital which are still based on wired LAN technology for medical device connectivity. Many have mentioned their gripes and major concerns about using Wi-Fi technology for patient monitoring and drug delivery monitoring in the OR as well as ICU departments.
Many hospitals are still using WMTS telemetry in their more critical patient monitoring areas. This is very expensive and maintenance for such a system is costly.
Can you tell us what are the major criteria to ensure a reliable safe and secure Wi-Fi network for medical devices?
If a hospital decides to use Wi-Fi technology, what are the proper guidelines to which they must adhere, to ensure that their current and future Wi-Fi network will be stable, reliable, safe and secure? What are the important features they should consider seriously before embarking on using this type of technology?
Great questions. Here we go with some answers:Read More
Some time ago Tim Gee pointed out that a major vendor for an in hospital communication system included the following statement in its documentation:
“This product is not intended for use with patient monitoring devices or other patient care devices. Do not use this product as the primary communications tool in health care environments, as it may use an unregulated frequency band that is susceptible to interference from other devices or equipment.”
Of course “primary communication” was exactly why the product was being purchased, and arguably what it was being sold for.
When discussing Clinical Decision Support (CDS) (here) I have pointed that it is common for CDS creators to in essence say that one should not rely on the output of the product, but instead always second guess the advice provided. This perhaps approaches a warning that I proposed for a product that I thought was seriously defective: DO NOT USE THIS PRODUCT. Maybe I was being facetious.
These examples may pale in comparison to the following disclaimer for medical image processing software:Read More