Submission of the Human Engineering File to the FDA and Other Regulatory Bodies, Sections 6 and 7: Part V

I cover Sections 6 and 7 in this article as shown below:

6	Summary of preliminary analyses and evaluations Evaluation methods used Key results and design modifications implemented in response Key findings that informed the human factors validation test protocol
7	Description and categorization of critical tasks  Process used to identify critical tasks List and descriptions of critical tasks Categorization of critical tasks by severity of potential harm Descriptions of use scenarios that include critical tasks

I consider Sections 6 and 7 together because the information for these two sections should have come from the formative stage of the research and design process. These two sections could be combined into a single section. However, it is apparent that the FDA (and probably other regulatory bodies as well) considers Section 7, Description and categorization of critical tasks, as important enough to have its own, separate section. 

Importance of Getting It Right

The contents of these sections, the descriptions and explanations provided, can be the difference between: 

• An easy, unquestioned acceptance of what you've done or
• A difficult, question-riddled review of the work that you performed resulting in:
• Approval delays, 
• A reworking of the submitted materials 
• Requests for additional research to be performed, or 
• Rejection of the human engineering file 

To fully address what should be included in Sections 6 and 7, you need to examine your entire HE process in the context of the research and development program of your medical device or system and determine whether your HE process can adequately address reporting requirements of these two sections. These sections form the core of the report of your research and design process up to the point immediately before you begin your final phase of testing, namely verification and validation (summative) testing.

Section 6: Summary of the Preliminary Analysis and Evaluations

What Should be in Section 6

I briefly cover the points of what should be included in Section 6. Assuming that you are a human engineering professional, you should already have a reasonable understanding of the meaning of each of three requirements listed below. 

1. Evaluation methods used

This comprises the entire body of research performed including all of the data collected before the implementing a foundational or initial design, and all of the testing performed on the design.

2. Key results and design modifications implemented in response

What findings from your research lead to you to creating your initial design and what where the factors that lead you to modifying your design?

3. Key findings that informed the human factors validation test protocol

How did your arrive at creating your research protocol for summative/validation testing? How do you know that your validation protocol is appropriate and will verify that your system or device is safe for use?

That's the brief overview of what should be in Section 6. However, what should be included in Section 6 are the logical threads of justifications for doing what you did: for creating your research and development plan, the initial/foundational design and how you went about modifying that design. 
   
Don't be deceived by the seeming simplicity of Section 6. It is far more complicated and demands much more investigative and design process rigor than one might imagine. 

Human Engineering (HE): Research and Development

Section 6 is the section where you lay out all research and development performed in relationship to human engineering. Thus, Section 6 becomes the place where you make your case for the research that you performed and the design choices that you made. After reading Section 6, the reviewer should have a clear understanding and be in agreement with the research and design process that was undertaken. This includes the rationale for the research plan as proposed and undertaken including the rationale for any changes made to the plan on the basis of research findings. It will include the rationale for the design process, including the initial or foundational design and the reasons for changes made through the design iteration process.

Human factors is the study of how human interact with or operate systems and devices. Its fundamentally research. Human engineering incorporates the human factors, but encompasses and  incorporates design and the design process that should be at its foundation, driven by research. The research that directs and informs design and the design process includes field, laboratory, library, risk or research-based standards. And in the absence of the ability to collect empirical data: scenarios and interaction walk-throughs and analysis. 


You will need to defend your rationale for the specific research projects undertaken and the design choices made. Because the narrative is an overview, it's often a good place to explain the much of the logic for the research undertaken and the design choices made.

Defending HE Research and Design Planning and Choices

Adequate and effective justification of your research and development plan and design choices will often be the key to insuring unquestioned acceptance of your submission. Here are some suggestions:

1. Justifying the Research and Development Plan -- the means for creating a usable and low-likelihood use-error and low risk system or device. Reasoning and justifications for the creating a research and development plan for this system or device include:
• Compliance with IEC 62366 (part 1).
• Conformance to FDA HE program guidance (on the FDA website).
• Guidance from AAMI/ANSI HE-75
• Guidance from previous, similar and accepted plans 
• This system or device is a next generation release of a currently, commercially available product. Thus the research and development performed along with field collected data provide guidance for research and design plan for this next generation product.
2. Justification for performing specific research include:
• Planned research
• Research fits within the guidelines set within the research plan.
• Research is designed to answer specific research questions. Often during a research program, questions arise that may be human performance, design specific, etc. that may not have been specified in the research plan. Often times these types of studies are applicable to the research and development of a variety of device and systems. In this case the research is "question-driven." Those research questions need to be clearly defined out within the research protocol and become the clear justification for the research and the applicability and potential value of the findings.
• Findings from planned research suggest the need for new research not originally planned.
3. Justification for the foundational design: is initial design that is prototyped, usability tested and then iterated. The foundational design establishes the basic design philosophy (appearance and operation) that will likely be commercialized. While the foundational design will likely be updated and improved throughout the research and development process; fundamentally, it will likely maintain the same design philosophy. Thus, establishment of the foundational design maybe the most consequential step in the research and development process. Justifications for the foundational design include:
• Updated version of an earlier, accepted design: using the same design philosophy. Updates and improvement driven-by field research, customer feedback, research on the use of the system under actual conditions.
• Findings from formative research as defined by the research and development plan undertaken before initiating a design.
• Compliance with accepted design standards, e.g., AAMI HE75. (There are a wide array of design standards issued and accepted by the US agencies as well as other agencies of a variety of countries. When localization of a design is required, the design standards issued by the targeted country should be considered and referenced.)
4. Justification for changes made to the foundational and modified designs.
• Findings from prototype testing.
• Findings from expert reviewers: resulting from design walkthroughs/reviews and/or interactions with the device or system.
• Limited field tests of prototypes.
5. Justification that the design has reached the stage for verification and validation (summative) testing. And that a research protocol can be written that can effectively and realistically test the system or device to demonstrate that the system or device will be safe for use by members of the targeted population in the intended use environment(s).
• This is the hand-off point to the summative testing phase.
• Justification that that the system or device is read to hand off: The formative testing up to this point should have subjected the system or device to the all of the testing that it would be subjected-to multiple times. And the system or device should have passed those tests multiple times. Thus, if the research and development plan was properly executed nothing of any concern should come from verification and validation testing. If there are findings that are the least bit concerning, then it is time to reexamine your research and development planning and protocols. 
• Finally, if your formative testing, meaning all of the testing performed up to this point, has been comprehensive,  rigorous and complete, then that testing should dictate the verification and validation research protocols.

What Should be Included in the Section 6 Narrative

I suggest that your narrative should be written in the form of a story. It should be a narration that describes in a linear fashion (from the beginning to immediately before the validation step) what you did, why you did it: 

• if it's research, summarize what you did and what you found, 
• if it's your foundational design, provide an high level description of how you arrived at this design (include enough figures to be sure that a reviewer will understand your description) and
• if it's a design update, explain what change or changes were made and why.

Be sure to include references to your submitted materials in your HE file.

Section 7: Description and categorization of critical tasks

Identifying the critical tasks that will be performed on your system or device should be part of formative research. Often the ability to identify the set of critical tasks is beyond the expertise of the human engineering professional and identifying as well as categorizing the critical tasks requires the support of subject-matter experts (who should be included from the beginning of the formative research stage). My experience has been to integrate subject-matter experts into the research and design process from product inception.  

The list of requirements for Section 7 include:

1. Process used to identify critical tasks

With your subject-matter experts, describe the process used to identify your critical tasks. 

2. List and descriptions of critical tasks

Include with this your justifications and reasoning for this list. 

3. Categorization of critical tasks by severity of potential harm

In addition, if any of your critical tasks have the possibility of inflicting moderate to critical harm, I suggest that mitigations developed to minimize the likelihood that harm would ever occur. 


4. Descriptions of use scenarios that include critical tasks

These use scenarios should form a fundamental part of both your testing as well as justification and rationale for your design (and updates to your design.)

Section 7 Narrative

I suggest that in your narrative that you include a table with the information from items 2 and 3 above. I would add a brief summary of the process that was used to identify your critical tasks. Finally, include a reference to the use scenarios that include the critical tasks. You don't need to include them in your narrative, a reference should be sufficient. 

______________________
Note: I plan on periodically updating this article as I learn more and reconsider what I have written. With each update, I'll include at the top of this article, when it was updated and list some of the changes that I have made. 

Commentary: HE-75 and IEC 62366 and Cleaning Up the Messes

I received a reminder recently when I was made aware of the International
Consortium of Investigative Journalists' database of medical device recalls of what human factors professionals working in the area of human engineering for medical devices are often called on to do: clean up the mess created by a failed design process that somehow failed to incorporate research. (Note that medical device development isn't the only domain where this kind of failure occurs, however, the impact of medical device failures can often result in fatalities.) The persons responsible for designing an awful, unusable and in some case, useless user interface expect the usability expert to come in, take one look and create a beautiful user interface. This is absurd!

Writing from my own perspective, there is nothing that a usability professional likes to do less than to correct a failed design that resulted from a failed design process. This week I was asked to save a group of programmers and user interfaced designers from the monstrosities that they had created. What was particularly strange was that the leader of the project thought that I could just redesign something by looking at what they had created. It was bizarre. Unfortunately, I had to deliver several harsh messages regarding the design process and the design, that were not well received. (Nevertheless, that is my job.)

Here is the point I want to make clear to anyone who reads this: Process and the resulting design should be considered as two sides of the same coin. The outcome of a good design process generally results in a good design. A nonexistent or poor design process often times leads to a poor design and a design that gets worse with each design iteration when attempts are made to fix problems or incorporate enhancements.

The processes and design direction provided by HE-75 and IEC 62366 can serve as a foundations for research and designing systems with user impacts within nearly any industry, particularly in those industries where the potential for harm is likely.

Careband: Keeping track of those with dementia

I was at an evening venture capitalist meeting on 13 November 2018. I'm not a venture capitalist but I have a few connections to this community and I periodically receive invitations to their meetings. Most of the time I pass on attending. I'm interested in science, mathematics and technology. VCs are interested in ways to make money. Nothing against them. We just live on different planes of existence.

However, I attended this meeting because I read the description of one of the companies doing a presentation, careband (http:www.careband.co).

careband

Careband provides a capability to track the location of people with dementia. This is a more difficult problem than you might imagine. In institutions, patients with dementia are known to wander away: from the institution, from their homes, from family members. The patients do not know where they are or how to return. Institutions who care for dementia patients frequently need to find their patients who have wandered away from the institution's grounds or to areas of the institution that caregivers do not expect that they would be able to wander. 

Thus there's a clear need to be able to keep contact track of dementia patients. To know where their location at all times and be notified when they've wandered off the grounds of the institution.  Here's a page from the careband.co website that summarizes the capabilities of their system.

The diagram above shows the elements of system for patients and customers/caregivers -- those responsible for caring for the dementia patient(s). Caregivers can see at a glance the current location of each patient. Each dementia patient wears a band about the size of a large wristwatch on the wrist that periodically sends a location related message to the network. All data is sent to careband's cloud server system. Patient location data is made accessible to the caregiver systems that are connected to the cloud server system.

The wrist bands connect to the Internet to the low-power communications system: LoraWAN. More information about this wireless data communications network is available here: https://lora-alliance.org/about-lorawan The LoraWAN network is a low-power, low-speed (0.3 kbps to 50 kbps) but long distance (up to 3 miles from an access point outside) and robust wireless communications system. 

The wristband also includes Bluetooth that is used to provide indoor location data. And an accelerometer has been included to provide information regarding whether the patient has moved his or her body during the reporting period. 

I am not familiar with all of the current capabilities of the careband.co system. However, I know that the wristband continually transmits to the cloud the following data:

• Patient ID data
• Transmission time 
• Location data
• Movement (whether or not the person has moved from the time of the last data transmission and the time of the current data transmission)
• Battery charge level

How careband.co is currently analyzing is something of which I am presently unsure, but there are a number of pieces of information that can be derived from this relatively small amount of data. Here's what's possible:

1. Current patient location
2. Map of patient's activity and the distance covered over time
3. Amount of time that the patient was moving
4. Alarm initiation: should the patient stray away from the institution, the system can automatically notify the caregivers. (Boundaries should be able to be drawn on the display.)
5. Trend and trend line analysis for patient activity time and distance covered. These could be indicators of the patient's cognitive health. Significant deviations from calculated trend lines could be indicators of a slip or improvement in a patient's cognitive and/or physical health.
6. Suggest that the patient has removed the band from his or her wrist (when the patient appears not to have moved during normal activity time) or that the patient maybe in distress or died.

There could be more information that can derived from the wristband data that I have yet to think of. As I come up with additional thoughts regarding this, I shall post them.

Upgrades to the wristband could include pulse oximetry and pulse rate data. Again, there are other capabilities that could be added that I have yet to think of.

Since the transmission speed is so low, careband.co will likely need to develop a data compression system to effectively communicate this data back to the cloud server system. 

Careband.co is one more interesting product for remote medical monitoring. It's not designed for remote patient management largely because most patients will normally be closely supervised. However, it could be an aid to enable people with dementia to live for a longer time in their own homes. The benefits to both the patient and to society are massive. Six months to a few years of being able to live in one's own home would improve both the quality of life for people with dementia and significantly, dramatically reduce the cost of care.

I shall continue to monitor careband.co's progress. Stay tuned.

Careband.co plans on making their products available through medical device distributors. Their products are not yet commercially available. They are about to manufacture the wristband. Their wristband has been approved by the FCC. FDA approval is not required.  If you are interested in purchasing their product, please contact them at care band.co.

I should mention that careband.co is looking for investors. If you're interested in what careband.co is selling, please contact them directly using the URL listed above.

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. 

Are Electronic Prescription Systems Failing to Trap Errors?

A Brief Introduction

Before I jump into the topic of electronic prescription systems, I want to make known how I came across the article I am about to post. I am creating a website that includes a substantial portion of the human factors related work I have produced over the years. That website also includes posting articles on the home page related specifically to human factors - and that includes article related to medical errors: a topic of interest to me.

The new human factors website is not yet ready for viewing. I have just created a usable home page. The bulk of the work is to come. I'll post the address when it's reached a usable state.


What's Going on with Electronic Prescription Systems?


Bloomberg news recently reported the results of a study that indicated that prescription errors are as frequent whether handwritten or written through an electronic prescription system. Here is the address of the Bloomberg article:
http://www.bloomberg.com/news/2011-06-29/errors-occur-in-12-of-electronic-drug-prescriptions-matching-handwritten.html

I have not yet had the opportunity to read the study. However, I shall and I'll continue to update this blog on this topic based on what I find. 


With respect to the Bloomberg article, this quote caught my eye:


"The most common error was the omission of key information, such as the dose of medicine and how long or how many times a day it should be taken, the researchers said. Other issues included improper abbreviations, conflicting information about how or when to take the drug and clinical errors in the choice or use of the treatment, the researchers said."


I have been a human factors professional for a long time and as I read the quote above my jaw dropped. The errors described in the quote are some of the most fundamental and easily trappable and correctable errors. It seems beyond belief that an electronic prescription system would allow a user to make such errors. In the environments where I have worked, I have designed and installed subsystems to insure that users do not make the kinds of errors as described in the Bloomberg article. When I have a chance to read the report, I'll cover specific errors, their detection and correction. And means to insure that patients are not harmed.


Here's a link to another publication that reported on the same study:


http://www.eurekalert.org/pub_releases/2011-06/bmj-oep062811.php

HE-75 Topic: Cleaning Up the Mess

I received a reminder this week of what usability professionals are often called on to do – cleaning up the mess created by a failed process. Somehow, the persons responsible for designing an awful, unusable and in some case, useless user interface expect the usability expert to come in, take one look and create a beautiful user interface. This is absurd!  It was the "nightmare" come true - something related to one of my other postings: HE-75 topic: Design first and ask questions later

Writing from my own perspective, there is nothing that a usability professional likes to do less than to correct a failed design that resulted from a failed design process. This week I was asked to save a group of programmers and user interfaced designers from the monstrosities that they had created. What was particularly strange was that the leader of the project thought that I could just redesign something by looking at what they had created. It was bizarre. Unfortunately, I had to deliver several harsh messages regarding the design process and the design, that were not well received. (Nevertheless, that is my job.)

Here is the point I want to make to anyone who reads this. Process and the resulting design should be considered as two sides of the same coin. Good design process nearly always results in a good design. A nonexistent or poor design process leads to a poor design. HE-75's design process can serve as a foundation design process for designing user interface in nearly any industry, particularly in those industries where the harm is particularly severe. Where I am currently working, I plan to use HE-75 as one of the foundation documents to set user interface design standards. And as I mentioned, I am not currently working in the medical or medical device industry. However, I have come to believe that in this industry, the level of harm can be significant. Thus, I shall incorporate HE-75.

 

Next time, I'll review so of the literature that might be of some use to the community.

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 Touch Screen Recommendations

I have found HE-75 to be one of the best human factors standards ever produced.  However, I have found their analysis and recommendations regarding touch screens lacking, and out of date.  To place a perspective on the HE-75 touch screen recommendations ... in the late 1980's and early 1990's, I ran a user interface design and implementation project inside of a larger project at Bell Laboratories.  To make a long story short, one of the user interfaces we needed to design and produce was a touch screen interface.  The touch screen used a CRT as a display device and it was as flat as we could make it.  In addition, the distance between the touch screen surface and the display was about 35 mm.  When I read of the issues related to touch screens and the recommendations in HE-75, I experience deja vu and I feel as if I've been transported back to that time.

Some of the most significant advances in user interfaces have been in the areas of display technology and touch screens with respect to hardware and in particular software.  Apple Computer has been a leader in combining the advances in both display technology, touch screen design and touch screen interface software.  I would have expected the HE-75 committee to have incorporated these advances and innovations in touchscreen software into the standard.  However, what I have found appears to me as ossified thinking or ignoring what has transpired.  

People in the medical field are using smart phones with their advanced touch screen interfaces in their medical practice.  Smart phone touch screens and now the Apple iPad have become the de facto standard in touch screen technology.  My previous article related to consistency ... here's a consistency issue.  Is it wise to suggest that medical device touch screen interfaces look and operate in a way different from the accepted standard in the field?  I know this is not a simple question, but I think it is one that will need to be addressed in future editions of HE-75.

Medical Implant Issues: Part 1, A True Story

When I started this article, I thought I could place it into a single posting.  However, having written just the first section, noted it's length and how much more there was to write.  Thus, I decided to turn this into a serialized publication just as I am doing with HE-75.  Thus, here is Part 1 ...
 

Part 1: Background Story

Before I dive into the technical details of this issue, I want to tell a true story from my own experience.  It involves a friend of mine.  (I need to be vague regarding the person's identity including gender and how I came to know this person.  As you read this, you'll understand.) 

My friend was incredibly intelligent (e. g., the best applied statistician I have ever known) and physically attractive, and diagnosed as a paranoid schizophrenic.  In the early 1990's, my friend underwent back surgery.  To my amazement, my friend claimed that the surgeon had placed a "chip," small processor into the person's spinal cord.  My friend said that the chip could be activated by people with controls that looked like garage door openers.  When activated, the chip would cause my friend to have a sudden, overwhelming desire to have sexual relations with the person who had activated the chip.  My friend called this chip a "tutu."

At the time I had been part of the cutting-edge technology community to know that such a chip was absurd.  And I told my friend that this chip did not exist. My information was not well received by my friend who was convinced of the reality of this chip.

I tell this story because at the time my friend informed me of the "tutu," the idea of embedding a chip in a human being and activate it using wireless means was patently absurd.  Embedding programmable chips with wireless communications less than a decade and a half later is no longer considered absurd, but real.  And for some people, frightening with religious overtones.  Consider what the Georgia state legislature just passed and you'll understand what I mean.  Here's a link to that article: Georgia Senate Makes "Mark of the Beast Illegal."


The reaction from the Georgia Senate makes my paranoid-schizophrenic friend's story seem plausible.  Interestingly enough and I did not realize it at the time (but I do now), that was my introduction to wireless, medical remote programming.  As I said, my friend was extremely intelligent and as it turned out more creative and prescient than I realized at the time.  Turns out that today a device embedded in the spinal cord with the ability to trigger sexual experience is real.  And the ability to embed microprocessors and controls in people with the capability of wireless communication and medical management is also real.


I tell you that story not to make light of people's stories and fears, but as a "sideways" introduction to the technical topic of dealing with multiple, embedded medical monitoring and remote programming systems.  And to suggest that people may have real fears and concerns regarding the capabilities that technologists like myself often overlook.  In this series I discuss real and imagined fears as well as the technical problems with multiple, implanted devices.




Part 2: Multiple, Implanted Wireless Communicating Devices

Books sold by Amazon that might be of interest in this series

New Frontiers in Medical Device Technology

MEMS and Nanotechnology-Based Sensors and Devices for Communications, Medical and Aerospace Applications
 

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.

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.

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.

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.