InnerWireless

In talking with a fellow connectologist today, I realized that the
import of the Hospira/InnerWireless announcement is not apparent to all.

Current medical device regulatory practice stipulates that when major components of a regulated system are changed, the system must be
reverified - some might go so far as to revalidate, submit a letter to
file or submit a new 510(k), depending on the extent of the change.

Under the FDA's Quality System regulation (QSR), verification "means confirmation by examination and provision of objective evidence that specified requirements have been fulfilled," i.e., testing against product specifications in the lab. The QSR defines validation as, "confirmation by examination and provision of objective evidence that the particular requirements for a specific intended use can be consistently fulfilled," i.e., demonstrating in an intended setting (customer site) that the system works as described in the 510(k) intended use statement and all labeling (web site, brochures, presentations and claims made by sales reps). Given that the verification testing resources in most medical device vendors are usually the biggest R&D bottleneck, this is a big deal.

To my knowledge, Hospira is the first medical device vendor to reverify their MedNet system to run on InnerWireless' infrastructure. InnerWireless, of course, wants many medical device vendors to be able to use their Wireless Utility. And a medical device vendor who wants to make a sale to a hospital that has InnerWireless installed (and that number is growing) has to support that infrastructure if they want to sell and install their product. Any hospital that invests in InnerWireless is probably a good prospect for a wireless connectivity solution, so I expect more device vendors to follow Hospira's lead.

This regulatory hurdle is an unanticipated expense in time and NRE (non recurring engineering costs) for vendors - money they'd rather spend on new product features.

The teaser on avoiding the revalidation effort at the end of the post refers to my belief that this burden could be avoided (or at least greatly reduced).

UPDATE:  Harvey Knauss of Delphi Consulting Group made the following comment:

Easy answer. Review the FDA Guidance document titled "Deciding When to Submit a 510(k) for a Changed to an Existing Device." Another quick answer is if the Indications for Use have changed or extensive changes in the design of the device then a new 510(k) is required. Adding wireless will require that all safety testing be completed to Standards that cover the whole system.

As Harvey knows, there are no easy answers. In my experience, getting a medical device vendor to change their regulatory approach (or to get a HIT vendor to accept FDA oversight for a product) can be a Sisyphean task. I agree, wirelessly enabling a medical device changes its intended use and requires a new 510(k) with full verification and validation. But the devices I'm referring to in this post are already wireless. The change to run on a distributed antenna system is equivalent to using a different make or model of access point - no change in transmitting frequency, technology or a removal/modification of features. Don't get me wrong, I'm not suggesting that you don't have to do anything, but if you put in place the right regulatory strategy you may be able to reduce your regulatory burden (the engineering work required to comply with regulations) significantly.

Here's an example where three widely divergent regulatory strategies - each with different impacts on R&D cost, time to market, and regulatory burden - are all executed within the law and approved by the FDA. In this example each medical device vendor wants to wirelessly enable their patient monitors and develop and sell a new central station product for surveillance and alarm notification. While this example focuses on the server required to implement a complete monitoring system, the principles can be applied to other connectivity situations.

  1. Vendor A determines that they must manufacture their server (i.e., configure, test and validate their own assembly of PC components into a complete server) in order to meet FDA regulations. They must design the computer, specify each component, assemble and test. Then as each component is changed or discontinued by the supplier, they must find a replacement, reverify and revalidate.
  2. Vendor B determines that they must select a specific server manufacturer and model to use in their system. Vendor B avoids the time and expense required to design, manufacture, and manage component obsolescence, but still has to verify and validate new models when their computer supplier decides to discontinue the product. Oh, and sales will have to explain to prospects why they're still selling an "obsolete" product, i.e., a product for which a newer model is available.
  3. Vendor C determines that due to the standardization of computers and the design of their system, they can simply specify minimum requirements for their server (e.g., 2 GHz Pentium, 512 MB memory, 120 GHz hard disk drive, Windows XP Professional etc.). There's still plenty of regulatory work in this scenario, but the ongoing effort is significantly reduced.

There are vendors who are currently selling systems using each of these approaches, all with 510(k) approval. The essence here is that the FDA QSR defines a process that can produce a safe and effective product through different means. Short answers must, by necessity, be easy answers as time requires that I make my response brief.