Medtronic Remote Monitoring Study: CONNECT

At the American College of Cardiology 59th annual conference George H. Crossley, MD presented evidence that cardiac patient from remote monitoring (one scheduled in-office visit per year with remote monitoring) verses standard in-office care (four in-office visits per year) cuts the time between the time a cardiac or device related event occurs and when a treatment decision is made.

The title of the study: "The clinical evaluation of the remote notification to reduce time to clinical decision (CONNECT) Trial: The value of remote monitoring."

I present a summary of the method and the results of the study gleaned from the slides presented by Dr. Crossley at the conference.

Hypothesis

Tested hypothesis: Remote monitoring with automatic clinician notifications reduces the time from a cardiac or device event to a clinical decision.

Additionally investigated were rates utilization of the health care system including hospitalization and between treatment groups.

Method

Study participants:  1997 newly implanted CRT-D and DR-ICD patients from 136 US centers were randomly assigned to one of two groups. The first group had 1014 patients assigned to the remotely monitored group and the second had 983 patients assigned to the standard in-office care group. The patients were reasonably well matched for age and gender characteristics.  (A procedure similar to the Biotronik TRUST studies.)

The patients were followed for 12 months.  (On first reading, I found the the time relatively short in that I would not expect enough differentiating events would occur during that time.  However, on further reading, I believe my first impression was incorrect.)

Findings

Time from Event to Clinical Decision

The median time (used nonparametric inferential statistics for the analysis) from the cardiac or device event to clinical decision was 4.6 days in the remote group and 22 days in the in office group. This difference was significant.  The remote group involved 172 patient while the in-office group involved 145 patients.

The cardiac/device events included:

• Atrial Tachycardia/Fibrillation (AT/AF) for 12 hours or more
• Fast Ventricular rate. Of at least 120 beats per minute during at least a 6 hour AT/AFT event
• At least two shocks delivered in an episode
• Lead impedance out of range
• All therapies in a specific zone were exhausted for an episode
• Ventricular Fibrillation detection/therapy off
• Low battery

Total number of events Remote group: 575 and In-office group: 391.  The slides show the breakdowns.

Office Visits

The number of office visits per patient reported are shown below.

                        Scheduled     Unscheduled      All office

Remote group:     1.68              2.24              3.92

In-office group:    4.33              1.94              6.27

The TRUST studies showed a slight increase of more unscheduled visits for the remote group. However, given the nature of the study and that remotely monitored patients would receive only one in-office visit per year, it's remarkable how similar the numbers between the two groups are.

Utilization of the Health Care System

Number of incidents where patients used the health care system show virtually no difference, hospitalization or emergency room. 

However, a remarkable difference was the significant difference in length of stay when there was a hospitalization. The remote group had a mean hospital stay of 3.3 days while the in-office group was 4.0 days with an estimated savings per hospitalization of $1659.

Conclusion

The CONNECT and (Biotronik) TRUST studies show clear benefits from a number of standpoints for remote monitoring.  In addition, the CONNECT study showed clear cost and hospital resource utilization benefits from remote monitoring in that hospitalized patients had shorter stays indicating that they were in better shape than patients in the in-office group when admitted to the hospital.  Quick responses seem to lead to better outcomes as well as cost reductions.

Here is the link to Medtronic's press release of the study: http://wwwp.medtronic.com/Newsroom/NewsReleaseDetails.do?itemId=1268659150410&lang=en_US

Here is another link to an article on the study that includes a link to Dr. Crossley's slides: http://www.cmio.net/index.php?option=com_articles&view=article&id=21235:acc-remote-monitoring-shortens-event-response-time-reduces-hospital-costs

Additional resources

Reimbursement for Remote Patient Monitoring in the United States- Regulatory Antennae Picking Up Demand Signals 

Remote ICD monitoring speeds diagnosis of arrhythmias.(CARDIOVASCULAR MEDICINE)(implantable cardioverter defibrillators)(Report): An article from: Internal Medicine News

Reader Article: Controlling Glucose Level to Prevent Diabetes

 Here's something I have been wishing for ... a guest article authored by one of my readers.  If you have something that you would want me to publish in this blog, by all means, please send it and if I think it has technical merit and seems appropriate, I shall publish it.  


This article is written by Kristina Ridley who writes for the diabetes blood glucose  blog. (http://www.diabetesmeters.org/)This is her personal hobby-blog that focuses on healthy eating and tips to measure blood glucose levels at home to help people understand early diabetes symptoms.  

This article may have bearing on remote monitoring technology for diabetes in the what people consume has likely impact on glucose and insulin levels.  I know that heart failure patients (whom I understand are often diabetic) can remotely report to caregivers their weight, blood pressures, etc.  I would seem reasonable that diabetics could report their food and fluids intake for remote monitoring by their caregivers. 

I am particularly interested in Kristina's last section, "Too Much Control."  My experience in cardiac rhythm management suggest close monitoring and control are strong positives.  I hope that Kristina or someone else could write a rejoinder to this section.


Here is Kristina's unedited article:

Here’s a Quick Way to Control Glucose Level to Prevent Diabetes

 

Our pancreas is affected by diabetes – specifically, Type 2.Our body contains glucose found in the blood stream, which it gets from the sugar in food. Our body uses the glucose, but only when it goes into our blood cells and the insulin released by our pancreas converts it. Insulin production and utilization is difficult for someone who lives with Type 2 diabetes. There is a lot of glucose in the body, but your cells cannot locate them.

The American Diabetes Association has become very important when it comes to gathering critical information about this medical condition. With approximately 23.6 million citizens living with diabetes, America is an extremely unhealthy country. Over 90% of all patients with diabetes have Type 2.Most diabetics tend to be overweight and have relatives with the same condition. Too much glucose can cause serious, irreparable damage to internal organs and to the overall nervous system.

Diabetes and Your Life

If you have Type 2 diabetes, you need to live in a healthy manner. Living healthy and engaging in healthy practices will affect you tremendously. Two common examples of healthy routines include exercising and consuming healthy foods. Making sure that your glucose levels stay in the recommended range translates into being able to avoid complications in your health. A finger prick test is a common and reliable way to monitor your body’s blood glucose levels. 

 

This test, according to physicians, is sufficient enough for glucose monitoring like the HbA1c test. The amount of glycated hemoglobin in your blood is determined by this HbA1c test, aside from it alerting you if you reach a high glucose level. Results of these A1c tests show that people with diabetes are at a seven percent level. The CDC reports that if one maintains their a1c levels at seven percent, they could reduce the possibility of risks as high up as forty percent.

Too Much Control 

Recently, there have been medical studies that seem to indicate that maintaining A1c levels below 7% may be a bad idea after all. One of these studies, conducted at the Lancet and Swedish Medical Center in Seattle, has found that people who have median levels may be at a far greater risk of death, especially for those taking insulin. However, other tests have indicated that A1c levels of 7 percent is still perfectly healthy. Matt Davies, An accredited Endocrinologist, has stated that maintaining a 7% A1c level is healthy according to recent studies, but that physicians should always take the individual patient's history into account prior to planning treatment.

 

Kristina provides diabetic recipes in here blog.  In addition, I have provided a link to Amazon that will initiate a search for diabetic cookbooks.

Search Amazon.com for diabetic cookbook

Why the Moniker "RemoteProgrammerGuru?"

For those who have wondered ... there is a story behind why I use the moniker, "RemoteProgrammerGuru."  Any identity that has as part of the name, "guru" could be considered more than a little ostentations.  Here's the definition as provided by Wikipedia:http://en.wikipedia.org/wiki/Guru.

The definition describes someone with "supreme knowledge."  Fortunately for me, the term in India is synomous with "teacher."  For me, the "term" teacher was more appropriate and the role of a teacher came as a surprise.

I was part of a project where remote programming was the technical centerpiece of a proposed solution.  Frankly, I was new to remote programming for medical devices ... as are most.  However, I have a rich telecommunications background including expertise in wireless communications.  (I was the principal investigator on two federally funded telecommunications research grants.)  I know the technologies and I know how things work. 

As it turned out, I knew more about telecommunications than my colleagues who had been working in remote programming for longer than I ... much more.  And I started teaching them, about communications and about remote programming and necessary processes to insure communication integrity.  In effect, I became a "guru," a teacher.

Finally, since remote programming when designed and implimented correctly, involves sophisticated monitoring, I decided to incorporate the term "remote programmer" to represent someone who informs people about remote monitoring and programming.  Thus the moniker, "RemoteProgrammerGuru" was created.

Announcement: Biotronik has MRI Conditional Pacemaker Approved in Europe

Announcement that Biotronik has gained European approval for an MRI conditional pacemaker and leads.  Here's a link to the announcement from Business Wire:
http://www.businesswire.com/portal/site/home/permalink/?ndmViewId=news_view&newsId=20100407006972&newsLang=en

I have worked on the usability issues related to providing MRI conditional pacemakers and leads.  Without disclosing too much, my work related to MRI conditional pacemakers and leads got me interested in remote monitoring and remote programming.  So, for me there's a link between MRI conditional pacemakers and leads, and remote monitoring and programming.

Article: Updates to the Development of Medical Body Area Networks (MBANS)

Mobihealth News has published an article indicating that Philips is interested in a 10MHz spectrum dedicated to MBANS.  Here's the link to the article:
http://mobihealthnews.com/7178/philips-suggests-dedicated-mhealth-spectrum/

Mobihealth suggests that Philips is taking a different approach to MBANs than GE who wants 40Mhz of spectrum dedicated to MBANs.  The GE is interested in MBANs that would be used in hospitals.  Philips is interested in the deployment of MBANs to the field, and that Philips would produce consumer and not medical grade products.  I am not sure how this could work in the US.  However, this development is worth continuing attention.

Article: Wireless Remote Monitoring Prevents Complications of Chronic Diseases

An interesting article about the benefits of remote monitoring in the care of patients with chronic diseases from the Press of Atlantic City, 8 March 2010.  Here's the link to the article:  http://www.pressofatlanticcity.com/life/monday_health/article_1333e585-e3a6-5ba8-a411-75530f6b63cf.html

Quotes from the article:

Improving management

By early 2012, Americans will use about 15 million wireless health-monitoring devices, according to a forecast from ABI Research, which tracks mobile-technology trends. The mobile health market is projected to more than triple to $9.6 billion in 2012 from $2.7 billion in 2007, according to study from Kalorama Information Inc

[T]he first pilot project in the nation to assess whether the use of remote digital devices with data sent over the Internet to a doctor's office improved management of multiple chronic diseases - diabetes, heart disease and high blood pressure, also known as hypertension. 

Diabetics and hypertensive patients increased the number of days between appointments by 71 percent and 26 percent respectively ...
"One of the great promises of wireless (health) is making it a part of the patient's daily life, not an interruption to what they're doing every day," ...

From personal experience I believe the last sentence I quoted is among the most important in the article.  The entire process should be so smooth, so automated, so uncomplicated and unintrusive that the patient's life is uninterrupted and that the data is seamlessly collected and sent to the patient's caregiver.

Two other items to note.  The first is a brief discussion of the sensors connected to the patient's body.  They mention band-aid size electrodes.  I am not sure if these are the "digital plaster" that I've discussed in an earlier article.  http://medicalremoteprogramming.blogspot.com/2009/11/digital-plaster.html
Or something else.  I do not know, but it would be interesting to find out.  If I have any informational, I'll post it.  If you have any information, please enlighten us with a comment.

The second issue of note is the discussion in the article regarding payment, and who will do it.  Given the convoluted nature of our system of payments, this will be the most difficult issue to resolve, I believe.  It's ironic considering that remote monitoring saves money.   I think the technical issues will be minor in comparison.  I hope I am proved wrong.

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 ...

For this ideal scenario to develop, five technologies need to be solved, and Klonoff sees printed electronics being used in every one:

• 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

 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".


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. 

 

More on Knowing Thy Target User Population

Before moving forward into product development, I want to elaborate on the issues in my first two articles. This article elaborates on the importance of knowing the target population and ways to gather that information.  

The next article will discuss  I have had some recent experiences that reinforced that importance of defining and clearing understanding the targeted user population. And the importance of fully understanding and documenting what those members of the user population do and the environment(s) wherein they live and work.

Before proceeding any further, please review my previous article on understanding your target population. The link to the article is below:

http://medicalremoteprogramming.blogspot.com/2010/03/know-thy-target-population.html

HE75 clearly emphasizes the importance of understanding your target population.   The standard instructs that companies who develop medical devices should:

1. Know their targeted user population
2. Involve users early and often
3. Accommodate user characteristics and capabilities. And in order to do this, one must first know what they are.

The information gathered about a target population should enable one to clearly define the qualities and characteristics of that population.  This can be particularly important when designing medical devices, particularly when those devices are targeted to patients. 

I have seen organizations a company, organizations that include program management, marketing and engineering assume that they know the characteristics of the targeted population.  Once the product is deployed, the company comes to a rude awakening and learns that their assumptions were often times false.  Neither the company nor the targeted user population(s) benefit from such a failure.

Methods for Gathering Target Population Data

The target population data is the most elemental data in the product development process.  All the descriptions about the targeted user population, their characteristics, culture and capabilities originate from this step in the research and development process.

So, how is this crucial data gathered? First, a confession ... the amount of work I have performed at this stage of the process has been limited.  My training is in cognitive psychology and computer science.  Most often I have been the recipient of such information about the targeted user population.  I have used the results of this first step as a means for recruiting subjects in my usability experiments and evaluations.  The training that is most suited to gathering this kind of data is anthropology and sociology.  The process of collecting target user population data draws on ethnographic and participant observation research methodologies.  The research can be observational.  It can be based on questionnaires administered orally or in writing.  It can be structured interview.  It can participant observation where the observer becomes participates in the activities of the target population.  It can be a combination of a variety of methods and include methods not listed above.  

The objective is the development well-grounded description that captures the important, defining characteristics of the target population.  The description can be provided in variety of ways, verbal or graphic.  The description should use the clearest and most appropriate methods available to covey that information to the members of the product development organizations.

Interestingly enough, I have used the data gathering methods I listed above.  However, I used those methods to collect data for the second step, Knowing what the user does and where they do it.  In other words, to gather task and environmental data.

Potential Costs for Failure to Correctly Define the Target User Population

Consider the following scenario ... that I collect task and environmental data about the wrong population, about a population that is not the target population.  What is the value of the results of my research?  And what could be the cost to the company for this failure?  What could be the cost to the target user population, to have a device with a user interface unsuited to their needs?

In reality, the cost could be high, but the product may not be a dismal failure.  Given the fact that we are all human, we share a wide variety of characteristics.  However, in the more stringent regulatory environment that is anticipated, it could mean delay, additional research, engineering and product development costs.  If the product is intended to provide a new capability to providers and/or patients, a delay could mean that a competitor could be first to the market the product.  Thus company could miss the competitive advantage to being first.

I have recent experience with two products targeted to patients. In one case the target population was well understood and well defined, and members of that population were used in usability testing.  In another case, there was a limited understanding of the target population by the research and development organization. And no member of the target population involved at any stage of the research and development process or in the development of the user interface.   In the first case where the target population was well understood and well defined, the user interface research and development process was clear and logical.  On the other hand, the research and development process that did not have a clear understand of the target population is struggling, it is learning as it goes.  Each time it learns something new about its target population, the user interface has to be updated.  It has been a costly process with constant reworks of the user interface.  So many reworks that the integrity of the original design has been lost.  It appears deconstructed.  At some point the entire user interface will have to be redesigned and that will likely come at the behest of the FDA enforcing HE75.

A Final Thought

HE75 instructs that medical product user interfaces should accommodate a diverse groups of users and should be maximally accessible. I see this as design objective of any user interface in that vernacular should be limited as much as possible and that limiting qualities should not be designed in or should be removed when detected. However, all products may not be accessible to all users but should be clearly accessible to the target population.  And I believe that the FDA will insist on this.

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.

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

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:

1. 
   
   The preconditions that lead to performing each task,
2. 
   
   The steps required to perform a task, and
3. 
   
   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:

1. 
   
   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.

2. 
   
   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.