This just came to my attention. Here's the link: https://www.washingtonpost.com/world/2020/03/01/coronavirus-live-updates/
I expect that this article will be periodically updated.
I expect that this article will be periodically updated.
Showing posts with label Communications. Show all posts
Showing posts with label Communications. Show all posts
Sunday, March 1, 2020
Tuesday, July 24, 2018
Adhesives: Part of the Future for the Remote Monitoring Sensors?
I just ran across this article a few minutes ago. It's a serious article published in Machine Design. Here's the link: http://www.machinedesign.com/mechanical/adhesives-enabling-future-wearable-medical-devices?NL=MD-005&Issue=MD-005_20180724_MD-005_524&sfvc4enews=42&cl=article_1_b&utm_rid=CPG05000003255032&utm_campaign=18775&utm_medium=email&elq2=5b76b40ea8f44d76b2b883c5c09f23fe
It's an extremely readable article and what's being described has in my opinion real applicability in the future of medical sensors. Adhesive, "band-aid" or strip sensors development applies to both the fitness set as well as to remotely monitored patients.
Transmitting data to monitoring systems and people will likely require an intermediate device such as a smart phone. I suspect that the real issues and hurdles will likely revolve around digital communications issues and standardization. Having worked most of my life in the communications domain, communications issues can be successfully overcome.
Here are a few quotes from the article:
It's an extremely readable article and what's being described has in my opinion real applicability in the future of medical sensors. Adhesive, "band-aid" or strip sensors development applies to both the fitness set as well as to remotely monitored patients.
Transmitting data to monitoring systems and people will likely require an intermediate device such as a smart phone. I suspect that the real issues and hurdles will likely revolve around digital communications issues and standardization. Having worked most of my life in the communications domain, communications issues can be successfully overcome.
Here are a few quotes from the article:
Device manufacturers are taking steps to create medical devices that are smaller, lighter, and less invasive. Whether they’re adhering device components together or sticking a device to skin, adhesives are uniquely bonded to a device’s success.
Both consumers and patients want wearable devices to be smaller, lighter and less cumbersome to use for seamless integration into their everyday lives. The design process can get challenging when devices must maintain accurate sensing capabilities, but also reduce friction to ensure precise data collection. Adhesives can help to keep friction to a minimum by being breathable and maintaining a low profile. In addition, options with flex electronics, as well as addressing battery implications and electromagnetic interference, provide opportunities for advancement.
Adhesive wear time is a crucial consideration when designing a wearable device, impacting overall resilience and durability, as well as how often the user will need to change their device.
______________
I should mention that by the looks of things, it appears to me that 3M maybe behind the article. Nevertheless, I think that considering adhesives in the research, design and development process of a bio-sensor is worth your time.
Tuesday, March 24, 2015
Benefits of Remote Monitoring & Mayo Clinic Announcement
I've been arguing for some time that remote monitoring can not only lower medical costs, but it show itself to be of benefit to the patient as well. Here's an article that not only shows that remote monitoring can be of benefit to the patient, but to the physician as well.
Remote monitoring can not only provide better and more data ... that can lead to better analysis and conclusions. It can provide that data to the physician before the patient comes in for a visit. Furthermore, if an adverse medical event occurs, that data is captured and available to the attending health care providers. Admittedly the patient would have needed to have been wearing the monitoring device at the time, but if the person was wearing the monitoring device that information would be available.
Here's the link to the article: http://www.healthcareitnews.com/news/remote-patient-monitoring-steps-toward-new-era
Here are a few quotes from the article that I found interesting ...
... if you spend $100 a month to monitor patients remotely – over a year it would cost much less then what you would pay if they have to come back to the hospital.
Remote monitoring can not only provide better and more data ... that can lead to better analysis and conclusions. It can provide that data to the physician before the patient comes in for a visit. Furthermore, if an adverse medical event occurs, that data is captured and available to the attending health care providers. Admittedly the patient would have needed to have been wearing the monitoring device at the time, but if the person was wearing the monitoring device that information would be available.
Here's the link to the article: http://www.healthcareitnews.com/news/remote-patient-monitoring-steps-toward-new-era
Here are a few quotes from the article that I found interesting ...
... if you spend $100 a month to monitor patients remotely – over a year it would cost much less then what you would pay if they have to come back to the hospital.
[T]here are two waves of activity. The more traditional top down wave extends the reach of hospitals with FDA approved medical devices that are deployed out in the home by providers by doctors to keep track of these patients.
There is also an increasing consumer wave where people are going out and buying the sensors and devices on their own and tracking their fitness and health and bringing that information to their healthcare providers.
=== I find this quote interesting in light of the Apple Watch and other similar devices ======
Some physicians, Kleinberg asserted, don’t need and don’t want that data from the patient and claim that they don't have a place to put the data and they don't have time to look at it.
=== Actually, machines can monitor this data on a continual basis. The machines can alert physicians as needed and provide summaries. Physicians need not review raw data. ======
"There's a push back to this consumer-up bottom-up wave. But over time I think we're going to see that the sensors and the data that’s coming from these devices is going to have more and more value and providers are going to put more faith in it," said Kleinberg. "They're going to look at it and make some sense of it and part of the way they are going to do that is if they have more confidence about that data."
=== I think the last sentence may be one of the most significant in the article. Confidence in the data and automated analysis will build and become mainstream. And I think that cost considerations will be a factor. =====
Announcement Title: Mayo Clinic To Develop Wireless Sensors To Treat Obesity
I found this quite interesting when I came across it. The sensors are far from being developed but I thought it worth posting the announcement link.
Here's the link to the announcement: http://www.healthitoutcomes.com/doc/mayo-clinic-develop-wireless-sensors-treat-obesity-0001
Here's a quote from the announcement.
The goal is to produce the first wearable patch sensor – the size of a bandage – that is wireless, disposable, and can remotely monitor patient movements via smartphone. This new technology would simplify tracking with greater accuracy of patients and clinical trial subjects for whom a certain level of activity is prescribed to achieve their goals.
Tuesday, June 28, 2011
Hacking Grandpa's ICD: Why do it?
Background
I am part of another professional discussion group with an interest in Medical Data, System and Device security. One of the topics was whether medical devices are a likely target for cyber-attacks. I made a contribution to the discussion and stated that I believed that although unlikely, I thought that medical devices will eventually be targets of cyber-attacks. But putting data security measures into medical devices is at odds with the directions that the medical device industry wants to take its product lines. The trends are for smaller and less power-hungry devices. Adding data security measures could increase power demands, increase battery sizes and thus increase device size. Nevertheless, I believe that starting the process of putting data security measures into the medical devices has merit.
I received a well-reasoned response that hacking medical devices was highly unlikely and research funding on security measures for medical devices would be money best spent elsewhere. That response started a thought process to develop a threat scenario to address his points.
I reviewed my earlier article on "hacking medical devices," http://medicalremoteprogramming.blogspot.com/2010/04/how-to-hack-grandpas-icd-reprise.html. I revisited the paragraph in my regarding the motivation for hacking a medical device, an extortion scheme.
When I wrote that article, I did not have any particular scheme in mind. It was speculation based more on current trends. Furthermore, I did not other motivations as particularly viable - data theft, not much money or value in stealing someone's implant data or killing a specific person, there are easier ways to do this although it might make a good murder mystery.
I did come up with a scenario, and when I did, it was chilling.
The Threat Scenario
First, as I had previously suggested, the motivation for hacking medical devices would be extortion. The target of the extortion would be the medical device companies. Before getting into the specifics of the extortion scenario requires that you understand some of the technologies and devices involved.
The base station need not be at a permanent location, but could be a mobile device (such as with the Biotronik Home Monitoring system). The base station in turn communicates with a large enterprise server system operated by the medical device company.
The two systems communicate use wireless or radio communication. For example, St. Jude Medical uses the MICS band - a band designed by the FCC for medical devices in the range of 400Mhz. To insure that battery usage for communications is minimal, the maximum effective range between is stated as 3 meters. (However, I have seen a clear connection established at greater 3 meters.)
In general, the implant sends telemetry data collected it has collected to the base station. The base station sends operating parameters to the implant. Changing the operating parameters of the medical device is know as reprogramming the device and define how the implant operates and the way the implant exerts control over the organ to which it is connected.
Device Dialogue of Interest to Hackers
As you probably have guessed, the dialogue of interest to those with criminal intent is the one between the base station and the device. The "trick" is to build a device that looks like a legitimate base station to the medical device. This means that the bogus device will have to authenticate itself with the medical device, transmit and receive signals that the device can interpret. In an earlier article (http://medicalremoteprogramming.blogspot.com/2010/03/how-to-hack-grandpas-icd.html), I discussed an IEEE article (http://uwnews.org/relatedcontent/2008/March/rc_parentID40358_thisID40398.pdf**) where the authors had constructed a device that performed a successful spoofing attack on a wireless Medtronic ICD. So, based on the article, we know it can be done. However, based on the IEEE article, we know that it was done at distance of 5 cm. This was aptly pointed out in a comment on my "How to Hack Grandpa's ICD" article.
Could a Spoofing/Reprogramming Attack be Successful from Greater than 5 cm or Greater than 3 meters?
I believe the answer to the question posed above is "yes." Consider the following lines of reasoning ...
Attack Motivations
Extortion: Earlier I mentioned that in an other article, I suggested that the motivation would be extortion: money, and lots of it. I think the demands would likely be in the millions of US dollars.
In this scenario, the criminal organization would contact the medical device companies and threaten to attack their medical device patients. The criminal organization might send device designs to substantiate their claims of the ability to injure or kill device patients and/or send the targeted company with news reports sudden unexplained changes in medical devices that have caused injuries or deaths in device patients.
Market Manipulation: Another strategy would be as a means to manipulate the stock prices of medical device companies - through short-selling the stock. In this scenario the criminal organization will create a few base station spoofing/reprogramming systems. Market manipulation such as placing the value of the stock at risk could be a part of the extortion scheme.
Book of Interest: Hacking Wall Street: Attacks And Countermeasures (Volume 2)
In another article I'll discuss how someone might undertake an attack.
** 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.
I am part of another professional discussion group with an interest in Medical Data, System and Device security. One of the topics was whether medical devices are a likely target for cyber-attacks. I made a contribution to the discussion and stated that I believed that although unlikely, I thought that medical devices will eventually be targets of cyber-attacks. But putting data security measures into medical devices is at odds with the directions that the medical device industry wants to take its product lines. The trends are for smaller and less power-hungry devices. Adding data security measures could increase power demands, increase battery sizes and thus increase device size. Nevertheless, I believe that starting the process of putting data security measures into the medical devices has merit.
I received a well-reasoned response that hacking medical devices was highly unlikely and research funding on security measures for medical devices would be money best spent elsewhere. That response started a thought process to develop a threat scenario to address his points.
I reviewed my earlier article on "hacking medical devices," http://medicalremoteprogramming.blogspot.com/2010/04/how-to-hack-grandpas-icd-reprise.html. I revisited the paragraph in my regarding the motivation for hacking a medical device, an extortion scheme.
When I wrote that article, I did not have any particular scheme in mind. It was speculation based more on current trends. Furthermore, I did not other motivations as particularly viable - data theft, not much money or value in stealing someone's implant data or killing a specific person, there are easier ways to do this although it might make a good murder mystery.
I did come up with a scenario, and when I did, it was chilling.
The Threat Scenario
First, as I had previously suggested, the motivation for hacking medical devices would be extortion. The target of the extortion would be the medical device companies. Before getting into the specifics of the extortion scenario requires that you understand some of the technologies and devices involved.
The wireless communications of interest occurs between a "base station" and a wirelessly enabled implanted device as shown in the figure below.
The base station need not be at a permanent location, but could be a mobile device (such as with the Biotronik Home Monitoring system). The base station in turn communicates with a large enterprise server system operated by the medical device company.
The two systems communicate use wireless or radio communication. For example, St. Jude Medical uses the MICS band - a band designed by the FCC for medical devices in the range of 400Mhz. To insure that battery usage for communications is minimal, the maximum effective range between is stated as 3 meters. (However, I have seen a clear connection established at greater 3 meters.)
In general, the implant sends telemetry data collected it has collected to the base station. The base station sends operating parameters to the implant. Changing the operating parameters of the medical device is know as reprogramming the device and define how the implant operates and the way the implant exerts control over the organ to which it is connected.
Device Dialogue of Interest to Hackers
As you probably have guessed, the dialogue of interest to those with criminal intent is the one between the base station and the device. The "trick" is to build a device that looks like a legitimate base station to the medical device. This means that the bogus device will have to authenticate itself with the medical device, transmit and receive signals that the device can interpret. In an earlier article (http://medicalremoteprogramming.blogspot.com/2010/03/how-to-hack-grandpas-icd.html), I discussed an IEEE article (http://uwnews.org/relatedcontent/2008/March/rc_parentID40358_thisID40398.pdf**) where the authors had constructed a device that performed a successful spoofing attack on a wireless Medtronic ICD. So, based on the article, we know it can be done. However, based on the IEEE article, we know that it was done at distance of 5 cm. This was aptly pointed out in a comment on my "How to Hack Grandpa's ICD" article.
Could a Spoofing/Reprogramming Attack be Successful from Greater than 5 cm or Greater than 3 meters?
I believe the answer to the question posed above is "yes." Consider the following lines of reasoning ...
- As I had mentioned earlier, I know that base stations and medical devices communicate at distances of 3 meters and can communicates greater distances. The limitation is power. Another limitation is the quality of the antenna in the base station. The communication distance could be increased with improvements in the antenna and received signal amplification.
- The spoofing/reprogramming attack device could be constructed to transmit at significantly greater power levels than current base station. (Remember, this is something built by a criminal enterprise. They need not abide by rules set by the FCC.) Furthermore, a limited number, maybe as few as one or two, of these systems need be constructed. I shall explain why later.
- A base station can be reverse-engineered. Base stations can be easily obtained by a variety of means. Medical devices can be stolen from hospitals. Documentation about the communication between the medical device and the base station can be obtained.
Attack Motivations
Extortion: Earlier I mentioned that in an other article, I suggested that the motivation would be extortion: money, and lots of it. I think the demands would likely be in the millions of US dollars.
In this scenario, the criminal organization would contact the medical device companies and threaten to attack their medical device patients. The criminal organization might send device designs to substantiate their claims of the ability to injure or kill device patients and/or send the targeted company with news reports sudden unexplained changes in medical devices that have caused injuries or deaths in device patients.
Market Manipulation: Another strategy would be as a means to manipulate the stock prices of medical device companies - through short-selling the stock. In this scenario the criminal organization will create a few base station spoofing/reprogramming systems. Market manipulation such as placing the value of the stock at risk could be a part of the extortion scheme.
Book of Interest: Hacking Wall Street: Attacks And Countermeasures (Volume 2)
In another article I'll discuss how someone might undertake an attack.
** 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.
Friday, April 9, 2010
Remote Monitoring/Programming and Diabetes Management
Diabetes management is a personal area of concern for me. No, I'm not diabetic. However, my late mother-in-law was. She had Type II diabetes; however, she was not overweight. She died of a sudden cardiac arrest that was a direct result of her diabetes. Although she did a great deal to manage her diabetes, her insulin would swing widely. Those wide swings damaged her heart muscles leading to a cardiac arrest. I can't help but believe if remote monitoring had been available to her, that she should would be alive today.
In the past my primary topical area has been cardiac rhythm management. I plan to broaden my focus. Diabetes management using remote monitoring and even remote programming will be a topical area of increasing focus in this blog. In later weeks I plan to branch out into COPD.
For those of you who have domain expertise in diabetes management and COPD, I would appreciate your comments. You can make your comments in the comment area of this blog or email them to me. Whatever way you feel the most comfortable.
To get things started, I have three links that I would like share. The first link is a blog article titled, "Finding patterns in diabetes treatment may be key for telemedicine." The article is a brief discussion about a presentation by Dr. David Klonoff of Mills-Peninsula Health Center and UC San Francisco. His focus was on Type I diabetics, however, I believe what he discussed has significant implications for Type II diabetics as well. Dr. Klonoff's interest is technology "...for automatic measurement of blood glucose, automatic dose calculation, and automatic insulin delivery." From the article ...
The article is a discussion of a need for a means for non-invasive monitoring of glucose levels. The capability of having a non-invasive means of monitoring glucose levels would go a long ways towards supporting automatic, remote monitoring of glucose levels. This could be an extension of the body area networks work (BANs). So if anyone has any ideas in this area, apparently this is a wide open area for invention.
Finally, I want to provide a link to a brief report by the Whittier Institute of Diabetes. The report is undated, but a brief review of the document's properties indicated that it was created in 2004. It's not as recent as I would like, however, I believe that it's findings are relevant. In summary, it showed that even relatively crude means for monitoring diabetes could lead to some positive outcomes at relatively low cost.
In the past my primary topical area has been cardiac rhythm management. I plan to broaden my focus. Diabetes management using remote monitoring and even remote programming will be a topical area of increasing focus in this blog. In later weeks I plan to branch out into COPD.
For those of you who have domain expertise in diabetes management and COPD, I would appreciate your comments. You can make your comments in the comment area of this blog or email them to me. Whatever way you feel the most comfortable.
To get things started, I have three links that I would like share. The first link is a blog article titled, "Finding patterns in diabetes treatment may be key for telemedicine." The article is a brief discussion about a presentation by Dr. David Klonoff of Mills-Peninsula Health Center and UC San Francisco. His focus was on Type I diabetics, however, I believe what he discussed has significant implications for Type II diabetics as well. Dr. Klonoff's interest is technology "...for automatic measurement of blood glucose, automatic dose calculation, and automatic insulin delivery." From the article ...
For this ideal scenario to develop, five technologies need to be solved, and Klonoff sees printed electronics being used in every one:In the quotation above, there are several links. The one of greatest interest to me and to this forum, is the "non-invasive" link. This will link you to an article titled, "The Search for Noninvasive Glucose Technology That Works: Where It Stands Now".
- Self-monitoring of blood glucose
- Continuous (and ultimately non-invasive) monitoring of blood glucose
- Alternate routes for delivering insulin rather than needles, such as micro-needles. (Klonoff referred to work being done at UC Berkeley; I saw some demonstrated at the University College Cork/Ireland (PDF poster here) although using traditional semiconductors, not printed electronics.)
- Artificial pancreas
- Telemedicine
The article is a discussion of a need for a means for non-invasive monitoring of glucose levels. The capability of having a non-invasive means of monitoring glucose levels would go a long ways towards supporting automatic, remote monitoring of glucose levels. This could be an extension of the body area networks work (BANs). So if anyone has any ideas in this area, apparently this is a wide open area for invention.
Finally, I want to provide a link to a brief report by the Whittier Institute of Diabetes. The report is undated, but a brief review of the document's properties indicated that it was created in 2004. It's not as recent as I would like, however, I believe that it's findings are relevant. In summary, it showed that even relatively crude means for monitoring diabetes could lead to some positive outcomes at relatively low cost.
Tuesday, March 30, 2010
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.
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.
Wednesday, March 24, 2010
Overcoming the Power Connudrum
I have written about the power consumption issue in earlier articles. I now include a link to another article that discusses further positive developments in towards solving the power requirements problem inherent in remote patient care. Here's the link to the article: Breakthroughs with Sensing in the Human Body By Dr Peter Harrop, Chairman, IDTechEx
The article discusses the following developments towards solving the power problem. The two fundamental areas are:
I shall continue to publish further developments in this area.
The article discusses the following developments towards solving the power problem. The two fundamental areas are:
- Advancements in reducing the levels of power required for body sensor nets.
- Methods for harvesting power: either from the wearer or from the environment.
I shall continue to publish further developments in this area.
Thursday, December 17, 2009
Wireless Telehealth Needs Standards and Inter-operability
I am providing the link to an article in MobiHealthNews with little commentary. The article can be found at: http://mobihealthnews.com/5797/nhs-wireless-health-needs-standards-interoperability/. My one comment is that it appears that his objectives for tele-medicine are similar to my own: provide medical care that keeps patients out of hospital and nursing homes.
The article is an interview with George MacGinnis who is with the Assistive Technology Programme at the NHS Connecting for Health in the UK. He was interviewed by MobiHealthNews at the Mobile Healthcare Industry Summit in London. I think it is well worth taking the time to read this interview. In addition, MobiHealthNews has included a video of the interview.
The article is an interview with George MacGinnis who is with the Assistive Technology Programme at the NHS Connecting for Health in the UK. He was interviewed by MobiHealthNews at the Mobile Healthcare Industry Summit in London. I think it is well worth taking the time to read this interview. In addition, MobiHealthNews has included a video of the interview.
Sunday, October 11, 2009
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.
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.
Subscribe to:
Posts (Atom)