1 00:00:00,000 --> 00:00:04,000 Welcome, everybody, to my talk, and thank you to Biohacking Village for having me. 2 00:00:04,020 --> 00:00:07,240 The title of today is, Why is Healthcare Security Hard? 3 00:00:08,260 --> 00:00:09,780 My name is Seth Carmody. 4 00:00:09,780 --> 00:00:12,540 I spent eight years at the FDA. 5 00:00:12,540 --> 00:00:23,100 I started off as a device reviewer, and then I transitioned to tech policy, and then I recently left the agency and joined a security tech startup. 6 00:00:25,300 --> 00:00:43,020 When we start to talk about healthcare economics, we need to first move past the struggles that security folks face, the frustration and the friction, the sticking points, a lack of funding, a lack of traction, and this problem is too big kind of thoughts. 7 00:00:43,420 --> 00:00:51,020 And once you are able to move past that, you start to observe some patterns, and what you realize is that these patterns are really just people. 8 00:00:51,020 --> 00:00:56,000 It's a collection of people making decisions, and those decisions are based on incentives. 9 00:00:56,000 --> 00:00:59,620 And the dude said, you look for the person who benefits. 10 00:00:59,620 --> 00:01:12,820 And indeed, once you start to unpack why people in the healthcare space make the decisions they do, especially around security, you start to understand the tension I felt as a regulator, and now still feel as a tech supplier. 11 00:01:13,280 --> 00:01:27,200 This talk is really a call to action, and this is the beginnings of shining a light, if only briefly, on the economic forces to provoke questions and really to ultimately prioritize where we spend our career capital. 12 00:01:27,200 --> 00:01:32,190 Since our time is precious, we want to spend it on the most impactful endeavors. 13 00:01:37,180 --> 00:01:46,480 Professor Ross Anderson wrote a paper from around 2001, what was called Why Information Security is Hard. 14 00:01:46,580 --> 00:01:56,540 I didn't know at the time when I was titling my talk for the Biohacking Village, but it's clear now after researching this talk why the titles align. 15 00:01:56,820 --> 00:02:04,660 In that paper, which as I understand launched formal research into security economics, Anderson described three market forces that make information security hard. 16 00:02:04,660 --> 00:02:12,280 He talks about network effects, such as the race to be first to market, today we launch, tomorrow we fix. 17 00:02:12,360 --> 00:02:21,060 He talks about the low marginal costs to produce software and that necessitates that software be sold on its value and not its cost. 18 00:02:21,140 --> 00:02:29,840 And lastly, technical lock-in, the software builder, the value of the software builder's company is equal to the total lock-in of all their users. 19 00:02:30,080 --> 00:02:43,100 So while I am presumably two decades behind, Professor Anderson states in his reconfigure of security engineering, the prominent textbook that he's authored, that medical devices specifically is an area that needs additional research. 20 00:02:43,100 --> 00:02:50,280 And today I intend to show the healthcare version of his key economic insights that make healthcare security hard. 21 00:02:53,200 --> 00:03:06,200 Whenever we start to talk about hard problems and things that make it easier, I tend to draw on things that I know well and I know the security space, I know the chemistry space very well, and I start to think of catalysis. 22 00:03:06,200 --> 00:03:16,520 And the general concept is that the universe says if you want to travel or go from point A to point B, that's going to cost you, and in catalysis we're talking about energy. 23 00:03:16,580 --> 00:03:24,520 But if you add a catalyst, it's like a discount from the universe, like a wormhole, thereby allowing you to reach your destination using fewer resources. 24 00:03:24,920 --> 00:03:35,780 And if we consider the significant resource constraints in healthcare security, if we want to be successful, we have to seek out the economic catalysts. 25 00:03:36,100 --> 00:03:46,720 So let's pose a thought experiment, and this might be helpful in decomposing a giant problem of healthcare security into some bite-sized chunks. 26 00:03:46,720 --> 00:03:51,600 So let's consider the following thought experiment given a specific resource time. 27 00:03:51,600 --> 00:04:02,540 The baseline projection on the bottom there basically says to reach some reasonable goal of, say, 90% safety, which is fairly arbitrary, but let's start there. 28 00:04:02,620 --> 00:04:08,620 Considering our current trajectory and current progress could take anywhere from 15 to 55 years. 29 00:04:09,320 --> 00:04:10,540 And this is the tension I feel. 30 00:04:10,800 --> 00:04:15,300 I felt it as a regulator being responsible for the progress of medical device cybersecurity. 31 00:04:15,300 --> 00:04:22,040 I felt it as a technology I feel it now even as a technology vendor responsible for making security easier. 32 00:04:22,040 --> 00:04:26,260 It's the same problem and the same operating incentives. 33 00:04:26,520 --> 00:04:29,080 And I also still feel this sense of urgency. 34 00:04:29,260 --> 00:04:38,580 Maybe nothing catastrophic will happen again, but maybe my concern is overblown, but this is the exact point of being prepared for a cyber event. 35 00:04:38,580 --> 00:04:41,400 You prepare for the worst and you hope for the best. 36 00:04:41,400 --> 00:04:55,140 It would be perfectly acceptable to me to over-prepare, to never need to reap the fruits of preparedness, but whatever your viewpoint is on urgency and preparedness, hopefully we can agree that regression isn't acceptable. 37 00:04:55,640 --> 00:05:02,280 And without a hard look and reckoning with the security economics, I fear that the probability that progress languishes or diminishes is too high. 38 00:05:02,560 --> 00:05:09,480 So if we can effectively identify the catalysts, we can compress the timeline to a decade or so without any additional effort. 39 00:05:10,660 --> 00:05:18,560 And when I envisioned this talk, I really wanted to talk about supply chain and liability together because they're literally the one-two punch of security economics. 40 00:05:18,560 --> 00:05:32,140 And when I say liability, I mean that when people produce technology, that there's some culpability to the security debt that's ingrained in that piece of technology. 41 00:05:32,620 --> 00:05:44,000 But first, I felt like it was sort of outside the bounds of this talk because we had some real problems in supply chain to solve first, which we'll talk about throughout the talk. 42 00:05:44,140 --> 00:05:51,960 The topics of equipment phase-out, legacy equipment, and simulation exercises are important but these topics won't be covered today. 43 00:05:54,120 --> 00:06:01,500 I like to frame the concept of healthcare supply chain economics within the supply chain. 44 00:06:01,500 --> 00:06:04,560 So that's the first problem that we're going to tackle. 45 00:06:05,000 --> 00:06:10,340 And it's a useful framer for all the discussions that will happen. 46 00:06:10,340 --> 00:06:12,540 It's kind of low fidelity. 47 00:06:12,540 --> 00:06:13,480 Maybe it's only one example. 48 00:06:13,480 --> 00:06:16,900 There are plenty of permutations on the supply chain. 49 00:06:16,960 --> 00:06:20,640 But here I think we have at least some of the major players represented. 50 00:06:20,640 --> 00:06:24,540 There are certainly some simplifications here and parts missing. 51 00:06:25,300 --> 00:06:35,580 The general flow is that if we consider that there are a bunch of builders and buyers relationships within the supply chain, we can start to tease apart some of the operating incentives. 52 00:06:35,640 --> 00:06:54,760 So tech, from big to small to security to general purpose tech, are supplying medical device manufacturers who act as buyers in this regard who then reassemble these pieces of technology into a medical device or some medical technology. 53 00:06:54,760 --> 00:06:57,080 This is specific to medical devices. 54 00:06:57,300 --> 00:07:00,140 But they're building it to achieve some intended effect. 55 00:07:00,140 --> 00:07:01,940 It could be a pacemaker. 56 00:07:01,940 --> 00:07:03,380 It could be an insulin pump. 57 00:07:03,380 --> 00:07:05,840 It could be a linear accelerator. 58 00:07:05,840 --> 00:07:22,480 And in general, we'll just assume that the medical device manufacturer who's regulated principally by the FDA but there are other regulatory forces that they're selling to principally a healthcare delivery organization or hospital system is a buyer. 59 00:07:22,580 --> 00:07:32,620 The hospital then facilitates the interaction of the device with the doctor and then the doctor delivers the therapy of that device to the patient. 60 00:07:32,620 --> 00:07:37,440 And all of these stakeholders when the supply chain economics have a role. 61 00:07:38,080 --> 00:07:46,500 But the thing is, is that healthcare's core competency is healthcare, not security. 62 00:07:46,500 --> 00:07:57,240 And therein lies sort of the first principle of healthcare supply chain economics and represents a significant barrier to overcome. 63 00:07:57,240 --> 00:08:03,360 So we typically hear about sort of where the security debt sort of builds up. 64 00:08:03,360 --> 00:08:08,540 We hear about what hospitals are doing to secure medical devices and other technologies. 65 00:08:08,540 --> 00:08:15,900 And just yesterday, IBM released a report that basically said healthcare is lagging in all key indicators within security. 66 00:08:15,900 --> 00:08:17,120 They spend less. 67 00:08:17,120 --> 00:08:19,660 They take more time to resolve things. 68 00:08:19,660 --> 00:08:22,120 They use less technology to solve a security problem. 69 00:08:22,120 --> 00:08:25,280 And this is indicative exactly of the thing that I'm talking about. 70 00:08:25,280 --> 00:08:30,220 It's because healthcare's core competency as it should be is healthcare, not security. 71 00:08:30,220 --> 00:08:35,660 And this is a core economic principle that specialization is efficient. 72 00:08:35,660 --> 00:08:41,700 You wouldn't want hospitals to be security experts because a jack of all trades is a master of none. 73 00:08:41,760 --> 00:08:52,780 So if you try to make healthcare security experts, healthcare stakeholders of all varieties, security experts, you get worse healthcare and inadequate security. 74 00:08:52,780 --> 00:08:57,140 And furthermore, trying to make everyone security experts is the uncatalyzed path. 75 00:08:57,140 --> 00:09:04,100 It will cost the most, will take the longest, and if we take this path, I doubt that we will ever collectively succeed. 76 00:09:06,540 --> 00:09:10,100 Make no mistake, secure tech is hard to build. 77 00:09:10,580 --> 00:09:24,680 So if we just back one step up from the healthcare delivery organization up into the manufacturer and its supply chain, from the manufacturer perspective, historically there has been a lack of out-of-the-box secure by design solutions. 78 00:09:24,800 --> 00:09:32,620 If MDMs, as I like to call them, needed an operating system, a wireless chip, a protocol, MDMs were under similar constraints as HDOs. 79 00:09:32,620 --> 00:09:37,340 In order to build life-saving technology, they had to use what was there. 80 00:09:39,360 --> 00:09:50,320 And because of the economics that Professor Anderson outlines in his 2000 paper, the components that the MDMs pulled from technology vendors' shelves weren't built with security in mind. 81 00:09:50,460 --> 00:09:54,220 Therefore, the security debt was passed to the manufacturer and in turn passed down the chain. 82 00:09:54,220 --> 00:10:06,600 And now that security has emerged as top of mind for regulators like the FDA and some leading HDOs, device manufacturers are at an inflection point where they need to buy secure components to build and maintain secure devices. 83 00:10:06,700 --> 00:10:10,400 And this transition is hampered by the security economic truth of healthcare. 84 00:10:10,400 --> 00:10:13,300 Healthcare's core competency is healthcare as it should be. 85 00:10:13,540 --> 00:10:19,340 Don't get me wrong, absolutely, device manufacturers should be building some security engineering capacity. 86 00:10:19,340 --> 00:10:22,780 These folks are the guides to the security universe and you need them. 87 00:10:22,780 --> 00:10:27,680 To what extent that capacity is built really depends on each individual company. 88 00:10:27,880 --> 00:10:48,620 Yet despite the receptivity of device manufacturers to transition and build security capacity, every product security person I've ever met, even the ones that have experienced tremendous success, have struggled in some capacity and scale to get the organization and individual business units to do what's necessary for security for reasons that we'll discuss throughout the talk. 89 00:10:49,260 --> 00:10:56,260 Since the transition is arduous, security folks within the device manufacturers need the tech communities help. 90 00:10:56,520 --> 00:11:13,020 Device manufacturers need as many out-of-the-box secure-by-design solutions as they can get and make no mistake, secure-by-design, leveraging zero-trust architectures, while not the topic of my talk, is a prerequisite for everything that follows. 91 00:11:13,800 --> 00:11:22,180 We can now confront the reality and magnitude of the challenge before us because despite the economic reality, the healthcare supply chain must be secured. 92 00:11:25,440 --> 00:11:35,300 We have a saying in chemistry that the best model system is the real thing and you won't know until you try, which means there is no amount of testing that can accurately model real life. 93 00:11:35,660 --> 00:11:38,220 I'm not the only one that thinks this way. 94 00:11:38,560 --> 00:11:46,100 The story of the DERAC-25 is a classic case study for lawyers, computer scientists, medical physicists, and so on. 95 00:11:46,100 --> 00:11:51,060 The case study is exquisitely described by Nancy Levinson's work in a few places. 96 00:11:51,060 --> 00:11:57,640 There's an appendix A of her book, Safeware, Systems, Safety, and Computers, and I think there's a separate paper as well. 97 00:11:58,180 --> 00:12:05,780 If you're not familiar with the story, a linear accelerator experiences failures over and under, irradiates, and kills some patients. 98 00:12:06,040 --> 00:12:12,340 It's a nightmare scenario for every manufacturer, and which they seek to avoid. 99 00:12:12,860 --> 00:12:19,760 And the story is probably so cliche and cherry-picked that eyes glaze over every time it's mentioned, but I'd like to use it here to describe two key messages. 100 00:12:19,760 --> 00:12:32,420 In particular, there's an FDA quote, which is basically giving feedback to the manufacturer on their corrective action plan, or a plan to fix the issues. 101 00:12:32,720 --> 00:12:46,860 The FDA reviewer says the following, we are in the position of saying that the proposed corrective action plan can reasonably be expected to correct the deficiency for which they were developed. 102 00:12:46,960 --> 00:12:54,640 We cannot say that we are reasonably confident about the safety of the entire system to prevent or minimize exposure from other fault conditions. 103 00:12:54,720 --> 00:13:00,400 And if I can speak for this FDA employee, I think what they're trying to say is what Donald Rumsfeld said so well. 104 00:13:00,400 --> 00:13:03,020 There are known knowns and unknown unknowns. 105 00:13:03,020 --> 00:13:07,020 They're just properties of the system which we cannot accurately predict. 106 00:13:07,020 --> 00:13:16,980 And this gets to the second point, that there's this underlying devotion and subscription, even today, to extrapolating the rate of component failure to the rate of system failure. 107 00:13:17,160 --> 00:13:24,340 And when we rely on deterministic values for rates of system failures, history has shown us that those risk models break down. 108 00:13:24,340 --> 00:13:31,900 And simply put, the classic probability times severity model is an oversimplified model that trades tractability for fidelity. 109 00:13:32,420 --> 00:13:38,900 This exact model breakdown is further exemplified by Richard Feynman and his Roger Commission work. 110 00:13:38,900 --> 00:13:46,060 On January 28, 1986, 73 seconds after liftoff, the space shuttle Challenger broke apart, killing seven crew members. 111 00:13:46,100 --> 00:13:58,720 In the resulting investigation of the Rogers Commission, member and Nobel Laureate Richard Feynman, a theoretical physicist, excoriated NASA management for extrapolating component failure rates to the entire shuttle system. 112 00:13:58,720 --> 00:14:13,980 Essentially, managers had concluded that through the use of component failure data, that if the shuttle launched once daily for 300 years, NASA would experience exactly one catastrophic failure, or one failure in 100,000 launches. 113 00:14:14,200 --> 00:14:22,320 Feynman's instincts told him otherwise and conversations with engineers resulted in a more realistic figure of one failure in 100 launches. 114 00:14:22,320 --> 00:14:26,500 Don't get me wrong, device manufacturers absolutely need to test to reduce risk. 115 00:14:26,500 --> 00:14:29,920 However, you will not know the extent until it's marketed. 116 00:14:29,920 --> 00:14:30,820 That's a fact. 117 00:14:30,820 --> 00:14:35,960 That's why the bar for marketing is not 100% safety and 100% effectiveness. 118 00:14:35,960 --> 00:14:45,720 The legal bar is reasonable assurance of safety and effectiveness, and in complex systems, with emergent behavior, you need to collect post-market data, which they do. 119 00:14:45,720 --> 00:14:47,860 It's just sub-optimal. 120 00:14:51,480 --> 00:14:55,440 Data is important, especially if the data indicate a near miss. 121 00:14:55,460 --> 00:15:00,580 Also, as part of the Rogers Commission, Feynman had to explain to NASA what a safety factor was. 122 00:15:00,580 --> 00:15:06,560 Some early tests of the booster rocket's O-rings resulted in the O-ring burning a third of the way through. 123 00:15:06,560 --> 00:15:17,760 NASA managers recorded this result as demonstrating that the O-rings had a safety factor of three, and Feynman had to explain that the safety factor is, in fact, zero. 124 00:15:17,900 --> 00:15:30,220 To paraphrase Feynman's example, if a 1,000-pound truck drove across a bridge designed to bear 3,000 pounds and a crack appeared in a beam even just a third of the way through, the safety factor is now zero. 125 00:15:30,220 --> 00:15:31,380 The bridge is defective. 126 00:15:31,380 --> 00:15:36,080 There was no safety factor at all, even though the bridge did not actually collapse. 127 00:15:36,080 --> 00:15:38,720 The data for the O-ring was there. 128 00:15:43,180 --> 00:15:58,200 To further build on this idea of systems and uncertainty in systems, as a regulator I had a front-row seat to quite a few economic externalities for security from routine vulnerability disclosures to global cyber attacks. 129 00:15:58,400 --> 00:16:00,560 What has been the impact of these events? 130 00:16:00,560 --> 00:16:05,000 We have lots of disclosures with a dash of coordination and a pinch of public. 131 00:16:05,000 --> 00:16:12,440 We've got WannaCry and Petya and a handful of large impact vulnerabilities that have us questioning why did I choose this field? 132 00:16:12,920 --> 00:16:24,020 As a manufacturer , it would be perfectly rational to the event of a disclosure dropping my stock price but ultimately recovering. 133 00:16:24,020 --> 00:16:26,060 You might read it with a sigh of relief. 134 00:16:26,060 --> 00:16:28,060 I'm glad that's over. 135 00:16:28,640 --> 00:16:30,880 What would be the incentive to change in that case? 136 00:16:30,880 --> 00:16:44,020 It would be very easy to play the event off as a black swan or an outlier instead of a larger symptom of an underlying issue or a cause to look under the hood or look into the field and see if there's anything else there. 137 00:16:44,700 --> 00:16:52,700 And furthermore, because healthcare's job is healthcare, hospitals still need to buy the technology and those darn patients just won't spontaneously get better. 138 00:16:52,940 --> 00:16:59,260 It wouldn't surprise me if there were negligible impacts to device and technology sales as a result of taxes potent as WannaCry. 139 00:17:00,560 --> 00:17:06,460 So what should we do when our crashes, our visible events are collectively shrugged off? 140 00:17:07,960 --> 00:17:13,040 Especially when folks know that there's nothing really that prevents a WannaCry 2.0. 141 00:17:15,540 --> 00:17:18,840 And this is the perfect job of the regulator. 142 00:17:18,840 --> 00:17:23,560 If the market fails to deliver the correct incentives, this is a primary example of the role of the regulator. 143 00:17:23,560 --> 00:17:30,100 If you look at the history of the FDA and think about why the FDA exists, it's about resolving information asymmetry for the consumer. 144 00:17:30,100 --> 00:17:46,140 The average person cannot assess the safety and efficacy of a drug or device and even if they could, it would be economically inefficient, not to mention ridiculous, that if before you ate or started chemo or passed out from a cardiac event, you had to evaluate the safety and efficacy of a product you needed. 145 00:17:46,160 --> 00:17:52,060 So you need an impartial body to see what's in the meat or evaluate the claim of a drug or device. 146 00:17:52,060 --> 00:17:55,060 And therein lies, again, the security economics of healthcare. 147 00:17:55,060 --> 00:17:57,180 Healthcare is healthcare, not security. 148 00:17:57,440 --> 00:18:05,980 So you are then reliant, as a consumer and patient, you're reliant on the entire supply chain to deliver healthcare and deliver security. 149 00:18:05,980 --> 00:18:07,500 It just doesn't work efficiently. 150 00:18:07,500 --> 00:18:08,300 It doesn't scale. 151 00:18:08,300 --> 00:18:11,400 It doesn't solve the problem on a timeline that we desire. 152 00:18:12,440 --> 00:18:19,600 Nicholas Taleb, the author of The Black Swan, offers us another brilliant explanation for the challenge of healthcare's transition to security. 153 00:18:19,660 --> 00:18:29,220 The idea of a Black Swan event or a low-probability event is often disregarded as possible, if regarded at all, and therefore isn't present in our risk models. 154 00:18:29,340 --> 00:18:35,820 Now, Taleb was talking about the uncertainty present in financial systems, but the concept applies directly to healthcare as well. 155 00:18:35,820 --> 00:18:47,200 We're so concerned with the probabilities, and indeed it is the foundation of risk management, that we've convinced ourselves that a security event is a Black Swan event, not an everyday occurrence. 156 00:18:51,910 --> 00:19:01,590 In 1990, the GAO released a report the FDA knew of less than 1% deaths, serious injuries, or equipment failures that occurred in hospitals. 157 00:19:01,590 --> 00:19:14,970 And at the time, reporting from hospitals to manufacturers about these events was voluntary, so the law was amended to make it compulsory for user facilities and hospitals to report to device manufacturers and FDA under certain conditions. 158 00:19:14,970 --> 00:19:17,650 And the result was a significant uptick in reporting. 159 00:19:19,890 --> 00:19:25,810 Separately, in 1999, the Institute of Medicine released a shocking report that the third leading cause of death in the U.S. 160 00:19:25,810 --> 00:19:28,170 was about 250,000 deaths. 161 00:19:28,330 --> 00:19:33,330 It was absolutely shocking. 162 00:19:35,870 --> 00:19:50,490 This study touched off a wave of efforts in hospitals to corral and reduce those errors, and I've seen recent reports into 2020 that those deaths due to preventable errors are significantly reduced to around 22,000. 163 00:19:50,490 --> 00:19:55,410 Regardless of the number, these two pieces of information got me thinking, how many close calls are there? 164 00:19:55,410 --> 00:20:04,490 And I wondered, what could be gained by leveraging the technology and connectedness to automatically capture, aggregate, and analyze the data about the performance of the device? 165 00:20:04,590 --> 00:20:10,390 In the age of technology, it's absolutely possible and cheap to assess the performance of the device for the betterment of healthcare. 166 00:20:10,390 --> 00:20:14,590 I mean, the internet figured out a way to monetize my online behaviors. 167 00:20:14,590 --> 00:20:16,930 Why not do something else useful with it? 168 00:20:17,870 --> 00:20:25,070 Imagine how difficult it was for the Therac-25 manufacturer AECL to piece together the puzzle as it emerged. 169 00:20:25,070 --> 00:20:29,150 We enjoyed the benefits of hindsight, but I imagine in the moment it was quite vexing. 170 00:20:29,150 --> 00:20:47,670 You've got people dying, and you can't even reproduce the error, but if you could further leverage the technology already on board to capture the events, black box style, pool and analyze the data, maybe it becomes far easier and far cheaper to respond meaningfully to the real world. 171 00:20:48,370 --> 00:20:51,090 We need to pay more attention at the system level. 172 00:20:51,090 --> 00:20:52,090 We need to look deeper. 173 00:20:52,090 --> 00:20:53,790 We need to collect data. 174 00:20:53,970 --> 00:20:57,670 I believe that in the real world, everyday devices experience security events. 175 00:20:57,670 --> 00:21:00,330 I mean, events as broadly as possible. 176 00:21:00,710 --> 00:21:05,310 People may not be dying, but I'm sure that there are near misses all the time. 177 00:21:05,310 --> 00:21:14,970 And if we can show the data, then that creates the incentive to build secure healthcare technology from the ground up. 178 00:21:14,970 --> 00:21:23,230 Using secure by design components from the tech industry as well as helps us answer the questions of how much security is adequate. 179 00:21:23,670 --> 00:21:25,230 So let's measure it. 180 00:21:25,490 --> 00:21:26,610 Heisenberg said it best. 181 00:21:26,610 --> 00:21:28,010 He changed the outcome by measuring it. 182 00:21:28,010 --> 00:21:35,770 Now he meant it for subatomic particles, but we'll take it here for changing the outcomes of healthcare for the better. 183 00:21:37,190 --> 00:21:44,590 And honestly, in order to get across the finish line for security, no security event perceived to be a black swan will get us across the finish line. 184 00:21:44,590 --> 00:21:48,990 It will be the innumerable cygnets that are hiding in the weeds of everyday data. 185 00:21:48,990 --> 00:21:52,270 And today I learned that cygnets were baby swans. 186 00:21:55,690 --> 00:21:59,930 Costanza said that he needed to learn risk management because it was on his resume. 187 00:22:00,510 --> 00:22:06,590 Let's not fall into the trap of using oversimplified risk management models because we build our careers on it. 188 00:22:06,590 --> 00:22:13,830 The uncertainty of behavior complex system demands the adoption of new, higher fidelity models that are plugged into the real world. 189 00:22:13,830 --> 00:22:17,030 For as Feynman put it, mother nature cannot be fooled. 190 00:22:17,110 --> 00:22:34,310 And in doing so, we'll begin to reveal the late economic incentives not just for secure by design, but I imagine a host of important clinical items we'll be able to tease out efficiently if failures are related to human factors, humidity, cyber security, 191 00:22:34,310 --> 00:22:40,230 bad boards, a software bug, or if it's a Tuesday in April during a full moon, you'll have the data right there. 192 00:22:40,230 --> 00:22:46,410 And as we look towards the future of healthcare where outcomes determine who gets paid, it will be the only way. 193 00:22:47,250 --> 00:22:54,030 Certainly, tremendous progress has been made, and the groundwork for catalysis and acceleration has been made possible by this progress. 194 00:22:54,030 --> 00:23:07,490 You only need to look to the FDA and international regulators recent policies in this space, and quite frankly, the efforts of security champions across the supply chain really to understand how deeply passionate healthcare is about fixing all sorts of problems, 195 00:23:07,490 --> 00:23:08,850 including security. 196 00:23:08,850 --> 00:23:15,510 We can supercharge their efforts by turning ineffectual black swans into effective everyday economic incentives. 197 00:23:15,670 --> 00:23:17,970 Thank you, and I'd be happy to take any questions.