Massive Market and Growth
The growth of the mHealth industry has product developers and software engineers increasingly focused on the regulatory acceptance criteria they may face when developing these apps. Research2Guidance, a global mobile research group, states that 500 million smartphone users are expected to be using mHealth medical apps by 2015. Today there are approximately 97,000 mHealth medical apps available, and sales of medical apps are expected to reach $26 million by 2017.
In the Farm blog The Rise of Mobile Health and the Importance of Human Factors, many of the drivers contributing to the explosive growth of mobile software development are highlighted, including economic and technology trends and the ubiquity and convenience of mobile platforms. It’s clear that healthcare information, made available to both consumers and healthcare providers via mobile devices, has the potential to reduce healthcare costs and improve care across multiple point-of-care environments.
To provide clarity and direction for mHealth medical app developers, the U.S. Food and Drug Administration (FDA) has developed guidance outlining the suggested path to approval and including a set of definitions on what is and is not regulated. The FDA differentiates between a wellness app and a potential medical device (such as a device that uses an mHealth medical app). This is an important distinction for developers, since the FDA has said it will not regulate wellness apps, and thus the documentation burden for the developer falls within more traditional development practices. Per these guidelines, an mHealth medical app will be regulated if it is:
- An app that displays, stores, analyzes, or transmits patient-specific medical device data
- An app that transforms or makes a mobile platform into a regulated medical device
- An app that performs actual medical device functions
- An app that allows users to input patient-specific information and provides patient-specific results, diagnosis, or treatment recommendations used in clinical practice or to assist in making clinical decisions
Present and Evolving Guidance
The current guidance for mobile medical applications was issued in 2011. This guidance provides some support to manufacturers by categorizing mHealth medical apps by risk to patient and addressing the level of development (including testing) documentation expected for each risk class. This guidance helps the developer determine accurate costing and time estimates. These guidelines also help determine which of the existing mHealth medical apps are to be classified as Class I (general controls), Class II (special controls in addition to general controls), or Class III devices awaiting premarket approval (PMA). Class I devices or MDDS (medical device data systems) are considered to be the least risky, and the FDA has exempted them from any regulatory requirements. mHealth medical apps that provide electronic transfer, storage, or display of medical device data qualify as Class I devices. Class II devices require filing for 510(k) clearance and include products such as mHealth medical apps that display radiological images for diagnosis. Class III devices requiring PMA may require clinical trials if the app is novel (with no predicates). An mHealth medical app also must be FDA approved if it is an extension of an FDA-approved and regulated medical device.
The FDA is making an effort to address concerns and provide oversight on guidance issues. It is important to be aware that congress is also asking for clarification on this effort. According to MobileHealthNews, as of March 15, 2013, a letter has been sent to the FDA seeking clarification on the agency’s intentions:
In an attempt to fill the gap, the guidance goes on to call out additional standards and regulations for subjects such as:
- Software verification and validation
- Off-the-shelf software used in medical devices
- Cybersecurity for networked devices containing off-the-shelf software
- Radio frequency wireless technology in medical devices
These regulations and guidelines, as well as the guidance for the content of premarket submissions for software contained in medical devices, provide insight into what is expected in a premarket submission for performance and process documentation, the potential high-level risks an app may encounter, and areas where field issues have occurred. By reviewing these publications, an mHealth developer who has little or no experience working in the regulated medical device market will have the key information required to develop a plan and a process for creating, testing, and documenting an app that can be submitted with the best chance for clearance.
Software Development Regulation
Critical to mHealth software development is guidance for the development process itself. The FDA does not author its own standards, but has chosen to recognize the European standard for software development ANSI/AAMI/IEC 62304:2006. A detailed discussion of this standard is included in the online article Developing Medical Device Software to IEC 62304. The European standard uses a patient risk method for identifying risk associated with device software, and relies heavily on ISO 14101:2007 for a risk management approach to be followed throughout software development.
For mHealth developers who are unfamiliar with regulated software development, Happtique, a mobile health software development company, has created a voluntary program that provides a set of interoperability guidelines. Designers who follow these guidelines and apply to have their mHealth medical apps tested will receive certification for their mHealth medical apps, informing the consumer that they have achieved this level of interoperability. The program has been reviewed by the FDA and is seen as a complement to its regulatory requirements. This is covered in the article Happtique Publishes Final Standards for Mobile Health App Certification.
While these numerous standards, regulations, and guidances are complex and may prove confusing, there are some basic steps that developers can take in order to provide a clear and predictable development path:
- Thoroughly understand the app’s intended use. It’s important to be able to define the intended use for an mHealth application and communicate its use precisely, including benefits the app provides to the end user and patient and, if possible, including what the app is not intended to do. Not only will this have a positive impact on the marketing of an mHealth app, it helps define the depth of process and documentation needed throughout the development process
- Follow existing FDA and international guidance relating to communication, electrical, and platform hardware, so that key risks can be avoided. Create a development process that will identify risk factors contained within hardware components, wireless protocols, operating systems, and platform-specific interferences, and from both a technical and a user perspective. Identify critical issues and create an approach that will minimize or eliminate them. Consider using FDA’s MAUDE database in order to mitigate risk
- Create a software development process according to the ANSI/AAMI/IEC 62304:2006 standard in order to support safe software that meets performance requirements
- As defined in the blog article The Rise of Mobile Health and the Importance of Human Factors, follow ANSI/AAMI HE75:2009 to ensure that the mHealth app will be safe and easy to use
- Consider an iterative implementation approach, rank risks and design mitigations around the highest risks. Implement and test those first, both for performance and for usability (by testing with real users). Build small increments and test those, continuing until all functionality is implemented and the risks have been minimized or eliminated
- For mHealth apps that will be used on multiple platforms, target implementation by most-to-least market impact, then go through the same iterative development path
- According to regulations, developers must monitor released applications for safety and effectiveness issues. mHealth developers should follow FDA CAPA guidance to improve the development process
- Finally, use well-established development and design, and incorporate testing tools, to reduce the probability of defect introduction
Home healthcare and the use of medical devices outside of the professional healthcare environment are on the rise. Modern medicine allows us to live longer and provides those with chronic diseases the ability to receive medical care at home. Examples of home-use devices are oxygen concentrators, hospital beds, sleep apnea monitors, body-worn nerve and muscle stimulators, and dialysis machines, just to name a few.
According to the NAHC (National Association for Home Care & Hospice), approximately 7.6 million individuals are receiving home healthcare in the United States from roughly 17,000 paid providers. Not only does home healthcare improve recipients’ quality of life, but it also provides cost savings. Looking at the chart below, you can see the cost advantages to receiving care at home.
Despite the advantages, employment of devices outside of professional healthcare facilities increases the risk of harm through unintended or potential misuse, driving an even greater need for devices to be designed using human factors principles to mitigate these risks.
In the past, manufacturers of home healthcare equipment were required to comply with IEC 60601-1, demonstrating that their designs mitigate the risks associated with use in the home by patients or caregivers. In 2010, a new provision, IEC 60601-1-11 was published, turning attention specifically towards Requirements for Medical Electrical Equipment and Medical Electrical Systems Used in Home Care Applications. Also in 2010, the FDA started the Medical Device Home Use Initiative to "ensure the safety, quality, and usability of devices labeled for home use." Accordingly, the agency states that it will take the following actions to support the safety and safe use of medical devices in the home:
- Establish guidelines for manufacturers of home-use devices;
- Develop a home-use device labeling repository;
- Partner with home health accrediting bodies to support safe use;
- Enhance post-market oversight; and
- Increase public awareness and education.
These steps will help address the challenges associated with the use of medical devices in the home and provide greater protections for patients receiving home healthcare.
As part of the initiative, a new draft guidance has been written to help manufacturers "design risk out of the device." Draft Guidance for Industry and Food and Drug Administration Staff, Design Considerations for Devices Intended for Home Use is meant to provide advice and summarize other guidance documents available to manufacturers, citing over 24 documents and international standards. It is important to remember that the guidance was created to help manufacturers understand all variables that should be taken into account when designing a home-use device, but that it is not possible to follow all of the guidelines simultaneously. Designers should follow the guidelines to the extent possible, which will help the FDA to evaluate the device’s requirements, functionality, and safety.
How are “home-use devices” and “environments” classified?
A home-use device is a medical device intended for users in any environment outside of a professional healthcare facility or clinical laboratory. The term includes devices intended for use in both professional healthcare facilities and homes.
A user is a lay person such as a patient (care recipient), caregiver, or family member who directly uses a device or provides assistance to the patient in using the device.
A home is any environment other than a professional healthcare facility or clinical laboratory where a device may be used.
Note that the word "home" is being used loosely to mean ANY location in which you use the device outside of a professional healthcare facility or clinical laboratory. Thus, it could be your primary home, your vacation home, your car, public transportation, outdoors, or any other non-clinical location.
It is vital to take into consideration the potential environment(s) where the device may be used. Just a few of the challenges are:
- There may be few electrical fixtures and they may not be up to code;
- The lighting may be poor;
- The home could be quieter or louder than a hospital environment. For example, children or a loud TV can add to noise level;
- Homes, vehicles, and public spaces are not always designed to mitigate maneuverability barriers; and
- Sterility and cleanliness in a home will not be the same as in a clinical setting.
So what should manufacturers do when designing their next home-use device? Consider the following high-level summary based on my review of ANSI/AAMI HE75:2009, Section 25, on home healthcare and the draft guidance on home use:
- The User - Front and center to the design of any product is the user. Who is the ultimate user of the device: the patient, the caregiver, a visiting nurse, or other person? Can the device be used by the intended population? Might the user have sensory, cognitive, or physical limitations? For example, is the device designed in such a way that someone with dexterity issues can use it properly without having to ask for help? Can they hear audible feedback from the device and see the screen well enough?
- The Use Environment(s) - Just as important as the user, the use environment must be strongly considered. Is the device stationary or mobile? Whether in the home or on the go, it is not possible to rely on proper power outlets and thus would require an alternative power source (e.g., batteries). If alarms are part of the device, manufacturers must ensure that they can “be heard in uncontrolled noise environments typically found in the home." Also consider whether the device will be permanently attached to the user in both private and public settings. How will the user bathe? Will it be comfortable when he or she is sleeping? Should it be made as inconspicuous as possible? How will he or she get through security scanners? The use environment(s) also will play heavily into design considerations as it relates to durability, potential exposure to the elements, and whether or not it can safely function in the expected conditions.
- Device Considerations - Multiple guidance documents exist to aid in the design process, offering a mix of regulations and advice. Manufacturers will find considerations related to such things as:
Training - Device training can take many forms: instructions for use, device labels, information sheets, and formal training, among others. Keep in mind that some users may not be able to understand multiple steps or a long list of warnings and precautions. Additionally, manufacturers should weigh the importance of training users in addition to providing written instructions. Tutorials built into device software can be helpful in cases where the device is used infrequently or the user may be slightly impaired (e.g., low sugar clouding mental judgment).
Post Market - What kind of support will be provided to the user once he or she is home using the device? Will 24-hour customer support be available? What happens if the device malfunctions or breaks? Users need to understand their options and what to do if they run into problems.
- Design controls and software;
- Learnability and intuitiveness;
- Sound;Labeling; and
The standards and guidance documents can assist manufacturers in developing safe, usable products. However, home-use devices still require extensive testing with the intended users—in simulated environments and later in actual home-use environments—to ensure their usability, understandability, and safety. If manufacturers consider the human factors that are specific to home-use devices, then they, their users, and the healthcare system as a whole will realize the benefits.
In my medium-term professional life of nearly 20 years, I have experienced the rolling hills of good and bad workplace culture. In many companies the term “culture” is often thrown about by HR for hokey team-building exercises, but is rarely well defined. It is one of those emotional terms people instinctively feel is either good or bad. Culture is a complicated equation with multiple input variables like diversity, financial footing, and ideology that hopefully outputs success. The most positive and successful company cultures have the following high-level attributes.
An open atmosphere that encourages creative thought.
In the consulting world, we live and die by our creativity. The freedom to express an idea in a group brainstorming session is critical. Even a bad idea (I’ve had more than a couple) has the potential to inspire someone else into a winning concept. When employees are encouraged to express themselves, free of a creative dictator who bullies meetings, the best ideas quickly rise to the top because nothing is held back.
A diverse group of people who can look at a challenge from multiple angles.
Diversity obviously plays a key role in creativity and culture. The best ideas come from people with the farthest reaching experiences. Staffing people from different corporate, social, and interest backgrounds produces the most diverse concepts because the pool of knowledge is that much bigger. A great company culture needs a broad spectrum of viewpoints to both develop great products and provide an interesting workplace.
Cross-functional teams uninhibited by psychological or physical walls.
Once the key people are in place, the internal teams need to work together. This is probably the single largest hurdle to positive corporate culture in large organizations. I can swing a hammer with the best of them, but milling a precision slip fit is a totally different issue. I need to know where to go and who to see for the optimal solutions to my problems. Physical barriers like separate buildings or even high cubical walls often compartmentalize people and unintentionally nudge employees into “defending their space” instead of valuing the people they work with. An openness and mutual cooperation can naturally develop when groups of talents (like engineers and designers) are mixed in one location and interact face to face on a daily basis. Innovation does not stop at boundaries, it overcomes them.
A means for a group and individuals to control productivity.
An often underestimated catalyst to a positive company culture is a department budget. Speaking as an engineer, we need tools to most efficiently do our work. A budget we can spend as we see fit (free of multiple approval signatures) is wonderfully liberating. It improves productivity by allowing employees to purchase tools they are excited to learn while making their jobs easier. Shiny new toys also have the added benefit of keeping people engaged while at the same time improving the company’s overall capability.
An internal quality/regulatory system that puts the idea first.
A positive culture is also fostered by an internal development system free of creative impediments. There is nothing more inspiration killing than the thought of forms, signatures, and cross-functional team approvals that need to be navigated before pencil can even be put to paper. Without question, standards and internal quality requirements are critical to manufacturing safe and effective products, but at the knife’s edge of concept creation there should be total freedom. That is by far one of the best parts of working for a consultancy. Our internal procedures were created around the framework of unimpeded development. Creativity comes first.
Contrary to the musings of academics, there is no set path to a utopian society. Human beings are wonderfully unique in thought, passions, and personality, but there are a few simple building blocks companies can put into place to foster a positive corporate culture. Leveraging the unique qualities of individuals to work together toward a common goal can be achieved when they are motivated, feel they have some control of their destiny, and are free to express themselves.
The words “Design of Experiments (DOE)” and “Taguchi” usually conjure up images of cell phones coming off the manufacturing line while someone inspects them for defects. The intended application for DOE is in the manufacturing world, so it’s easy to see why the product design community often neglects these methodologies. However, my experience implementing DOE into product design shows otherwise. Using screening designs, where applicable, can save design firms (and the harried engineers doing endless testing) time, money, and resources.
A DOE is loosely defined as purposeful change to the inputs of a process to observe change in the outputs. Whether we choose a fractional factorial or a full factorial does not change the fact that we are using DOE, unless we are picking a method without being mindful of the advantages and disadvantages of our selection. The image below illustrates the relationship among DOE (also referred to as Experimental Design), screening designs, and the Taguchi method. The Taguchi method is a type of screening design, which is a type of fractional factorial, which falls under the umbrella of DOE along with full factorial.
Becoming an expert in Design of Experiments often requires entire courses, poring over textbooks devoted to the subject, and spending hundreds of hours on real-world experimental design and analyses. A little bit of linear algebra helps as well. The advantage of Taguchi screening designs is that they provide a taste of the subject without requiring a degree in statistics. Engineers can access standard tables and available software, and become “experts” in screening designs over the course of a few hours.
Types of projects in the product design world that might be good candidates for a screening design include:
- A product that is not meeting expected performance results
- A large number of concepts that need to be narrowed down to a few
Popular Experimental Design Methods
How many of us have gone into the lab only to return with more questions than answers? Mechanical engineers like me, who are not usually trained in statistical analysis, tend to employ one of two experimental methods: full factorial or one-variable-at-a-time. Full factorial involves testing every combination of variables in a separate test configuration. The output is a model that theoretically describes the behavior of the system. How often do clients ask for a complete mathematical model of their system? More often than not, the client just wants to make it work. One-variable-at-a-time involves performing one test, looking at the results, and then designing the next test based off those results. The idea is that each test will point you in the direction of the optimized solution. However, this type of testing can often lead to numerous tests with conflicting information and no quantitative numbers to back up observations. A screening design provides the best of both of these methods; it points to the optimal solution with minimal test setups. If a more precise output is preferred, a full factorial can be run with more thoughtful, and ideally less, main factors.
Overview of Screening Designs
Screening designs introduced by Genichi Taguchi replace traditional full factorial configurations with a fraction of the tests by sacrificing information about interactions among main factors. Usually consisting of eight, 16, or 27 separate orthogonal configurations, depending on the number of design variables, screening designs point to the optimal discrete setting of each main factor tested. This means that screening designs largely neglect interactions among main factors. For example, if you were to run an experiment testing seven variables at max./min. values, for a full factorial you would run 128 different configurations. A Taguchi screening design calls for eight. If the screening design eliminates two factors from being important, your full factorial count suddenly drops to 32, with just the addition of eight preliminary tests.
In one case we implemented a Taguchi screening design to simultaneously reduce testing time and improve performance in an environment with a high degree of noise. Noise is a factor that affects performance but that we have little control over, like swings in ambient temperature, machining tolerances, or in this case, differences in technique from surgeon to surgeon. Our client had a bench-top surgical device that was operating well in the lab but had sporadic performance in the surgical suite.
We identified five main factors on the device we were able to change (design variables) and two noise variables that accounted for most of the variation we observed. We were able to pare down four of the factor options to two or three levels: either a max./min. for continuous factors or a discrete setting for qualitative variables. Our qualitative variables were three swappable blade geometries, each coming in two different sizes. Because none of these can be interpolated between, they are defined as discrete.
With a full understanding of the design variables and noise variables, we debated doing a full factorial versus a Taguchi screening design. A full factorial would have required 2 x 2 x 2 x 2 x 3 = 48 separate test setups neglecting noise and 48 x 2 (levels for noise variable one) x 2 (levels for noise variable two) = 192 separate test setups with noise included (total testing time would be about 28 days). A Taguchi L18 required 18 test setups x 4 runs for each setup to account for noise = 72 tests (total time would be about 5 days). This means that we only perform the test setup, the most time-consuming portion of the test, 18 times, and run four samples through each setup. The Taguchi L18 was the clear winner because of the balance of information about noise and time savings. The Taguchi method would not have been a good choice if our output, system performance, was a nominal target rather than a minimizing or maximizing target, or if the factors had not been independent from one another.
After running 18 separate configurations, the output is an indication of what factor settings lead to an optimized system performance. Below is a commonly used chart called a Main Effects Plot that compares each design variable with the overall mean system performance.
This plot indicates that in order to maximize system performance, shown on the vertical axis, the optimized design variable levels are high speed, high mass, elliptical blade geometry, and small blade size. Since the slope of temperature is shallow, I can eliminate it as a major contributor to system performance. Using my optimized design variable settings, I plug the system performance for each into the expected performance equation. This equation predicts the output, which in this case is system performance, when the design variables are set to the desired levels. The expected performance equation indicates that I can expect an increase in system performance from 62% to 73%.
The last step is to run confirmatory tests. Now that I have a number for expected performance, it is necessary (and just common sense!) to prove that the optimized variables will get close to this number. The number of tests is up to your own discretion; I usually run enough so that I’m confident in the result. If the confirmatory tests do not match the expected performance number, the issue is probably either that main factors or noise variables are not accounted for, or that there is a high degree of interaction among main factors.
If more data is required to further optimize results, a full factorial or other type of design could be run with more efficiency due to the knowledge gained from the screening design. In this case, most of the variable settings were either linear or discrete, which means I can rely on the screening design data to choose the optimized variable setting. If I suspected one of the variables was nonlinear, like if the speed variable actually looked like a quadratic function, I would want to describe a more complete model to be sure that my results reflect the actual performance. I might add levels to speed and test against the two successful blade geometries to get a more finely tuned model. This means that my original full factorial experiment is reduced from 192 tests to 3 (levels of speed) x 2 (blade geometries) x 2 (levels of noise variable 1) x 2 (levels of noise variable 2) = 24 tests.
Taguchi or not, the key to getting meaningful data out of testing is the old standby: measure twice, cut once. It’s tempting to sprint into the lab, throw something together, and expect things to go a certain way. What usually happens is that you end up wasting half a day figuring out that you need better controls when you could have been spending that time carefully planning out a test plan. What variables do I really care about? What do I want to measure? What is my contingency plan if I don’t get meaningful data? Better yet, once you get a meaningful plan together, get the client to sign off on it so that everyone is on board in terms of expectations, timelines, and program risks. Although screening designs may not be suitable for all situations, when they work they save a huge amount of time, money, and resources.
Engineering Statistics Handbook. Ed. Carroll Croarkin and Paul Tobias. 1 June 2003. National Institute of Standards and Technology Information Technology Laboratory SEMATECH. 10 December 2012 .
Stephen R. Schmidt and Robert G. Launsby. 2005. Understanding Industrial Designed Experiments (4th Ed.). Air Academy Press, Colorado Springs, CO, USA.
Human factors engineering as applied to the design of medical devices has never been as important as it is today, especially since the release of the U.S. FDA’s draft guidance document Applying Human Factors and Usability Engineering to Optimize Medical Device Design in June 2011. With the imminent rise of mobile health applications (apps), human factors engineering principles will become even more vital to the success of this emerging industry and to the safety of the patients for whom they are designed.
Numerous factors have contributed to the recent explosion of mobile health applications and remote patient monitoring, creating a perfect storm of opportunity for this sector of the medical industry. Economic trends, such as the push for cost reduction and new regulations mandating disincentives or penalties for the readmission of Medicare patients into hospitals within a certain period of time, are pushing healthcare providers toward a more vested interest in keeping patients at home. Technology trends, such as the migration to electronic health records, the advancement of digital health applications, cloud computing, the widespread use of social media and the ubiquity of mobile devices, play a huge role. The ability to self-monitor and keep a diary of health issues through the use of mobile apps is strengthening relationships between healthcare providers and their patients.
Consider the following points:
- By 2015, 500 million smartphone users are expected to be using medical apps1, according to Research2Guidance, a global mobile research group;
- The market for mobile health apps is expected to quadruple to $400 million by 20162, according to ABI Research;
- Over three million patients will be monitored over cellular networks by 20163; and
- Three of every four dollars spent on U.S. healthcare is for chronic diseases, and family caregivers are estimated to provide 80% of all long-term care for chronic diseases.3
FDA to start regulating mobile health/medical apps
In July 2011, the FDA released a draft guidance document on mobile medical applications “to inform manufacturers, distributors, and other entities about how the FDA intends to apply its regulatory authorities to select software applications intended for use on mobile platforms.” 4
Since the release of this document, there has been movement within the app development industry to understand and anticipate exactly which mobile applications will require FDA approval. The guidance indicates that the following types of mobile applications would be subject to regulatory processes:
- Software applications that can be executed on a mobile platform, or Web-based software applications that are tailored to a mobile platform but are executed on a server; and
- Software applications that have an intended use within the scope of the concept of medical device as regulated by the FDA, and:
- Are used as an accessory to a regulated medical device (for example, an app that connects to a medical device for the purposes of controlling the device in some way); or
- Transform a mobile platform into a regulated medical device (for example, an app that remotely monitors patient vital signs).
(Note that according to ANSI/AAMI HE75:2009, a mobile medical device is not limited to only mobile phones and tablets, but any device that can be mobile, whether by carrying or rolling.)
You may notice that the guidance does not apply to mobile apps intended to analyze, process or interpret medical data; the FDA has indicated that it will address these types of mobile applications in a separate guidance document. However, the important takeaway is that the FDA will soon be releasing legally enforceable guidelines that will apply to a plethora of medical and health apps already on the market and many more under development. In fact, a bill set to be introduced in the U.S. House of Representatives called the Healthcare Innovation and Marketplace Technologies Act (HIMTA) proposes to establish an Office of Mobile Health at the FDA specifically to provide recommendations on mobile health issues and create a support program to help developers navigate HIPAA privacy regulations.
Importance of applying human factors to mobile apps
The implementation of human factors engineering throughout the design process will be critical for emerging mobile health applications, not only because the FDA is exerting its responsibility to protect and promote public health by regulating these new mobile medical devices, but because it’s good practice and is an essential tool for decreasing patient safety risks while increasing usability and effectiveness.
Take it from someone who has already been through the process. An article written by Brian Dolan for mobihealthnews in May 2011 describes a panel that he moderated with several mobile health app companies who have already navigated the FDA’s 510(k) process successfully. In the article, WellDoc Founder/CEO Ryan Sysko is quoted as saying that if he could change one part of the process, he “would have the FDA provide greater clarity around what successful human factors testing looked like.”5
Our research and usability team at Farm knows the detrimental consequences of failing to apply human factors engineering to product development efforts. We have helped many clients whose medical devices have been rejected by the FDA for lack of necessary or appropriate human factors evaluations. As we always remind our clients, human factors is not a one-time testing event that occurs at the end of the development cycle, but rather an ongoing iterative approach that starts at the very beginning.
The importance of implementing an iterative approach in the design of mobile medical apps is as relevant as applying the process to physical devices. As the more savvy companies have learned, a robust process starts with the gathering of user requirements and includes preference testing of multiple design concepts, design verification, which could include several rounds of formative usability testing of the product itself and related documentation, and a final summative validation test that proves the successful mitigation of use-related safety risks. As is the case with physical medical devices, mobile medical app developers will be expected to follow the user-centered design guidelines of the international standard IEC 62366: 2007.
During the development process, mobile app designers should turn to established human factors guidelines, particularly those set forth in the ANSI/AAMI HE75:2009. Below are some examples from HE75 that could apply to mobile medical devices and/or apps.
- Carefully analyze the conditions under which the mobile device is going to be used (for example, when a user is moving or being moved, in moving vehicles, while wearing the device or during stationary use, on a rack, above the head, etc.).
- The display on the mobile device should not be obstructed by additional accessories, wires or devices.
- Auditory indicators can be used to supplement visual indicators and should provide the ability to adjust volume, on/off and native language (when feasible).
- When possible, aim to work with existing technologies that already have protocols in place that work with medical industry standards, such as the IEEE 802.11 series of standards for LANs, Bluetooth and cell phone protocols.
- Carefully analyze the conditions under which the mobile device is going to be used and how detrimental it is when the battery runs low.
- Keep important tasks immediately identifiable.
- Ensure that the design takes into account the small size of the screen, limiting the amount of images and text.
- Remain consistent; place information in the same place over a series of screens.
- Offer more than one way to navigate through the system.
- Provide guidance such as prompts or pop-ups when applicable.6
Below are some mobile app design best practices published by the mHIMSS Design Tenet Workgroup in January 2012.
- Eighty percent of screen real estate should be dedicated to data; twenty percent to interface.
- For readability, a single sans-serif typeface and up to six type treatments for the typeface are used.
- Color is used sparingly and helps the information, the interaction and the user experience accomplish an apps’s intended purpose.
- The app displays controls in a progressive manner, only the ones needed at specific points along the intended workflow.
- The app works within mobile device limitations such as: no hover text feature, larger target size and smaller display.
- The app leverages new capabilities, such as touch-based interactions, location awareness, proximity sensitivity, integrated communications and push notifications.7
The rise of the mobile health industry is underway and offers an outstanding opportunity to revolutionize healthcare. In September it was announced that the FCC would act on key recommendations from its mHealth Task Force to adopt wireless health technology8.
In order for mobile health application developers to be successful, they must create safe, easy- to-use products that can pass the rigorous FDA approval process. The critical path to this success begins by stringently applying the principles of human factors engineering. Drawing a reference from the Hippocratic Oath, the ultimate goal for designers is to first do no harm, and then do everything possible to provide the best possible product experience for the patient. The only way to do this is to involve end users in the design process from start to finish.
- Lawmaker Pitches New FDA Office of Mobile Health, Jenny Gold, Kaiser Health News, September 26, 2012.
- 5 Ways Mobile Apps Will Transform Healthcare, Derek Newell, Forbes.com, June 4, 2012.
- Webinar: The Inevitable Imminent Rise of Remote Patient Monitoring, MobiHealthNews, September 2012.
- Draft Guidance for Industry and Food and Drug Administration Staff: Mobile Medical Applications, U.S. Department of Health and Human Services Food and Drug Administration, Center for Devices and Radiological Health, and Center for Biologics Evaluation and Research, July 21, 2011.
- Lessons Learned from FDA Cleared Mobile Health Companies, Brian Dolan, MobiHealthNews, May 5, 2011.
- ANSI/AAMI HE75:2009 Human Factors Engineering – Design of Medical Devices, American National Standard, October 21, 2009.
- Selecting a Mobile App: Evaluating the Usability of Medical Applications, mHIMSS App Usability Work Group, July 2012.
- Fact Sheet – mHealth Task Force Recommendations, Federal Communications Commission, September 24, 2012.
I recently started my ninth year as a mentor for the Lawrence MA “Gearheadz” High School FIRST robotics team. FIRST is a non-profit program that serves to inspire young people's interest and participation in science and technology through robotic competition. Over the years it has occurred to me how this experience very much parallels the “real-world” of product development. Both have to deal with challenges that present themselves at the start of any new project, like cost, schedule, and resources. In both cases, there is never enough time or budget. Engineers, admit it: When have you felt that, at the end of a project, you had plenty of both? And from a people side, we all have to learn to work efficiently with team members of varying skill sets and levels, including those who may not yet have developed the necessary skills to deal with a project’s challenges. In this post, I present some of the commonalities I have observed between students in an inner-city high school robotics club and professional designers and engineers who constantly learn new methods, get inspired to solve the hard problems, and ultimately develop a useful device.
Product development firms, like Farm, must constantly generate creative solutions by relying on two fundamental elements: 1) a sturdy yet flexible foundation of a development process, and 2) creative individuals. Process, to a large degree, is a map of those common steps required to complete the journey from problem to solution, or in Farm’s case, from the seed of an idea to the implemented end product. Farm’s process is based on these elements:
- Strategy (e.g., definition of user, marketing, and business needs)
- Specifications and planning (e.g., definition of design inputs and general planning)
- Development (e.g., generation of product concepts through prototyping)
- Verification and validation (e.g., testing to ensure the device does what it’s supposed to do)
- Transfer into production
Farm’s process has played a critical role in all sorts of successful medical device projects, from drug delivery devices to surgical robots to wearable casts.
As for the second critical element: The creative individual. At Farm, we look for a balance of many attributes in our technical staff; he/she is open-minded, an out-of-box thinker, internally motivated, intellectually curious, knowledgeable in multiple manufacturing processes, can conceptualize appropriate-to-the-market concepts, versatile in typical design tools (e.g., CAD), and a team thinker (ability to work on abstract concepts in a group setting). There is no ideal proportion of these skillsets, as each individual brings different backgrounds and personal strengths.
This is a great place to start, but like a good spaghetti sauce base, these elements are only the core ingredients. We still need to add more flavors, a bit of personality, and enough time to bring it all together. To stay sharp and grow, we all need to stretch ourselves. This is made easier when the company culture encourages the synergizing of personal and company interests by sponsoring training events that range from internally-developed courses on Design for Experiments to Web-based courses on Geometric Dimensioning and Tolerancing to intellectual property licensing exams.
And to foster a positive work atmosphere, organizations should not forget to include the fun stuff like group cook-outs, biking treks through the woods, or ultimate Frisbee games, as these social events contribute tremendously to a cooperative environment, which is key for the long-term health of an organization. This is the building a team part... it takes time for people to gel and get into a groove.
So how does this relate to a FIRST high school robotics club?
Let’s first consider the process. The odds are that a process-starved professional organization will eventually fester into true anarchy (and ultimately bankruptcy!); the only question is when. Similarly in a high school club, any teacher will agree that should you dare to combine the youthful energy, immaturity, and hormonal “issues” of teenagers with no process, then an even more elevated level of anarchy will manifest itself and at a much more accelerated rate.
Drawing from my experiences, I’d like to leave you with a few takeaways, which are observations that apply to both the FIRST high school robotics program and the “real world” of product development. Recognizing these similarities should help bring home the pertinence of the robotics program for today’s youth as well as illustrate how professionals can gain valuable usable experience by contributing to such programs.
Takeaway #1: Mentoring kids offers a vehicle for hyper-fast-paced training for a professional by: 1) evaluating how robust your process is (describing a process to a teenager is usually harder than to a professional peer or direct report), and 2) sharpening your saw on how to recognize potential weaknesses for additional training. This could be considered a kind of “HALT (Highly Accelerated Life Test) for managers” training program. To be sure you’ll see the defects right away in your management techniques and abilities. (And you’ll have to fix them without delay to keep things rolling.)
Takeaway #2: Tossing these high school kids into such new spaces that they are not yet fully prepared for can give them wonderful exposure to the dynamics of working in a real-world group, including having to learn technical and team-related skills “on the job.” Though on a different scale, young professionals also experience this perspective, so make a point to nudge your less experienced staff into higher-level tasks from time to time. It’s okay to try something, be challenged, and struggle a little as it is all a part of the learning process!
Now let’s consider the “staff”. In a professional setting, you can usually count on the trainee to already have a sound background through some combination of formal education and/or experience. Not so in the case of the high school robotics club. In most cases for the Gearheadz, we need to teach fundamental things like how to drill a hole (safely and relatively precisely) long before we address the more complicated aspects of conceptualizing or the fundamentals of mechanical and electronics elements and programming. The process is important and it takes time. Eventually, meeting on multiple evenings each week and on Saturdays during the six-week winter build season, the kids all experience how to turn a problem statement (the rules of the game that change from year to year) into concepts, and ultimately into a 100 pound, four-foot-tall remote controlled robot that competes with and against five other robots developed by similar teams from all over the world.
Takeaway #3: Training needs to be delivered in a timely fashion and at an appropriate level. Especially true when the student is taking his/her first steps, but this also applies at any experience level. None of us like it when the subject matter is presented at too high or too low a level. Knowing your audience (and being flexible) is the mantra for anyone who teaches or makes presentations.
In the end, if we all don't keep focused on the need to constantly train the less experienced as well as ourselves, then we take the first step towards their, as well as our, own obsolescence.
And what about the fun stuff? “Fun” and "success" can have many different definitions, but they’re not necessarily mutually exclusive. For us Gearheadz mentors, we watch for the blood, sweat, and tears that every student puts into each robot every year and how it can positively impact lives. One particularly memorable moment for me was that shriek of excitement from a freshman after drilling her first hole using the drill press. The student was later voted president of the robotics club as a senior and is now a senior robotics major at Worcester Polytechnic Institute. Another success is the quiet kid with struggling grades who eventually raised his grades to the team’s standards and morphed into a leader and a skilled robot driver. Still another is last year's co-captain, who joined the team as a junior with no intention of majoring in a science, but is now an engineering major in college.
Takeaway #4: Though it is still called work, keep it fun. You don’t need to be a teenager to admit that life is too short to not have fun!
In conclusion, there is no longer any question that America needs to bring its A-game to escalating the understanding of the sciences by today's students from kindergarten through college. Unfortunately, too many finger this as a problem for the schools to address. However, there are many opportunities for people to pitch in to help solve the problem, to expose kids to this fascinating world of technology, to permit a kid to practice leadership as part of a team, to further motivate the kid who already has that sparkle of interest in his/her eyes, or to draw the aimless kid away from the seemingly inevitable dead-end choice. FIRST is one of these programs.
And we as professionals get to sharpen our “work” skills in the mean time!
A critical indicator of progress during the early stages of product development is the pace at which new information is created; such information is simultaneously the foundation upon which new concepts are built and the lens through which current concepts are viewed.
So how best to create new information?
Experience helps; all things being equal, having done something before encourages success the next time around. Beyond that it’s prototype, evaluate, repeat. Quickly.
Prototyping isn’t the bottleneck; between rapid prototyping and traditional shop work, concepts can be realized almost as quickly as designers and engineers can think them up. The limiting factor is evaluation, particularly trying to quantify the fuzzy front end.
Evaluation in the early stages typically focuses on low-fidelity prototypes, demonstrations by expert users, videos of actual procedures, and benchmarking of competitor products. Much of the information gathered at this point is necessarily qualitative. Still, some quantifiable questions remain: how much deviation is there in the angle at which different docs hold a laparascopic device? What is the path of personnel during a procedure? How does the movement of someone wearing a brace compare to healthy person?
Questions such as these can be answered (some with surprising ease) using computer vision (CV). All that is required is a camera to capture the images/videos and a tool such as MATLAB or Python to analyze it.
I’m going to share a simple example of CV in just a moment, but first a word of caution: some circumstances lend themselves to CV more than others. Specifically, straightforward CV projects will share the following characteristics:
- Measurements of interest are 2D (3D requires stereoscopic vision)
- In a controlled environment (i.e. consistent lighting, plain background)
- Low precision (high precision requires more fine-tuning of the code, camera resolution is also a factor)
In the example below, a Post-It is placed near the ankle, knee, and thigh. From this modest setup, angle data is extracted during a portion of gait.
Setup time: 20 min.Coding time: 2 hours (without reusing code)
The great thing about computer vision as a development tool is that it’s expandable. Once you can perform a simple task such as the one I’ve shown here, it’s a short step to more advanced topics like real-time vision and skin detection. Once you start adding these tools like these to your tool belt, you’ll be surprised at the uses you find for them.
What is the most valuable engineering resource Farm has at its disposal? From a cost/benefit perspective, it’s hard to argue against the co-op student. The benefits are straightforward: a company identifies talent while utilizing low-cost labor and a student gains first-person knowledge of an industry and its practices. Farm currently utilizes two simultaneous co-ops in six-month employment cycles, and being a former co-op student myself (now an engineer at Farm), I feel compelled to share my thoughts on how both companies and co-ops can benefit most from the cooperative educational experience. While my previous co-op experiences were generally positive, I have also observed a number of negative experiences in the past. Here are some recommendations based upon traits that commonly create positive co-ops, from both an employer and student’s perspective.
For Co-op Employers
Have Work on Day One
Co-ops generally arrive to work on their first day with their motivation and ability at inversely proportional levels. They want to help, but they don’t know how. Having a task from the get-go is extremely important as it creates an immediate sense of value and worth. This is a challenge for many product development firms because co-op-appropriate work doesn’t always exist. In this situation, create work. If a co-op lacks CAD skills, create a design problem that requires grasping complex surfacing or master models. Try not to rely on stock tutorials and lessons as most students have already completed these. A unique and well-defined task can go a long way toward creating lasting co-op motivation.
Understand a Co-op’s Goals Before and After Hire
While interviewing a co-op, most companies will inquire about what a student wants to get out of the experience. Some will answer honestly, some will tell the interviewer what they want to hear, and some simply don’t know. Regardless, it is important to continue this dialogue after the student is hired and throughout the experience. Interests and aspirations change rapidly for co-ops, and showing that you value their goals is essential.
Throw Them into the Fire
With a good co-op student, a product development firm can take the burden off of its full-time employees and rely on the co-op to complete billable tasks. This inherently requires a certain level of trust; trusting the co-op to complete deliverable tasks at a high level. Because of this, many firms wait to give co-ops responsibility until they have definitively proven themselves over time. Instead, try throwing them into the fire. Treat co-ops like full-time employees while simultaneously checking their work exhaustively. This method might eat into company overhead in the short term, but it’s worth knowing a co-op’s true capabilities as soon as possible.
Create Positive Press
The primary goal for a co-op employer is to get quality work from an otherwise inexperienced employee. While this is a completely valid goal, co-op employers often overlook the goal of creating positive press for their companies. When co-op students return to class, they reflect on their experience. They make presentations, write reports, take surveys, and above all share their reflections. Because of this, a positive co-op experience for one student can completely influence the opinion of hundreds of others. Why not make a positive impression on the engineers and designers of tomorrow?
Understand Your Company
You need to do your homework! A co-op student who researches the ins and outs of a company will get in the game much faster once employed. Prior to employment, co-ops should strive to gain a full understanding of a company’s core competency, clientele, competitors, business practices, past projects, and future goals. It might not be easy to find, but the information is out there, especially if the company is classy enough to have a blog. Possessing this knowledge allows co-ops to understand where they can fit in and allows them to suggest how they might be most valuable to a company. It isn’t enough to follow instructions. Good co-ops should assume they are being underestimated, and use company knowledge to ensure that they are utilized as effectively as possible.
Know How to Learn
Learning at a product development firm is stressful. For co-ops, balancing personal educational goals with the hectic demands of contract product development can seem borderline unachievable. Fortunately, product development firms are among the most efficient educational outlets out there, provided you know what you’re getting into. Here’s what to expect:
When billable work doesn’t exist, co-ops are often used for company initiatives or are left to their own devices to complete lessons and tutorials. This is the best time to find work that benefits both co-op and company. For engineers, learning a relevant programming language, becoming familiar with GD&T, developing machine shop skills, and becoming acquainted with new manufacturing techniques are all examples of valuable ways to spend unbillable time. Try to focus on subjects that will be applicable to upcoming projects.
Every time I’m forced to learn something new for a project, Bill O’Reilly’s voice pops into my head yelling “We’ll do it live!” This is where the most efficient learning happens. You’re forced to master and execute a skill in a very short timeframe, and getting it wrong isn’t an option. You pull information from coworkers, past projects, and outside contractors simultaneously. It isn’t ideal from a low-stress point of view, but from an efficiency perspective, there’s nothing better. As a co-op, being ready and eager for this type of education is indispensable.
Show Off Your Skills
A major source of co-op frustration arises when students aren’t given challenging work. The cause is understandable from both perspectives; co-ops want their work to teach them new skills, but employers don’t want to give important tasks to inexperienced workers. Co-op skill also varies widely from student to student, so employers are often conservative with the work they delegate. To solve this problem, co-ops should try to advertise their capabilities as much as possible. A company-wide “About Me” presentation or public portfolio that outlines previous projects and experience can be extremely beneficial for both co-ops and employers. Additionally, “About Me” presentations should be used to express relevant educational goals and interests. It seems obvious, but many co-ops will complete entire internships without ever expressing their skills and goals.
A good co-op experience has the potential to produce both a valuable education for a student and a budget surplus for an employer, a win-win scenario. Unfortunately, co-ops are often underutilized in the contract product development world. Deadline-driven projects necessitate instant results, and project managers just don’t have the resources to bring co-ops up to speed. Instead, co-ops sit idle and the reciprocal relationship is broken. It’s a shame, because when the co-op experience is successful, the long term advantages can be immense. Budgets are balanced, talent is identified, and knowledge is gained. A quality co-op experience is something to strive for by both students and employers, reflected by the fact that almost all of Farms entry-level engineering hires are previous co-ops. It’s evidence that a well-executed co-op program benefits everyone.
Lee PaneckiMechanical Engineer at FarmNortheastern University Alum
Interested in being a Farm Co-op? Visit Farm's Career Page!
In this enlightened age of “intelligent engineering”, data and the interpretation of data have become critical to the success of a project. The development tools in our high-tech toolbox are always expanding and bringing new insight to increasingly complex systems. But without a detailed product specification roadmap, we fall into the trap of generating oceans of useless data. The design team of today needs to be keenly adept at gathering, filtering, and utilizing data for the best possible patient outcome as well as commercial success.
Engineers love data. We always want more high-speed cameras from more angles to record more prototype scenarios to verify more simulations. This brings us to one of a program manager’s greatest frustrations: usable data. Whether you are designing an autonomous surgical robot, a patient-specific knee implant, or a paperweight for all the new regulations, volumes of data are useless without the proper specification framework to filter and process it. This is the role of the Product Requirement Document (PRD).
The PRD is designed to keep the development team on task and focused on specific product functionality. If the PRD is written at the end or evolves during the development program, truth-seeking engineers will generate ever increasing volumes of data. We do this to provide program decision makers a broad spectrum of options with varying degrees of feasibility. Working without a PRD is absolutely the slowest and most expensive way to develop a product. In a perfect world, every program would start with a detailed PRD backed by historical benchmarking data, but this is not an option for truly innovative technology looking for a production platform. Even without a PRD, the development team will still need critical, effective processes to reach definitive milestones and eventually a market-conquering product. Without hard stops during the process to critically analyze data, you will get stuck in never-ending loops of data gathering and end up creating more variables than answers.
Because development resources are finite, brainstormed concepts need to be vetted quickly and either fail fast or prove promising and carried further. If hanging weights off of a rapid prototype strapped to a car bumper gets you pertinent data in hours as opposed to machining prototypes and a detailed test fixture over four weeks, go with the car bumper. The most challenging aspect is to define the critical variables and harmonize them into a succinct goal. A great development team finds the facts in the figures and keeps the thought process moving forward quickly and efficiently.
One of the most powerful tools to reduce and accelerate prototyping loops is finite element analysis (FEA). FEA has made giant leaps forward in capability over the past 15 years. Large assemblies are now translated directly from any CAD environment, contact pairs are automatically assigned, and a mesh is created after the click of one button. It is the perfect tool to fail fast in both positive and negative ways. The results are shown plain as a rainbow on the computer screen, but are they fact? The quickest way to further a concept with FEA is through comparative analysis. If option A predicts X stress and option B is 1/2X stress with the exact same setup, you are moving in the right direction. The question then becomes are the physical stress levels at X or 10X.
There are many ways to validate FEA simulations in the real world. With the ever decreasing cost of 3D printers, you can be up and testing concepts in hours. The 3D printing materials will not be exactly representative of production materials (build layers, for example, are ideal crack slip planes), but remember that stress is force/area. Whether a part is printed or machined, both will have the same high-stress location when tested in identical setups just different ultimate loads and displacements. The issue arises when your prototype fails in ways you did not predict or expect. The failure load and location are in essence only one data point in a complex system. Would thinning out a section and increasing flexibility actually be more beneficial than thickening and stiffening a part? Does adding a gusset to support a corner relocate the high stresses to an even more critical location? To fully comprehend the behavior of a part or assembly, you need multiple data points within the system to trend or predict how your concept is performing as a whole.
Strain gages provide very enlightening data for validating FEA simulations. I have found over the years that many people either don’t understand or are afraid of using strain gages. The key is to confirm your gage application and data gathering process on something simple, like a bending beam, to start with. Perform the hand calculations, confirm the calculations with an FEA run, and match your physical gage readings to the predicted results. Once you validate your process, a whole new array of data gathering is available to physically map the performance of your concept. Strain gages have been immensely useful for sorting out FEA constraint issues and uncovering inappropriate setup assumptions. It is rare in the real world that anything is truly fully fixed. The development team will still need to iterate between the FEA setup/results and gage readings, but at least they will have a physical data path to correlation. It takes an experienced technical lead to understand when the analysis and physical testing are aligned well enough to predict the trend for your specific functional requirement. Strain gages are cheap, apply them liberally.
The desire to compress timeframes through the “intelligent engineering process” has become a reality across multiple industries. Development teams of today have the most incredible physical and virtual tools at their disposal, but they need to know how to most efficiently utilize them. Even without a PRD, data still needs to be gathered, sorted, and acted upon to develop and validate a concept. The right data in the right hands at the right time does make all the difference. Budgets, personnel, and time to market have all been significantly reduced, while at the same time product expectations have never been higher.
The 2012 Symposium on Human Factors and Ergonomics in Health Care took place March 12-14 in Baltimore Maryland. There were nearly 400 human factors professionals, manufacturers, healthcare providers, policy makers, and other stakeholders there, including many of my friends and a number of Farm’s clients.
On the final day, Ron Kaye and Quynh Nhu Nguyen from the FDA’s Human Factors Group presented the Closing Plenary Session: FDA Human Factors Q&A. The chair and moderator was Anthony D. Andre, who organized the symposium. Previously during the conference, the audience had submitted questions for consideration, and the ones below were selected to be answered by the Agency. I’ve done my best to paraphrase based on my notes.
- Q)When do you expect the FDA draft human factors guidance document to be finalized?
- A)The guidance is expected to be finalized by the end of this year. The human factors team is going through 600 good comments and is making changes.
- Q)What is the average turnaround time on a validation protocol review?
- A)For devices where only CDRH is involved, a minimum of 30 days. For combination drug-device products where both CDRH and CDR are involved, it is estimated at 30-60 days.
- Q)What are the two most common or serious mistakes found in FDA submissions?
- A)No human factors done at all and no tangible link between risk priority and user tasks. “We have had a lot of success but there is still a lot to be done.” Now that the new guidance has been out there the FDA has found that companies are following it and practicing good process.
- Q)Do I have to have a perfect product with zero errors?
- A)The point is to find errors and fix them…The fact is some things just cannot be designed out of the device. If this is the case, the device still could be better than other products on the market, even if it’s not perfect. When a manufacturer claims that it is as safe as possible, sometimes the human factors team will meet with the medical officer and get his opinion. FDA reviewers take his input very seriously and try to make the best possible decision. The final and most difficult question is: Do the benefits outweigh the risks?
- Q)If the new product is clearly better and safer than the legacy (predicate) device, do you get “credit”?
- A)Reviewers look at each submission in isolation, and don’t compare. For example, if one device has 10 serious errors and another one has five, will the FDA accept the one with five? No. The question is: What are the problems and can they be fixed? For some products misuse can cause death, for others misuse might cause minor irritation. This doesn’t mean they will ignore the less risky product, but in reality, limited resources force the Agency to focus on the more dangerous products.
- Q)Can manufacturers request specific reviewers?
- A)Yes, you can include the request in a cover letter and send that along with your submission.
- Q)If there is an existing product on the market and you have made only one component change, do you have to revalidate with the same rigor?
- A)It depends on what the component was. If a case can be made, you can focus the validation testing on just that one component, but it depends on the risk associated with the component in question.
- Q)Are there categories of devices that do not require human factors testing?
- A)If there is no significant user interaction and the device is low risk then maybe. The FDA is working on a list of these devices, which will be published at some point.
- Q)What is the FDA’s approach regarding software and electronic medical records?
- A)This is not being decided by the human factors team; Dr. Patel in the Management Office is leading the effort. We have reviewed stand-alone software applications and evaluated whether or not critical actions are supported well by the UI. It can get complicated, however.
- Q) Do you have to test a kit that includes approved syringes for home use?
- A) It depends on risk analysis and justification for why not. The FDA takes into account user profiles (tremors). Do users have unique aspects affecting the use of syringes?
- Q)How is delay of therapy viewed?
- A)Depends on how long of a delay and clinical relevance of speed. For some products, like AEDs and infusion pumps, a delay is critical. You should evaluate what the delay means clinically.
- Q)For combination devices, should you incorporate anything learned from a Phase Three Clinical Study into your human factors studies?
- A) You should conduct your summative testing first, make changes, and then go into your Phase Three Clinical Study.
- Q)What if you are trying to get a combination device approved but there are ancillary steps like washing your hands or preparing the injection site and you know that patients don’t do it? It is out of the manufacturer’s control.
- A)In general, if these tasks are critical to safe use, you should look at them.
- Q)Can you test a device in phases, for example, test the basic tasks first and then have people use the device for a while and learn the more complex tasks during use, and test those later?
- A)Depends on the training that’s necessary to use the device safely and effectively. We would need to know more about the device you’re referring to in order to answer the question.
These were certainly some interesting questions, and I along with the rest of the audience really appreciated the Agency’s willingness to address them in a public forum. It was a perfect closing to the event.