How This Blog Got Going: MRI Safe and Conditional Pacemakers, Reprise

I have decided to return to the thing that I was working on when I started this blog ... an MRI conditional pacemaker. Specifically, an MRI conditional pacemaker for St. Jude Medical. At the time I was Lead Human Engineering Clinical Systems Engineer on this project. Before I go any further I would like to distinguish between MRI conditional and MRI safe devices. It is important to distinguish between the two.

MRI Conditional v. MRI Safe

Having an MRI safe implanted cardiac device is the ideal situation. If the cardiac device is MRI safe, it means that a device patient can be "popped" into an MRI without any changes to the device. For the patient it's just like the person does not have an implanted device. The only difference is that the resulting imagery from the MRI around the device may not be as good if the person did not have an implanted device. 

An MRI conditional device presents some significant procedural challenges to all those involved. If a person has an MRI conditional device, certain conditions must be met before the device patient is allowed to enter the MRI. When I was working at St. Jude Medical, changes in the settings that operate the device are required before the patient enters the MRI. Once scanning is complete, the settings need to be changed back to their normal, operational settings.

As of publication of this article, only one medical device company has a commercially available MRI safe pacemaker, Biotronik. St. Jude Medical and Medtronic have commercially available MRI conditional devices. 

When I was work at St. Jude, the only cardiac device being engineered to permit patients to have MRI scans were pacemakers. At the time ICDs and CRTs were not considered for MRI compatibility. However, apparently, Biotronik has developed an MRI conditional ICD that is commercially available ... at least in Europe.

There are other issues regarding MRI compatibility such as whether there are limits on the area that can be scanned a cardiac device patient ... something other than a full body scan. The allowable limits on how much can be scanned are continually in flux. But this particularly issue does not have anything to with the story I want to tell.

My Experience with the MRI Conditional Project

The St. Jude Medical MRI conditional pacemaker was engineered to enable patients to undergo an MRI scan. To insure that pacemaker patients would not be harmed by the scan required that the operating settings on the pacemaker be adjusted. (To make a long story short ... a change in the setting needed to make sure that the sensing lead to heart be turned off. The pacemaker could be changed to constant pace or turned off entirely if the patient is not pacemaker dependent ... as most pacemaker patients are.)

So the major problem in this entire issue was in regards to how to change the settings on the device? Who would do it, how would it be done, what would the settings be? Essentially three basic approaches were considered:

1. Have the patient's cardiac physician or cardiac nurse go to the MRI center, lugging their device programmer with them, change the settings on the patient's device to those that are MRI compatible, wait for the scan to complete, reset the settings to normal and examine the patient to insure that the patient is OK.
2. Have the settings changed remotely. The patient is at the MRI center, the cardiac professional is in the office, at the hospital or at home. This is known as "remote programming."  At the time this was something that the FDA did not allow. Using remote programming, the patient's device communicates wireless to a pacemaker communicator located at the MRI center. The cardiac professional sees a 30 second rhythm strip before setting the patient's device to the MRI settings and sees another 30 second rhythm strip after the changes have been made. (Just like an onsite cardiac professional would do.) The patient undergoes the scan. During that time, the professional can perform other tasks. Once the scan is complete, the cardiac profession changes the pacemaker settings back to normal and sees the before and after rhythm strips. 
3. The pacemaker is programmed with two settings by the cardiac professional using the programmer. The first set of settings define the normal operation of the pacemaker. The second set are the MRI settings: that is, the settings of the pacemaker when the patient undergoes an MRI scan.  When the pacemaker patient goes to the MRI center, the MRI tech takes a wand (that's best way I can describe it.) and changes the settings from normal to MRI. Once the patient completes the MRI scan, the MRI tech uses the wand to change the patient's setting back to normal. 

I became quickly apparent that cardiac professionals had no interest in option 1. As it turned out St. Jude Medical chose the third approach. 

When the third approach was described, I had numerous objections ... mostly related to the device that would change the setting on the pacemaker. Thankfully, there have been substantial changes and upgrades made to the wand. However, I wanted to purse option 2, remote programming. And the desire to purse option 2 inspired me to start this blog ... hence the title Medical Monitoring & Remote Programming.

Wherefore Remote Programming?

Most physicians showed some hesitancy when it came to adopting remote programming. They saw it as unproven ... and they were right, it was (and so far as I know still is) unproven and still not acceptable to the FDA. However, many if not most were intrigued by the idea and thought that the technology should be pursued. Many clearly saw the potential value of the technology, the value of being able to monitor patients remotely with the potential ability to change cardiac device settings without the patient being in the office could be a revolution in patient care ... not only for people with chronic conditions like heart problems, diabetes or neurological problems that involve implanted devices, but potentially everyone. And it need not involve the need for implanted or wearable devices. We'll explore this in later postings.

Some Articles of Interest Before the 4th

I came across two long investigative articles that I thought could be of interest those in the medical products field. One article is from the National Journal and the other from Pro Publica. Here are the links to the articles with short clips.

Spinal Product Controversy Raises Red Flags on Medical Journals’ Disclosure Policies

Medical journals have long had to wrestle with the possibility that financial bias influences the work they publish, but if the growing controversy over Medtronic's Infuse spinal product is any indication, they may not be doing enough.

Comment: This is an area that should concern everyone in the field of medical devices and device research. I am very aware that companies fund a lot of empirical and academic research much of which is published in peer-reviewed and respected medical journals. On the face of it, nothing wrong with that. When I was a graduate student, some of my research was funded the research and development division of a well-known (non-medical) company. The funding had absolutely no bearing of the design of the research program, the data collected or interpretation of the data. The concern expressed in this article is whether data maybe suppressed or not reported in an unbiased fashion particularly when it comes to reporting data related to the risks. You be the judge.

How the Media Fell for McKinsey's Twisted Health Care Report

Critics of last year’s health care law pounced on what seemed like a damning new survey, but the details were a lot murkier than the headlines.

Comment: This is an interesting article well worth your time to read.


Finally, here's a short article that just came across indicating how rural health may well be the driver behind telemedicine. Here's the link to the article:


Rural Healthcare to Drive the Global Telemedicine Industry

...[C]ountries face various problems in the provision of medical services and health care, including funds, expertise, and resources. To meet this challenge, the governments and private health care providers are making use of existing resources and the benefits of modern technology. Besides, with limited medical expertise and resources, telecommunication services have the potential to provide a solution to some of these problems. As telemedicine has the potential to improve both the quality and the access to health care regardless of the geography; the rural market is driving the incessant growth of the telemedicine market.

Medtronic Remote Monitoring Study: CONNECT

At the American College of Cardiology 59th annual conference George H. Crossley, MD presented evidence that cardiac patient from remote monitoring (one scheduled in-office visit per year with remote monitoring) verses standard in-office care (four in-office visits per year) cuts the time between the time a cardiac or device related event occurs and when a treatment decision is made.

The title of the study: "The clinical evaluation of the remote notification to reduce time to clinical decision (CONNECT) Trial: The value of remote monitoring."

I present a summary of the method and the results of the study gleaned from the slides presented by Dr. Crossley at the conference.

Hypothesis

Tested hypothesis: Remote monitoring with automatic clinician notifications reduces the time from a cardiac or device event to a clinical decision.

Additionally investigated were rates utilization of the health care system including hospitalization and between treatment groups.

Method

Study participants:  1997 newly implanted CRT-D and DR-ICD patients from 136 US centers were randomly assigned to one of two groups. The first group had 1014 patients assigned to the remotely monitored group and the second had 983 patients assigned to the standard in-office care group. The patients were reasonably well matched for age and gender characteristics.  (A procedure similar to the Biotronik TRUST studies.)

The patients were followed for 12 months.  (On first reading, I found the the time relatively short in that I would not expect enough differentiating events would occur during that time.  However, on further reading, I believe my first impression was incorrect.)

Findings

Time from Event to Clinical Decision

The median time (used nonparametric inferential statistics for the analysis) from the cardiac or device event to clinical decision was 4.6 days in the remote group and 22 days in the in office group. This difference was significant.  The remote group involved 172 patient while the in-office group involved 145 patients.

The cardiac/device events included:

• Atrial Tachycardia/Fibrillation (AT/AF) for 12 hours or more
• Fast Ventricular rate. Of at least 120 beats per minute during at least a 6 hour AT/AFT event
• At least two shocks delivered in an episode
• Lead impedance out of range
• All therapies in a specific zone were exhausted for an episode
• Ventricular Fibrillation detection/therapy off
• Low battery

Total number of events Remote group: 575 and In-office group: 391.  The slides show the breakdowns.

Office Visits

The number of office visits per patient reported are shown below.

                        Scheduled     Unscheduled      All office

Remote group:     1.68              2.24              3.92

In-office group:    4.33              1.94              6.27

The TRUST studies showed a slight increase of more unscheduled visits for the remote group. However, given the nature of the study and that remotely monitored patients would receive only one in-office visit per year, it's remarkable how similar the numbers between the two groups are.

Utilization of the Health Care System

Number of incidents where patients used the health care system show virtually no difference, hospitalization or emergency room. 

However, a remarkable difference was the significant difference in length of stay when there was a hospitalization. The remote group had a mean hospital stay of 3.3 days while the in-office group was 4.0 days with an estimated savings per hospitalization of $1659.

Conclusion

The CONNECT and (Biotronik) TRUST studies show clear benefits from a number of standpoints for remote monitoring.  In addition, the CONNECT study showed clear cost and hospital resource utilization benefits from remote monitoring in that hospitalized patients had shorter stays indicating that they were in better shape than patients in the in-office group when admitted to the hospital.  Quick responses seem to lead to better outcomes as well as cost reductions.

Here is the link to Medtronic's press release of the study: http://wwwp.medtronic.com/Newsroom/NewsReleaseDetails.do?itemId=1268659150410&lang=en_US

Here is another link to an article on the study that includes a link to Dr. Crossley's slides: http://www.cmio.net/index.php?option=com_articles&view=article&id=21235:acc-remote-monitoring-shortens-event-response-time-reduces-hospital-costs

Additional resources

Reimbursement for Remote Patient Monitoring in the United States- Regulatory Antennae Picking Up Demand Signals 

Remote ICD monitoring speeds diagnosis of arrhythmias.(CARDIOVASCULAR MEDICINE)(implantable cardioverter defibrillators)(Report): An article from: Internal Medicine News

How to Hack Grandpa's ICD

I've discussed possible communications security problems with implanted devices in an earlier post.  The link below provides a link to a University of Washington study that was published in 2008 in IEEE Symposium on Security and Privacy. Here's a link to the University of Washington article. 

Researchers find implantable cardiac defibrillators may expose patients to security and privacy risks


The article includes a link to the published paper.  I suggest that you download the paper and read it. 


Although the article was published in 2008, I believe it still has relevance.  First, it references a Medtronic Carelink Home Monitoring unit that I am quite certain is still in widespread use.  Second, they reverse engineered the Medtronic unit to create their own system that could mimic the Medtronic unit.  Although I am not an electrical engineer by any stretch of the imagination, I can attest to soundness of their methods.  I have worked with a variety of engineers who have tested communications system security using similar methods.  Furthermore, I have worked with engineers who have successfully cracked harden communications systems.  Thus I shall continue to monitor developments and findings in this field because this could impact the engineering of the communications systems for remote monitoring and programming.


One of the flaws in the Medtronic unit that made reverse engineering relatively easy was that the data was not encrypted.  I do not know if currently any or all communications between home monitoring units from any device company and implanted devices is encrypted.  Encryption adds significant overhead to communications.  Thus it makes the communication between the device and a home monitoring unit significantly longer.  It can impact battery life because encrypted transmissions have more bytes to transmit.

One of the potential limitations to hacking implant radio communications is the extremely low power level of that communication. The low power levels suggest that the hacker would have to be in close proximity to the device, within three meters.  However, their article did not extensively investigate the communications distance issue or methods that might be used to get around the proximity problem.

Third, the authors also had access to a Medtronic programmer.  A study of the operations of the programmer enable the authors extend their capabilities to hack communications with the implanted device. 

The scariest part of the article is a discussion of how it would be possible to kill a person with an ICD using the device they constructed.  Here's that section of the article (edited):

Inducing fibrillation

During implantation surgery, it is common for a physician to test the newly implanted ICD to ensure that it can both sense and appropriately treat a cardiac
condition known as ventricular fibrillation (V-Fib), one of the most common kinds of heart rhythm problems. Accordingly, the ICD has several testing modes in which it can induce VFib.  Such a test — called an electrophysiological (EP) study — is normally conducted with cardiologists standing by to stop the fibrillation if the ICD fails to do so. ... [a] programmer sends the ICD a sequence of commands that ... [a] shock to be applied to the patient’s heart at a precise point in the patient’s cardiac rhythm, with the goal of inducing V-Fib. When its automatic therapies are enabled, the ICD should immediately detect and treat the fibrillation by delivering the proper therapy. ... We then used our commercial programmer to conduct an EP study ... We then replayed a recording of the EP study command sequence via our software radio. At least three of 30 replay attempts succeeded. We successfully triggered command shocks via replayed commands even after turning off all of the
ICD’s automatic therapies.
Quoted from:
Halperin, D, Heydt-Benjamin, T., Ransford, B., Clark, S., Defend, B., Morgan, W., Fu, K., Kohno, T., Maisel, W. Pacemakers and Implantable Cardiac Defibrillators:
Software Radio Attacks and Zero-Power Defenses, IEEE Symposium on Security and Privacy, 2008, pp 1-14.

Update on 29 September 2009 Posting

I have an update related to my 29 September posting, Medtronic Remote Programming Patent.I stated the following in that posting ...

I believe that Medtronic's patent ... 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. ... 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 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. ...

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. ...


I unearthed an article published in the August 2008, Journal of Computers, titled "Design Overview Of Processor Based Implantable Pacemaker" authored by Santosh Chede and Kishore Kulat both from the Department of Electronics and Computer Science Engineering at the Visvesvarayan National Institute of Technology. (I do not have an address for you to access this article, however, if you search on the journal, the title and authors, you will find it.)


Their article describes the means by which they created a pacemaker using at Texas Instrument (TI) MSP430F1611 processor to build a pacemaker.  The TI MSP430 processor (TI MSP430 Microcontroller Website) is a general purpose RISC processor similar in architecture to the DEC PDP-11.  The TI MSP430 is designed for ultra-low power consumption and targeted to battery-powered, embedded applications.  In other words, this would be the kind of processor on which to base a line of implantable medical devices.  Having looked around the website, I noted that the application of the processor included medical devices, but not implants.  However, based on the Journal of Computers article, I can see a clear route to creating implants using this processor. (I haven't yet found a comparable processor, however, I suspect the existence of one or more.  As I find additional processors in this class, I shall make them known in this blog.)


Finally, I think the important message of the Journal of Computers article is that it is possible to use a general purpose processor and software to create a pacemaker or any other implantable medical device such as a neuro-stimulator, CRT-D, or drug-pump. As I discussed earlier, using a general purpose processor and software to create the product, can be an effective business and technical strategy.  

Medtronic Patent Application: Communication system for medical devices

On May 31, 2007, the US Patent Office published the Medtronic patent application, Communication system for medical devices, Application number: 20070123955. I came across this patent application today (10/14/2009).  Here's the abstract to the patent application:

A communications device facilitates communication between a medical device and a wireless communications network and comprises a telemetry circuit configured to wirelessly communicate with one or more medical devices, and a computer network communication interface configured to wirelessly communicate directly with a wireless computer network. 


I invite my readers to go to the USPTO website, look-up the patent application, and refer to Figure 3.  You will notice that this looks remarkably like the figure that I published in this blog on 10/11/2009.  There are a few differences, first, the Medtronic communications model is less robust than the one I showed.  Second, the Medtronic model does not show a multi-channel wireless communication or opportunistic routing capability.  Third, the Medtronic model does not include a Central Server and is missing the means to manage the unreliable network-side wireless connection. The differences I discussed are disclosed in a patent application filed in June 2004.  All indications are that a patent will be issued.



The Medtronic patent application bears a remarkable resemblance to US Patent 7,149,511, Wireless Intelligent Personal Server.  The major difference is that the Medtronic patent application is directed towards a medical application whereas Patent #7,149,511 is directed towards general use.  

The communication model defined by Patent #7,149,511 was extended and turned into the model that I showed after extensive analysis and systems modeling.  The communications model shared by both Patent #7,149,511 and the Medtronic patent application showed a lack of robustness.  While the model that I drew has shown itself to be extremely robust, secure and scalable.  The software that Rosetta-Wireless developed used the communications model that I drew. 



I mention this because I was part of a research and development program geared fundamentally towards the development of a secure, sophisticated and robust communications system with capabilities to support the transport of medical communications.  I mentioned in an earlier article in this blog that the NIH was interested in our communications model and it's ability to transport data for medical applications.


I say all this because I believe I understand the purpose of this Medtronic system as proposed in the patent application.  The Medtronic patent application discloses a means for transporting data and programs bidirectionally.  Thus, it is an enabling technology for supporting remote programming.  And if you read the Medtronic application, you will note that it does in fact mention remote programming.  


I believe this application is a marker that defines the level of interest that Medtronic has in remote programming.  And that level of interest appears significant.  They have a series of patents including a significant and broad patent that clearly marks-out the intellectual boundaries of remote programming.  Now, I have come across what can only be defined as an "enabling" technology patent application that defines how data and programming could be transported over wireless.

More to come ...

Medtronic International Patent Application: Remote Programming of Implantable Medical Devices

Medtronic has an international patent application that extends Remote Programming, particularly, the capability to maintain security and safety of patients.  Before I dive into the details, the authors of this patent application make some very interesting points regarding the value of remote programming.  I'd like to quote a few items from that application.  It provides a clear argument regarding the value of remote programming.

... if the medical conditions of a patient with an implantable device warrant continuous monitoring or adjustment of the device [e. g. a pacemaker], the patient would have to stay in the hospital indefinitely. 

From personal and discussions with others, people want to live at home, not in a hospital or a nursing home.  Remote programming can be one tool that makes this possible even for people with severe, irreversible heart failure.  

Yet another condition ... requires that a patient visit a clinical center for occasional retrieval of data from the implanted device ... .  Depending on the frequency of data collection, this procedure may pose a serious difficulty and inconvenience for patients who live in rural areas or have limited mobility.  ... in the event a need arises to upgrade the software of an implantable medical device, the patient will be required to come to the clinic or hospital to have the upgrade installed.

Consider a patient who lives in the middle of the Navajo Reservation.  The Navajo Reservation (that surrounds the Hopi Reservation) lies in the northeast corner of Arizona and takes in parts of Utah and New Mexico.  To say the least, it is huge, rural and a very long way from any major metropolitan area.  It would be a significant burden for someone living in the middle of the Navajo Reservation to travel to any of the likely places where a device physician would be located.  Remote programming would be a significant help to these patients.

The essence of the patent application

The following quote summarizes the purpose of the patent application.

The present invention is directed toward providing a remote programming method for use with implantable medical device systems that helps ensure safe, secure programming of a medical device in a remote location.

The quote isn't particularly well-written, but it does convey what this patent is addressing: it's addressing the security problem.  Briefly, here's the problem, as it stands, anyone in a device clinic or for that matter, a hospital with a computer log-in who has access to a patient's records or has the ability to perform remote programming is provided with the ability to do virtually anything to the patient's device remotely.  This is a not a safe situation for the  patient and it's a potentially massive legal problem for the device managers.

Medtronic has defined a multi-layered or tiered system whereby certain people are provided with a specific level or levels of authorization.  For example, a clerical person may be granted authorization to review patient records and verify that certain scheduled changes and updates to patients' devices have been performed.  On the other hand, device physicians may be granted full authorization to see and do anything and everything. 

The security system that they propose is not unlike other security systems in the field.  Agencies in the Federal Government, National Laboratories, many companies, etc. all have authorization systems similar to the one being proposed.  The difference is that this addresses remote programming of medical devices.  

The patent application is narrow enough so that I suspect that Medtronic will likely receive an International Patent.  That's assuming that there are no patent applications in the same domain that have preceded the Medtronic application.  It does make clear Medtronic's strong interest in this area of technology.  Patient care is the future of the medical device industry and clearly, Medtronic has clearly recognized this.

Next time, I'll dive into remote programming and issues related to data communication.  I'll intersperse these posts to discuss the Achilles Heel of Remote Programming: Electrical Power.  And a way that this problem might be solved.  Say tuned.  These next posts should be interesting and informative.

Medtronic Patent 7,565,197: Migrating Instructions Among Implants (Updated 6 Apr 2015)

An intriguing but not fully explained claim in this patent is claim number 29.  It is a double-dependent claim in that it depends on two previous claims (claims 1 and 25); nevertheless, it describes a means for migrating instructions or data from one implanted device to another.  Here's the claim ...

The method of claim 25 wherein the remote medical device is an implantable medical device and
transmitting the remote programming instructions comprises transmitting the data to a remote external medical device capable of communicating with the implantable medical device and further transmitting the remote programming instructions from the external medical device to the implantable medical device, the remote external medical device receiving the updated state token value whenever the implantable medical device and the external medical device are in communication.

Here's how I read the meaning of this claim.

• There are by implication two external medical devices. One is implanted ... and there could be multiple implanted devices ... and the other is external to the central data system. This could be the patient's bedside wireless communication device, it could be a laptop computer, an iPhone, etc. Conceivably, it could be an Apple Watch. The central data system is in communication with the external device and the external device is in communication with the implanted device. See http://medicalremoteprogramming.blogspot.com/2015/03/internet-of-things-from-connected.html for more details on the means for communications. What is described is a mediated connection with the implanted medical device.
• A patient could have two or more implanted devices both of whom are in communication with a single external device.
• The implanted devices operate more or less independently from each other, however, they could be working as part of a therapeutic system to address a single problem or a particular class of problems, e. g., cardiac or neurological.
• For those not familiar with implanted medical devices, they have both sensing and stimulation capabilities.  The stimulation is most effectively delivered when the conditions are right ... as sensed by the sensors and computed by implant's internal processor.
• If implanted devices are working semi-autonomously, there may be a need for one implanted device to send its data to another device to which it is logically connected.  
• If two or more implanted devices are going to work as a system, they must have the capability to transmit data to each other and/or have the capability to transmit to an external device that will in turn relay the information to the other devices or would act as a central manager, take the data produced by the implanted device, perform it's own calculations and then send instructions to all the implanted devices.
  
• I believe this claim describes fundamentally both methods for managing two or more implanted devices working to deliver systematic and multi-faceted therapy to address a single medical problem.

I am most familiar with cardiac devices and I cannot think of a reason to have more than one device implanted to manage any heart problem.  The heart is nicely contained and localized.  However, the nervous system is well distributed and it would be reasonable to consider having multiple devices collaborating to deliver a particular therapy or set of therapies. 

I certainly can see a cardiac patient requiring an insulin infusion pump. I suspect that there are many people living today who have both implanted devices. 
 

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'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.