Hello, and welcome to the CLE titled "When Things Go Wrong: Understanding, Privacy, Security, and Liability for the Internet of Medical Things." I'm Bethany Corbin, senior council at Nixon Gwilt Law, where I work extensively with medical devices and healthcare innovation companies that are seeking to disrupt standard care delivery and care coordination models. The internet of medical things, or IOMT, is a rapidly evolving field that has the potential to transform the healthcare industry. We've already started to see the effects and the impact that IOMT can have with developments like remote patient monitoring. I'm really excited to talk with you today about the compliance and legal risks that are associated with IOMT, including the evolving liability structure for IOMT device malfunctions. I'll start first by giving a roadmap of what we're going to cover in this CLE. First, I'll provide an overview of IOMT. Next, I'll discuss the privacy and the security risks that are inherent with IOMT, including an overview of the regulatory landscape and in-depth discussion of privacy and security risks, and identification of several risk mitigation strategies. We'll then talk about liability structures for IOMT with a focus on products liability and standing. And then finally, we'll have a short conclusion to this episode. So I wanna start first by discussing the evolution of the IOMT industry, or as it's sometimes called, the connected health device industry. The IOMT industry is integrally tied to the evolution and expansion of digital health, which created interconnected systems that allow for data exchange without human interaction. So before we get into the specifics of IOMT, I want to trace a bit of the healthcare industry's transformation from paper healthcare to digital healthcare. If we look at healthcare prior to the 1960s, we see that almost all medical records at that time existed in paper form only, and they had to be manually organized into filing systems. While they weren't efficient for data exchange and care coordination purposes, paper records actually had the benefit of evading electronic threat actors. The main risk to healthcare privacy and security at that time was the actual physical removal or stealing of the paper record, which was much harder to effectuate. Around the mid 1960s, however, the first electronic clinical information system was developed, and it formed the basis of what is commonly known as the electronic health record, EHR, or the electronic medical record, EMR, system. The invention of the EHR served as the first widespread opportunity for healthcare organizations to digitize patient health data. The federal government began using the EHR system around the 1970s through its Department of Veteran Affairs. That said, it was only around the early 2000s that EHRs experienced widespread adoption. And indeed in 2004, the Department of Health and Human Services, or HHS, created the Office of the National Coordinator, ONC, of Health Information Technology, which was designed to promote a national health information technology infrastructure. Shortly thereafter, Congress authorized incentive payments to healthcare providers who satisfied meaningful use criteria, which included the use of EHRs. And Congress's goal here was to encourage the widespread adoption of EHRs through the Health Information Technology for Economic and Clinical Health Act, or HI-TECH Act. Corresponding with this rise in EHR adoption, the HIPAA privacy and security rules were enacted in the early 2000s to emphasize patient privacy and safety in the digital era. So while transitioning to EHRs was a really important first step towards healthcare digitization, there was still a lot of hesitancy on the part of most healthcare institutions to fully embrace the digital health revolution. However, the increasing demand for connectivity, information sharing, and data retention was undeniable, so to fill this gap, the wearable wellness technology industry developed, and this included products like the Fitbit and the Apple Watch. The rise in wearable tech really began to change the way that consumers interacted with and thought about the healthcare space, and more and more consumers became interested in monitoring their health and their wellness away from their provider. And as a result of this, the wearable tech industry experienced significant growth in the 2010s, and it really offered consumers a way to take personal responsibility for their health and wellness. Now that said, it wasn't really until the COVID-19 pandemic hit that digital health became mainstream. Faced with a sudden decrease of in-person clinical services, healthcare organizations quickly adopted and installed telehealth platforms to help facilitate virtual care management. New connected health devices and wearables were also being produced, and consumers started to heavily rely on health and wellness technology to monitor their symptoms and their vital signs. Remote patient monitoring, or RPM, also gained significant adoption by healthcare providers during this time, and more and more patients were really seeking the flexibility to monitor their conditions from home. However, this rapid technology adoption occurred within established corporate and clinical frameworks that were actually never designed for or equipped to handle rapid digitization. Further, given the immediate health crisis that providers faced with COVID-19, and this, at the same time, trying to digitize, many healthcare organizations did not have the resources that they needed to thoughtfully develop and prioritize privacy and security in their IT frameworks or their IOMT devices. And as a result, a lot of healthcare organizations unintentionally introduced security vulnerabilities into their networks, which have provided opportunities for cyber criminals to attack those vulnerable platforms and software. Additionally, given the rapid development of IOMT solutions, technology has actually outpaced regulation. So this means that there are significant gaps in the compliance and liability frameworks for IOMT devices, and we'll discuss that more in this presentation. As part of the digitization process, IOMT and connected health devices have really become a common staple in most healthcare institutions, and they're used by a vast majority of patients to monitor and track their care virtually. This then leads us to the question of, "What is IOMT?" Well, this may seem a bit surprising, but IOMT actually lacks a universally agreed upon definition. As its name suggests, IOMT represents a network of smart healthcare or medical devices that collect and exchange personal data and health information across health information technology, or IT, systems. The term "IOMT" generally refers to the interaction between computers, sensors, and other objects to collect and transfer health data or other patient information through a wireless data infrastructure that's enhancing information and data flow between patients and physicians. In this manner, IOMT devices function on embedded sensors which automatically measure and transfer patient data across networks to data stores without requiring any human interaction. So if we break this down even further, IOMT devices essentially function in three stages. First, IOMT devices are typically embedded with radiofrequency identification sensors, which can then use radio waves to identify people and objects. These sensors allow IOMT devices to detect and gather data from users and the surrounding environment. Second, IOMT devices transmit the collected data through wifi, Bluetooth, the internet, or mobile phone networks. The transmitted data is then stored using cloud-based applications. Finally, recipients of the data must sift through the massive amounts of data that are collected by these IOMT devices. And this data is typically analyzed for insights, trends, and intelligence that can then be used to help guide future healthcare decision making and increase productivity and patient safety. This then leads to the question of, "What are some of the common types of IOMT devices that we're seeing in the market today?" While the two main aspects of healthcare that really come to mind when we think about connected health are connected medical, or IOMT devices, especially implantable medical devices, and connected health systems, such as connected hospitals, from an IOMT device perspective, there's been a lot of interest and movement in creating modern implantable medical devices that can perform life-saving tasks or provide vital medical care to patients. So for example, an implantable device may deliver insulin or other types of drugs to a patient. The device would then be calibrated to determine appropriate dosage and timing. The device would collect data from the patient before and after each dose and transmit that data to the patient's provider. Another example would be a wifi-connected implantable device that provides direct stimulation to an organ. That said, not all IOMT devices are implantable. So some examples of IOMT devices that are not implantable would be things like connected inhalers, connected blood pressure monitors, connected glucose monitors, clinician-monitored wearable fitness trackers, et cetera. From the IOMT system side, what we're actually seeing is the development of an entire ecosystem of connected health devices under one roof, such as a connected hospital. These organizations have a substantial number of internet or network-connected health machines and devices, which can include x-ray machines, MRI scanners, patient health monitors, connected safety devices, et cetera. As of right now, it is actually estimated that US hospitals have an average of 10 to 15 connected devices per bed. According to the American Hospital Association, the US is home to 6,210 hospitals, each of which have between 50 to 500 beds. So the 931,203 staffed hospital beds across the nation translates to more than 14 million connected medical devices just at a patient's bedside. Going forward, the IOMT industry is projected to be worth $158.1 billion in 2022 and 170... I'm sorry, $187.6 billion in 2028. By 2025, Statista anticipates that more than 200 million healthcare connected devices will be installed. So IOMT is an area that's seeing a lot of rapid growth, and it will continue to be an important area for the healthcare industry to monitor and keep up to date with. Now, why is there expected to be such a huge growth and continued expansion of IOMT? Well, the benefits of IOMT are exceptionally promising, and they serve as a major factor driving increased adoption of connected health technology today. There are three main categories of benefits for IOMT devices. The first is remote monitoring and telehealth, the second is behavioral modification and patient outcomes, and the third is administrative efficiency. So first, IOMT has an immense opportunity to benefit both patients and providers by transforming the landscape of telehealth and enabling remote patient monitoring. With remote patient monitoring, providers can establish a constant connection with patients regardless of their physical locations, and this allows physicians to monitor acute and chronic conditions without limiting patient freedom and mobility. Real-time supervision through connected health devices can also save lives and medical emergencies by providing timely alerts to patients and providers. This collection and exchange of health data can also speed up the decision making process of doctors, particularly when these decisions are time sensitive. Further, through remote patient monitoring, healthcare costs can also be lowered. In addition, remote patient monitoring can also lead to improved drug management, improved diagnosis and treatment, and enhanced patient experiences. And all of these can lead to an overall improvement in patient health outcomes. Second, IOMT can encourage behavioral modifications for patients and improve patient health management. This is especially true for patients that have chronic illnesses. With IOMT devices, patients can manage their medical conditions at home and transmit data directly to their providers. And this really gives patients a sense of responsibility and accountability for their health, and it can provide incentives to take medication, perform necessary testing, et cetera. Finally, IOMT can help to enhance administrative efficiency and operations. There are quite a few medical tasks that can be automated, so in that sense, IOMT devices may operate more efficiently than manual data collection, and they can offer increased reliability. Similarly, connected health devices may have the ability to identify errors and mistakes more quickly than human providers, or they can warn providers of potential failure indicators before they occur. Further, IOMT can also create a more efficient organizational infrastructure. So for instance, a hospital may use IOMT devices to develop a real-time location system. That system could provide automatic updates, based on data, to allow family members to track the progress of a loved one who's undergoing surgery. Similarly, a hospital can use IOMT devices to analyze workflow trends with the goal of identifying staffing needs for upcoming shifts. So in one example, a hospital used this type of data and was able to save about $650,000 in just six months by reducing unnecessary overtime. So there's a lot of potential for connected health devices in terms of patient, provider, and organizational outcomes and efficiency. The benefits of connected health devices, however, really need to be weighed against their potential for harm and the risks that accompany these devices. So while IOMT shows significant promise, the heightened connectivity of medical devices can really be problematic when we look at it from several perspectives, and this includes privacy, security, device resilience, and patient safety. And we'll explore these risks briefly here, and this is gonna serve as the foundation from which we discuss the legal considerations and remedies for IOMT later on in this presentation. So first, IOMT devices can present new attack vectors and vulnerabilities for healthcare IT infrastructures and present unique privacy and security risks. Many IOMT devices connect over unsecured networks or networks that employ weak security protections. With the wireless transmission of data, there are enhanced access points for cyber criminals to compromise IOMT device security and privacy. If an IOMT device is compromised, sensitive patient data can then be publicly shared, which results in a violation of patient privacy, and it can lead to emotional and reputational damage. Given that healthcare data is highly valued on the black market, so for example, medical records are actually worth 20 to 50 times more than financial data, bad actors actually have a financial motive to attempt to hack unsecured IOMT devices. Second, IOMT expands the attack surface from which cyber criminals can enter larger medical networks. Every time a healthcare organization connects an IOMT device to its IT network, that IOMT device can potentially operate as a backdoor entry point into the healthcare organization's IT system. Indeed, the mere presence of IOMT devices in healthcare settings has really been shown to weaken the overall security of an IT network, and these access points must be constantly monitored by IT security professionals. Hackers that gain entry to the larger health network can compromise large amounts of patient data, and they can hold that data for ransom. In some instances, these attacks can completely halt organizational operations and substantially limit the ability of the healthcare organization to even provide basic patient care. Finally, IOMT devices, particularly those that are implanted into the human body, pose a risk of bodily harm or death for patients, and this is just one of the unique aspects of IOMT that really sets it apart from the larger IOT industry. So for example, a 2012 episode of Homeland showed how an implantable IOMT device could be hacked to cause the device to malfunction. Indeed, former vice president Dick Cheney had the remote capabilities for his Pacemaker disabled after research identified that vulnerabilities could allow hackers to remotely cause a heart attack. Similarly, researchers and white hat hackers have shown an ability to remotely hack insulin pumps and alter the device settings. And if this occurs, the insulin pump may actually fail to provide any medication, or it may provide excessive insulin, which can then cause death. In 2014, the Federal Bureau of Investigations, FBI, warned hospitals to actually discontinue using certain infusion pumps that had a security flaw which would enable unauthorized users to alter medication dosages. And these risks are also present for more standard connected health technologies, such as a CT or an MRI scan. Researchers in Israel actually developed malware as a way of drawing particular attention to the security weaknesses that exist in medical imaging equipment and networks that transmit those images. specifically, the malware would let attackers add realistic malignant-looking tumors or growths to CT or MRI scans prior to those scans being reviewed by radiologists. Additionally, the malware could remove cancerous growths without detection and cause a misdiagnosis. In a blind study, the researchers used real CT lung scans with 70 of those scans being altered by the malware. The malware successfully tricked three skilled radiologists into misdiagnosing conditions almost every single time. Where the malware added fabricated cancerous nodules, the radiologists diagnosed cancer 99% of the time. Where the malware removed real cancerous nodules, the radiologists said that patients were healthy 94% of the time. Thus, there is a real need to ensure that IOMT devices are properly secured and that they're properly monitored given their ability to compromise patient care. So given this above landscape and the vulnerabilities that are associated with IOMT devices, it's really essential to understand the compliance and the liability frameworks for IOMT devices and for IOMT device manufacturers and users. To that end, the remainder of this presentation is really gonna focus on examining the legal structures and the liability frameworks that may apply to certain aspects of the IOMT industry. I'm going to start first by discussing the privacy and security regulatory frameworks for IOMT devices, and then I'll present some strategies for IOMT privacy and security compliance. Next, I'll present a high level overview of recent IOMT cases and explore one of the most common barriers that plaintiffs face in litigating these cases, which is the issue of standing. And then, finally, for IOMT devices that do malfunction or are hacked, we'll evaluate the applicability of common tort theories and, in particular, products liability and negligence, in helping patients recover damages for the harms that they suffer. As part of this presentation, I'll also identify the challenges that occur whenever existing tort theories are used and are applied to emerging technology. So first, let's understand how IOMT privacy and security are regulated at the federal level. In the United States, privacy and security are generally governed through a patchwork sector-based framework. In the healthcare industry, regulatory authority is vested primarily in two government agencies: the Department of Health and Human Services, HHS, and the Food and Drug Administration, FDA. HHS's Office for Civil Rights, or OCR, is the primary regulatory authority for privacy and security in the healthcare industry, whereas the FDA has jurisdiction over the safety and efficacy of medical devices. Both HHS and the FDA may oversee certain aspects of medical devices. However, significant gaps do exist in the regulatory framework that permit portions of the IOMT industry to remain unregulated. So from a privacy and security perspective, the Health Insurance Portability and Accountability Act, HIPAA, including the privacy and security rules, serves as the floor upon which privacy and security standards are measured for the healthcare industry. Congress passed HIPAA in 1996 to ensure motility of health insurance coverage and reduce healthcare delivery costs. While the original scope of HIPAA did not contemplate privacy and security, these protections were subsequently added when the transition occurred to electronic health records. And as a result, the HIPAA privacy and security rules are the major governing frameworks for federal healthcare privacy and security. The scope of HIPAA, however, is quite limited. So in particular, HIPAA applies only to covered entities and their business associates, and it only protects a subset of health information, which is known as protected health information, or PHI. To be a covered entity, an organization has to fall into one of three categories which are statutorily defined. They have to either be a healthcare provider processing standard transactions, a health plan, or a healthcare clearing house. Alternatively, an organization could be a business associate of a covered entity, and that can include any person or organization that is performing certain specified functions on behalf of a covered entity. The information that's protected by HIPAA only includes PHI, and PHI means individually identifiable health information that is transmitted in any form or medium. And this can apply to current, past, or future health information. Now, the HIPAA privacy rule sets limitations on a covered entity's or a business associate's use or disclosure of PHI. The general rule is that, subject to certain exceptions, a covered entity or business associate may not use or disclose PHI except as required or permitted in the privacy rule, or as authorized by the individual in writing. The HIPAA security rule, in turn, really operationalizes the privacy rule's protections by requiring covered entities and business associates to implement administrative, technical, and physical safeguards for a subset of PHI, which is electronic PHI, so PHI that is transmitted in an electronic form. While the goals of the HIPAA privacy and security rules are laudable, there are significant gaps when trying to apply these regulations to digital health technology. HIPAA's protections only extend to digital health companies and manufacturers who qualify as covered entities or business associates, as we just discussed. So if an IOMT device manufacturer or a user is not a covered entity or a business associate, then it is not required to comply with HIPAA's privacy and security frameworks. And this means that many of the wearable devices and the connected health apps that are on the market today, that are not actually used or created by a healthcare organization that is covered by HIPAA, they actually fall outside the bounds of HIPAA. So many IOMT devices and their manufacturers may not be subject to HIPAA's requirements and protections. In contrast to the HIPAA privacy and security framework, the FDA plays a central role in the general regulation of medical devices. And in particular, the FDA is responsible for ensuring the safety and the efficacy of medical devices. The type of oversight and pre-market approval that is needed for each type of medical device is going to vary depending on the device's classification, and the device's classification is assessed based on the device's level of risk. So for instance, Class 1 devices are seen as the least risky, and they're subject only to general controls. These devices can also be subject to enforcement discretion by the FDA. Class 2 devices have a higher risk level and may be required to satisfy general or specific... Or special controls or go through the 510K pathway for approval. Finally, Class 3 devices are those which pose a high risk of illness or injury to humans, and these are gonna be your most heavily regulated devices. And these devices are often going to require things like clinical trials, extensive pre-market approval reviews, et cetera, prior to authorization. Typically you'll see Class 3 devices being those that are used to sustain or support human life. The FDA has recognized the intersection of medical devices and emerging technology, and it really appreciates the cybersecurity risks that these devices pose. As a result, the FDA has issued cyber security guidance for medical devices, the most recent of which was publishing draft guidance in April 2022, and this was titled "Cyber Security and Medical Devices: Quality System Considerations and Content of Pre-Market Submissions." This voluntary guidance emphasizes the need for robust cybersecurity controls to help ensure that medical devices remain safe and efficient. And the FDA has also noted that medical device security is really a shared responsibility for stakeholders throughout the medical device ecosystem. And this includes healthcare facilities, patients, healthcare providers, and manufacturers of medical devices. The FDA has also issued guidance regarding post-market management of cybersecurity in medical devices, and this was published back in December of 2016. That guidance really focuses on managing post-market cybersecurity vulnerabilities, and it stresses that the interconnected structure of IOMT enables the exploitation of vulnerabilities that can represent a real risk to human health. As a result, continual maintenance throughout the device's life cycle is really necessary to protect against these exploits. IOMT device manufacturers must proactively address cybersecurity vulnerabilities so that they can minimize risks to health and safety for humans. Again though, the FDA notes that this is a shared responsibility among stakeholders, so this means everyone needs to be involved and proactive in cybersecurity, including medical device manufacturers, users, information technology system integrators, help IT developers, and IT vendors. The key here is connected... Responsibility. The downside, though, to the FDA guidance is that this guidance is voluntary. It's not mandatory, and the FDA cannot mandate cybersecurity protections, particularly in IOMT devices that are already approved and marketed. So the voluntary nature of this guidance really fails to adequately incentivize compliance. The FDA's lack of authority and frameworks to regulate IOMT device security, combined with HIPAA's limited applicability, has resulted in an insufficiently addressed regulatory gap for IOMT devices. So given the privacy and security risks that we have just discussed for IOMT devices and the possibility that many IOMT devices will fall outside of the federal regulatory systems for privacy and security of healthcare, the question then becomes, "How can healthcare organizations mitigate the privacy and security risks that are present with these devices?" Well, there's a few compliance strategies that can really assist with risk mitigation, both from the business and the manufacturer perspectives. First, let's look at compliance strategies for healthcare organizations that use or integrate IOMT devices into their networks. The first compliance strategy that I recommend is to create a data map, so that the organization knows and understands all of the places in the IT network where IOMT devices connect and/or store data. The data map should depict, one, where health data is created and stored on servers and networks; two, who has access to that health data; three, where data backups are located; and four, which data collection entry points can introduce vulnerabilities into the healthcare system. Data maps help to track an organization's data flow, they help to depict the permissible uses and disclosures of data, and they can be immensely helpful in identifying compromised data and systems if a breach occurs. In addition to a data map, having a medical device inventory can also be extremely beneficial. So a medical device inventory identifies every connected health device that exists within that organization, and it's helpful to understand what data each device collects and where that device accesses the broader network. Interestingly, only 36% of healthcare delivery organizations actually consider themselves effective in knowing where all of their medical devices are, and that can present a problem whenever you're trying to secure against cybersecurity vulnerabilities and risks. You have to know where each device connects on your network, how many devices are connected on your network, and their vulnerability points. Second, healthcare organizations must prioritize endpoint security. Given the interconnected nature of IOMT devices, many healthcare organizations have thousands of endpoints connected to their network. Endpoints can include things like mobile and medical devices, smartwatches, laptops, et cetera. To show the scale of this problem, consider that 73% of IV pumps have a vulnerability that could jeopardize patient safety. 73%. Yet despite that, IV pumps actually make up 38% of a hospital's digital device footprint. So this makes IV pumps actually one of the riskiest IOMT devices that are in use today. If an IV pump's vulnerability is exploited, it could not only harm the patient, but it could also serve as an entry point into the healthcare organization's larger IT network. Healthcare organizations should thus determine the type of endpoint security that they need and whether endpoint protection platform, endpoint detection and remediation, or extended detection and response are appropriate tools from managing cyber risk. Third, healthcare organizations should segment IOMT devices from the main IT network. Because each IOMT device can serve as an access point into the healthcare organization's network, and because healthcare organizations can have thousands of IOMT devices that are connected to their network, this represents a large platform from which bad actors can compromise the broader security network. Segmenting IOMT devices from that main network means that if a breach or a vulnerability related to those devices occurs, it will not spread to the broader health network, which allows the breach to be more easily contained. From the IOMT manufacturer perspective, it is essential that manufacturers implement stronger privacy and security frameworks. The regulatory gaps and the voluntary cybersecurity frameworks that exist today have allowed some IOMT developers to evade government oversight. Additionally, the economic realities that surround IOMT device creation can promote a race-to-market mentality that prioritizes speed of device creation over safety. Without actively prioritizing security, it is estimated that programmers make between 10 and 50 errors for every 1000 lines of code. Given that some IOMT devices, like an MRI machine, can have millions of lines of code, this means that there can be thousands of errors in a device's code which can lead to extensive vulnerability. One method that IOMT manufacturers can really use is implementing privacy and security by design. So privacy and security by design refers to the process by which a manufacturer implements and automates data privacy and security controls within the product design and infrastructure, so that privacy and security can be built into the actual product. And this means that manufacturers should really begin thinking about privacy and security at the outset of design creation, rather than focusing on reactionary privacy and security measures after design production. This also means that IOMT manufacturers should take a complete privacy and security life cycle perspective when they design their products. There are seven foundational principles for manufacturers who want to implement privacy or security by design. The first is that privacy should be proactive, not reactive, and should be preventative in nature, not remedial. This means privacy has to be a forethought in any IOMT device, and that it should help drive the ultimate IOMT device design. Second, privacy should be the default setting. This means users of IOMT devices should not need to resort to self-help to protect their privacy. Instead, privacy-friendly settings should be the default. Third, privacy should be embedded into design. IOMT devices should ensure that privacy is integral to their design and not just a design feature. Fourth, privacy should be positive sum, not zero sum. So this means that integrating privacy into the IOMT device's design should not be treated as a trade-off. There has to be a win-win solution for device design that still incorporates privacy. Fifth, there should be end-to-end security. This means that the IOMT device should have full life cycle protection. Sixth, there must be visibility and transparency. This means that the use of personal information should not be obscured or obfuscated. Finally, there needs to be respect for user privacy, and it should be user-centric. So the user of the IOMT device is going to be the principle beneficiary of privacy, and that individual is going to be impacted if privacy is violated. So the user's needs should be forefront in the minds of designers. IOMT manufacturers may also consider following voluntary industry cybersecurity and privacy frameworks that seek to highlight best practice standards. So these frameworks would allow IOMT companies to adopt cybersecurity structures that best meet their organizational needs. Some security frameworks that are in use today, but these are not the only ones that are out there, include the National Institute of Standards and Technology, NIST, Health Information Trust Alliance, HI Trust, Center for Internet Security Critical Security Controls, and International Organization for Standardization, which is the ISO. Another tactic is for IOMT device manufacturers to begin creating and implementing software bill of materials, SBOM. So manufacturers who create SBOMs for their IOMT devices are providing enhanced visibility into the, essentially, ingredients of their device. So an SBOM is really similar to something like a food label, right? It's all the ingredients, all of the components to that IOMT device. And this is especially important because software contains numerous third party components that are not usually disclosed or identified. And if healthcare organizations don't know what components are in the software that is comprising their IOMT devices, then they don't have the transparency or the visibility that they need into the software to know when a patch may be needed for specific vulnerability. In May of 2021, there was actually an executive order which stated that SBOMs are important to cybersecurity, and the FDA referenced the importance of SBOMs in its cybersecurity guidance recently. That said, only about 27% of respondents in a recent survey noted that their company generates and maintains an SBOM currently. All right, so given the potential privacy and security risks that are associated with IOMT, the next question really becomes a question of liability. In other words, if an IOMT device malfunctions, or if it is hacked, who is liable? is it the device manufacturer? Is it the cyber criminal? Is it the healthcare organization that used the device? This is actually a really complicated question, and it has not been resolved by the courts yet. However, there are certain tort frameworks in existence today, such as products liability and negligence, which could be applicable or could be stated as a cause of action in an IOMT lawsuit. So let's start first by looking at products liability. In accordance with traditional tort doctrines, IOMT device malfunctions would typically be addressed through state products liability laws, so long as preemption is not implicated. Products liability refers to the liability of a manufacturer, processor, or seller whose goods injure consumers. There are three legal paths under which products liability could be pursued. The first is strict liability, the second is negligence, and the third is breach of warranty. However, as we're going to discuss, the application of products liability causes of action to IOMT device malfunctions or breaches is not necessarily going to be a winning argument for the plaintiffs. As IOMT continues to progress, it may require reshaping traditional tort doctrines and redefining who can be held at fault if something does, in fact, go wrong with an IOMT product. So let's start first with an overview of strict products liability. Strict products liability combats harm that is caused by unreasonably dangerous products. Strict products liability requires demonstration of physical harm, death, or property damage directly attributable to a defective device. Accordingly, strict products liability is most typically applied to products that are capable of causing substantial harm, death, or property damage due to product defects. Strict liability means that the plaintiff does not have to demonstrate any sort of intent or specific mental state, or mens rea, on behalf of the defendant at the time that the act was committed. The purpose of strict liability is really to place the cost of any harm that a consumer experiences due to an unreasonably dangerous product on the manufacturers, developers, or sellers of the defective devices. In contrast to other tort doctrines, like negligence, strict liability requires no prior knowledge of a risk as a prerequisite to liability. Instead, liability is automatically going to attach once it has been proven that a device is defective, and this is true regardless of whether the manufacturer used all possible care when developing the product. Defective digital products, though, are not new, but strict products liability has actually not been applied that frequently in these types of cases. Rather, its use for digital products is much more limited, and this is really due to three primary reasons. First is the existence and application of what is known as the economic loss doctrine. The economic loss doctrine limits the type of damages that can be remedied through strict products liability. Specifically, the economic loss doctrine precludes claims that are based solely on financial losses. In the past, financial losses have been the primary kind of injury that digital devices have produced. However, as we've discussed, IOMT actually has the ability to avoid the economic loss doctrine because these devices can result in physical harm or death, depending on the type of IOMT device and the type of hack or malfunction. So while the economic loss doctrine has served as a traditional barrier to strict products liability for digital devices, it may actually not be a barrier for certain types of IOMT devices going forward. Second, to prove strict products liability, plaintiffs must prove that a missing security feature or digital defect was solely responsible for the plaintiff's harm or damage. The problem for most users of IOMT devices is that they don't have any empirical evidence to support the probabilities for their claims. Additionally, if there is any third party interference with the IOMT device, for example, by a hacker, then that interference can constitute what is known as an intervening event that absolves the manufacturer from liability. An interesting question actually arises as to whether the IOMT device manufacturer can still be held strictly liable if it is the device manufacturer's insecure code that led to the hacker being able to compromise the device in the first place, or whether that hacker's actions are actually separate intervening events. Finally, there is still ambiguity and uncertainty regarding whether software is classified as a product or a service. As the name suggests, products liability is only applicable to products. In some states, software or code can be viewed as an intangible item and not a product. As such, some states may not permit the use of strict products liability for insecure code in IOMT devices. So given these considerations, it is possible that strict products liability will not provide a sufficient remedy for consumers, even though IOMT devices can present a potentially substantial risk of harm. That said, the converse could also be true. As IOMT devices continue to develop and expand, and as more IOMT devices are integrated into the human body, there may be a greater application of strict products liability in ways that states did not originally intend. If strict products liability is used for IOMT devices, there's still going to be the question as to where along the supply chain liability will ultimately fall if a device malfunctions. IOMT devices actually differ from other technological developments because of their extensive supply chains that can span multiple manufacturers, developers, suppliers, coders, and sellers. Even though there's a potential for parties to contractually assign risk and liability, strict liability cannot be transferred by contract. So this means that if strict products liability is applied for IOMT devices, thorough incident investigation protocols are going to have to be developed, and innovators may actually be driven out of the market by the potential for strict liability. The next products liability theory that's potentially applicable to IOMT devices is negligence. To prove a negligence claim, the plaintiff has to demonstrate a duty or standard of care, breach of that duty, cause in fact, approximate cause, and damages. In the context of products liability, negligence occurs if a manufacturer places an IOMT product into the commerce stream with design defects or inadequate labeling. If the manufacturer did not use ordinary care in creation of the product and a plaintiff suffers injury that is caused by that negligent conduct, then the manufacturer could be liable. Negligence can arise for IOMT manufacturers in a couple of ways, and these include design of the product, selection of product materials, production process, product assembly, inadequate testing, and placement of inadequate warning or directions. A very common application of negligence occurs in the context of design defects, and this would be particularly true for IOMT devices. A design defect claim states that a manufacturer's product design was unreasonable given the product's risk of harm and the availability of safer alternative designs. This means that design defect claims must allege three elements. First, the product poses substantial likelihood of harm. Second, a safer and more feasible alternative product or design existed. And third, the product caused the plaintiff's injury. Plaintiffs injured by IOMT devices could bring design defect claims that are premised on insecure code. In such a claim, the plaintiff would argue that the manufacturer's IOMT device was inherently risky due to the use of certain code and the failure to adhere to cybersecurity best practices. This argument, though, has an uphill battle given the current IOMT landscape. Specifically, there is no universally secure code, which means plaintiffs are gonna have a hard time establishing that the code and security processes used by the manufacturer are less safe than other alternatives. Additionally, plaintiffs have to show that there is a safer alternative product design. However, given the rapidly developing state of connected health technology, there often will not be an alternative product design on the market. Further, given that there are inherent flaws in software, it's really going to be difficult for plaintiffs to prove that any alternative product would actually be safer. Moreover, plaintiffs may have significant difficulty proving that a product posed a substantial risk of harm. So implantable IOMT devices have similar connectivity mechanisms that are going to pose similar risks of harm, so it's gonna be difficult for a plaintiff to show that one product is more or less risky than another, and the courts could risk opening a floodgate for litigation and driving manufacturers out of the field if they find that implantable IOMT devices pose a substantial likelihood of harm because there's no universally safe code. So risk is always going to be inherent with any IOMT device, and it's not clear what level of risk is acceptable. Finally, for plaintiffs attempting to apply general negligence principles outside the design defect context, they're really going to have difficulty establishing the existence of a duty of care. As we've discussed, there are no mandatory federal cybersecurity standards for IOMT devices, and these products even fall outside the bounds of federal privacy laws. The final products liability model that is frequently applied to device defects is breach of warranty, including warranties under Article 2 of the Uniform Commercial Code and common law warranties. The law regarding whether Article 2 applies to IOMT devices, which can incorporate software and software-related services, is unclear. Further, IOMT... Will not apply to software insecurities, and it will not provide guarantees against breaches or hacks. Implied warranties, such as the implied warranty of merchantability for goods and the implied warranty of workman-like quality for services, are often going to be disclaimed. The final barrier that I wanna discuss right now for IOMT claims is the foundational notion of standing. Standing refers to the threshold condition that all individuals who seek to enter court to argue a claim must show that they are the proper party to do so. In other words, there must be a proper plaintiff for there to be a proper case before the court. Standing is a constitutional requirement that is derived from the case or controversy requirement that is set forth in Article 3, Section 2 of the US Constitution. Indeed, standing is arguably the most important of the case or controversy requirements. The idea is that judicial power, provided under Article 3, only adheres to the courts when the plaintiff has the proper qualifications to bring a case before the court. A plaintiff must demonstrate standing for each claim and each case that the plaintiff seeks to bring before the court and for each form of relief that is sought. At its most basic, this means that the plaintiff must have a personal stake in the outcome of the case or controversy to have standing to bring that case before the court. The constitutional requirements for standing include three elements. First, an invasion of a legally protected interest which is concrete and particularized and actual or imminent, not conjectural or hypothetical. Second, there must be a causal connection between the injury and the conduct complainant. IE, the injury must be fairly traceable to the action of the defendant. And third, it must be likely, as opposed to speculative, that the injury will be redressed by a favorable decision. Courts have already diverged, though, on the application of standing principles to internet of things claims. Most IOT and connected device cases, along with other cyber and data breach actions, are stalled at the motion to dismiss stage, as courts are really trying to determine whether plaintiffs have standing to sue based on unrealized risks of harm. While there have been a few cases that have alleged actual harm from internet of things devices, most cases to date have actually involved the future threat of things like identity theft as a result of a data breach and stolen health information or financial data. Federal courts have continued to struggle to try to fit data breach injuries into traditional Article 3 standing requirements. The Seventh Circuit, for example, held that standing existed in FCA et al versus Flynn et al, based on unexploited security vulnerabilities in connected vehicles. The respondents in that case brought a punitive class action based on alleged design flaws in connected phone, navigation, and entertainment controls. The base allegation there was that the U-Connect design vulnerabilities exposed respondents to an increased risk of injury or death if their cars were hacked because of the design flaw. However, there was no allegation that respondents' vehicles were ever actually hacked. Respondents' theory of standing was solely premised on hypothetical future hacks that require speculative actions by third party criminals. That said, the Seventh Circuit found that this risk of harm satisfied the standing requirements. This decision, though, is in contrast to the Ninth Circuit's opinion in Cahen versus Toyota Motor Corp. In Cahen, the Ninth Circuit rejected standing in an almost identical case when it held that the mere possibility of a connected vehicle hack was insufficient to confer standing. Similar to Flynn, the plaintiffs in Cahen argued that their vehicles were vulnerable to being hacked because of an insecure computer code. The plaintiffs did not allege a single malfunction with their connected vehicles, and they did not claim any type of physical injury. Indeed, some of the plaintiffs were not even aware of any vehicles that had been hacked outside of controlled environments. Rather, the plaintiff stated that the hacking was an imminent eventuality due to the security vulnerabilities and that the defendants, nonetheless, marketed their vehicles as being safe. The Ninth Circuit found that these alleged risks and defects were speculative, and they dismissed plaintiff's economic loss theory as not credible. Dor plaintiffs that suffer physical harm from IOMT devices, standing is likely not going to be an issue. However, for plaintiffs who suffer harm related to data breach, data exposure, or general device insecurities with the possibility of future harm, those standing concerns are likely going to be implicated. And this divergence in application of legal principles to evolving technology can create unintended consequences. For example, it means that plaintiffs could be able to forum shop their case based on the varying legal standards in each jurisdiction. And plaintiffs may be able to select a forum with more favorable judges and results. This can lead to an award of relief based purely on the court system that's selected, not the merits of a party's case. It also creates substantial uncertainty for companies and device manufacturers who may not know which standards apply. Such uncertainty can lead not only to increased costs for consumer products, but also can inhibit innovation by deterring otherwise qualified manufacturers and innovators from entering the tech market. So this concludes our presentation on IOMT devices, liability, and understanding privacy and security risks. Thank you so much for listening today. I hope you found this informative, and I look forward to speaking with you again in the future.