DiscoverInside MedTech Innovation
Inside MedTech Innovation
Claim Ownership

Inside MedTech Innovation

Author: Shannon Lantzy

Subscribed: 6Played: 34
Share

Description

Join Shannon Lantzy, as she brings you stories from inside the medtech ecosystem, featuring innovators, commercializers, regulators, and consumers. The show covers a wide array of topics, from patient-driven innovation to cybersecurity. We’ll examine the details that influence individual regulatory decisions and the broader impacts of emerging global issues, ensuring that great technology reaches the people who need it most.
50 Episodes
Reverse
Vulnerability disclosures are speeding up, and the tools built to defend medical devices haven't caught up to that pace. Ken Hoyme spent his career building the safety-critical systems behind the Boeing 777 and Boston Scientific's cardiac devices, then wrote the paper that became the industry's playbook for streamlining post-market security patching. He joins Shannon Lantzy to break down why the gap between finding a vulnerability and fixing it matters more than ever, what code signing has to do with who controls a patch, and why automated insulin delivery could become the proving ground for how medical devices get updated in the future.Timestamps:[00:00] Introduction to Ken Hoyme and his paper on post-market security[01:00] Ken's path from Honeywell to Guidant to Boston Scientific[04:00] What draws Ken to life-critical systems[06:00] Ken's high school years and family background[07:00] What AAMI is and how Ken got pulled into committee work[09:00] The origin of AAMI TIR57 and its purpose[10:00] Why cybersecurity risk doesn't behave like historical safety risk[12:00] The CIA triad and why medical devices need to think beyond confidentiality[14:00] Real-world cases: MRI outages and stroke misdiagnosis risk[16:00] Why patching everything immediately isn't as simple as it sounds[17:00] The "sneaker net" era of deploying software updates[19:00] Ken's core thesis for vertically integrated devices like CGMs and insulin pumps[20:00] The parallel between hardware sustaining engineering and software patching[23:00] Why platform and application testing get tangled together[25:00] Making the case for separating verification from validation[26:00] Why it's hard to predict how a patch changes system behavior[27:00] The case for a dedicated, separately funded post-market patch team[30:00] AI as a red teamer and the coming vulnerability flood[32:00] The Linux bug that sat undetected for 27 years[33:00] Could open-source patches be trusted for medical devices[36:00] What it would take to "validate the validation"[58:00] The worst advice Ken's heard about post-market security[1:00:00] What Ken would fix about how FDA regulates devices[1:03:00] Ken's heroes and where to find him onlineConnect with Shannon: LinkedIn: https://www.linkedin.com/in/shannonlantzy/Website: https://www.shannonlantzy.com/Connect with Ken: LinkedIn: https://www.linkedin.com/in/kenhoyme/
Generative AI doesn't act like a medical device. It acts like a form of intelligence, and Dr. David Blumenthal thinks it should be overseen like one. Blumenthal, the Harvard-trained physician and policy expert who ran the $25 billion federal rollout of electronic health records under Obama, joins Shannon Lantzy to lay out a new framework for regulating AI as a practitioner rather than a tool. They trace the parallel between physician training and AI development, debate whether FDA is even the right agency for the job, and dig into why nobody actually measures doctor error rates. The conversation moves through Operation Warp Speed, the economics of EHR adoption, and a look ahead at fully automated hospital wings.Timestamps: [00:00:00] Introduction and AI's promise and peril in healthcare[00:03:00] David's path from Capitol Hill to primary care to the Commonwealth Fund [00:12:00] Operation Warp Speed as a model for fast, safe innovation [00:20:00] Why FDA safety review protects the market as much as patients [00:25:00] Meaningful use and the human side of EHR adoption [00:32:00] Defining generative AI: intelligence, not medical device [00:36:00] Borrowing physician licensing to oversee AI [00:44:00] Comparing human training to AI accreditation [00:52:00] Who should regulate agentic AI in the clinic [00:56:00] Measuring error rates: doctors versus algorithms [01:04:00] Economic incentives and how AI adoption differs by system [01:08:00] Science fiction, robotic surgery, and rapid fireFollow Shannon and David:Connect with Shannon: LinkedIn: https://www.linkedin.com/in/shannonlantzy/Website: https://www.shannonlantzy.com/Connect with David: Website: https://www.hks.harvard.edu/about/david-blumenthal
The technology to secure healthcare already exists. Getting it adopted by the people building medical devices is a different problem entirely. Andrew Carney spent a decade in classified offensive cyber operations, defended one of the world's largest banks through the Log4j crisis, and now runs cybersecurity programs at ARPA-H and DARPA. Shannon and Andrew get into what it actually means to run a "locked down" med device that isn't as safe as it looks, how digital twins and cyber ranges let hospitals stress-test systems without touching a live patient environment, and why a tool that automatically finds and fixes software vulnerabilities is landing a 95% acceptance rate from human developers. They also cover how medtech companies can plug directly into ARPA-H's research pipeline, and what it takes to pitch a federally funded research program from scratch.Timestamps: 00:00 – ARPA-H and the case that the tech already exists, it's just not distributed 03:15 – From classified offensive cyber to reverse engineering without source code 10:00 – Inside HSBC during the Log4j crisis 17:30 – What a "locked down" legacy device can still get away with 25:00 – Thinking like the attacker: foothold, ransom, and silent data exfiltration 32:00 – DigiHeals: adapting defense-grade tools for healthcare 39:00 – Digital twins, cyber ranges, and testing at scale 45:30 – What UPGRADE actually does (and the limits ARPA-H won't cross) 51:30 – Karambit's "software bill of behaviors" 59:30 – The SBIR lineage path from proven tech to commercial product 69:00 – What it takes to become an ARPA-H program manager 75:00 – Rapid fireFollow Shannon and Andrew:Connect with Shannon: LinkedIn: https://www.linkedin.com/in/shannonlantzy/Website: https://www.shannonlantzy.com/Connect with Andrew: LinkedIn: https://www.linkedin.com/in/andrew-carney-945458a6/Website: https://arpa-h.gov/
Software problems cause 20 medical device recalls a month. 82% of those are classified as software design failures. Dr. Robert Charette has spent five decades documenting why large-scale technology systems fail and why organizations keep repeating the same mistakes.In this conversation with Shannon Lantzy, Bob brings a perspective rarely heard in medtech: one shaped not by the device industry, but by NASA, the Department of Defense, Fortune 100 companies, and the national rollout of electronic health records. He introduces the distinction between software failures and software blunders, explains why testing is impossible to perfect but impossible to skip, and walks through the risk ecology framework that looks at technical, financial, political, and organizational forces together. He also addresses the Change Healthcare ransomware attack as a case study in systemic interface risk, the red-yellow-green project management inversion, and what AI-generated code means for regulated software.Timestamps:[00:00:00] Introduction and the 20 recalls a month statistic [00:02:44] Why Bob's outsider perspective is the point [00:03:16] NASA Challenger and the software review panel [00:08:44] Why you can never test everything but can never stop testing [00:11:56] Failures vs. blunders: a critical distinction [00:13:12] What is a risk ecologist? [00:15:16] When FDA regulation is the only incentive that works [00:16:08] The case for market-driven standards and tort law [00:22:24] Bob's role in the EHR meaningful use panel [00:25:44] Why the national EHR rollout was not well thought through [00:29:00] Change Healthcare as a systemic interface failure [00:30:16] How to map interfaces and assume failure [00:33:36] Efficiency vs. single point of failure [00:34:44] International regulatory reliance and the turtles all the way down problem [00:39:24] Designing software to be verified and validated from the start [00:43:00] Applying V&V to automated insulin delivery systems [00:48:00] Flipping the risk dashboard: start at red, prove your way to green [00:51:20] Why no one wants to be the naysayer [00:53:08] How executives actually tolerate risk [00:55:04] The Hubble Effect and knowing when to kill a project [00:56:28] AI and regulated software: the gray beard's take [01:01:04] AI is perfect for experts and dangerous for everyone else [01:03:16] Cardinal rule: your system will be evaluated outside the criteria you set [01:04:12] Rapid fire questionsFollow Shannon and Robert:Connect with Shannon: LinkedIn: https://www.linkedin.com/in/shannonlantzy/Website: https://www.shannonlantzy.com/Connect with Robert: LinkedIn: https://www.linkedin.com/in/robert-charette-500309/Website: https://www.ieee.org/
Randy Horton is Chief Solutions Officer at Orthogonal, a firm that specializes in accelerating software as a medical device, digital therapeutics, and connected device ecosystems. He has spent his career at the intersection of product management, digital transformation, and regulatory compliance, and co-chairs the cloud computing standards committee at AAMI with Pat Baird from Philips.In this conversation with Shannon Lantzy, Randy breaks down why medtech companies are either too cautious about cloud or not cautious enough, and what good cloud design for medical devices actually looks like. He explains the concept of indirect control, why the medical device you had at 8am may not be the same one you have at 8pm, and how modern software practices from Netflix, Amazon, and other tech giants are more compatible with medtech's safety requirements than most people realize. He also addresses the language gap between tech and medtech, the role of the quality systems engineer, and why the FDA is no longer the biggest barrier to innovation.Timestamps:[00:00:00] Introduction and the cloud computing challenge in medtech[00:02:36] Randy's origin story and the early commercial web[00:03:28] How healthcare ran through his career before medtech[00:05:44] Lessons from an $80 million IT transformation[00:07:00] Why established companies struggle to separate why from how[00:09:56] The all-nighter on Mosaic that started everything[00:11:00] Retail tech, hardware is hard, and the limits of the physical world[00:13:20] Sensors, foundational models, and the promise vs. reality of platforms[00:15:08] History as systems thinking[00:17:24] Safe, effective, and commercially successful: what that means in cloud[00:19:52] How cloud providers change constantly and why that matters[00:21:44] Indirect control: the crux of cloud in medtech[00:23:36] Conservative cloud architecture as good medical device design[00:24:00] Post-market surveillance vs. revalidation: the naming debate[00:25:44] Two scenarios: too conservative and not conservative enough[00:27:32] Risk matrices and why Shannon hates them[00:29:40] Deming, total quality management, and the real conversation[00:31:08] What medtech can learn from unregulated industries[00:33:52] Why medtech still builds custom[00:34:16] The language gap between tech and medtech[00:37:20] Wrapping risk-based thinking around AI development[00:42:44] The quality systems engineer role[00:45:00] Evidence and traceability as the real difference[00:46:00] Cost, documentation, and tools like GitHub and Jira[00:48:52] Sales conversations at Orthogonal[00:51:36] What is next: neurostimulation, home diagnostics, new business models[00:53:48] CMS is now the bigger barrier than FDA[00:54:24] Rapid fire questionsFollow Shannon and Randy:Connect with Shannon: LinkedIn: https://www.linkedin.com/in/shannonlantzy/Website: https://www.shannonlantzy.com/Connect with Randy: LinkedIn: https://www.linkedin.com/in/randyhorton/Website: https://orthogonal.io/
loading
Comments 
loading