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.
Tuesday, March 30, 2010
Know What Thy User Does and Where They Do It
Review ...
Last time, I discussed the importance of knowing your target population and their use environment. That first step identifies and specifies the population for inclusion. It is the means for including who should be included and excluded, and the environment where they work. For example, a targeted population for a particularly medical product could be surgical nurses who work in hospitals. The target population does not include all nurses or even all surgical nurses. In addition, the use environment in which the targeted population performs their work needs to be a part of the definitional equation.
Thus, the first step in the design process is defining the properties of the target population, determining who is and who is not part of that population. And include a complete description of their working environment, the environment where the product or service will be used. Field research will be necessary to establish the target population and its characteristics and the work environment. When this step is finished, the next step is perform additional research to establish the details of the work of interest and the environment in which it performed. (The means for collecting this information and form of the analytic product will be discussed in a later article.)
Know What Thy User Does and Where They Do It
Last time, I discussed the importance of knowing your target population and their use environment. That first step identifies and specifies the population for inclusion. It is the means for including who should be included and excluded, and the environment where they work. For example, a targeted population for a particularly medical product could be surgical nurses who work in hospitals. The target population does not include all nurses or even all surgical nurses. In addition, the use environment in which the targeted population performs their work needs to be a part of the definitional equation.
Thus, the first step in the design process is defining the properties of the target population, determining who is and who is not part of that population. And include a complete description of their working environment, the environment where the product or service will be used. Field research will be necessary to establish the target population and its characteristics and the work environment. When this step is finished, the next step is perform additional research to establish the details of the work of interest and the environment in which it performed. (The means for collecting this information and form of the analytic product will be discussed in a later article.)
Know What Thy User Does and Where They Do It
Knowing what the user does consists of documenting the tasks that the target user population would perform with the product or service that a company plans to provide.
Once the product or service has been conceptually defined, the following information from the target population must collected:
The preconditions that lead to performing each task,
The steps required to perform a task, and
How frequently each is performed (in absolute terms and in relationship to other tasks.
The information collected focus on the actions performed by a user localized to the product or service in development. The data would have little or no reference to the use environment – the full set of activities and environmental conditions wherein this product or service will be used. Thus once having collected the task data specific to the product or service in development, the next step would be placing this product or service within the environment wherein it will used.
A full and complete description or representation of the use environment may not always be possible. Moreover, often times there are multiple use environments. And a description or descriptions may be only of a representative sample. Nevertheless, it can be extremely useful to understand how the product or service in development will be used in context.
The final research products resulting from this step in the product development process are:
Task analyzes: pertaining only to the product or service in development.
That include:
Breadth analysis, that consists of:
The number of tasks users would perform using the product or service in development
Their frequency of performance
Depth analysis
Define how each task is performed
The level is detail required will vary with the complexity of the task
Each task analysis should include likely errors and the steps required to correct them.
There are a variety of means to represent task analyze. The representation method should be agreed on by the affected parties.
Task execution within the wider use environment
The tasks that users will perform with the product or service in development will be performed within a larger context.
The tasks within the wider context and how those other tasks relate to each other requires documentation.
The other tasks require a breath analysis. Rarely is a depth analysis required unless tasks are intermingled.
I discuss the benefits of knowing what your user does and where they do it in my next article. I shall discuss with reference to HE75 and what the FDA will likely require from the medical product companies.
Where in a company's organizational structure is this work performed?
Knowing your 1) target population and their use environment, and 2) what your users do (task analysis) are the first two steps in the product formation stage of development. This precedes requirements gathering stage of product development. Thus, this would require the engagement of human factors engineers working with marketing and other product and field-focused organizations to engage those working at this early stage. St. Jude Medical with whom I consulted for 15 months has placed their all their human factors engineers in systems engineering. Thus, the placement of human factors engineering only in systems engineering means that important data impacting the beginning of product development is either not produced, or produced at a later stage in the development process where its impact is minimal or non existent.
As I shall discuss later, it is important that human factors engineering be involved from concept to deployment, thus human factors engineers should be distributed throughout an organization.
Stirrings in the Regulatory Environment
Medical product producers are regulated by the Federal Government. Anyone who reads this blog is highly likely to know that. Drug companies are acutely aware of governmental regulation in that their products must be “safe and effective.” Drug companies must prove through research safety and effectiveness. Implanted device manufacturers must demonstrate that the implanted devices themselves are safe and effective. Devices and drugs that deliver therapy have to prove to the FDA safety and effectiveness.
But what about the user interfaces for devices that enable users to make changes to the operation of implanted devices, deliver therapies, provide information about the patient, etc., where's the proof in the form of empirical data to prove that they're safe and effective?
In the US, more people are killed by medical errors each year than are killed in automobile accidents and in the military service combined. Yet, the FDA has placed few relatively requirements on the process for designing user interfaces on medical products and services. This is a disgrace and the FDA knows it. FDA mandates for insuring the usability of medical devices, products and services has been merely to determine only that a usability process is in place. FDA mandates for usability have not reached the level of the Departments of Defense or Transportation. Companies that design and build medical systems have not been required to prove to the FDA that their products are usable in their use environment. Yet, it is clear that usability is just as important in medical practice as with combat systems and cars – particularly when one considers the number of injuries and deaths resulting from medical errors. And with more powerful and complicated systems are being designed and planned, the need for the FDA to act and act effectively in the area of usability grow substantially.
In my personal experience, I saw a device under development that if used improperly, could injure or in one case, lead the to death of a patient. In fact, I uncovered a condition in which the device when used properly could lead to death. And, it would have been surprisingly easy to do. Of course, I raised my concerns regarding this device and its potential for injuring patients. Nevertheless, in the current regulatory environment, I believe that it would be possible that the device could be approved for use by the FDA because of the lack of a clear standard from the FDA that the company prove empirical data regarding that the device is usable and safe.
The Department of Defense has been particularly forceful with contractors regarding insuring that members of the target population will be able to use systems within the environment of their intended use. It does not take a great deal of contemplation to understand the value of insuring that a system can be operated effectively by a soldier in a combat environment. A system that could save the lives of fellow soldiers or civilians would be useless if it could not be used effectively by a member of the target population (i. e., a soldier) in combat. If the user interface is too cumbersome or complicated when used in the stress and difficulties of the combat environment, then all the time and effort taken to create that system has been wasted. NASA and the FAA have taken a stance similar to the DoD. The Department of Transportation in conjunction with Congress have taken a strong stance with respect to the design of user interface of vehicles.
I believe that the FDA will begin to strong stance similar to other regulatory bodies of the Federal Government regarding insuring that the user interfaces of medical devices meet specific usability standards and the meeting of these standards must be demonstrated experimentally with empirical data. I think that one of the first step in the process of ever increasing regulation of the user interfaces of medical will be the adoption of HE75 by the FDA. This would start the process towards mandating that companies prove their products meet user performance standards.
Saturday, March 27, 2010
A more complete article on the NIST Grant fund BANS research
I have added a more complete article without comment regarding the NIST funded study to advance the capabilities of Body Area Networks (BANS). It appears to be largely taken from the press-release from Worcester Polytechnic Institute.
Here's the link: http://itisinteresting.me/2010/03/1-2-million-award-from-nist-facilitates-groundbreaking-study-of-wireless-body-area-networks/
Here's the link: http://itisinteresting.me/2010/03/1-2-million-award-from-nist-facilitates-groundbreaking-study-of-wireless-body-area-networks/
Thursday, March 25, 2010
Know Thy Target Population
Background
Members of the project core team including myself were sitting around a meeting table at St. Jude Medical. We had received a sample of work from a well-known human factors and design consulting company. It was a detailed design of a user interface of a web-based system that the consulting company had designed. (I withhold the nature of the system because some of you may know this consulting company and have received the same sample system. I want maintain the anonymity of this company.)
Most of the members of the core team were impressed by the design and the level of detail provided in the sample of work. I was not impressed. Why? There was nothing in the design that tied back to the target population the system would serve, nor was their any reference to any research performed that justified the design or the services that would provide its users. In other words, I had no way to evaluate whether the design was good or bad, whether it suited the user needs or not. Furthermore, there was no information provided by the consulting company regarding the target population, its needs, skill-level, etc.
If I understand the objectives of HE75 correctly, then medical device companies will be required to demonstrate through research - it is unclear whether the research required will involve the need for empirical research or a literature search. However, companies will be required to demonstrate a clear understanding of the targeted population and the use environment of that target population for whom their products and services are intended for use. The consulting company who provided St. Jude Medical with work samples failed to demonstrate any knowledge of the targeted population.
Know Thy Target Population
And know the use environment of thy target population: objectives, distractions, dangers, skills, needs, etc.
There are few things that rankle a human factors professional more than an ascetically pleasing design that fails to take in account the population of the actual users. I will not discuss any specific examples in this article. However, you can look around the Web, around your home or office, or a hospital or clinic and see all kinds of products and displays that were designed without regard to the target user population. Companies continue to build products with user interfaces ill-suited to the target populations. Why?
Designing research, collecting and analyzing data and turning the analysis into appropriate products and in particular, well-suited user interfaces takes time and money. In highly competitive environments, time can be more of a concern than money. For companies that have adopted a "fast follower" business model, time often looms larger than money when planning and developing products, and designing user interfaces. Products based on a fast follower approach can often be successful if the product or product upgrade does not require a user interface. Development is nothing more than the implementation of a proven algorithm. However, when there is a user interface, the lack of attention to understanding the target population can become painfully obvious once the product or service is introduced.
When a company uses a "fast follower" model or does not want to devote the time, effort and money to research, the temptation can be to rely on opinion leaders, other companies' products, best guesses, or "expert" opinions. These approaches often bring fast outcomes. Furthermore, I have noticed that often times decision-makers believe that they can determine what is and what is not a good user interface - that a good user interface design is something that anyone can assess.
I believe that some of the faith that decision-makers have placed in themselves comes from their experience with consumer products, such as the Apple's iPhone. The iPhone is an combination of excellent physical design ascetics and small, touch-screen user interface design. What many people forget is that Apple devoted copious amounts of time, money, expertise to research and development of the physical design and the user interface of the iPhone.
The iPhone was designed with the general public in mind. Apple may have targeted the iPhone to a more youthful population, however, I have noticed that many, many older people pulling out their iPhones. I have also noted that there are numerous medical applications targeted to iPhones, applications that would be of interest to older people. The iPhone may have been targeted to a more youthful population, but its touchscreen interface with its large, wide buttons, high contrast and high resolution screen enables elderly users to access its capabilities.
When user interfaces are targeted to a specific population, it becomes imperative that the characteristics, needs, qualities, etc. of the target population be well-known and understood. The user interfaces introduced to that population will likely be tied to a specific set of tasks with clear objective within a specified environment. The use environment maybe more complex and stressful than the use environment of a consumer product. Furthermore, and this is particularly true of many medical devices, the consequences of making an error can be significantly more harmful than any consumer product.
For decades, the Department of Defense has pressed its contractors to follow standards and demonstrate usability in the use environment. The first step in that process is understanding the target population and the use environment. Given the accumulating evidence that medical errors kill more people per year than automobile accidents and war, I believe that the FDA will take strong steps such as the steps taken by the Departments of Defense and Transportation. Judgment will no longer substitute for data and analysis. The evidence that I have seen is that HE75 and HE74 will provide significant guidance towards directing companies towards gaining a full understanding of the target population and their use environment.
One thing to note, target populations and use environments are dynamic, not static. Continuing research is essential.
Next time: Now that you have an understanding of your target population and the use environment, what do you do next? I shall come back to specific techniques for research a target population and their use environment in a later article. However, I want to provide a process overview before diving into specifics and specific techniques.
Members of the project core team including myself were sitting around a meeting table at St. Jude Medical. We had received a sample of work from a well-known human factors and design consulting company. It was a detailed design of a user interface of a web-based system that the consulting company had designed. (I withhold the nature of the system because some of you may know this consulting company and have received the same sample system. I want maintain the anonymity of this company.)
Most of the members of the core team were impressed by the design and the level of detail provided in the sample of work. I was not impressed. Why? There was nothing in the design that tied back to the target population the system would serve, nor was their any reference to any research performed that justified the design or the services that would provide its users. In other words, I had no way to evaluate whether the design was good or bad, whether it suited the user needs or not. Furthermore, there was no information provided by the consulting company regarding the target population, its needs, skill-level, etc.
If I understand the objectives of HE75 correctly, then medical device companies will be required to demonstrate through research - it is unclear whether the research required will involve the need for empirical research or a literature search. However, companies will be required to demonstrate a clear understanding of the targeted population and the use environment of that target population for whom their products and services are intended for use. The consulting company who provided St. Jude Medical with work samples failed to demonstrate any knowledge of the targeted population.
Know Thy Target Population
And know the use environment of thy target population: objectives, distractions, dangers, skills, needs, etc.
There are few things that rankle a human factors professional more than an ascetically pleasing design that fails to take in account the population of the actual users. I will not discuss any specific examples in this article. However, you can look around the Web, around your home or office, or a hospital or clinic and see all kinds of products and displays that were designed without regard to the target user population. Companies continue to build products with user interfaces ill-suited to the target populations. Why?
Designing research, collecting and analyzing data and turning the analysis into appropriate products and in particular, well-suited user interfaces takes time and money. In highly competitive environments, time can be more of a concern than money. For companies that have adopted a "fast follower" business model, time often looms larger than money when planning and developing products, and designing user interfaces. Products based on a fast follower approach can often be successful if the product or product upgrade does not require a user interface. Development is nothing more than the implementation of a proven algorithm. However, when there is a user interface, the lack of attention to understanding the target population can become painfully obvious once the product or service is introduced.
When a company uses a "fast follower" model or does not want to devote the time, effort and money to research, the temptation can be to rely on opinion leaders, other companies' products, best guesses, or "expert" opinions. These approaches often bring fast outcomes. Furthermore, I have noticed that often times decision-makers believe that they can determine what is and what is not a good user interface - that a good user interface design is something that anyone can assess.
I believe that some of the faith that decision-makers have placed in themselves comes from their experience with consumer products, such as the Apple's iPhone. The iPhone is an combination of excellent physical design ascetics and small, touch-screen user interface design. What many people forget is that Apple devoted copious amounts of time, money, expertise to research and development of the physical design and the user interface of the iPhone.
The iPhone was designed with the general public in mind. Apple may have targeted the iPhone to a more youthful population, however, I have noticed that many, many older people pulling out their iPhones. I have also noted that there are numerous medical applications targeted to iPhones, applications that would be of interest to older people. The iPhone may have been targeted to a more youthful population, but its touchscreen interface with its large, wide buttons, high contrast and high resolution screen enables elderly users to access its capabilities.
When user interfaces are targeted to a specific population, it becomes imperative that the characteristics, needs, qualities, etc. of the target population be well-known and understood. The user interfaces introduced to that population will likely be tied to a specific set of tasks with clear objective within a specified environment. The use environment maybe more complex and stressful than the use environment of a consumer product. Furthermore, and this is particularly true of many medical devices, the consequences of making an error can be significantly more harmful than any consumer product.
For decades, the Department of Defense has pressed its contractors to follow standards and demonstrate usability in the use environment. The first step in that process is understanding the target population and the use environment. Given the accumulating evidence that medical errors kill more people per year than automobile accidents and war, I believe that the FDA will take strong steps such as the steps taken by the Departments of Defense and Transportation. Judgment will no longer substitute for data and analysis. The evidence that I have seen is that HE75 and HE74 will provide significant guidance towards directing companies towards gaining a full understanding of the target population and their use environment.
One thing to note, target populations and use environments are dynamic, not static. Continuing research is essential.
Next time: Now that you have an understanding of your target population and the use environment, what do you do next? I shall come back to specific techniques for research a target population and their use environment in a later article. However, I want to provide a process overview before diving into specifics and specific techniques.
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.
An another article on BANs
Another article on Body Area Networks and the Federal Government's continuing interest in furthering its development. Here's the link to the article: http://www.informationweek.com/news/healthcare/mobile-wireless/showArticle.jhtml?articleID=224200068
Much of the work seems analogous vehicle telemetry research and development. One of the applications for the technology we developed at Rosetta-Wireless was for the transport of vehicle telemetry over the commercial wireless network in real-time or near real time. The problem that we solved was handling gaps, faults and multiple types of wireless connections while the vehicle was in motion. Again, body data will need to be transported over wireless using a robust logical connection to overcome the imperfections of the wireless network and perform the task without burdening the user - an extremely important consideration.
The next article will discuss the implications of HE75 and the means, methods and importance of not burdening or overtaxing the user.
Much of the work seems analogous vehicle telemetry research and development. One of the applications for the technology we developed at Rosetta-Wireless was for the transport of vehicle telemetry over the commercial wireless network in real-time or near real time. The problem that we solved was handling gaps, faults and multiple types of wireless connections while the vehicle was in motion. Again, body data will need to be transported over wireless using a robust logical connection to overcome the imperfections of the wireless network and perform the task without burdening the user - an extremely important consideration.
The next article will discuss the implications of HE75 and the means, methods and importance of not burdening or overtaxing the user.
Tuesday, March 23, 2010
Human Factors Issues in Remote Monitoring and Remote Programming
Series Overview and Background
Human factors issues related to remote monitoring and remote programming (remote patient care) will predominate in my postings over the next several months. If I learned anything while working at St. Jude Medical, I learned the value of human factors engineering in relationship to remote monitoring systems. Before I discuss what I learned, I want cover a few issues regarding remote patient care.
If you talk to a device clinic clinician, that person will have few difficulties in communicating to you the value of remote monitoring technology. I heard stories from cardiologists that before remote monitoring technology was in place that device nurses would have to telephone device patients. The emotional strain on the nurses was so great that device nurses would burn-out in two years.
Remote monitoring provides a service to patients and their caregivers. Most patients do not want to come to the device clinic and caregivers would rather that they did not. Remote monitoring lengthens the time between clinic appointments. Furthermore, remote monitoring can detect signs of potential problems much earlier than a visit to the clinic. Remote monitoring can keep patients out of emergency rooms and can provide patients with a better quality of life. Finally, remote monitoring can lower the cost of care while improving it.
Among the medical trail blazers, there is an interest in remote programming. The ability to remotely make changes in the operation of a medical device could enable caregivers to be more proactive and provide patients with care where ever they are located, rather than just in the clinic. This capability significantly lowers barriers and limitations on patients and their caregivers. Patients can lead more free and independent lives and less tethered to clinic appointments.
Sounds wonderful, doesn't it? Remote patient care technology does provide the underlayment, the enabling capability. However, remote patient care system cannot be limited to the technology. From my perspective working at St. Jude Medical, roles of caregivers and patients have been under valued, misunderstood or neglected in the development of systems to provide remote patient care. I cannot speak for other medical device manufacturers. I can say, because this is public information, that St. Jude Medical's remote monitoring system has come under fire because of issues related specifically to the performance and design of the user interface of their remote monitoring system.
I am not singling-out St. Jude Medical regarding the design and implementation of their remote monitoring system. St. Jude Medical implemented a beneficial and desired medical system. However, it appears that they failed to understand two essential elements who are just as essential to the remote care system as the hardware and software. Thus the current state of St. Jude Medical's remote monitoring system serves as a starting point for the articles that will follow this one.
My next two articles will focus on the new AAMI/ANSI standard HE75 due to be officially released in April 2010. I cannot quote from the document at this time, however, I can say that HE75 is founded on the basic foundations of human factors. Thus, from that standpoint, there is nothing new about what is contained in HE75. I know several people on the HE75 committee and I can say that they are consumate human factors professionals, and dedicated to the profession.
I can also say that should the FDA adopt this document (and all expectations are that the FDA will adopt it), the relatively lax approach that FDA approach to usability and human factors will come to an end. There is a massive body of literature that documents the massive number of injuries and deaths from medical errors, and some of those medical errors can be traced back to poor device designs. It may well be that the FDA will believe that it is time to "crack down" on poorly designed medical system user interfaces. Furthermore, medical systems are becoming increasingly more powerful and complicated, thus the capability to do injury to patient will increase. Thus, the need to insure that medical devices and their user interfaces will meet specific and unambiguous performance standards before being approved by the FDA.
I plan to focus specifically on medical devices related to remote patient care in this blog. However, I may stray from time to time when there is something that seems particularly relevant or interesting.
I shall not discuss anything regarding future St. Jude Medical products or services in this blog. However, I can discuss some of the issues I faced in general terms to illustrate points. I suspect that the experiences I relate will resonate with others.
Next time: Human factors in the research and development of medical devices.
Human factors issues related to remote monitoring and remote programming (remote patient care) will predominate in my postings over the next several months. If I learned anything while working at St. Jude Medical, I learned the value of human factors engineering in relationship to remote monitoring systems. Before I discuss what I learned, I want cover a few issues regarding remote patient care.
If you talk to a device clinic clinician, that person will have few difficulties in communicating to you the value of remote monitoring technology. I heard stories from cardiologists that before remote monitoring technology was in place that device nurses would have to telephone device patients. The emotional strain on the nurses was so great that device nurses would burn-out in two years.
Remote monitoring provides a service to patients and their caregivers. Most patients do not want to come to the device clinic and caregivers would rather that they did not. Remote monitoring lengthens the time between clinic appointments. Furthermore, remote monitoring can detect signs of potential problems much earlier than a visit to the clinic. Remote monitoring can keep patients out of emergency rooms and can provide patients with a better quality of life. Finally, remote monitoring can lower the cost of care while improving it.
Among the medical trail blazers, there is an interest in remote programming. The ability to remotely make changes in the operation of a medical device could enable caregivers to be more proactive and provide patients with care where ever they are located, rather than just in the clinic. This capability significantly lowers barriers and limitations on patients and their caregivers. Patients can lead more free and independent lives and less tethered to clinic appointments.
Sounds wonderful, doesn't it? Remote patient care technology does provide the underlayment, the enabling capability. However, remote patient care system cannot be limited to the technology. From my perspective working at St. Jude Medical, roles of caregivers and patients have been under valued, misunderstood or neglected in the development of systems to provide remote patient care. I cannot speak for other medical device manufacturers. I can say, because this is public information, that St. Jude Medical's remote monitoring system has come under fire because of issues related specifically to the performance and design of the user interface of their remote monitoring system.
I am not singling-out St. Jude Medical regarding the design and implementation of their remote monitoring system. St. Jude Medical implemented a beneficial and desired medical system. However, it appears that they failed to understand two essential elements who are just as essential to the remote care system as the hardware and software. Thus the current state of St. Jude Medical's remote monitoring system serves as a starting point for the articles that will follow this one.
My next two articles will focus on the new AAMI/ANSI standard HE75 due to be officially released in April 2010. I cannot quote from the document at this time, however, I can say that HE75 is founded on the basic foundations of human factors. Thus, from that standpoint, there is nothing new about what is contained in HE75. I know several people on the HE75 committee and I can say that they are consumate human factors professionals, and dedicated to the profession.
I can also say that should the FDA adopt this document (and all expectations are that the FDA will adopt it), the relatively lax approach that FDA approach to usability and human factors will come to an end. There is a massive body of literature that documents the massive number of injuries and deaths from medical errors, and some of those medical errors can be traced back to poor device designs. It may well be that the FDA will believe that it is time to "crack down" on poorly designed medical system user interfaces. Furthermore, medical systems are becoming increasingly more powerful and complicated, thus the capability to do injury to patient will increase. Thus, the need to insure that medical devices and their user interfaces will meet specific and unambiguous performance standards before being approved by the FDA.
I plan to focus specifically on medical devices related to remote patient care in this blog. However, I may stray from time to time when there is something that seems particularly relevant or interesting.
I shall not discuss anything regarding future St. Jude Medical products or services in this blog. However, I can discuss some of the issues I faced in general terms to illustrate points. I suspect that the experiences I relate will resonate with others.
Next time: Human factors in the research and development of medical devices.
Development of BANS Expected to Accelerate
For those not in the "know," BANs is an acronym for Body Area Network. It is a technology to capture and transmit body-related telemetry. The National Institute of Standards and Technology (NIST) has granted the Center for Wireless Information Network Studies at Worcester Polytechnic Institute (WPI) Worcester, MA, $1.2 million over three years to advance BANs technology. The research will focus on the propagation of radio waves around and through the human body. This could have real potential for the development of robust communications standards to enable medical devices to send and receive data and instructions over wireless networks. This research is something to watch.
http://medicaldesign.com/engineering-prototyping/research-development/development-bans-expected-accelerate-032210/
Receiving a NIST grant is a significant achievement. I was the Principal Investigator on a $2 million, two year grant to Rosetta-Wireless. The NIST vetting process is arduous, but the grants generally fall into the seven figure range over two to three years. I know that wireless data communication is an important area of interest to NIST particularly as it relates to medical applications, more specifically into the areas of wireless medical monitoring and remote programming. I know that NIST has continued hopes for a medical application of the technology that my company, my research and development team created.
For those who have an interest in BANs, one of the technical problems is getting the data collected by BANs back to a location where medical professionals can review and evaluate it. And, if need be, make changes remotely in the operation of the implanted medical system (e. g., pacemaker, ICD, insulin pump, etc.). If you review some of my earlier posts, you'll note that I have described methods to transport data and instructions over the commercial wireless network from and to a patient's implanted medical device.
I shall continue to bring to light any further developments in BANs.
http://medicaldesign.com/engineering-prototyping/research-development/development-bans-expected-accelerate-032210/
Receiving a NIST grant is a significant achievement. I was the Principal Investigator on a $2 million, two year grant to Rosetta-Wireless. The NIST vetting process is arduous, but the grants generally fall into the seven figure range over two to three years. I know that wireless data communication is an important area of interest to NIST particularly as it relates to medical applications, more specifically into the areas of wireless medical monitoring and remote programming. I know that NIST has continued hopes for a medical application of the technology that my company, my research and development team created.
For those who have an interest in BANs, one of the technical problems is getting the data collected by BANs back to a location where medical professionals can review and evaluate it. And, if need be, make changes remotely in the operation of the implanted medical system (e. g., pacemaker, ICD, insulin pump, etc.). If you review some of my earlier posts, you'll note that I have described methods to transport data and instructions over the commercial wireless network from and to a patient's implanted medical device.
I shall continue to bring to light any further developments in BANs.
Subscribe to:
Posts (Atom)