Apple Watch 4, Preview of Medical-Monitoring Features

Here's an article regarding the Apple Watch 4 and what are suppose to be built in medical monitoring features.

Here's the link: https://www.mobihealthnews.com/content/apple-watch-series-4-will-have-fda-cleared-ecg-fall-detection?mkt_tok=eyJpIjoiTkRVMk0yVmxNamsyWkRneiIsInQiOiJjWXRoaVpENmhJYlBRNFlzVVBYZ3hrc0VEVFdsYmNLUG1FQUIrQmcyMnVHMTRwSnBORDh6cW1Da1kzbjJqS2JxbHcydjRuTk0zaG5qRzBvMFR1MmdiMmZyNGhyXC9SZmYyYkduaSs5R0tyRG85TXkrMHVxTnFFYXFrVE5jWHpIRWwifQ%3D%3D

Here's the list of new medically-related features:

1. ECG (30 second rhythm "strip")
2. A-Fib detection (of course, if you're paying attention and you know the symptoms, you'll probably know sooner than the watch.)
3. Fall detection (as in when the person falls, the watch detects that it has occurred)

All information is sent back to Apple Health Records where all this information be accessible to a physician/cardiologist.

Apple has received FDA approval, according to the article. 

I'm not going to comment until I've had a little more time to study the Apple Watch 4 except to say, if you can detect A-Fib, then why not V-Fib? V-Fib is much more life threatening. Also too, if you've got a 30 second rhythm snap shot, you can do a lot with that. 

I'll touch on these and other questions regarding the Apple Watch 4 and Apple's effort to product a remote medical monitoring device and medical monitoring system later. 

UK Perspective Regarding FDA Regulatory Requirements

A Linked-In colleague posted a link to this article. I read it and found it interesting enough to post the link and comment on it. It's by a UK publication and discusses the FDA regulatory process as it relates to Human Engineering requirements for device approval for commercialization.

Here's the link:
http://www.emdt.co.uk/daily-buzz/what-are-fda-usability-testing-requirements-device-approval?cid=nl.qmed01.20150325

In addition, I provide my own perspective on the article in the "Commentary" section below. I do not critique the article. I only attempt to expand on a few points from it.

But first, a brief summary of the article.

Article Summary

Medical errors have become an increasing concern of the FDA. I became interested in medical errors when I was a consultant at St. Jude Medical Cardiac Rhythm Division in Sylmar, CA. During my time at St. Jude (2009-2010), deaths by medical error were being reported as being 100,000 to 120,000 per year. Last year, I posted links to two articles that stated that deaths by medical errors could be closer to 400,000 per year. (http://medicalremoteprogramming.blogspot.com/2014/07/rip-death-by-medical-error-400000-year.html)

It has been noted by the FDA a large proportion of medical errors can be attributed to poorly designed medical device user interfaces. Since a fundamental mission of the FDA is increasing patient safety and reducing injuries and fatalities in the practice of medicine, the FDA has begun placing greater emphasis on improving the usability of medical device user interfaces.

This article provides measures that show the FDA's increasing emphasis on usability and human factors issues by showing the increasing frequency that companies seeking medical device clearance for the US market mention the terms "usability" and "human factors." Figure 1 from the article clearly shows the increasing usage of these terms in company filings.

The focus should be on the trends, not the absolute numbers because not all filing documents have been included in the count. But the trend clearly shows an increased emphasis by companies to increasingly use the terms "usability" and "human factors" in their filings with the FDA. The two figures that follow suggest the degree that companies have incorporated the FDA prescribed human factors engineering process and design guidance documentation.

The documents listed below are specifically targeted to defining and supporting the human factors engineering process and the development of the Human Engineer File that's included as part of a company's filing to the FDA.

• ISO 62366, Medical Devices - Application of Usability Engineering to Medical Devices
• AAMI / ANSI HE75:2009, Human Factors Engineering - Design of Medical Devices (General)

I'll discuss the documents above in greater detail and describe how they're intended to fit within the human factors engineering process when developing medical devices.

• IEC 60601-1-6 Medical electrical equipment - Part 1-6 General requirements for Safety - Collateral standard: Usability
• IEC 60601-1-8 Ed. 1, Medical Electrical Equipment - Part 1-8: General Requirements for Safety - Collateral Standard: Alarm Systems - Requirements, Tests and Guidance - General Requirements and Guidelines for Alarm Systems in Medical Equipment (General)

The two documents above are engineering standards. They're engineering specifications that medical devices must meet. They are technical and specific.

I show Figure 3 from the article before showing Figure 2. 

The increasing reference of 60601-1-8 is not surprising given the increased emphasis on safety. My real interest is in the significant increase in reference to ISO 62366. As mentioned, this is process standard the lays out how human factors engineering should be engaged to reduce "use errors." The emphasis in this standard is on the reduction of risk. Risk management is extremely well embedded in the medical device design and engineering process. It would seem that from a cultural perspective, ISO 62366 fits with the medical device engineering process. 

I want to contrast the dramatic, increasing references to ISO 62366 with the references to AAMI/ANSI HE75 shown in Figure 2 below.

References to AAMI/ANSI HE75 rise and fall from 2010 to 2013 instead of a steady upward trend that you see with ISO 62366 in Figure 3. I would like to emphasize that ISO 62366 and AAMI/ANSI HE75 should be considered as companion documents. (I'll expand on this in the Commentary section below.)

Commentary

The article does support the contention that the FDA and the companies it regulates are paying increasing attention to usability and human factors. That they're paying enough attention is another matter entirely. As new medical devices are introduced we should see two things. First, the use error rate for the newly introduced medical devices (once users have adapted to them) should decline in relationship to other similar devices currently in use. Second, we should see over time the number of per year of deaths and injuries from medical errors begin to decline. This will take time to detect.

Without a doubt, the push by the FDA to define a human engineering process in the design and testing of medical devices, and to press for testing under actual or simulated conditions is needed. In many ways the FDA is mirroring many of the processes that have already been adopted by the US Department of Defense (DoD) in the area of human engineering. Admittedly, the DoD doesn't always get it right, there is an understanding within the DoD that it is important ... life saving, battle-winning important ... to insure that those at the controls can do their jobs quickly, effectively and with as few errors as possible.  So from that standpoint, the FDA has adopted processes from programs that have proven effective. But the FDA has just passed the starting line. And much more will be required going forward.

ISO 62366 vs AAMI/ANSI HE75

As I mentioned earlier ISO 62366 and AAMI/ANSI HE75 should be consider complementary or companion documents. HE75 is a much larger document than 62366 and includes a significant amount of device design guidance and guidelines. 62366 is almost entirely a process document that's devoted to directing how to go about managing the research and development process of a medical device. In addition, the focus of 62366 is managing risks, risks in the realm of reducing use errors.

I found it interesting that references to HE75 were not increasing at the rate as references to 62366. I would have expected Figures 2 and 3 to have a similar appearance with respect to 62366 and HE75 in large part because the documents significantly overlap. In fact I might have reasonably expected references to HE75 to outpace 62366 because HE75 includes design specific guidelines in addition.

One possible reason for references to HE75 not being referenced in the same accelerated way as HE75 may have to do with the fact that the European Union has not adopted HE75, so it's required for medical devices that will be marketed in the EU (CE).  (I am currently unaware of the regulatory requirements of other countries on this matter.) Medical device companies are international companies and the documents that they file in one country are generally the same in each country. Thus since the EU hasn't adopted HE75, references to HE75 and HE75's use as a foundational process and design document may be less.

DESIGN RATIONALE

I'm not sure that this is true at this point in time, but I am certain that the following will be true going forward at some time in the future. I believe that the FDA will hold companies to account for their user interface designs. I believe that the FDA will demand that companies clearly define how they came up with their user interface designs and that those designs are well-grounded in empirical evidence.

This is what I mean ... the FDA will demand that the design choices ... these include: controls, placement of controls, number of controls, actions performed by controls, the way the control responds, methods for interacting with the device (e. g., touch screen, buttons, mouse), size of the display, etc. ... for medical device user interfaces must be grounded in empirical data.

Commercial websites are often designed by graphic artists. Often times the design of webpages reflect the artist's aesthetic sensibilities. Layout appear they way that they do because they look good.

I believe that the FDA will require that user interface designs for medical devices have an empirically grounded design rationale. Companies will be required to point to specific research finding to justify the design and the design choices that they made. Furthermore, as the design of the user interface evolves with each iteration of testing, the FDA will require that changes to the design be based on research findings.

Finally, I believe that soon if it is not occurring already, that the FDA will require:

1. That companies submit documentation to show in detail the full evolutionary design process beginning from product inception, including ...
2. Detailed pre-design research ... population(s), method(s), research questions and rationale, etc ... as well as the findings and what they suggest for the design of the user interface
3. A design that includes with a full discussion of the design rationale ... why was it designed the way it was ... 
4. A detailed description of the evolution of the design that include full and clear justification(s) for each change in the design ... and require that changes be grounded empirical data 
5. A full description of pre-commercialization testing process and method ... with a clear justification for why this testing meets FDA testing requirements
6. And a complete and clear analysis of the testing data.

What I'm suggesting above is that the process of designing and testing a medical device user interface should be more than going through the prescribed steps, collecting the data, doing the tests, etc. There should be a clear thread that ties all the steps together. When in a subsequent step, one should be able to point back to the previous steps for the rationale to explain why the user interface was designed to appear and operate the way it does ... to this point.

As near as I can tell, what I described above is rigorous than is currently required by the FDA. However, I believe that it would be in any company's best interest to follow what I've suggested because there may come a time when the FDA's enforcement becomes more rigorous. 

Another reason may be lawsuits. If a company can show that it went beyond the FDA's regulatory requirements at the time, those suing would likely have less of a chance of collecting damages. And if damages were awarded, they may likely be lower. Also, if the company went beyond the FDA requirements, it would be likely that there would be fewer people injured and that should lower damages.

FINALLY

This article has been a springboard for me to discuss a number of topics related to human engineering for medical devices user interfaces. This topic will remain a central part of this blog. I'll return this within a week or two, and discuss in depth other topics related to the human engineering process for medical device user interfaces. 

HE-75, Usability and When to Prototype and Usability Test: Take 1

Prototyping and Testing will be a topical area where I shall have much to contribute.  Expect numerous articles to appear on this topic.

I had a discussion a few days ago with one of my colleagues who has worked as a user interface designer, but has little knowledge of human factors.  He was completely unaware of the concepts of "top-down" and "bottom-up" processes to user interface design.  I provide for you the essence of that discussion.

Top-Down Approach

The top-down approach begins with a design.  Most often the initial design is a best or educated guess based on some set of principles.  Could be aesthetics or "accepted" standards of good design, or something else.  The design is usability and/or acceptance tested in some manner.  (Anywhere from laboratory testing to field-collected data.)  In response to the data, the design reworked.  The process is continual.  Recent experience has suggested that the top-down approach has become predominant design methodology, particularly for the development of websites.

Top-down is a valid process, particularly for the deployment of new or unique products where the consequences of a failed design do not lead to serious consequences.  It can get a design into user hands more quickly.  The problem with a top-down approach (when practiced correctly) is that it relies on successive approximations to an ill-defined or unknown target.  To some degree it's similar to throwing darts blindfolded with some minimal correction information provided after each throw.  The thrower will eventually hit the bull's eyes, but it may take lots and lots of throws.

The top-down approach may have a side benefit in that it can lead to developing novel and innovative designs.  Although, it can have the opposite effect when designs are nothing more than "knock-offs" of the designs from others.  I have seen both coming out of the top-down approach.

Bottom-Up Approach

HE-75 teaches the use of a bottom-up approach where first one defines and researches the targeted user population.  Contextual Inquiry is also a bottom-up approach.  Since I have already discussed researching the targeted user population in depth, I'll not cover it here.  

With the bottom-up approach, the target is clear and understood.  And tailoring a design to the user population(s) should be a relatively straight forward process.  Furthermore, the bottom-up approach directly addresses the usefulness issue with hard data and as such, more likely to lead to the development of a system that is not only usable, but useful.

Useful vs. Usable

I'll address this topic more deeply in another article.  It suffices to say that usability and usefulness are distinctly different system qualities.  A system may be usable, that is, the user interface may require little training and be easy to use, but the system or its capabilities are not useful.  Or, and this is what often happens particularly with top-down approaches, much of what the system provides is not useful or extraneous.

Personal Preference

I am a believer in the bottom-up approach.  It leads to the development of systems that are both usable and useful sooner than the top-down approach.  It is the only approach that I would trust when designing systems where user error is of particular concern.  The top-down approach has its place and I have used it myself, and will continue to use it.  But, in the end, I believe the bottom-up approach is superior, particularly in the medical field. 

HE-75 Topic: Risk Management

One more HE-75 topic before proceeding into design and design related activities.  The topic, risk management.

Reading HE-75, you will note that this document continually discusses risk management and reducing risk.  In fact, the entire document is fundamentally about reducing risk, the risks associated with a poor or inappropriate design.

If you drive a car, especially if you have been driving cars for more than a decade or two, you will note that a driving a car with well-designed controls and well-laid out and designed displays seems inherently easier than one that is poorly designed.  Furthermore, it has been demonstrated time and again that driving safety increases when a driver has been provided well-designed controls and displays, driving become less risky for everyone concerned.

Car makers now see safety as selling point.  (Look at a car that was built in the 40s, 50s or 60s and you'll note how few safety features the car included.)  Manufacturers are beginning to include in their luxury models driver-error detection systems.  For example, one manufacturer has a system that signals the driver of the existence of an other vehicle the space the driver wants to move to.  One of the qualities of a well-designed user interface is the ability to anticipate the user and identify and trap errors or potential user errors, and provide a means or path for preventing or correcting the error without serious consequences.  Car manufacturers have been moving in this direction.  I suggest that the adoption of HE-75 will be the FDA's way of pushing medical manufacturers in the same direction.


Risk Management: Creating a Good Design and Verifying It


My many blog postings on HE-75 will address the specifics of how to create a good design and verify it, and the process of incorporating these design and verification processes in the a company's risk management processes.  In this posting I want to address a two issues at a high level.


First, I want to address "what is a good design and how to do to create it." Creating a good design requires a process such as one outlined by HE-75.  I am often amused at hiring managers and HR people who want to see a designer's portfolio having no conception regarding how the design were created.  A good design for a user interface is not artistry, it is a result of an effective process.  It should not only look good, but it should enable users to perform their tasks effectively and with a minimum of errors.  Furthermore, it should anticipate users and trap errors and prevent serious errors occurring.  And finally, it should provide users with paths or instructions on how to correct the error.  This is what HE-75 teaches in that it instructs researchers and designs   And to that end, the design process should reduce risk.  Think this is not possible?  Then I suggest you spend some time in the cockpit of a commercial airline.  It is possible.


Second, HE-75 teaches that design verification should be empirical and practiced often throughout the design process.  This is an adjunct to classic risk management that tends to be speculative or theoretical in that it relies on brainstorming and rational analysis.  HE-75 teaches that medical device and system manufacturers should not rely just on opinions - although opinions provided by subject-matter experts can provide valuable guidance.  HE-75 instructs subjects drawn from the targeted population(s) should be used to guide and test the design at each stage of the process.  This becomes the essence of risk management and risk reduction in the design of user interfaces.



Additional Resources

I have this book in my library.  It provides some good information, but it's not comprehensive.  Unfortunately, it's the only book I know of in this field.  
















These books I do not owe, but provide you with the links for information purposes.  I am surprised at how few books in the field of medical risk management there are.  It may go a long ways to explain the large number medical errors, especially the ones that injure or kill patients.

Risk Management Handbook for Health Care Organizations, Student Edition (J-B Public Health/Health Services Text) 

Medical Malpractice Risk Management 

HE-75: Collecting Data and Modeling Tasks and Environment

This article expounds on my earlier article related to AAMI HE-75: Know what thy user does and where they do it. 


Collect and Represent the Data


Ideally the first steps in the design process should occur before a design is ever considered.  Unfortunately, in virtually every case I have encountered, a design for the user interface has already been in the works before the steps for collecting user and task related data have been performed.


Nevertheless, if you are one of the people performing the research, do as much as you can to push the design out of your mind and focus on objectively collecting and evaluating the data.  And, in your data analysis, following the data and not your or the preconceived notions of someone else.


There are a variety of means for collecting data and representing it.  The means for collecting the data will generally involve:

• Observation - collecting the step-by-step activities as a person under observation performs their tasks.
• Inquiry - collecting data about the a person's cognitive processes.

Once the data has been connected, it requires analysis and representation in a manner that is useful for later steps in the design process.  Data representations can include:

• Task models - summary process models (with variants and edge cases) of how users perform each task.  This is different from workflow models in that in task models no references to specific tools or systems should be included in the task model.  A task model should be abstracted and represented at a level without reference to actions taking place on a particular device or system.
• Workflows - summary process models (with variants and edge cases) similar to the task flows with reference to a particular device or system.  For example, if the user interface consists of a particular web page, there should be a reference to that webpage and the action(s) that took place.
• Cognitive models - a representation of the cognitive activities and processes that take place as the person performs a task.
• Breadth analysis - I have noted that this is often overlooked.  Breadth analysis organizes the tasks by frequency of use and if appropriate, order of execution.  This is also the place to represent the tasks that users perform in their work environment but were not directly part of the data collection process.

Detailed Instructions


I cannot hope to provide detailed instructions in this blog.  However, I can provide a few pointers. There published works on how to collect, analyze and model the data by leaders in the field.

Here are three books that can recommend and several can be found in my library:


User and Task Analysis for Interface Design by  J. Hackos & J. Redish


I highly recommend this book.  I use it frequently.  For those of us experienced in the profession and with task and user analysis, what they discuss will seem familiar - as well it should.  However, what they do are provide clear paths and methods for collecting data from users.  The book is well-structured and extremely useful for practitioners.  I had been using task and user analysis for a decade before this book came out.  I found that by owning this book, I could throw all my notes away related to task and user analysis, and use this book as my reference.


Motion and Time Study: Improving Work Methods and Management 
by F. Meyer
Motion and Time Study for Lean Manufacturing (3rd Edition) by F. Meyer & J. R. Stewart


Time and motion study is a core part of industrial engineering as the means to improve the manufacturing process.  Historically, time and motion studies go back to Fredrick Taylor (http://en.wikipedia.org/wiki/Frederick_Winslow_Taylor) who pioneered this work in the later part of the 19th and in early part of the 20th Century.  I have used time and motion studies as a means for uncovering problematic designs.  Time and motion studies can be particularly useful when users are engaged in repetitive activities and as a means for improving efficiency and even as a means for reducing repeated stress injuries.  The first book I have in my library however it is a bit old (but very inexpensive) so I include the second book by Meyers (and Stewart) that more recent.  I can say that the methods of time and motion can be considered timeless, thus adding a book published in 1992 can still be valuable.

Time and motion studies can produce significant detail regarding the activities that those under observation perform.  However, these studies are time-consuming and as such, expensive.  Nevertheless, they can provide extremely valuable data that can uncover problems and improve efficiency.


Contextual Design: Defining Customer-Centered Systems (Interactive Technologies) by H. Beyer & K. Holtzblatt &

Rapid Contextual Design: A How-to Guide to Key Techniques for User-Centered Design (Interactive Technologies) by K. Holtzblatt, J. B. Wendell & S. Wood


The first book I have in my library, but not the second.  I have used many of the methods described in Contextual Design before the book was published.  The contextual design process is one of the currently "hot" methods collecting user and task data, and as such, every practitioner should own a copy of this book - at least as a reference.


I believe what's particularly useful about this contextual inquiry is that it collects data about activities not directly observered.  It's able but that affect the users and the tasks that they perform.  For example, clinicians engaged in the remote monitoring of patients often have other duties, many of them patient related.  Collecting data exclusively targeting remote monitoring activities (or the activities specific to a targeted device or company) can miss significant activities that impact remote monitoring and vice versa. 


Additional Resources


As a graduate student, I had the privilege of having my education supported by Xerox's Palo Alto Research Center.  I was able to work with luminaries of the profession, Tom Moran and Allen Newell on a couple of projects.  In addition I was able to learn the GOMS model.  I have found this model useful in that it nicely blends objectively observed activities with cognitive processes.  However, the modeling process can be arduous, and as such, expensive.  

Allen Newell and Herbert Simon are particularly well known for their research on chess masters and problem solving.  They were well-known for their research method, protocol analysis. Protocol analysis is a method that has the person under observation verbally express their thoughts while engaged a particular activity.  This enables the observer to collect data about the subject's thoughts, strategies and goals.  This methodology has been adopted by the authors of contextual inquiry and one that I have often used in my research.


The problem with protocol analysis is that it cannot capture cognitive processes that occur beyond the level of consciousness, such as the perception.  For example, subjects are unable to express how they perceive and identify words, or express how they are able to read sentences.  These processes are largely automatic and thus not available to conscious processes.  (I shall discuss methods that will enable one to collect data that involves automatic processes when I discuss usability testing in a later article.)  However, protocol analysis can provide valuable data regarding a subject's thoughts particularly when that person reaches a point where confusion sets-in or where the person attempts to correct an error condition.

Here's a link from Wikipedia: http://en.wikipedia.org/wiki/GOMS.


Another book that I have in my library by a former Bell Labs human factors researcher, Thomas K. (TK) Landauer, is The Trouble with Computers: Usefulness, Usability, and Productivity.


This is fun book.  I think it's much more instructive to the professional than Don Norman's book, The Psychology Of Everyday Things.  (Nevertheless, I place the link to Amazon just the same.  This is a good book for professional in the field to give to family members who ask "what do you do for a living?")  

Tom rails against the many of the pressures and processes that push products, systems and services into the commercial space before they're ready from a human engineering standpoint.  Although the book is relatively old, many of the points he makes are more relevant today than when the book was first published.  The impluse to design user interfaces without reference or regard for users has been clearly noted by the FDA, hence the need for HE-75.

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. 
 

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.