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.