Medtronic Remote Programming Patent

Medtronic has been working on remote programming for medical devices for at least a decade. I cannot be certain because I do not and have not worked for Medtronic. But, I have on good authority that I am not far off.

I believe that Medtronic's patent (#7,565,197, please see earlier posts) reveals not only the extent of Medtronic's work on remote programming and their level of development of this technology, it reveals a product development path. I can make this statement with confidence because I have been in this business for a long time. The strategy that I believe Medtronic has taken is in keeping with long-standing trends in technology development.

Over the last several decades, the trend has been to move away from  specialized processors specifically designed for a particular domain to more powerful, general-purpose processors. This enables products to be defined more by software than by hardware. Processing power has become smaller, less power hungry and cheaper, thus allowing software to become the means for defining the system's capability. Furthermore, this enables multiple products to be defined by a single hardware platform.

I think most everyone in the industrialized countries have had some experience with software-defined systems. Numerous products that many of you have encountered run on a standard hardware platform. This is particularly true of products based on a PC hardware platforms. I have been part of the early stage development of two companies who both use a PC platform, but define their products with software. The products could not be more different, but nevertheless they still use the same hardware platform.

The Medtronic patent suggests a similar product strategy ... that different products will use fundamentally the same hardware architecture, but they will be defined by the software that they run. So, a pacemaker, a neurostimulator and a drug pump will share the same processor hardware platform, but their operation will be defined primarily by the software that they run. For example, take some time and examine pacemakers, ICDs. CRTs/CRT-Ds, neuro-stimulators, drug pumps, etc.  Although they have different purposes, they have enough in common to consider the possibility that all of them could share a common processor platform. 

The implications are significant for all functional areas within Medtronic, from research and development, product development, software development and management, and from product support. Medtronic can leverage its enormous scale to make its scale as a company a major asset. It can substantially reduce the number of hardware platforms it supports, it can leverage its software development capabilities to have its software development groups produce software for multiple product lines, it can create more products without a substantial requirement for additional support each time a product is produced. The list of benefits goes on and on. I shall cover those benefits in later posts.

In the next post I shall drill down into the technical specifics of this patent.

Medtronic Patent, Continued: Managing Multiple Devices

To my readers, you should read the posting that immediately precedes this one for background information.


One of the more intriguing aspects of the recently issued Medtronic patent is the capability to manage multiple implanted devices. Here's a list of possible implanted devices included in the patent's description ...

"cardiac stimulation devices, cardiac or other physiological monitoring devices,
neuromuscular stimulators, implantable drug pumps, or the like."

An earlier patent application from St. Jude Medical (Pacesetter) filed in 2001 (listed in this patent as "System and method for remote programming of implantable cardiac stimulation devices" by Snell, et al) was limited to cardiac implanted devices. I find it interesting that this broader and more inclusive patent application has receive a patent, and the narrower, earlier filed patent application from the cardiac device division of St. Jude Medical has not.

Nevertheless, the broad coverage of the Medtronic patent does make things more interesting. As I discussed in an earlier post, patients who have implanted medical devices (IMDs) generally have more than one medical problem, and one or more of those additional medical problems have a significant likelihood of being addressed by an implantable device. For example, a patient may have both a heart problem and diabetes, both of which can be treated with implanted medical devices.

So, if a patient has more than one IMD, how does one manage that? Medtronic makes a wide range of devices. Would every device require it's own external patient management and communications unit? (See Figure 1 of the patent. The external unit is pictured as a laptop computer.) I've seen the solution from one large medical device provider and the answer is "yes." Each device would require it's own monitoring unit.

It may be that Medtronic is attempting to address this issue. The patent application suggests a single, intelligent external patient management and communications unit could manage any of the devices Medtronics produces. I find it interesting that in Figure 1, the monitoring unit shown is a laptop computer. A laptop should be able to provide more than enough computing power and communications capability to manage multiple implanted devices.

Let's take this mode of thinking a bit further ... the patent suggests that Medtronic might well be settling on a single platform, a single system to manage its IMDs, in any combination. This makes sense and it would be a significant cross-company breakthrough if they were able to pull it off.

To contrast with the smallest of the big-three medical device companies, St. Jude Medical is a much smaller company, but makes many of the same devices that Medtronic produces. However, St. Jude Medical is highly fragmented due in part that much of its growth has come through acquisition. Its much of its cardiac device division was originally Pacesetter that was acquired from Siemens. Other companies have been acquired and have been integrated into its cardiac device division. (This is no small achievement.) However, the cardiac division remains separate from the rest of the St. Jude Medical divisions. There is no cross division platform.

Medtronic is a more integrated company than St. Jude Medical, but it is significantly larger and more un-wieldy. Nevertheless, Medtronic may be able to pull it off and settle on a company wide external patient management and communications unit platform and software architecture.

I want to take my speculation one step further. I shall not go into to detail here, but I want to raise the question and address it more detail in a later posting. I think it's fair to speculate that if Medtronic is considering a company-wide platform and software architecture for their external patient management and communications unit then it makes sense to consider a common platform and architecture for their implanted medical devices. This would be a revolution in medical device technology, but is Medtronic considering this? It is anyone's guess and I shall devote at least one posting to this issue.

Medtronic's Remote Programming Patent, 1st commentary

I mentioned in my earlier entry that I plan to focus on the recently granted patent of Medtronics, "Conditional requirements for remote medical device programming" (US Patent # 7,565,197). I have started my analysis of this patent and have found it extremely rich with respect to defining remote programming and it's future.

For those not familiar with remote programming and how it fits in the medical device industry, a brief primer. First, medical devices are implanted machines designed to provide support to a patient with a specific medical condition, such as heart failure, irregular heart beats, diabetes, etc. The more well-known implantable devices include pacemakers, defibrillators and drug pumps.

Second, significant advancements in implants have been made over the last decade. These are small computers with communications capabilities, including the capability to communicate using a radio, wireless, connection. Implants can transmit significant amounts of data.

Third, patients with implanted devices are generally provided a home-monitoring unit that communicates with the implanted device. This communication has largely been one-way, that is, the implanted device sends its data to the home monitoring unit that in turn uploads the data to a central repository (a large, centralized computer system) managed by the device manufacturer. The central repository provides the device managers the ability to review (using a Web connection) the uploaded device data to determine if the patient has had any medically significant episodes (such as a shock delivered by the defibrillator to restart the patient's heart) and to determine if any of the settings on the device require adjustment.

Finally, often times patients may have more than one device. Patients with implanted medical devices often have more than one significant medical problem that requires the intense management provided by implantable devices.

Medical devices have a significant limitation, battery size and life. The medical device requires power to enable it to deliver the prescribed therapy to the patient and (particularly when wireless communications are used) enable the device to transmit data. Conceivably, remote programming will require even more power. I shall discuss the power issue in a later posting.

As I mentioned earlier, the communication has largely been one way, from the device to the central repository. And, the information is data, not programming instructions. Remote programming adds a significant dimension to the patient device management.

Today, patients must travel to their device manager's clinic every time their implanted device requires an update. That update could include something as simple as changing in the way that their device operates to updating the software (firmware) in their device. Remote programming makes it possible to perform all the updates remotely - in the field - that today requires a visit to the clinic. It also provides the capability for finer control over a patient's device or devices.

This implications of this patent are significant. Although there is only 1 primary claim and 32 claims total, I believe that this patent can be considered broad. How Medtronics plans to defend or profit from it is anyone's guess. Nevertheless, this patent is worth further exploration and speculation. My next post will be my first examination of the technical specifics of this patent.

Introduction

I am a telecommunications human factors professional with 20 years of experience. I started my career at AT&T Bell Laboratories and have worked at and founded a variety of cutting-edge technology companies, small and large. My graduate education has been in cognitive psychology and computer science. My doctoral dissertation blended both psychology and artificial intelligence.

I has first introduced to human factors as a graduate research associate working on a project funded by Xerox’s Palo Alto research center (PARC). A tour of PARC started me down the road of a career in human factors.

As interesting as I found intelligent systems, I found telecommunications equally fascinating – although I have no formal training in the discipline. I learned telecommunications primarily on the job, in corporate classrooms and through library research.

I first became involved with telemedicine when I was the Chief Technologist of a cutting edge wireless communications start-up company, Rosetta-Wireless. We had applied for (and won) a $2 million grant from the National Institute of Standards and Technology (NIST). We were proposing to build a system that could support client-server, telemedicine (among other applications) applications over any available wireless connection. One of our proposal reviewers was a well-known medical researcher from National Institutes of Health (NIH) who showed considerable interest in our technology. (I am not at liberty to disclose his name.) In case you were wondering, we were able to build that system. It works extremely well and has the extraordinary capabilities to support all types of client-server applications over constantly shifting and unreliable wireless communications conditions.

In this blog, I focus on the technical aspects of telemedicine including medical monitoring and remote programming. I became motivated to create this blog when I stumbled across US Patent #7,565,197, Conditional requirements for remote medical device programming, owned by Medtronics. For my first few blog entries, I shall analyze this patent and discuss what I think are its implications for the future of medicine.