The above title is the topic for my presentation at this year’s Medical Device Connectivity Conference. The event this year will be held at the Hyatt Dulles in Herndon, VA November 21-22. The agenda is just about finalized; you can check it out here.
This post is both a preview and a bit of thinking out loud as I continue to develop the the presentation. Suggestions or criticisms are welcome via comments below.
Whenever connectivity is added to a product or solution, things change. If this is a new product direction for the company (or a new variation of an established product category purchased by a provider organization) the resulting changes are often unexpected – by both buyer and seller. And whether expected or not, not meeting the market requirements that result from these transformations means bad things can happen like:
- Unsatisfied customers and/or user resistance due to unmet requirements,
- Lower than expected adoption rates, and
- Lost sales to competitors who better meet requirements resulting from transformations.
The goal of the presentation is to provide a concise framework to be able to identify and anticipate those changes, even when it’s the first time dealing with connectivity.Read More
Creating and launching innovative ground-breaking new technologies and solutions is a heady experience, especially in health care where innovations can literally save lives. Pioneering new technology is hard and very expensive work. There is always a rush to get the product finished enough to be able to launch and start generating some revenue. Features considered not essential are pushed farther out on the product roadmap and these products are launched based on the innovations that have been implemented.
A couple of products come to mind as examples: FlowSense Medical’s digital urine flow meter (recently acquired by Baxter) and PixCell Medical’s cell based point of care diagnostics. In both of these cases, a non essential capability that’s been pushed off is connectivity. Feature trade-off decisions is an everyday activity in medical device product development. However, every trade-off has consequences. Let’s look at those consequences, and more importantly, how to mitigate them.Read More
Wireless sensors are intended to operate via short range wireless communications. That’s why they’re called “body area” networks. Due to power consumption constraints, wireless sensor radios typically don’t operate as 802.11 a/b/g/n radios used in enterprise networks. The reference designs from the manufacturers of radios intended for wireless sensors often indicate a range of a few meters and show wireless sensors communicating with a gateway device that aggregates sensor data and then communicates with the enterprise network where the sensor software applications reside.
When asked if they’d prefer their wireless sensors with a patient worn gateway (typically about the size of a deck of cards or smaller) or just the wireless sensors by themselves, most users – patients and caregivers – overwhelmingly chose the sensors-only option. They just got rid of those nasty sensor cables, why would they want some extra box they have to keep track of?
Asking requirements gathering questions on feature trade-offs that aren’t supported by the technology is often times a frustrating experience. It is, however, important to identify all market requirements, even the ones you may not be able to meet with current technology. Let’s look at how we might solve this conundrum.Read More
On September 4, 2013, the FDASIA mandated workgroup presented their recommendations to the Health IT Policy Committee in Washington, D.C. Some reporting on the meeting cast the draft report as downplaying potential FDA regulation of healthcare IT applications (HIT), while others emphasized the uncertainty (subscription required) of the process and ultimate outcome. Such news stories are, by necessity, short and can’t cover all the issues but this one from iHealthBeat provides a good summary.
The final report (links to all draft documents) was submitted September 4, 2013 and was basically unchanged from the preliminary report.
The question to be answered by the workgroup was how to regulate HIT. I think we’re past the question of whether or not HIT should be regulated: there have been reports of patient deaths starting in 2005 (here and here), and that’s with almost zero reporting requirements on the part of providers or vendors, and the proliferation of HIT vendor non-disclosure and hold harmless agreements to supress reporting (see reports here and here).
The report, also called the “Section 618 report” for the section of FDASIA that mandates the workgroup and their report, is extremely concise and to the point – perhaps too concise for those outside the world of regulated medical devices. Of the three entities, FDA, ONC and FCC that are the focus of the report, by far the most focus was on the FDA. ONC and FCC received minor recommendations. This blog post focuses on the FDA issues and recommendations. You will have to read the workgroup’s recommendations yourself to pick up the specifics regarding ONC and FCC.Read More
A bit more than two years after releasing their draft guidance, FDA has released the final guidance (pdf) on mobile medical apps (FDA press release). FDA also put up a new page on their web site with information on mobile medical apps.
In this final guidance, FDA has chosen to use two factors to distinguish between mobile medical apps that are low risk that they do not intend to regulate, and higher risk apps that will be regulated. FDA will regulate those mobile medical apps intended:
- to be used as an accessory to a regulated medical device; or
- to transform a mobile platform into a regulated medical device.
As always with FDA, the question of whether a mobile app is regulated or not, will be decided on the intended use or claims made by the manufacturer as described in promotional materials, user manuals and similar content and communications.
FDA references two pages of examples of mobile medical apps. The first list includes Class II medical devices that have received premarket clearance (aka, a 510k). Anyone can submit a 510k for clearance for any kind of device – whether FDA really thinks its a medical device or not. Consequently, this list is not an absolute guide to what FDA considers a mobile medical app that they want to regulate. Unfortunately, the page does not include any links to product information or information on the 510k summary for each product. A search on the “K number” in the FDA’s 510k database, e.g., K020866 for Abbott’s Freestyle Tracker Diabetes Management System, will return a 510k summary for the product, including intended use, classification and product code.Read More