Near Future: Remote Monitoring and Programming

This article will focus on a system of remote medical monitoring and remote programming as shown in the figure below.

I've discussed elements of this design in earlier posts, so I'll not go into detail about things that I have already covered.  This is particularly true with respect to the communications model wherein that involved a mobile and a central server.  The model I show in the figure is more "ready" for commercial deployment in that there multiple, redundant Central Servers in multiple locations.  This is in keeping with telecommunications philosophy for achieving near perfect connectivity through the backbone systems.

Another addition is that of WiMax (802.16 standard, for more information: WiMax Wikipedia) that is now being commercially deployed. This adds another viable data channel from which to send data.  As I mentioned before, the system that we developed was able to move traffic over one or all channels simultaneously, and traffic can be rerouted based on additional channel acquisition or loss. 

The important elements of this design for this discussion are at the ends.  Let's begin at the bottom of the diagram.  A patient could be implanted with multiple devices from multiple manufacturers.  In the diagram I show an insulin pump from Medtronic (http://www.medtronic.com/our-therapies/diabetes-management/index.htm), an ICD from St. Jude Medical (http://www.sjmprofessional.com/Products/US/ICD-Systems/Current-RF-ICD.aspx) and a pacemaker from Boston Scientific (http://www.bostonscientific.com/Device.bsci?page=HCP_Overview&navRelId=1000.1003&method=DevDetailHCP&id=10103841&pageDisclaimer=Disclaimer.ProductPage).  We could include devices from Biotronik (http://www.biotronik.com/portal/home) as well.  The mobile server in the diagram can communicate with all the devices and address and communicate with them individually.  (We have already proven this technology.)  We would assume that the data traffic from the devices would be bidirectional and that delivery is guaranteed and secure across the connection, to and from the analysis and device servers.

Without going into substantial detail, each device has a specific and separate device managing process running on the mobile server.  Using a "plug-in" architecture, each process communicates with the multi-layered, distributed system that moves data across the network.  Each device has a continuous, virtual connection with its counterpart Analysis and Device Management server to support both remote monitoring and remote programming.

The digital plaster (or plastic strips) would generate various types of monitoring data as shown in the diagram.  A single, multi-threaded process could manage any number of strips.  

It would be conceivable for the device managing processes to subscribe to any of the digital plaster processes and send the collected data from the patients to any or all of the Analysis and Device Management Servers. The digital plaster strips could collect data from any number of locations and a variety of types of data.  This would reduce the need for building the monitoring capabilities inside of the devices and conceivably provide the kind of the data the device could never provide.  

This system is primarily software-defined and is highly flexible and extensible. Furthermore, it provides the flexibility to incorporate a wide variety of current and future monitoring systems.  I'll continue to update this model as I find more products and technologies to include.