Slashdot Mirror

https://www.google.com.au/sear...

https://professional.medtronic...

This, too:

http://www.medtronic.com/for-h...

a lot of opportunity for medical monitoring

Continuous blood sugar monitoring would require a supply of reagent to react with glucose and need constant refills. There are no currently known properties of dissolved blood sugar you can measure without a direct chemical reaction.

Haven't heard of a Continuous Glucose Monitoring (CGM) system? Medtronic makes one, and I suspect other manufacturers do as well. Like the first article said, I don't believe they're currently used in place of the more traditional meter but there's probably no reason they couldn't eventually be.

I have a Medtronics Nerve Stim in my chest with a wireless remote.

In my experience you have to get the handheld remote or it's antenna lead within a half inch of my skin right over the device.

http://professional.medtronic.com/products/primeadvanced-spinal-cord-neurostimulator/index.htm

I disagree; pacemakers have been capable of two-way communication for some time with the right equipment. Here's just one example: http://www.medtronic.com/for-healthcare-professionals/products-therapies/cardiac-rhythm/patient-management-carelink/medtronic-carelink-network-for-cardiac-device-patients/index.htm#tab2 And there has been a successful demonstration of a hack: http://www.nytimes.com/2008/03/12/business/12heart-web.html How long until these are automated? Who knows, but just know that they are at risk. . .

A key thing that is left out (But what most people have surmised):

    Pacemaker <--MICS Band--> Home monitoring unit (developed by pacemaker company; obtains IP address - typically via dial-up.) <--TCP/IP--> PaceMaker Companies Servers <-- TCP/IP--> Physician Web connection

The 400mhz is considered to be the MICS band - http://en.wikipedia.org/wiki/Medical_Implant_Communication_Service . The great thing about MICS is that it covers not only 'both sides' of the pond, but pretty much all sides. (E.g. Asia, Europe, and the US). The 'challenge' with 400mhz is that it's only a 'few meters' coverage. So you have to have the home monitoring unit (the unit that actually does 'connect' to the internet and the implanted device) within a 'few meters' of the device/patient.

Pacemakers are very small, compared with an ICD (defibrillator). In both cases, battery space is one of the biggest uses of the volume of the CAN. (in a defib you also have a large capacitor). The more energy you use for communication, the faster you drain the battery - and the less power you have for therapy. No one has an 'externally rechargeable' unit - so the only option is to put the patient under for surgery and replace the unit. (Low risk - BUT, there is a risk... and it's a surgery. and these things aren't cheap)

It will probably be a long time before your pacemaker signs on automatically to the local WiFi connection to 'dial home' to the physician. (Power, security, and proprietary data communication formats to name a few reasons).

One commenter early said, "pacemakers have been connected for years" - that's via "TTM" - http://www.google.com/search?q=transtelephonic+monitoring+pacemaker&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a

TTM doesn't provide very much data from the CAN. Basically and EGRAM, battery strength, and maybe a few other items. The at home monitoring unit can pull more data from the can.

The great thing about these systems are the peace of mind from monitoring the pacemaker on a daily/weekly/monthly basis versus once every 6-12 months or 'when the patient feels bad.' And when the patient does 'feel bad' the physician can pull up the latest information from the pacemaker the help determine if the patient should come in or not.

Company Websites:
St. Jude (Featured) - House Call - http://www.sjm.com/devices/device.aspx?name=housecall+plus+remote+patient+monitoring+system&location=us&type=10
Boston Scientific - http://www.aboutlatitude.com/
Medtronic - http://www.medtronic.com/physician/carelink/index.html

As a cyborg (literally, if technically) I have to wonder what such a solar electrical storm would do to implanted electronic medical devices, such as my pacemaker. Any knowledgeable insights? If this shuts down, I'm history in seconds.

Medtronic's neurostimulator (for pain treatment) lasts at least 9 years. The Japanese government sponsored the development of a rechargable pacemaker, but found that IC and manufacturing advances made devices more than 5 years old obselete. Recently, advances in data storage and wireless distance/data transfer have given new features to mature treatments.

http://www.medtronic.com/neuro/restore/noFlash.htm l

But I agree, that's probably still fairly rare.

There are many things computer science education does not teach the average student about programming. This is burdened by the fact that programming can vary significantly across areas of CS (i.e. networking vs. database implementation) and even within the same area (GUI programming on Windows vs. GUI programming on Apple computers).

When I was at GA Tech the administration prided themselves on creating students that could learn quickly about technologies thrown at them and had broad knowledge about various areas of CS. There was also more focus on learning how to program in general than specifics. This meant that there was no C++ taught in school even at the height of the language's popularity because its complexity got in the way of teaching people how to program.

Students were especially thought to learn how to think 'abstractly' which especially with the advent of Java meant not only ignoring how hardware works but also how things like memory management work as well. In the general case, one can't be faulted for doing this while teaching students. Most of my peers at the time were getting work at dotcoms doing Java servlets or similar web/database programming so learning how things like how using linked lists vs. arrays for a data structure affects the number of page faults the system makes were not things that they would really have to concern themselves with considering how things like the virtual machine and database server would be more significantly affect their application than any code they wrote.

Unfortunately for the few people who ended up working on embedded systems where failure is a life or death situation (such as at shops like Medtronic) this meant they sometimes would not have the background to work in those environments. However some would counter that the training they got in school would give them the aptitude to learn what they needed.

I believe the same applies for writing secure software. Few schools teach people how to write secure code not even simple things like why not to use C functions like gets() or strcpy(). However I've seen such people become snapped into shape when exposed to secure programming practices.

I wish this kind of tool would have been mainstream 3 years ago when I had an emergency aortic valve replacement. I wouldn't have to live with a 30+ centimeters scar on the chest (I was 18. I'll probably live more time in my life with my mechanical valve than I lived without it), and pain wouldn't have been that much of a big deal. But I guess I'm already getting used to it. It's just that my chest was not perfectly closed back, so I have a kind of small bump near the bottom of my sternum. I guess with this "robot", I wouldn't have this.