[00:00.000 --> 00:04.000] Welcome, everybody, to my talk, and thank you to Biohacking Village for having me. [00:04.020 --> 00:07.240] The title of today is, Why is Healthcare Security Hard? [00:08.260 --> 00:12.540] My name is Seth Carmody. I spent eight years at the FDA. [00:12.540 --> 00:16.360] I started off as a device reviewer, and then I transitioned [00:16.360 --> 00:20.180] to tech policy, and then I recently left the agency and joined [00:21.180 --> 00:23.100] a security tech startup. [00:25.300 --> 00:28.160] When we start to talk about healthcare economics, [00:28.160 --> 00:32.120] we need to first move past the struggles that security [00:32.120 --> 00:37.140] folks face, the frustration and the friction, the sticking points, [00:37.240 --> 00:40.020] a lack of funding, a lack of traction, and this problem [00:40.020 --> 00:44.200] is too big kind of thoughts. And once you [00:44.200 --> 00:48.360] are able to move past that, you start to observe some patterns, and what you realize is that [00:48.360 --> 00:52.080] these patterns are really just people. It's a collection of people [00:52.080 --> 00:56.000] making decisions, and those decisions are based on incentives. [00:56.000 --> 01:00.040] And the dude said, you look for the person who benefits. And indeed, [01:00.040 --> 01:04.600] once you start to unpack why people in the healthcare space make the decisions they do, [01:04.600 --> 01:08.020] especially around security, you start to understand the tension [01:08.020 --> 01:12.820] I felt as a regulator, and now still feel as a tech supplier. [01:13.280 --> 01:16.360] This talk is really a call to action, [01:16.360 --> 01:20.040] and this is the beginnings of shining a light, if only briefly, [01:20.040 --> 01:23.960] on the economic forces to provoke questions and really [01:23.960 --> 01:28.040] to ultimately prioritize where we spend our career capital. Since our time [01:28.040 --> 01:32.190] is precious, we want to spend it on the most impactful endeavors. [01:37.180 --> 01:39.360] Professor Ross Anderson wrote a paper [01:39.360 --> 01:43.440] from around 2001, what was called [01:43.440 --> 01:47.680] Why Information Security is Hard. I didn't know at the time [01:47.680 --> 01:51.600] when I was titling my talk for the Biohacking Village, but it's clear now after [01:51.600 --> 01:55.480] researching this talk why the titles [01:55.480 --> 01:59.180] align. In that paper, which as I understand launched [01:59.180 --> 02:03.420] formal research into security economics, Anderson described three market forces that make [02:03.420 --> 02:07.220] information security hard. He talks about network effects, such as [02:07.220 --> 02:12.280] the race to be first to market, today we launch, tomorrow we fix. [02:12.360 --> 02:15.720] He talks about the low marginal costs to produce software [02:15.720 --> 02:19.540] and that necessitates that software be sold on its value [02:19.540 --> 02:23.420] and not its cost. And lastly, technical lock-in, the software [02:23.420 --> 02:27.300] builder, the value of the software builder's company is equal [02:27.300 --> 02:31.360] to the total lock-in of all their users. So while I am presumably [02:31.360 --> 02:35.480] two decades behind, Professor Anderson states in his reconfigure [02:35.480 --> 02:39.500] of security engineering, the prominent textbook that he's authored, [02:39.500 --> 02:43.560] that medical devices specifically is an area that needs additional research. And today [02:43.560 --> 02:47.520] I intend to show the healthcare version of his key economic insights [02:47.520 --> 02:50.280] that make healthcare security hard. [02:53.200 --> 02:56.320] Whenever we start to talk about hard problems and things [02:56.320 --> 03:00.320] that make it easier, I tend to draw on things that I know well and I know [03:00.320 --> 03:04.280] the security space, I know the chemistry space very well, and [03:04.280 --> 03:08.180] I start to think of catalysis. And the general concept is that [03:08.180 --> 03:12.280] the universe says if you want to travel or go from point A to point [03:12.280 --> 03:16.520] B, that's going to cost you, and in catalysis we're talking about energy. [03:16.580 --> 03:20.240] But if you add a catalyst, it's like a discount from the universe, like a [03:20.240 --> 03:24.520] wormhole, thereby allowing you to reach your destination using fewer resources. [03:24.920 --> 03:28.260] And if we consider the significant resource [03:28.260 --> 03:32.180] constraints in healthcare security, if we want to be successful, [03:32.180 --> 03:35.780] we have to seek out the economic catalysts. [03:36.100 --> 03:40.460] So let's pose a thought experiment, and this might be helpful [03:41.520 --> 03:44.400] in decomposing a giant problem of healthcare [03:44.400 --> 03:48.320] security into some bite-sized chunks. So let's consider the [03:48.320 --> 03:52.200] following thought experiment given a specific resource time. The baseline [03:52.200 --> 03:56.200] projection on the bottom there basically says [03:56.780 --> 04:00.380] to reach some reasonable goal of, say, 90% safety, which is [04:00.380 --> 04:04.380] fairly arbitrary, but let's start there. Considering our current trajectory and current [04:04.380 --> 04:08.620] progress could take anywhere from 15 to 55 years. [04:09.320 --> 04:12.220] And this is the tension I feel. I felt it as a regulator [04:12.220 --> 04:16.500] being responsible for the progress of medical device cybersecurity. I felt it as a technology [04:16.500 --> 04:20.600] I feel it now even as a technology vendor responsible [04:20.600 --> 04:24.080] for making security easier. It's the same problem and the same [04:24.080 --> 04:29.080] operating incentives. And I also still feel this sense of urgency. [04:29.260 --> 04:32.720] Maybe nothing catastrophic will happen again, but maybe [04:32.720 --> 04:36.660] my concern is overblown, but this is the exact point of being [04:36.660 --> 04:41.400] prepared for a cyber event. You prepare for the worst and you hope for the best. [04:41.400 --> 04:44.780] It would be perfectly acceptable to me to over-prepare, [04:44.780 --> 04:47.720] to never need to reap the fruits of preparedness, [04:47.720 --> 04:52.660] but whatever your viewpoint is on urgency and preparedness, hopefully we can agree [04:52.660 --> 04:56.580] that regression isn't acceptable. And without a hard look and [04:56.580 --> 05:00.400] reckoning with the security economics, I fear that the probability that progress languishes [05:00.400 --> 05:04.900] or diminishes is too high. So if we can effectively identify the catalysts, [05:04.900 --> 05:08.620] we can compress the timeline to a decade or so without any additional [05:08.620 --> 05:12.580] effort. And when I envisioned this talk, I really [05:12.580 --> 05:16.520] wanted to talk about supply chain and liability together because they're literally [05:16.520 --> 05:20.840] the one-two punch of security economics. And when I say liability, [05:22.080 --> 05:24.000] I mean that [05:24.460 --> 05:28.500] when people produce technology, that there's some culpability to [05:28.500 --> 05:32.140] the security debt that's ingrained in that piece of technology. [05:32.620 --> 05:36.640] But first, I felt like it was sort of outside the [05:36.640 --> 05:40.880] bounds of this talk because we had some real problems in supply chain to solve first, [05:40.880 --> 05:44.860] which we'll talk about throughout the talk. The topics [05:44.860 --> 05:48.860] of equipment phase-out, legacy equipment, and simulation exercises are important [05:48.860 --> 05:51.960] but these topics won't be covered today. [05:54.120 --> 05:58.420] I like to frame the concept of healthcare supply chain [05:58.420 --> 06:02.540] economics within the supply chain. So that's the first [06:02.540 --> 06:06.560] problem that we're going to tackle. And it's a useful [06:06.560 --> 06:10.340] framer for all the discussions that will happen. [06:10.340 --> 06:14.000] It's kind of low fidelity. Maybe it's only one example. There are plenty [06:14.000 --> 06:18.400] of permutations on the supply chain. But here I think we have at least [06:18.400 --> 06:22.320] some of the major players represented. There are certainly some simplifications [06:22.320 --> 06:26.380] here and parts missing. The general flow is [06:26.380 --> 06:30.280] that if we consider that there are a bunch of builders and [06:30.280 --> 06:34.460] buyers relationships within the supply chain, we can start to tease apart some of the operating [06:34.460 --> 06:38.520] incentives. So tech, from big to small [06:38.520 --> 06:42.460] to security to general purpose tech, are supplying medical [06:42.460 --> 06:46.100] device manufacturers who act as buyers in this regard [06:46.100 --> 06:50.220] who then reassemble these pieces of technology into [06:51.420 --> 06:54.760] a medical device or some medical technology. [06:54.760 --> 06:58.420] This is specific to medical devices. But they're building it [06:58.420 --> 07:02.280] to achieve some intended effect. It could be a pacemaker. It could be [07:02.280 --> 07:05.840] an insulin pump. It could be a linear accelerator. [07:05.840 --> 07:09.820] And in general, we'll just assume that the medical [07:09.820 --> 07:13.080] device manufacturer who's regulated principally by the FDA but there are other [07:15.380 --> 07:17.800] regulatory forces that [07:17.800 --> 07:21.360] they're selling to principally a healthcare delivery organization or hospital system [07:21.360 --> 07:25.280] is a buyer. The hospital then facilitates the [07:25.740 --> 07:28.960] interaction of the device with the doctor and then the doctor delivers [07:29.720 --> 07:33.760] the therapy of that device to the patient. And all of these stakeholders [07:33.760 --> 07:37.440] when the supply chain economics have a role. [07:38.080 --> 07:41.740] But the thing is, is that [07:42.720 --> 07:46.500] healthcare's core competency is healthcare, not security. [07:46.500 --> 07:49.780] And therein lies sort of the first principle [07:49.780 --> 07:54.260] of healthcare supply chain economics and represents a [07:54.260 --> 07:58.000] significant barrier to overcome. So [07:58.000 --> 08:01.800] we typically hear about sort of where the security debt [08:01.800 --> 08:05.320] sort of builds up. We hear about what hospitals are doing [08:05.880 --> 08:10.020] to secure medical devices and other technologies. And just yesterday, IBM [08:10.020 --> 08:13.980] released a report that basically said healthcare is lagging in all [08:13.980 --> 08:17.900] key indicators within security. They spend less. They take more [08:17.900 --> 08:22.120] time to resolve things. They use less technology to solve a security problem. [08:22.120 --> 08:25.860] And this is indicative exactly of the thing that I'm talking about. It's because [08:25.860 --> 08:30.220] healthcare's core competency as it should be is healthcare, not security. [08:30.220 --> 08:34.560] And this is a core economic principle that specialization [08:34.560 --> 08:38.600] is efficient. You wouldn't want hospitals to be security experts [08:38.600 --> 08:41.900] because a jack of all trades is a master of none. So [08:41.900 --> 08:46.320] if you try to make healthcare security experts, [08:46.320 --> 08:50.520] healthcare stakeholders of all varieties, security experts, you get worse [08:50.520 --> 08:54.500] healthcare and inadequate security. And furthermore, trying to make everyone [08:54.500 --> 08:58.580] security experts is the uncatalyzed path. It will cost the most, [08:58.580 --> 09:02.340] will take the longest, and if we take this path, I doubt that we will ever [09:02.340 --> 09:04.100] collectively succeed. [09:06.540 --> 09:10.100] Make no mistake, secure tech is hard to build. [09:10.580 --> 09:14.400] So if we just back one step up from [09:14.400 --> 09:18.280] the healthcare delivery organization up into the manufacturer and its supply chain, [09:18.280 --> 09:22.620] from the manufacturer perspective, historically there has been a lack of out-of-the-box [09:22.620 --> 09:26.480] secure by design solutions. If MDMs, as I like to call them, [09:26.480 --> 09:30.360] needed an operating system, a wireless chip, a protocol, MDMs [09:30.360 --> 09:34.900] were under similar constraints as HDOs. In order to build life-saving technology, [09:34.900 --> 09:37.340] they had to use what was there. [09:39.360 --> 09:42.460] And because of the economics that Professor Anderson outlines [09:42.460 --> 09:46.320] in his 2000 paper, the components that the MDMs pulled from [09:46.320 --> 09:50.320] technology vendors' shelves weren't built with security in mind. [09:50.460 --> 09:54.220] Therefore, the security debt was passed to the manufacturer and in turn passed down the chain. [09:54.220 --> 09:58.020] And now that security has emerged as top of mind for regulators like the FDA [09:58.020 --> 10:02.560] and some leading HDOs, device manufacturers are at an inflection point [10:02.560 --> 10:06.600] where they need to buy secure components to build and maintain secure devices. [10:06.700 --> 10:10.400] And this transition is hampered by the security economic truth of healthcare. [10:10.400 --> 10:13.300] Healthcare's core competency is healthcare as it should be. [10:13.540 --> 10:18.300] Don't get me wrong, absolutely, device manufacturers should be building some security engineering [10:18.300 --> 10:22.780] capacity. These folks are the guides to the security universe and you need them. [10:22.780 --> 10:27.680] To what extent that capacity is built really depends on each individual company. [10:27.880 --> 10:31.080] Yet despite the receptivity of device manufacturers to transition [10:31.080 --> 10:35.600] and build security capacity, every product security person I've ever met, [10:35.600 --> 10:38.760] even the ones that have experienced tremendous success, [10:38.760 --> 10:42.760] have struggled in some capacity and scale to get the organization and individual [10:42.760 --> 10:46.940] business units to do what's necessary for security for reasons that we'll [10:46.940 --> 10:51.560] discuss throughout the talk. Since the transition is arduous, [10:51.560 --> 10:56.260] security folks within the device manufacturers need the tech communities help. [10:56.520 --> 10:58.500] Device manufacturers need as many out-of-the-box [10:59.180 --> 11:03.280] secure-by-design solutions as they can get [11:03.280 --> 11:07.160] and make no mistake, secure-by-design, leveraging zero-trust [11:07.160 --> 11:11.100] architectures, while not the topic of my talk, is a prerequisite [11:11.100 --> 11:15.600] for everything that follows. We can now confront the reality [11:15.600 --> 11:19.720] and magnitude of the challenge before us because despite the economic reality, [11:19.720 --> 11:22.180] the healthcare supply chain must be secured. [11:25.440 --> 11:30.000] We have a saying in chemistry that the best model system is the real thing and you won't know [11:30.000 --> 11:33.840] until you try, which means there is no amount of testing that can accurately [11:33.840 --> 11:38.220] model real life. I'm not the only one that thinks this way. [11:38.560 --> 11:41.860] The story of the DERAC-25 is a classic case study [11:41.860 --> 11:46.100] for lawyers, computer scientists, medical physicists, and so on. [11:46.100 --> 11:49.200] The case study is exquisitely described by Nancy Levinson's work [11:49.660 --> 11:52.620] in a few places. There's an appendix A of her book, [11:52.620 --> 11:57.640] Safeware, Systems, Safety, and Computers, and I think there's a separate paper as well. [11:58.180 --> 12:01.180] If you're not familiar with the story, a linear [12:01.180 --> 12:05.780] accelerator experiences failures over and under, irradiates, and kills some patients. [12:06.040 --> 12:09.100] It's a nightmare scenario for every [12:09.100 --> 12:12.340] manufacturer, and which they seek to avoid. [12:12.860 --> 12:16.980] And the story is probably so cliche and cherry-picked that eyes glaze over every time it's mentioned, [12:16.980 --> 12:21.200] but I'd like to use it here to describe two key messages. In particular, there's an FDA [12:21.200 --> 12:24.940] quote, which is basically [12:26.140 --> 12:28.920] giving feedback to the manufacturer on [12:28.920 --> 12:32.420] their corrective action plan, or a plan to fix the issues. [12:32.720 --> 12:37.140] The FDA reviewer [12:37.140 --> 12:40.820] says the following, we are in the position of saying that the proposed [12:40.820 --> 12:44.940] corrective action plan can reasonably be expected to correct the deficiency [12:44.940 --> 12:49.140] for which they were developed. We cannot say that we are reasonably confident [12:49.140 --> 12:53.040] about the safety of the entire system to prevent or minimize exposure from [12:53.040 --> 12:56.960] other fault conditions. And if I can speak for this FDA employee, I [12:56.960 --> 13:00.800] think what they're trying to say is what Donald Rumsfeld said so well. There are [13:00.800 --> 13:04.980] known knowns and unknown unknowns. They're just properties of the system [13:04.980 --> 13:08.900] which we cannot accurately predict. And this gets to the second point, [13:08.900 --> 13:12.580] that there's this underlying devotion and subscription, even today, to [13:12.580 --> 13:16.980] extrapolating the rate of component failure to the rate of system failure. [13:17.160 --> 13:20.520] And when we rely on deterministic values for rates of system [13:20.520 --> 13:24.700] failures, history has shown us that those risk models break down. And simply [13:24.700 --> 13:28.700] put, the classic probability times severity model is an oversimplified model [13:28.700 --> 13:31.900] that trades tractability for fidelity. [13:32.420 --> 13:36.700] This exact model breakdown is further exemplified by Richard [13:36.700 --> 13:40.980] Feynman and his Roger Commission work. On January 28, 1986, [13:40.980 --> 13:44.580] 73 seconds after liftoff, the space shuttle Challenger broke apart, killing [13:44.580 --> 13:49.120] seven crew members. In the resulting investigation of the Rogers Commission, [13:49.120 --> 13:52.700] member and Nobel Laureate Richard Feynman, a theoretical physicist, [13:52.700 --> 13:56.600] excoriated NASA management for extrapolating component failure [13:56.600 --> 14:00.360] rates to the entire shuttle system. Essentially, managers had [14:00.360 --> 14:04.520] concluded that through the use of component failure data, [14:04.520 --> 14:08.300] that if the shuttle launched once daily for 300 years, NASA would experience [14:08.300 --> 14:12.300] exactly one catastrophic failure, or one failure [14:12.300 --> 14:16.020] in 100,000 launches. Feynman's instincts told him otherwise [14:16.020 --> 14:20.260] and conversations with engineers resulted in a more realistic figure of [14:20.260 --> 14:24.360] one failure in 100 launches. Don't get me wrong, device manufacturers [14:24.360 --> 14:28.420] absolutely need to test to reduce risk. However, you will not know [14:28.420 --> 14:32.320] the extent until it's marketed. That's a fact. That's why the bar for marketing [14:32.320 --> 14:36.300] is not 100% safety and 100% effectiveness. The legal [14:36.300 --> 14:40.160] bar is reasonable assurance of safety and effectiveness, and in [14:40.160 --> 14:44.240] complex systems, with emergent behavior, you need to collect post-market [14:44.240 --> 14:47.860] data, which they do. It's just sub-optimal. [14:51.480 --> 14:55.440] Data is important, especially if the data indicate a near miss. [14:55.460 --> 14:59.280] Also, as part of the Rogers Commission, Feynman had to explain to NASA what a [14:59.280 --> 15:03.800] safety factor was. Some early tests of the booster rocket's O-rings [15:03.800 --> 15:06.560] resulted in the O-ring burning a third of the way through. [15:06.560 --> 15:10.000] NASA managers recorded this result as demonstrating that the [15:10.560 --> 15:14.180] O-rings had a safety factor of three, and Feynman had to explain [15:14.180 --> 15:18.880] that the safety factor is, in fact, zero. To paraphrase [15:18.880 --> 15:22.640] Feynman's example, if a 1,000-pound truck drove across a bridge [15:22.640 --> 15:26.400] designed to bear 3,000 pounds and a crack appeared in a beam [15:26.400 --> 15:30.520] even just a third of the way through, the safety factor is now zero. The bridge [15:30.520 --> 15:34.420] is defective. There was no safety factor at all, even though the bridge [15:34.420 --> 15:38.720] did not actually collapse. The data for the O-ring was there. [15:43.180 --> 15:46.480] To further build on this idea of systems [15:46.480 --> 15:50.260] and uncertainty in systems, as a regulator [15:50.260 --> 15:54.340] I had a front-row seat to quite a few economic externalities for security [15:54.340 --> 15:58.200] from routine vulnerability disclosures to global cyber attacks. [15:58.400 --> 16:02.180] What has been the impact of these events? We have lots of disclosures with [16:02.320 --> 16:06.140] a dash of coordination and a pinch of public. We've got WannaCry and [16:06.140 --> 16:09.820] Petya and a handful of large impact vulnerabilities that have us questioning [16:09.820 --> 16:14.360] why did I choose this field? As a [16:14.660 --> 16:18.380] manufacturer, it would be perfectly rational to [16:19.340 --> 16:22.300] the event of a disclosure dropping my stock price [16:22.300 --> 16:26.460] but ultimately recovering. You might read it with a sigh of relief. [16:26.460 --> 16:30.420] I'm glad that's over. What would be the incentive to change [16:30.420 --> 16:33.980] in that case? It would be very easy to play the event off as a black swan or [16:33.980 --> 16:36.620] an outlier instead of a larger symptom [16:37.540 --> 16:41.940] of an underlying issue or a cause to look under the hood or look into the [16:41.940 --> 16:45.980] field and see if there's anything else there. And furthermore, because healthcare's [16:45.980 --> 16:49.900] job is healthcare, hospitals still need to buy the technology and those darn [16:49.900 --> 16:53.980] patients just won't spontaneously get better. It wouldn't surprise me [16:53.980 --> 16:57.660] if there were negligible impacts to device and technology sales as a result of taxes [16:57.660 --> 17:02.080] potent as WannaCry. So what should [17:02.080 --> 17:06.460] we do when our crashes, our visible events are collectively shrugged off? [17:07.960 --> 17:09.500] Especially when folks know that there's [17:10.040 --> 17:13.040] nothing really that prevents a WannaCry 2.0. [17:15.540 --> 17:18.160] And this is the perfect job of [17:18.160 --> 17:22.200] the regulator. If the market fails to deliver the correct incentives, this is a primary example [17:22.200 --> 17:25.940] of the role of the regulator. If you look at the history of the FDA and think about why the [17:25.940 --> 17:30.100] FDA exists, it's about resolving information asymmetry for the consumer. [17:30.100 --> 17:34.000] The average person cannot assess the safety and efficacy of a drug or device [17:34.000 --> 17:37.960] and even if they could, it would be economically inefficient, not to mention ridiculous, that if [17:38.620 --> 17:42.400] before you ate or started chemo or passed out from a cardiac event, [17:42.400 --> 17:46.140] you had to evaluate the safety and efficacy of a product you needed. [17:46.160 --> 17:49.980] So you need an impartial body to see what's in the meat or [17:49.980 --> 17:54.040] evaluate the claim of a drug or device. And therein lies, again, the security [17:54.040 --> 17:58.140] economics of healthcare. Healthcare is healthcare, not security. So you [17:58.140 --> 18:01.980] are then reliant, as a consumer and patient, [18:01.980 --> 18:05.980] you're reliant on the entire supply chain to deliver healthcare and deliver security. [18:05.980 --> 18:10.180] It just doesn't work efficiently. It doesn't scale. It doesn't solve the problem on a timeline [18:10.180 --> 18:14.040] that we desire. Nicholas Taleb, the author of [18:14.040 --> 18:17.900] The Black Swan, offers us another brilliant explanation for the challenge of [18:17.900 --> 18:22.280] healthcare's transition to security. The idea of a Black Swan event or a low-probability [18:22.280 --> 18:26.460] event is often disregarded as possible, if regarded at all, [18:26.460 --> 18:30.380] and therefore isn't present in our risk models. Now, Taleb was talking about [18:30.380 --> 18:34.480] the uncertainty present in financial systems, but the concept applies directly [18:34.480 --> 18:38.380] to healthcare as well. We're so concerned with the probabilities, and indeed [18:38.380 --> 18:42.240] it is the foundation of risk management, that we've convinced ourselves [18:42.240 --> 18:47.200] that a security event is a Black Swan event, not an everyday occurrence. [18:51.910 --> 18:54.070] In 1990, the GAO released [18:54.350 --> 18:57.530] a report the FDA knew of less than 1% [18:57.530 --> 19:01.590] deaths, serious injuries, or equipment failures that occurred in hospitals. [19:01.590 --> 19:05.410] And at the time, reporting from hospitals to manufacturers about [19:05.410 --> 19:09.290] these events was voluntary, so the law was amended to make it compulsory for user [19:09.290 --> 19:13.390] facilities and hospitals to report to device manufacturers and FDA [19:13.390 --> 19:17.650] under certain conditions. And the result was a significant uptick in reporting. [19:19.890 --> 19:21.430] Separately, in 1999, [19:21.430 --> 19:25.250] the Institute of Medicine released a shocking report that the third leading cause of death [19:25.250 --> 19:28.170] in the U.S. was about 250,000 deaths. [19:28.330 --> 19:33.330] It was absolutely shocking. [19:35.870 --> 19:37.150] This study [19:37.150 --> 19:41.210] touched off a wave of efforts in hospitals to corral and reduce those [19:41.210 --> 19:45.270] errors, and I've seen recent reports into 2020 [19:45.270 --> 19:49.270] that those deaths due to preventable errors are significantly reduced to around [19:49.270 --> 19:53.210] 22,000. Regardless of the number, these two pieces of information got me [19:53.210 --> 19:57.050] thinking, how many close calls are there? And I wondered, what could be gained by [19:57.050 --> 20:01.110] leveraging the technology and connectedness to automatically capture, [20:01.110 --> 20:05.130] aggregate, and analyze the data about the performance of the device? In the age [20:05.130 --> 20:08.950] of technology, it's absolutely possible and cheap to assess the performance of the device [20:08.950 --> 20:12.770] for the betterment of healthcare. I mean, the internet figured out a way to [20:12.770 --> 20:16.930] monetize my online behaviors. Why not do something else useful with it? [20:17.870 --> 20:21.210] Imagine how difficult it was for the Therac-25 manufacturer [20:21.830 --> 20:25.070] AECL to piece together the puzzle as it emerged. [20:25.070 --> 20:29.150] We enjoyed the benefits of hindsight, but I imagine in the moment it was quite vexing. [20:29.150 --> 20:32.510] You've got people dying, and you can't even reproduce the error, but if [20:33.180 --> 20:36.630] you could further leverage the technology [20:37.120 --> 20:41.370] already on board to capture the events, black box style, [20:41.370 --> 20:45.050] pool and analyze the data, maybe it becomes far easier and far cheaper [20:45.050 --> 20:49.170] to respond meaningfully to the real world. We need to [20:49.170 --> 20:53.790] pay more attention at the system level. We need to look deeper. We need to collect data. [20:53.970 --> 20:57.170] I believe that in the real world, everyday devices experience security [20:57.170 --> 21:00.330] events. I mean, events as broadly as possible. [21:00.710 --> 21:05.310] People may not be dying, but I'm sure that there are near misses all the time. [21:05.310 --> 21:09.090] And if we can show the data, then that creates the incentive to build [21:09.090 --> 21:13.090] secure healthcare [21:13.090 --> 21:17.250] technology from the ground up. Using secure by design components from the tech [21:17.250 --> 21:21.250] industry as well as helps us answer the questions of how [21:21.250 --> 21:25.230] much security is adequate. So let's measure it. [21:25.490 --> 21:29.330] Heisenberg said it best. He changed the outcome by measuring it. Now he meant it for subatomic [21:29.330 --> 21:32.090] particles, but we'll take it here for changing the [21:33.110 --> 21:35.770] outcomes of healthcare for the better. [21:37.190 --> 21:41.390] And honestly, in order to get across the finish line for security, no security [21:41.390 --> 21:45.130] event perceived to be a black swan will get us across the finish line. It will be the [21:45.130 --> 21:48.990] innumerable cygnets that are hiding in the weeds of everyday data. [21:48.990 --> 21:52.270] And today I learned that cygnets were baby swans. [21:55.690 --> 21:57.170] Costanza said that he needed [21:57.170 --> 22:01.210] to learn risk management because it was on his resume. Let's not fall [22:01.210 --> 22:05.030] into the trap of using oversimplified risk management models because we [22:05.030 --> 22:09.030] build our careers on it. The uncertainty of behavior complex system demands [22:09.030 --> 22:13.070] the adoption of new, higher fidelity models that are plugged into the real [22:13.070 --> 22:17.030] world. For as Feynman put it, mother nature cannot be fooled. [22:17.110 --> 22:20.150] And in doing so, we'll begin to reveal the late economic incentives [22:20.970 --> 22:25.010] not just for secure by design, but I imagine a host of [22:25.010 --> 22:28.770] important clinical items we'll be able to tease out [22:28.770 --> 22:32.550] efficiently if failures are related to human factors, [22:32.950 --> 22:36.950] humidity, cyber security, bad boards, a software bug, or if it's a Tuesday [22:36.950 --> 22:40.930] in April during a full moon, you'll have the data right there. And as we look [22:40.930 --> 22:44.690] towards the future of healthcare where outcomes determine who gets paid, [22:44.690 --> 22:48.950] it will be the only way. Certainly, tremendous progress has [22:48.950 --> 22:52.890] been made, and the groundwork for catalysis and acceleration has been made possible [22:52.890 --> 22:56.890] by this progress. You only need to look to the FDA and international regulators [22:56.890 --> 23:00.130] recent policies in this space, and quite frankly, the efforts [23:00.810 --> 23:04.730] of security champions across the supply chain really to understand how [23:04.730 --> 23:08.850] deeply passionate healthcare is about fixing all sorts of problems, including security. [23:08.850 --> 23:12.750] We can supercharge their efforts by turning ineffectual black swans into [23:12.750 --> 23:16.990] effective everyday economic incentives. Thank you, and I'd be happy to take [23:16.990 --> 23:17.970] any questions.