New Communication Model for Medical Devices, Continued

I came across an IEEE journal article published in 2008 by two Welch Allyn research engineers.  The article has enough relevance to the topical area of my blog that I plan to devote at least one article to discuss it's contents.  The article addresses wireless communications and specifically, medical-grade wireless networks and issues surrounding their deployment.

I mention the IEEE article because having a reliable connection is a major concern to anyone who would implement a medical application that uses remote programming. Remote programming would involve downloading new instructions, new software or software patches to a device.  That download must be performed safely, securely and without error.  Furthermore, entire connection system would have to be extremely tolerant of errors and connection breaks.  In that vein, I discuss the Rosetta-Wireless connection model in more detail with special emphasis on how the model provides a reliable, logically stable and secure connection with significant throughput.  This is a continuation of the article titled "New Communications Model for Medical Devices" that I published 11 October 2009.  It is also a continuation of the article that I published on 14 October 2009," Medtronic Patent Application: Communication system for medical devices ."

I provide a slightly revised drawing of the connection model below.  (You should see a larger drawing in another window/tab if you click on the drawing). 

 

The area of interest of this discussion is defined by the curly-brace on the right. It is the communications path between the mobile server and the central server. As I had mentioned in my previous post the Central and Mobile Servers are logically identical; i.e., whatever data is on the Central Server will migrate to the Mobile Server and vice versa. So, if a file appears on the CS, it will be mirrored to the PS automatically. Furthermore, since the two servers are logical twins, they continue to maintain a logical connection with each other even when disconnected.

From a security standpoint, all transmissions are encrypted, all data on the mobile server is encrypted and the two system authenticate each other using a shared secret. The data on a Mobile Server is managed by a secure, centralized authority, thus if the Mobile Server is ever stolen, once that stolen Mobile Server contacts a Central Server, the Central Server will send a signal to erase it's data and terminate its operation. This is important because should anyone consider such a model as this for the transfer of medical data, the data and any device that manages that data in the field will have to be secured.

Wireless networks are inherently unreliable, they rely on radio technology with all it's physical instabilities to provide a connection.  Anything moving adds instability by continually moving in and out of coverage. The TCP/IP protocol was not designed to handle communications where there are frequent breaks and re-connections.  The protocol was designed for an “always connected” state.  Furthermore, the endpoints of the communications link – the service provider (server) or the user's equipment (client) – have been designed to “expect” an “always connected state as well.  Neither the network, appliances, user devices or users are designed to handle frequent communication breaks.

The crux of this model and the point of this article is to describe a means for transforming an intermittent and unreliable wireless connection environment into a reliable one. It does this in two ways.

First, the Mobile Server has the capability of utilizing more than one connection simultaneously (opportunistic routing).  If two or three connections are available, data can be send over all the connections simultaneously.  Should a connection suddenly drop, the system reconfigures itself and starts moving data over the remaining channels.  For example, the Mobile Server could have connections both with WiFi and 3G.  The WiFi connection could suddenly drop, but the data would be routed over the 3G connection, seamlessly and without interruption.  Thus the system is able to use connection redundancy in an effective manner and without the need to suddenly switch to an available  wireless connection once that wireless connection drops.  Since it can connect to an infinite number of wireless connections (the software is capable of doing this.  There are no limits on the number of simultaneous connections.), all the software does is move the traffic to the active connection(s). 

Second, the two servers, Mobile and Central, continually maintain a stable connection between each other.  Should their be a connection break, each server preserves the state of the data transfer (in the case of a file - a data or software file - with a known end point) or the state of the session should the transfer be a streaming connection (such as video or voice).  Should all connections drop, when the Mobile and Central Server reconnect, they authenticate each other and restart the transfer of data. 

(One aspect of the system related to its reliability is the capability of the Mobile Server to connect to a variety of Central Servers thus increasing system reliability by providing multiple connection paths to the System Service Provider Servers.)

Finally, it's time to describe the value of the model I've described to the endpoints.  The System Service Provider Servers (or Enterprise Server) is provided a stable, hardwired connection.  The applications running on the System Service Provider Servers are not required to handle any connection problems.  Adding the code to handle intermittent connections just adds to their complexity.  The engineers developing services, particularly those based on remote programming, can be assured that the transfer of data between the System Service Provider Servers and the Mobile Server is reliable and assured.

Once the necessary data or software reaches the Mobile Server, the Mobile Server connects in the usual manner to manage uploads, downloads and messages with a patient's device or devices.  (A discussion for a later article.)

Biotronik (http://www.biotronik.com/portal/home) has just introduced a new Home Monitoring system.  Their Home Monitoring system uses a wearable device monitor/wireless communications device similar to the Mobile Server I have described.  Their Home Monitoring Device appears to be tasked only for remote monitoring, not remote programming.  Biotronik bears watching.

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

Savings from Telehealth

http://www.cataractoutsourcing.com/healthcare-it/telehealth-save-billions/

Supporting data to indicate that telehealth has both medical and financial benefits. Remote monitoring and programming are some of the technologies that support telehealth systems.

New Communications Model for Medical Devices

I was the Chief Technologist for Rosetta-Wireless, a high-technology start-up company that won a $2 million Advanced Technology grant from the National Institute of Standards and Technology (NIST).  I was the primary author of the technology grant proposal, the systems architect and the principal investigator on the project.  With the intelligence, talents and hard-work of a highly talented group of telecommunications and computer software engineers, we created a software system that with minor modifications could support the system pictured below.  In this post, I describe the fundamental capabilities of this system depicted.  (I have no concerns about describing this system, it's patent protected.)  In later posts, I'll go into greater detail how this system could be the best means to support bi-directional communications with implanted medical devices.

Let's begin at the top of the drawing.  The top portion of the diagram shows a basic configuration that allows device clinics to access patient data from a repository (Remote Programming & Data Monitoring Servers) managed by the device manufacturer.  The device clinics access the repository over a web connection.  From their browser they can manage the patient data collected on the device company's computerized repository.  Currently, device clinics can only monitor patients.  Remote programming would allow patients' devices to be managed through this same user interface. 

The important part of this diagram is the communications model between the patient's device and the company's server system.  Beyond the company's firewall is a system called the "Central Server."  It has a reliable, high speed connection from itself to the company's server system.  The Central Server has a logical "twin," the "Mobile Monitoring Server."  It is a logical twin in the sense that when ever something is sent to one server, that server mirrors whatever it is to the other server.


The Mobile Monitoring Server is a mobile computer system similar to an iPhone.  It is intended to be with the patient at all times.  It communicates with a Central Server (and can communicate only with a Central Server thus providing exceptional security and reliability) over any available wireless connection.  It uses a system that we call "Opportunistic Routing to communicate over a diversity of wireless channels.  It can communicate with the Central Server over one or more channels simultaneously.  The Mobile Monitoring Server is also responsible for managing the wireless connection.  The system is designed to seamlessly communicate data bi-directionally over an unreliable data communications network without losing a single bit of information and it has the ability to send large amounts of data over wireless connections reliably, and without error.  And it works.  


Furthermore, the Central Server provides a stable connection to the company's server system.  This would be crucial to remote programming to insure that once a set of instructions or new software is sent, destined for the patient's implanted device, that it get's there, guaranteed.  And even if there's a break in the wireless connection, it will still get to it's destination.


The Mobile Monitoring Server connects to the implanted device (I show a St. Jude Pacemaker model that currently uses this wireless communications channel) using an FCC designated channel calls MICS. (I'll leave it to you to research.)  MICS operates in the low 400 Mhz range and has substantial limits on the level of power that can be used for transmission.  Both the frequency and the power levels insures that the implanted device cannot communicate directly with either WiFi or 3G.  Furthermore, medical devices can use only limited power for communications.  Their batteries are small and the battery life is calculated in years. 


Many of my next posts will cover specific scenarios related to remote programming and how they would communicate over this communications model.  I'll probably do some gloating and describe why this is a superior model to all others.  


However, even with relatively low power consumption, remote programming faces a problem, one that might be it's Achilles heel.  That's the problem of power and having enough of it.  When I was with Rosetta-Wireless, power was the major problem that we had to face.  There have been significant improvements in battery technology and the development of low power processors, etc.  But, as far as I can tell, the problem for remote programming does not lie with the Mobile Device, it lies with the implanted device.  The amounts and frequency of data communication required for a full-fledged remote programming system to be effective is extremely large.  Many megabytes, possibly gigabytes of data and software would be transferred to the implanted device.  This will require significant amounts of power.  However, I have come across a new company that I think may provide a significant breakthrough with the ability to harvest electrical power from the person with the implanted device.  Stay tuned.

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