Sara Dyson, Medmarc

Medical Device Software & Products Liability: The Homefront (Part II)

By Sara E. Dyson, Esq.
Sara Dyson, Medmarc

This second article in the three-part series looks at the use of software in medical devices in non-clinical settings, particularly the home environment. It addresses software’s role in the home healthcare trend, explains the software-related risks that arise from home-use products, and discusses what manufacturers can do to make these products safer.

In 2011, as part of a study of quality metrics published by FDA in its white-paper, Understanding Barriers to Medical Device Quality, the agency warned manufacturers of software-driven products about the need to test products in the environments in which they will be used.10 The report states, “Most companies attributed poor software quality to challenges around ‘developing comprehensive test cases to simulate the effects of field usage.’ Software products are operated by a diversity of users, in various applications and environments.” This is an important warning that designers of software may miss if they are consulting the software-specific guidances only, since they don’t address the need to test software in real-world conditions.

In 2014, FDA issued a guidance document titled, Design Considerations for Devices Intended for Home Use. The document warns, “Failure to adequately consider potentially hazardous situations during the design of home use devices may result in inappropriate use, use error, or incompatibilities between the use environment, the user, and the device. This could cause the device to malfunction, possibly contributing to death or serious injury.” The document is intended to guide the design of all aspects of home-use products, whether related to software or mechanical functionality. However, the document touches only briefly on software specifically. “Software plays a critical role in the operation of some devices. For these devices, you should focus on developing device and software architecture and algorithms for performance, error detection, control, and recovery.” It also advises software developers “to account for the needs of home users” and how upgrades will be performed. Despite the somewhat meager advice applicable to software directly, this guidance contains excellent information on how to approach the various risks that arise from the home environment. Though this guidance is not typically thought of as “standard” among the collection of guidances for software developers, I strongly recommend it to those who design software for home-use devices.

Understand the Potential for Misuse. According to FDA, “A use error refers to a situation in which the outcome of device use was different than intended, but not due to malfunction of the device. The error may have been due to a poorly designed device, or it may have been used in a situation that promoted incorrect usage. Other users may make the same use error with similar or worse consequences.”11 In addition to performing “real world” software tests to identify potential use errors, human factors testing is another tool for companies that are trying to anticipate problems. In my experience, device firms sometimes underestimate the importance of human factors testing or dismiss it as a “nice to have,” since it can be expensive and may require companies to look outside their own organizations for the expertise necessary to perform this sort of analysis. However, omitting human factors testing could be a big mistake; particularly for manufacturers that are re-tooling traditional products to make them “connectable” or are converting “physician-only” devices into products intended for use by laypersons. These companies must be careful not to fall into the trap of expecting their devices to perform the same in the home environment as they do in the clinical environment, and human factors testing is one way to determine whether a product is ready to become a member of the next generation of home-healthcare products.

Often companies learn of “use errors” when conducting post-market surveillance of their products. FDA requires medical device manufacturers to monitor adverse events and user complaints. Companies that do this well can discern patterns of misuse over time. When such a pattern emerges, a company should consider undertaking changes to the product’s design and/or safety information ─ and, in fact, may be obligated to do so under products liability law or FDA rules. FDA data on adverse events can also provide companies with a means of assessing the performance of their products as compared to other products in the marketplace ─ and the performance of “peer” products can be relevant in products liability. If a competitor product boasts design enhancements or safety features that the product in litigation omits, the manufacturer may be liable to the plaintiff for damages that its comparably less-safe product caused. For this reason, staying abreast of how companies are evolving their products to make them safer for home use can be important to mitigating risk.

Know the Limits. While the new generation of home-healthcare products seems to be answering a call to empower patients, it is important to know when the pursuit of this objective is out of sync with a particular device’s capabilities to deliver safely on the promise. In 2015, Medtronic won FDA approval of the world’s first app-based remote monitoring system for patients with implantable pacemakers.12 At first glance, this app seems to embody all of the risks that I have identified as belonging to this new generation of products, primarily because pacemakers heretofore did not involve interfacing, operationally speaking, with patients. However, looking more closely at what this app is designed to do, it appears that the app only allows users to select how their data will be conveyed to healthcare providers. The data, itself, is not accessible by patients, avoiding possible scenarios in which patients could self-diagnose or otherwise misuse the information.

It is important to set user expectations for the device’s capabilities. Not every device can be operated safely and effectively by every user in every home environment. A manufacturer should be clear about the conditions under which use of a device is appropriate ─ and simply avoid adding capabilities that create risks that cannot be managed.

The next article in this series looks at “interoperability,” the risks that arise from connecting devices through a common software language, and related risk management strategies.

References

  1. Ada-Helen Bayer and Leon Harper, Fixing to Stay: A National Survey of Housing and Home Modification Issues, AARP, May 2000.
  2. Bureau of Labor Statistics, Occupational Outlook Handbook, “Home Health Aides,” June 22, 2017, see www.bls.gov/ooh/healthcare/home-health-aides.htm.
  3. See https://www.bls.gov/emp/ep_table_104.htm.
  4. Telemedicine statistics are from “How Telemedicine Is Transforming Health Care,” The Wall Street Journal, June 26, 2016 by Melinda Beck.
  5. FDA’s definition of “medical device” is provided here: www.fda.gov/AboutFDA/Transparency/Basics/ucm211822.htm
  6. “Patient-Generated Health Data | Policy Researchers & Implementers,” HealthIT.gov, September 30, 2015, https://www.healthit.gov/policy-researchers-implementers/patient-generated-health-data.
  7. Mack, Heather. “Remote patient monitoring market grew by 44 percent in 2016, report says,” MobiHealthNews, February 8, 2017.
  8. Regaldo, Antonio. “This Doctor Diagnosed His Own Cancer with an iPhone Ultrasound,” MIT Technology Review, October 27, 2017.
  9. Id.
  10. Access the report here: www.fda.gov/downloads/AboutFDA/CentersOffices/CDRH/CDRHReports/UCM277323.pdf
  11. See “Postmarket Information – Device Surveillance and Reporting Processes” at www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/HumanFactors/ucm124851.htm.
  12. See “Medtronic Announces FDA Approval and Launch of World’s First App-Based Remote Monitoring System for Pacemakers,” November 17, 2015, at www.medtronic.com/us-en/about/news.html

Related Articles

About The Author

Sara Dyson, Medmarc