Transitioning Tech Professionals Into MedTech: Webinar

Randy Horton

Published on: January 12th, 2023

This blog contains the video and a detailed summary of our January 26th, 2023 webinar.

Can a software engineer or data scientist working in the social media, logistics or cruise ship industries be successful in MedTech? When these new hires are brought on by MedTech firms, it’s with the hope that their experience using modern methods of software development and project management will help MedTech firms Move Faster. But we often see the opposite happen: New hires, frustrated by MedTech’s processes, systems, requirements and acronyms, fail to synergize the best ideas from the tech world with the frameworks and constraints of MedTech regulations.

Before they can help us Move Faster, we need to onboard new employees to the Break Nothing ideal. We need to go beyond giving them a crash course on ISO 13485, IEC 62304, QMS, SOP, CAPA, 510(k) and De Novo approvals that teaches them the whats of MedTech software. These industry newcomers need to also be engaged with the whys behind what we do. Outside hires can help MedTech firms raise the collective knowledge of our teams, bring about culture change and up our software game, but unless we change our approach to onboarding and utilizing their skills on an ongoing basis, we’ll continue to have unrealized potential, frustrating results and unmet expectations.

On January 26th, 2023, Orthogonal held a webinar on how to successfully bridge the chasm between tech and MedTech so our industry can take advantage of new employees’ experiences to rapidly evolve successful devices. Randy Horton, Orthogonal’s Chief Solutions Officer, moderated a panel featuring the following expert speakers:

Larkin Lowrey, Engineering Leader & Technologist
Xenios Papademetris, Author and Professor of Radiology & Biomedical Imaging and Biomedical Engineering, Yale
Bernhard Kappe, CEO and Founder, Orthogonal
Melissa Gill, Principal Product Owner, Orthogonal

Key Takeaway Points

1. Software engineers, developers and other tech professionals from outside industries are drawn to MedTech because they want to help people while solving interesting technical challenges. MedTech organizations can leverage the unique skills that tech professionals bring to our industry to help us improve the processes that lag behind the rest of the technical world. But before we can do that, we need to ease newcomers’ frustrations with our industry regulations. To help make the transition, we need to teach new hires that every process we follow is in service of patient safety.

2. Successful onboarding depends on our ability to clearly communicate constraints, requirements and processes to newcomers. New hires and MedTech companies need to learn to speak each other’s languages.

3. Newcomers to our industry have access to resources that give them a solid foundation of the basics, like regulatory structure, privacy and HIPAA concerns, the medical device software development life cycle, etc., but not how to apply them. They’ll need to work together with people in their new organizations to gain a complete picture of what we do and what we value.

Webinar Recording

Webinar Summary

The following is a summary of the webinar’s discussion, edited for conciseness and clarity.

What makes MedTech different?

The medical device industry is one of many transformed by software in the last two decades. However, unlike most other industries, medical device manufacturers have taken a slower path in leveraging modern computing technologies, like the cloud, mobile connectivity and the Internet of Things, because they are held back by complexities in regulations and payment structures. These regulations ensure our devices do no harm to patients and truly deliver their clinical benefits. We can’t ignore them, but MedTech can use approaches developed in other tech industries to drive greater software reliability, safety and innovation.

Compared to MedTech, the greater tech world can look like an unregulated free-for-all. Because they’re unconstrained, tech companies can run experiments that aren’t allowed within the medical device space. Larkin Lowrey, Engineering Leader and Technologist, formerly of Tandem Diabetes Care, spoke as someone with a long career in tech: “The overall level of investment in software engineering, technology practices, etc., is many orders of magnitude higher outside of MedTech than it is inside.”

Newcomers entering MedTech feel the friction caused by the FDA regulations that constrain our ability to develop and evolve our internal processes. Their preferred tools, techniques and deployment environments run up against our rigid design controls and systems engineering requirements.

“Especially in medical device software, we need processes and tools to make sure we are developing safe software, keeping patients safe while we bring them outcomes,” said Melissa Gill, Principal Product Owner, Orthogonal. To take advantage of the expertise that outside hires bring to our industry, we need to be willing to look critically at what we’re doing, and see how we can bring in new thinking to more successfully achieve our medical and business goals of delivering working, safe software faster.

What draws people to MedTech?

Why would people from the less-constrained world of Big Tech want to join our highly regulated sector? Larkin reflected on what people coming from the wider tech world have said during the recruitment process: “I can’t do this social media stuff anymore. I need to do something that’s actually going to put good energy into the universe.” They see MedTech as a way to help people, and they’re not wrong. Larkin even received a shout-out from a participant at the webinar: “Thank you, Larkin. My daughter uses Tandem’s diabetes pump, it’s critical to her care.”

We’re proud that talented techies are drawn to MedTech because they want to help people while working with pretty cool technology that integrates hardware, software and the human body. But acclimating newcomers to how we help people is one of our greatest challenges. For example, the approach MedTech takes to quality management is sharply different from that of the outside tech world. Tech companies might worry about a bug that’ll cost them $10 million an hour until they fix it. MedTech has to also worry about the human cost of patient injury or even death.

“One of the most important things about training first-timers newly exposed to MedTech regulations is to not just focus on the process, but also making sure they understand the whys behind it,” said Melissa, “and ultimately, those whys connect back to patient safety, and the types of costs that can’t or shouldn’t be measured in dollars.” These “whys” put the issues newcomers face with our processes in perspective, and help them move past frustrations so we can tap into their fresh ideas and approaches to make our work faster and more efficient.

We need to speak each other’s language

When crossing the chasm between the greater tech world and MedTech, we need to learn to speak each other’s language. “Even though we speak English in the English-speaking world, we don’t use our words to mean the same thing. Those of you who come from a machine learning background will use the word ‘validation’ differently than how that word is used in the medical device industry,” said Xenios Papademetris, Author and Professor of Radiology & Biomedical Imaging and Biomedical Engineering at Yale.

Bernhard Kappe, Orthogonal CEO and Founder, pointed out: “There is so much jargon in the medical device industry. I know it took me a long while to understand what these things mean. We use an awful lot of jargon on the software development and engineering side as well, and if you’re not familiar with it, it can be just as much of a barrier as the medical device jargon.”

Xenios foresees this language barrier becoming an even bigger issue as MedTech further embraces AI and machine learning (ML). Data scientists who can help us integrate AI/ML with medical device software are a step removed from the quality activities that are familiar to software engineers. “If you tie [data scientists] down, they will be unproductive. You need to create an open environment in which they can take advantage of their skills, but also teach them how to work in our environment and the constraints we operate under,” Xenios said.

Successful onboarding depends on our ability to communicate clearly: “If you are in charge of processes, you need to be able to explain the whys of the process, not just the how,” Xenios said. “People starting out need to learn the why as opposed to just the what. And once you do, it makes sense – or it doesn’t make sense, but you learn to live with it.”

How we can explain constraints

Constraints of the medical device development process, such as fidelity to processes defined in a QMS and the levels of analysis and documentation required, are a large source of frustration for new hires. “I think one of the challenges we have is understanding which of those constraints in the industry are real and which ones are constructed based on a legacy,” said Bernhard. “There are absolutely constraints and objectives fundamentally based on keeping patients safe and being able demonstrate to regulators that what you’re doing is safe and effective, when they have very little time to actually spend on checking on your quality and regulatory and how you are complying with the regulation.”

Larkin added that many of the constraints we work within serve the purpose of convincing a busy FDA or other governing body regulator that we’ve acted sensibly. “They need to perform their job as quickly and as efficiently as possible to either get you approved or denied without expending a tremendous amount of effort,” he said.

Software engineers from outside of MedTech are accustomed to quality control techniques such as peer review of code and requirements. What they’re not used to is providing documented evidence of their code’s quality to a third party inspector. “The biggest source of friction for me,” Larkin said, “is getting engineers to understand that we have to do something because somebody who isn’t part of the team has to be convinced that what you did is safe, prudent and appropriate.”

MedTech has “middlemen – in our case, regulators – who exist between the company and consumers. We can’t just make consumers happy. We also have to satisfy the middlemen, and follow regulatory constraints that limit our ability to make changes and adapt in a timely manner.

A crash course on crossing the chasm

“Wouldn’t it be great if there was a curriculum to give new hires on their first day or two on the job so they could more quickly understand MedTech, its nuances and what makes it different?” Randy Horton, Orthogonal’s Chief Solutions Officer, has heard this from many MedTech leaders. So when he came across Xenios’s book and Coursera course on an introduction to medical software, he realized that the professor had filled an important gap. (For more on both see www.medsoftbook.com)

Xenios describes his course as walking people from the outside in. It starts with the basics: What is medical software, and what makes it different? And then goes over regulatory structure, the environments medical device software lives in, privacy and HIPAA concerns, the development life cycle process, and how to talk with medical professionals.

Part of the course is examining case studies of software engineering failures. Xenios has students present on these case studies so that they understand the pitfalls of working without safety in mind. Though only some of these studies concern medical software, the same principles and lessons learned apply to medical device software engineering.

Syllabus of weeks 1-4 from Xenios’s 12-week Coursera course.

Xenios has taught this class for seven years, and the biggest change he’s seen over those years is the increased prevalence of AI/ML in his students’ projects. “That’s going to be another revolution that is coming our way. Again, MedTech will be slower than the outside industry and maybe we can learn from them a little bit as they develop those techniques in our lifetime,” he said.

What do we teach newbies first?

Former Orthogonal Director of Delivery Tanya Wojcik asked: “How do you teach newbies what to care about first? Do you teach them how to follow processes? Do you teach them to pay deeper attention to risky areas of a system?”

What employees are taught first may depend on the stage of their new organization. For a start-up, “everyone is figuring it out and no one has the knowledge,” said Bernhard. Processes are discovered through trial and error. If a newcomer is hired as a junior developer at a company that has already incorporated software development best practices into the constraints of regulations, they’re likely not expected to architect a system from scratch. “But those junior people need to do good software development, and they’re going to learn it by participating in the teams, risk management meetings and activities and learning it along the way, just as they would learn architecture along the way and improve their craft.”

Who new employees learn from is also important. Xenios highlighted the value of new employees understanding what issues their managers are concerned about. They should be asking, “Why is this person asking me to do it this way? What is driving that? What are the constraints my boss is operating under?” This helps new hires understand why they’re being asked to do certain things and helps to make decisions.

Xenios sees his textbook (and its companion Coursera class) as covering the first half of what newcomers need to know, and their managers when they go to work at MedTech companies will then teach the second half. His course teaches the general layout of the industry, the terms and the words that outside tech hires need to know. Then, when they go to work in MedTech, they’ll round out their knowledge base.

Xenios also noted that many of the people taking his Coursera class, to his surprise, are MedTech professionals working in regulatory affairs and quality roles. Although these people are not software developers, understanding what software developers do and the constraints they operate under facilitates communications between software teams and the quality and regulatory teams that they work in tandem with. Bernhard agreed: “Not everyone can invent new ways of doing things, but if you’re going to transform and get the best of both worlds or apply modern practices within the constraints, you need to have people who are thinking about the rules and the execution.”

Speakers

Larkin Lowrey, Engineering Leader & Technologist

Larkin Lowrey most recently worked at Tandem Diabetes Care as a Senior Director for Software Engineering. He implements Agile best practices learned over 20+ years from building high-performance software engineering teams and products for two other critical infrastructure industries: telecommunications and automotive.

Xenios Papademetris, Author and Professor of Radiology & Biomedical Imaging and Biomedical Engineering, Yale

Xenios the lead author of the new textbook Introduction to Medical Software: Foundations for Digital Health, Devices and Diagnostics (Cambridge University Press, 2022), and the main instructor for the companion Coursera Class Introduction to Medical Software. He has 25+ years of experience in medical image analysis and software. He has been involved in medical projects including cardiac image analysis, image-guided epilepsy neurosurgery, image-guided prostate biopsy, development of methods for real-time fMRI, vascular image analysis and general neuroimaging analysis. His software work was part of the original Yale BioImage Suite software package. More recently, he has focused on the creation of server-less tools that can be run in a browser.

Bernhard Kappe, CEO and Founder, Orthogonal

Bernhard Kappe is the Founder and CEO of Orthogonal. For over a decade, Bernhard has provided thought leadership and innovation in the fields of Software as a Medical Device (SaMD), Digital Therapeutics (DTx) and connected medical device systems. As a leader in the MedTech industry, Bernhard has a passion for launching successful medical device software that makes a difference for providers and patients, as well as helping companies deliver more from their innovation pipelines. He’s the author of the eBook Agile in an FDA Regulated Environment and a co-author of the AAMI Consensus Report on cloud computing for medical devices. Bernhard was the founder of the Chicago Product Management Association (ChiPMA) and the Chicago Lean Startup Challenge. He earned a Bachelor’s and Masters in Mathematics from the University of Pennsylvania, and a Bachelor’s of Science and Economics from the Wharton School of Business.

Melissa Gill, Principal Product Owner, Orthogonal

Melissa has 10 years of experience in Agile Project/Product Management and four years of experience in QA. She has worked in enterprise, security, pharma and SaMD industries on web, mobile and cross-platform projects. Melissa brings her experience implementing Jira/Confluence and Agile processes at numerous organizations to Orthogonal, where she also implements eQMS tooling and process improvements.

Moderator

Randy Horton, Chief Solutions Officer, Orthogonal

Randy Horton is Chief Solutions Officer at Orthogonal, a software consulting firm that improves patient outcomes faster by helping MedTech firms accelerate their development pipelines for Software as a Medical Device (SaMD), digital therapeutics (DTx) and connected medical device systems. Orthogonal makes that acceleration happen by fusing modern software engineering and product management tools and techniques (e.g., Agile, Lean Startup, User-Centered Design and Systems Thinking) with the regulated focus on device safety and effectiveness that is at the heart of MedTech.

Horton serves as Co-Chair for AAMI’s Cloud Computing Working Group, as well as AAMI CR:510(2021) and the in-process Technical Information Report #115, all of which address how to safely move medical device computing functions into the cloud. He is a frequent speaker at conferences and webinars, including events hosted by AdvaMed, AAMI, HLTH, RAPS and the Human Factors and Ergonomics Society (HFES).