Medtech Mindset Software Development Rightley Mcconnell

EPISODE 12 – Med Device Software: Agility and Quality with Rightley McConnell

In this episode,Rightley McConnell, VP of Operations at Precision Systems, Inc., covers how to maintain quality and speed when developing medical device software.

Rightley and Dan discuss:

  • Challenges to device software development for complex systems
  • Use of AGILE methodology and how to remain flexible in a regulated environment
  • Applicable standards, including 21 CFR 820, ISO 13485, IEC 62304, & ISO 14971
  • How quality can and should remain central at each development phase
  • And more

If you have any questions, please feel free to contact us or connect with Rightley.

apple-podcast Listen on Google Play Music spotify-logo-png-file-spotify-badge-large-png-1280 rss

Episode Transcript

Dan Henrich:                       Hey, Rightley, thanks very much for coming on MedTech Mindset.

Rightley McConnell:              Absolutely. Thanks for having me.

Dan:                       It’s great to have you here and have PSI involved. Just so our listeners get to know you a little bit, can you quickly introduce yourself and PSI, and tell us about the different types of projects that you guys work on in MedTech.

Rightley:              Sure. Starting with the company, we’re Precision Systems Incorporated. We’ve been in business since 1979, and we really focused on mission-critical, safety-critical systems that cannot fail. So we’re writing code that goes inside devices that are in operating rooms, in vitro diagnostics. They could also be a life sustaining type three types of devices, infusion pumps in the like. We’ll do consultation requirements, design, the software development, unit testing, final V&V, and anywhere, pretty much along the line, also post-market. Once something gets out, if a customer needs some changes, we can help them with controlling that and updating the code, getting it back out to the field. So I’m the Vice President of Operations here. I have been for about four years now. And I’m a recovering engineer. I started here as a software engineer. It was just my second job out of school, and so I’ve been here about 14 years.

Dan:                       Great, great. And how about the different areas you touch within the product development process? So you mentioned the types of devices you work on, but what are the main roles that you play as you interact with clients?

Rightley:              A lot of the roles that we play at the very early stages of product conception could be helping with getting requirements for even the product, in place. And then also working through, software requirements on down you might say. So helping those customers with understanding how to roll product requirements into software requirements, how to make sure that they have all the right planning in place, how to make sure that the software is properly designed first, then implemented well. And it’s really full stack from there on down. And then just of course, making sure that they’re following all of the right regulatory procedures and have all the right SOPs in place, so that when they get through and they submit to a 510(k) for instance, to the FDA, that all the documentation is there.

Dan:                       Okay. And we’re going to delve into our theme here shortly, which is, how to ensure speed-to-market, operating in an agile environment while maintaining high quality standards throughout the software development process. But can you just talk broadly a little bit about the main challenges that that folks developing software for critical medical devices face throughout the process?

Rightley:              Sure. There’s two main paths that the challenges come down. You have the human, the soft challenges, and it usually deals with education and making sure that folks understand when they go down this path, that the regulatory, the design, the documentation, everything that goes around the process that goes around the actual product development can be as much or more than the product development itself. So a lot of the challenges stem from that, and understanding and planning far enough out to make sure that they have realistic timelines and or able to get the right resources, the right stakeholders involved early enough, so that they have a product development that goes smoothly, as part of the overall development that has to be done in the company. So that’s one. And then of course there are always technical challenges.

Rightley:              Software is sometimes nothing but technical challenges on its rougher days. So a lot of the types of challenges come down the line with interfacing known hardware to unknown hardware. Interfacing different devices within a product suite. Anytime you have two different components or devices talking to one another, there’s opportunity for challenge. So usually, code within a system can be self-contained, and controlled, and the development is, I want to say free of surprise, but it has a certain level predictability to it. As soon as you start interfacing different systems together, and some are off the shelf, and some are custom, and some you’re developing as part of the product, that’s where technical challenge usually comes in.

Dan:                       Talking about this, maintaining high levels of quality through the development process, what are the applicable standards that come to play in your day-to-day?

Rightley:              So for medical devices, everything is really dictated and flows down from the FDA. And that’s 21 CFR part 820. And that really talks about overall medical device development and quality management. From that, we have gotten our quality management system because we focus on software, is really based around a standard called IEC 62304, which is a software development life cycle standard that is for medical devices. And so 820 flows down in points two 62304, as an appropriate set of standards to use for development of software.

Rightley:              So our quality management system here at PSI is built around that, and that quality management system is also appropriate and we have been able to be certified to ISO 13485. So that’s the medical device manufacturing standard. We’re manufacturing code. So our part of the system is just the software, so we are able to be certified to 13845 because we follow good manufacturing practice, which is 62304. So there’s a bit of a web of standards, but it really all flows down from 21 CFR 820, and that points to all the different standards that are appropriate for different aspects of product development.

Dan:                       Sure. And there’s one other that you didn’t mention that I just want to highlight, because I think it’ll come up which is ISO 14971, having to do with risk management. Can you talk a little how that plays into your process?

Rightley:              Yeah. Thank you. So a 14971 as you mentioned, talks about risk management. And it’s a risk-based approach to doing software development. So 62304, and 14971 really play together. So it’s all about identifying and mitigating risk, early in the product development process so that you can flow that down into your software development process, and make sure that you’re focusing on designing, developing and testing the right parts of the system, and really making sure that you’re maintaining that very high level of quality without testing everything needlessly to the same level that you might need to test the very most critical parts of the system.

Rightley:              That also helps you mitigate technical risk as well. When you’re doing that failure modes, and effects, criticality analysis, FMECA, which is prescribed by 14971, you’re going to identify technical risks in addition to patient risks. They’re just going to come out as part of the process. You set those aside, really, you focus on 14971 on the patient risk, but there’s technical risks also need to be examined. So in mitigating those risks early on, as part of a phase zero and doing that initial investigation into what the technical risks are, really can pay dividends down the line, and it really helps maintain schedule and keep your development on track, with fewer surprises down the road.

Dan:                       So let’s turn to the turn to the meat of our discussion, which is how to ensure speed-to-market, maintain an agile process, and maintain high quality standards throughout the software development process. I know every company who’s doing this type of work is going to follow somewhat of a phased approach, whether it’s Archimedic, PSI, or other players in the industry. But can you just walk us through your software development process by phase, and talk about the different types of activities that take place there, and how you operate to maintain quality, and move quickly?

Rightley:              We look at it as six phases. So our phase zero is investigation. Phase one is planning. Phase two is requirements realization. Phase three is V&V. Four, regulatory and product launch, and then five is post-market surveillance. So those are the six main phases that we go through. Phase zero, and the way that we really apply, we look back at that FMECA right away, and we start looking at what things do we need to focus on, and what risks do we need to mitigate from a technical aspect and also from a patient-risk aspect. And phase zero, really, the main goals for us in the software development aspects, are to come out of phase zero with a good software requirements spec, a good architecture, and usually that’s expressed in an architectural design chart, and good product requirements. So those are the main three things from the software aspect that we try to get out of phase zero.

Rightley:              Those are what really sets you up for success later on down the road. Requirements, we here at PSI, and I think most anybody that gets into any product development, know that requirements are the source of everything. It’s either the source of your problems or the source of your success. Having good product requirements means you could flow down to good hardware requirements, good software requirements, and that means that all the different parts of the system are being developed in harmony. So that’s really the goal of phase zero, is to walk out of it with all the stakeholders, pretty much understanding what the system needs to do in order to fulfill its goal and help the patient.

Rightley:              So phase one is planning. Planning, planning, planning. So it’s all about making sure that you can turn those requirements from a software perspective, into designs you can lay out. Sprint schedules, this is where the AGILE approach starts to come in, and where you can really plan out, now that you know what the product is really going to be, you can lay out how long it’s going to take to get there, and how you’re going to develop it. So the main thing to understand about planning is if you don’t have a plan, you can’t change it. So having a plan and a work breakdown structure that’s based on the requirements that flows down into sprints, and usually we set them up on about a monthly basis. Different companies find different things more useful. It could be six weeks, it could be two months. It depends on what the development cycle of the rest of the product is. But we find that setting up the sprints on a monthly basis right there in that planning phase is what really allows us to be agile and keep things moving throughout development.

Rightley:              There are always going to be roadblocks. There’s always going to be something that’s going to require you to wait on developing a certain aspect of the system. That’s why having the sprint plan is so great, because you move something from sprint three back to sprint one, and vice versa, and keep the whole project moving, even if one particular part of it is not really allowing you to progress. That’s a lot of the difference between the traditional V model, Waterfall model of software development, and applying some added agile methodologies within and overall SDLC or software development life cycle methodology.

Rightley:              So phase one really, the biggest thing there is to make sure that you have a plan. Break down the work, lay out a sprint schedule, and know that it’s going to change. So during that phase, it’s also a really good idea to understand how changes are going to be managed, how problems are going to be reported. All the SOPs, and all the standards that really are around product development, that’s the point where you make sure that those are in place, and all the stakeholders understand and agree those.

Rightley:              Because that, sometimes may seem a little bit just doing boring paperwork, but you wouldn’t believe how many times sitting down and getting all the stakeholders, software guys, hardware guys’ management, marketing, they all think a little bit differently, as you might imagine. And so having everybody sit around and agree to a plan about who’s responsible for what at what points, how changes get managed, when there’s a design freeze, laying that out all up front really helps get everybody on the same team. And good planning and a good start like that in that phase one is critical for letting all the different teams go and do their work and then come back together and make sure that everything plays together well.

Dan:                       Right. So phase zero, maybe you would say the big deliverables of that, or the hardcore requirements … Maybe I should say detailed requirements both from a-

Rightley:              Product requirements, software requirements, hardware requirements, electronics, those parts should all be really worked out as part of that first investigative phase.

Dan:                       And your Phase One deliverables will be a laid out schedule of sprints that everyone agrees to adhere to. And there is a plan for change management in place. Is that correct?

Rightley:              Absolutely. You must plan to change. And that’s also when the mechanical guys, the electronics, everybody makes sure that their schedules mesh together. It doesn’t mean that everybody gets started, runs off and begins doing work immediately as soon as that phase is closed out. It just means that everybody’s plan is laid out about when things have to be done so that nobody ends up being left behind on the critical path, and then playing catch up.

Dan:                       Right, right. Okay. So let’s move into phase two where I think is where the rubber really starts to meet the road with software, and all the quality standards that come to play, right?

Rightley:              Right. So this is where, as you said, the rubber meets the road with software development. Phase two, design realization, is, in software coding and parlance, this is implementation for us. So this is where we start executing on those sprints. We open every sprint at the beginning of the four weeks, let’s say, we have goals set out for what we’re going to achieve during that time and make sure that the sprint deliverables that we’ve set up are possible, because that’s a great time to stop and evaluate and figure out if we’re waiting on a piece of electronics to get there before we can write a little bit of code, or if we’re waiting on the marketing group to give some answer about a certain thing before it can progress, that’s where we’re trying to make sure for that sprint for that group of work, we’ve got the things that we need in order to actually execute.

Rightley:              So for that, let’s say four weeks, we’re writing code. So if you’re more so in the software world, you may have heard something called Test-Driven Development. There are some aspects of that in there, where essentially you’re writing automated code along with the software so that you know, as you write functions or groups of functions, that they do the operation that they’re supposed to, and then when you write additional functions to interface with them, you’re not breaking them. So it’s really, really important that during that sprint, while writing the code, write the automated unit tests along with it. It really helps to ensure quality. It helps getting your speed to market, and it also allows you to make other changes in other sprints elsewhere, without fear of breaking the code you already wrote. So it really sets you up for success in being able to apply those agile tenants, but not have to worry too much about what you’ve already done previously.

Rightley:              So throughout the sprint, we’re developing and then towards the end of the sprint, there’ll be a cut off. So it could be somewhere, usually in like week three of the four week, or it could be a little bit later, that’s where we’ll do any sort of integration, like a little bit higher-level testing, to make sure that everything that we’ve developed over the sprint functions properly. The idea, and what we found that our clients love is that they want a sprint-deliverable at the end of month, that is functional to a point, and everything in their works, because they want to be able to show progress. And this is great for an internal teams and external teams like us, alike, being able, for software, which is a mushy, amorphous thing that a lot of people think is a little bit of black magic, being able to show deliverables on a regular basis and be able to report about what is done and what’s functioning, and be able to say, “Yes, this works”, gives everybody else in the rest of the team a nice warm fuzzy when they can see that progress from month to month.

Rightley:              So really aim that at the end of the sprint you’re getting something that is well tested and works to the prescribed level, and then really that’s where we iterate through the phases. Just same process, opening the sprint, doing the work, closing the sprint and on and on and on. And throughout that at the beginning of each sprint, like I said, we’re making sure that everything that we have is available to us, that we can execute the sprint, and it allows us to be agile, move things from sprint to sprint, and try and keep the overall workload as flat as you can, because as you establish a team, you want to keep that team working on the project, you don’t want to scale up and scale down. Being a bit more agile allows you to do that most optimally, and most efficiently, and keep the fastest way to market is to keep a nice level workflow. So that’s what the sprints and being able to reorganize them as you go allows you to do.

Dan:                       Let’s jump into phase three, which is I think where a lot of the requirements and documentation really come into play, of how to, how to ensure the speed-to-market while maintaining quality.

Rightley:              Right. So we talked a little bit about, in the previous phase, we’re doing automated unit testing, which is one kind of verification. But the vast majority of the V&V, verification validation goes on in phase three. So that’s where at the highest level you’re taking the requirements that you developed early on, along with the FMECA, and getting the-

Dan:                       Sorry. One second. Before we go on, just tell us briefly … You mentioned the FMECA at the beginning, but just real quickly run through what that is and how it comes to play.

Rightley:              Sure. So what that essentially is, you could think of it as almost as a table or a spreadsheet and it often is organized as such. And it’s a listing of every risk and harm that can happen to the patient. There are entire standards and podcasts that could probably be done about how to do an effective FMECA. But really what you’re concerned about is getting all of the patient risks listed out, then understanding what’s the likelihood of that risk happening? So is it a one in 10 chance, or one in a million chance? How likely is it to happen once something gets into the field is being used by the patient? And not to mention that other stakeholders as well, especially like in, perhaps in in vitro diagnostics, there could be handling of blood where you have to be concerned, not only about, could you get a wrong result for the patient, but there are operators who have to handle blood. So you need to be thinking about the other stakeholders that are involved in the process as well.

Rightley:              So what’s the likelihood of this harm happening to them? And then also, what’s the severity? And understanding if something happens and it’s a minor inconvenience, that’s something that you can test to a certain degree, and you have to understand, you may not want to spend a man-year of development, in testing something that might cause five minutes and then inconvenience to somebody every 100 operating hours of the system. But things that could happen perhaps very rarely, but are very serious, you need to spend some time mitigating.

Rightley:              So the whole idea is that once you understand the criticality and the effects and the likelihood of something happening is how do you move those risks and mitigate those risks? What actions do you take throughout the rest of the development process? And especially in phase three when you’re doing a verification validation, to understand that those risks have indeed been mitigated and you’re not going to hurt somebody when this thing gets into the market. So that’s the main goal in FMECA.

Dan:                       Great. Okay. So back to what you’re saying about bringing the requirements in the FMECA into play here at phase three, let’s jump back into that.

Rightley:              Sure. So a really, at the highest level, that the FDA generally prescribes three levels of testing for software. There’s unit testing, there’s integration testing, and then there’s system-level testing. Unit testing we talked about, and that’s at the lowest level. We prescribe automated unit testing that is executed, it’s built alongside the code. That happens in phase two. Then some integration testing, where this is where you’re basically integrating components of the system. It could be software to hardware, it could be multiple software components together, you’re checking that they inter-operate correctly. So you’re making sure that during that phase, the software all plays together nicely with the other components of the system and itself. That can be done in an automated fashion, perhaps. It can also be done in a manual fashion. It can be done at the sprint level, but usually it happens more so long in phase three at the V&V phase. And then of course, there’s system-level tests. And system-level verification is the one that I think, the vast majority of what people understand verification to be, that’s where that happens.

Rightley:              So that’s where you’re looping back, looking at the software requirements that you developed early on in the system. And you may have modified and updated a bit through the design realization, but making sure that the system hits all of those requirements. And that by nature of hitting those requirements, it’s fulfilling the product requirements, and fulfilling the intended use to the customer, to the patient. So that’s where the vast majority of V&V activities come into play. That’s writing and executing those step-by-step tests.

Rightley:              You can write a lot of your system-level verification very early in the process, in the planning stage, and it’s highly recommended to do that. But quite often you’ll have to update those as you go through design realization, and you get to that final place where you’re going to start doing dry runs of your system-level verification, and then doing the official run of your system-level verification on the software.

Rightley:              The FMECA really comes into play there because you need to make sure that you’re not only testing that mitigation that you came up with via the steps, but you’re also making sure that you’re focusing in the right areas of the system. You may write many test plans that are, let’s say for instance, I’m talking about an in vitro diagnostic device. Just theoretically, you’re looking for some type of cell in a blood sample for instance. That’s the whole purpose of the device. Just as a theoretical, for instance. Your FMECA and therefore your testing is going to dictate that you spend a lot of time verifying, and later on validating that the software indeed is able to find with high levels of specificity and sensitivity, the particular type of blood cell that you’re looking for. That’s very important, and a lot of your tests should be written around that of course, when you think.

Rightley:              But on the same hand, you need to verify that you can quickly and easily flow through all of the screens in the workflow without having any problems with clicking and navigating from screen to screen. So it could cause a little bit of confusion or if there were some problem where you couldn’t navigate from screen to screen, that can be a real inconvenience. Especially if it’s one of those things that it might happen one time out of 100. It’s an annoyance. But worst case scenario, you run the test again.

Dan:                       It’s not the same as having a false negative for HIV blood test or something like that.

Rightley:              Yeah. A false positive or worse, a false negative. Right?

Dan:                       Right.

Rightley:              So that’s where you need to focus in that V&V stage when you’re writing those verification and then later on for the overall product validation, where you’re really focusing on the items that are really high-criticality and likelihood to occur from the FMECA. There’s another good point to point out too, that the quality of your software requirements really dictate how much trouble you’re going to have when you get to this stage. I think of it as there are “four Cs” for a good software requirement. And these will be; complete, correct, concise and you need to be able to confirm it.

Rightley:              So complete, as in, each requirement in your software requirements needs to express a complete thought. It might mean that there is a button on the screen that does this. There is the ability to handle the intake of a patient sample. There are workflows that hit the patient data input, and the screen outputs. Those all might be different requirements, but each requirement should be a complete statement or thought. Just like we learned back in grammar school that each sentence should be a complete thought, so should each requirement.

Rightley:              It needs to be correct. That seems obvious, but it needs to be reviewed that it’s correct and it doesn’t conflict with other requirements that are in the document. You wouldn’t believe how many software requirements documents that we’ve looked at or that we’ve seen, where you can pick out two or three in the same section that all conflict with one another. It’ really helpful to get people that are not even necessarily deep into the software development process, to give those a look through and make sure that it makes sense to them. Good software requirements should make sense to pretty much anybody that reads them.

Rightley:              So they should be concise. One of the biggest places that we see software requirements problems are in big long narrative requirements, when it really should be broken up into maybe 10 or 12 different requirements, instead of a paragraph. Testing a paragraph in phase three with software, with concise followable steps that can be repeated, trying to test that the requirement has been met when it’s 15, 16 sentences long is really, really difficult. And it leaves a lot of openness to interpretation. So it’s really important that your requirements be concise.

Rightley:              And finally, they need to be confirmable. So having good requirements that are testable, that don’t say things like the system must run indefinitely. You can’t test assist them indefinitely. So how would you ever know if you met that requirement? It shall be easy to use. How is it easy to use? That needs to flow down into very specific requirements, because you can’t test, is the system easy to use? It’s great to have those goals of being easy to use and being 100% uptime, but you need to have a confined confirmable requirement that you can test. If you follow those four Cs at the beginning in phase zero, it makes phase three way easier. So that’s big tips for verification, validation software.

Dan:                       Great. Okay. So phase four where we get into the regulatory submission, maybe not a particularly time-consuming part of the process, but it’s where you find out if you have done phases zero through three correctly, right?

Rightley:              Yeah.

Dan:                       So tell us a little bit about how the standards come into play. And obviously, if this phase doesn’t go well, then your time-to-market is going to be set back considerably.

Rightley:              Considerably. Yeah. So this is where all the previous phases really pay off, where you find out what you didn’t do right, as you said. So most of the software team’s role as we found, when it comes to this, is helping to put together the submission for the 510(k). So that means going back through making sure that your traceability from requirements through design, through implementation, through test is all complete. Making sure that you have all the prescribed documentation. The FDA is great in that the regulations are out there. You can find what needs to be submitted for a 510(k), just by going to the FDA website. And they list off all the documents and everything from a software perspective that you need to have. Even list off the types of testing that we were talking about.

Rightley:              That stuff is all there and when you’re trying to put together the 510(k), that’s when you find out whether or not the software team did their part. So that’s where you can either find that we’re going to have a nice 90 day window, where the FDA is reviewing our submission, or we’re going to be sent back to the drawing board several times to, hopefully not recreate, but find in our documentation package, in the code, where we tested this, where we explain that, and how we did everything.

Dan:                       So let’s talk about…you get sent back to the drawing board, which from time to time may happen even with the best laid plans. Where does the AGILE methodology come into play, and how do you go about relaying out, getting a tourniquet on this time-suck, to ensure that you’re addressing those things as quickly as possible and that it’s going to go through the second time.

Rightley:              Sure. There’s nothing saying that you can’t apply these AGILE methodologies to the requirements and the documentation and the design phases as well. So it’s like setting up a new sprint. When something gets identified and you can’t just go back and point to in the document where that item is discussed, if you need to do additional mitigation, you need to do additional documentation, you need to have some additional processes set up or some SOPs put into place, that’s like another sprint in the AGILE methodology. So if you do it very much the same way. As I mentioned before, it’s all about taking the sprint inputs, figuring out, “Do we have everything that we need? Who are the stakeholders that we need to pull in? How do we get consensus around the work that needs to be executed?”

Rightley:              You plan that sprint’s work. And that could be documentation work, it could be design work, it could be development, it could be retesting or testing further something, making sure that a risk has been mitigated, and then you execute on the sprint. So you’re really following that same opening, working, closing the sprint methodology that you would during the whole development phase. So it’s all about planning your work, executing the work, and making sure that the work that you did is well tested and integrates well into the rest of the system. And it could be software, it could be documentation, it could be anything.

Dan:                       So phase five then is the post-market phase, right? During which time you’re required to conduct post-market surveillance for your device. Right? Monitor what type of adverse events might be occurring, analyze their severity. Talk to us a little bit about the software maintenance and monitoring and retirement phase.

Rightley:              So the planning for how this is handled is actually is back in phase one. So how you’re going to handle change control, how you’re going to handle a configuration management of the software, how you’re going to handle when something comes in from the field, evaluating and going back through, perhaps adding to the FMECA based on information you get from the field, and then flowing that back through the process. So again, I don’t mean to sound like a broken record, but you’re really going to, again, apply that methodology, that AGILE methodology again, of evaluating what the information that comes in from the software perspective. Do we have to then flowing back through the requirements? Does it mean we need to change a requirement? Do we need to test a requirement differently? How does this affect the requirements? How does this affect the design? Where, if anywhere, do we need to make a change in the code? How does all of this get tested? And then how do we rerelease this back out into the field?

Rightley:              So it starts back at that FMECA, and it flows back through the whole process, but you set it up like a sprint. So what are your inputs for the sprint? What’s the work you need to do and what’s the output? How do you close the sprint out? So it’s all about change control and having those SOPs and having those standards in place, before you ever get to that point. You don’t want to be scrambling to figure out how are we going to handle this customer complaint, and this adverse effect reported from the field, because you don’t have an SOP in place. A worst case scenario, somebody hears something like that or a complaint comes in, and it just gets dropped or it’s not handled, or the software is never looked at because there’s no SOP. There’s nothing in place for how to handle something like that.

Dan:                       So let’s talk a little bit about what MedTech Innovation teams ought to have in place when they approach a software development partner. We’re talking starting in phase zero here. What do you expect them to have in hand, besides the funding? What do you expect them to have in hand when they come to you and say, “Rightley, I need your team to develop this system for me”?

Rightley:              Sure. Well, there’s usually difference between what we would like to have and what we expect that they have when they come. But we tend to help and get involved with anything from product requirements on down. Ideally, somebody comes to us and we’ve seen this a lot with startups, especially with serial entrepreneurs, and non-first time founders. They’ve been through this before. They understand what the outputs of a good phase zero, or it might be called a phase one in what they’re used to. But with the outputs of that are, and they come to us with software requirements that follow the four Cs. Or maybe they just need a little bit of a review and some questions to answer and they’re tweaked and we’re good to go. That’s ideal. And we’ve had some great customers that are startups. And again, usually it’s maybe not the founder’s first startup, but they come to us with those requirements.

Rightley:              What we oftentimes will get, is a long form narrative set of product requirements, and usually an explanation that goes along with it, and a fair amount of data and science behind it that says, “Here’s the medical problem that we’re tackling.” We get a lot of that. So a very often we will help them in forming those long-form narrative type of product requirements that are based in science and medicine, and starting to flow those down into short, testable product requirements, and then software requirements and on down.

Dan:                       Let me ask you a question that I’m sure a lot of your clients face, a lot of our early stage company clients encounter it at Archimedic, an early struggle is assembling enough funding to hire a vendor like PSI, like Archimedic, to help them develop their product. And they want to make sure that they are in the best position they can be, during all that time when they’re raising funds to be ready to start. What should a team be doing to get ready to launch into this process, with a software vendor?

Rightley:              In preparation for being able to bring a software vendor on board, or even if they’re choosing to hire software folks and bring them in house and have them as FTEs, be prepared by having at least identified somebody that’s in the regulatory realm, that understands the regulation that’s around their device. And maybe they haven’t actually engaged them yet, but have them on tap and know that you’ve got somebody that understands what regulation, and how it is going to apply, and that of course will flow down into software. Because we understand software very, very well, inside and out, but we don’t always understand the overall medicine behind it, and how the risks of software can actually flow upward to patient risks, and how the FDA is going to look at those.

Rightley:              So that person is really, really important, whether they’re in house or somebody else, you need to identify them. Having a good understanding of the addressable market and the product requirements, what the product needs to do is often oftentimes overlooked. And they could be long-form narrative requirements. But have something that at least, your internal stakeholders all understand and agree, because I can’t tell you how many different times we’ve been into what was supposed to be a software kickoff meeting, and some of the very basics about system operation and what the device must do, are still being hashed out around the table. So having all the stakeholders internally agreeing about what market they’re addressing, how the product’s going to be developed, what the product’s going to do, very important.

Rightley:              And then also before coming and looking for software vendors, review those standards that we talked about. You don’t have to be an expert. You don’t have to know 62304 inside now. But it’s written in fairly plain English. And you don’t have to read and understand every aspect of it, but the standards are all out there. Evaluation copies can often be obtained of like 62304, and some of the paid standards, just for educational purposes. But reviewing the 21 CFR 820, reviewing 62304, or at least understanding the overall software development life cycle, and reviewing ISO 14971, and what goes into risk management are a huge leg up in the understanding what’s about to come, what’s going to be in this process and understanding the overall effort that’s going to have to be applied around not just the product development itself, but everything that goes around it.

Dan:                      So one thing that we haven’t talked about but I’m sure is on a lot of listeners minds, talking about ensuring quality through the software development process, is cybersecurity, right? More and more devices are Internet connected. And there’s risks of malicious or unintentional interference with software that may be critical to a patient’s health or data security. Talk a little bit about how does that tie into your quality processes.

Rightley:              Sure. So no matter when you’re listening to this, there’s always going to be a recent data breach that keeps this fresh in people’s minds. And we get this question all the time. And it could be a podcast or an episode all into itself-

Dan:                       And I think it will be.

Rightley:              But from a software perspective … And there are a lot of facet to data security, cybersecurity. It’s not just software. There are hardware aspects. There are a lot of different … There’s a lot of network and infrastructure aspects that go along with it. But where it really comes into a lot of the software development that we do is it’s … It’s good best practices really are your best protection. You can go way into the weeds and there’s a lot of things that can be done, and security that can be added on top of a system, or built around a system, or in the network infrastructure where the system is connected. But a lot of it is just best practices. And unfortunately, a lot of the things that we hear about of cybersecurity problems with devices in the field, is where best practices just weren’t followed.

Rightley:              So those are things like, again, I hate to harp on requirements, but understanding back even at their requirements phase, who needs what access to what data when? And how is it tracked, if any of that access is made, or if data is changed? And how is that data protected? So is it encrypted when it’s sitting on the chip inside a device, or on a server or in a hard drive in a PC? Is it encrypted when it’s being transmitted across the network? Even a local network, is it an encrypted then? Is the appropriate level of access and password protection, and changing of passwords and everything, is that all built into the software from the beginning? So really, those are all best practices that that should be followed throughout the requirements, the design, and then of course in implementation. And then of course when you get into V&V, test them. Make sure that you’re doing a bit of penetration testing, make sure that you’re doing a bit of that button pushing, and trying to find those unintended consequential effects which may allow somebody access into a system.

Rightley:              It’s really hard to test everything of course, but really following good practices and shrinking your attack vectors is your best insurance. You can never be 100% sure that you’re invulnerable. It just doesn’t happen. There’s always vulnerability. The main thing is to make sure the devices and the things that you’re working on, have the smallest attack vectors possible. And that’s really your best insurance. It all comes from just following good practices, good requirements, good design, and using good off the shelf technologies and components that are well supported by the industry, and they’re being tested and proven everyday in use.

Rightley:              You’re right. You’re trying to eliminate surprises. That’s the whole point. So the whole point of applying this AGILE methodology throughout, and while maintaining the quality around the requirements is to eliminate surprises. You’re trying to mitigate those risks as many as you can figure out upfront, and you’re trying to make sure that each sprint you deliver has increasing levels of functionality and that they’re really no surprises from the previous one. So that’s how you’re really ensuring the speed-to-market. You can only make development go so fast. But you can try and eliminate as many surprises as you can, and try and make sure that you’re getting to market when you think you are, even if it’s not as fast as you had initially hoped.

Dan:                       So the term AGILE comes up a lot. I think people throw it around very casually and I think it’s leaked out of software into other disciplines. And there’s AGILE everything. What do you mean when you say AGILE methodology and why is it so critical to integrate it into the development of a Med device software system?

Rightley:              Sure. I think AGILE has gotten somewhat of a bad name over the years in the software development community because I think quite often, AGILE, and as I’ve heard it put, is not spelled A-D H-O-C. It’s not just an ad hoc methodology that allows us to develop a ‘fly by the seat of their pants’ and figure out today what they’re going to develop today. That’s not what AGILE is or supposed to be. There are a lot of flavors of it. And there’s a lot of different ways you can practice it, but they all have a lot of similarity in that it still means getting all of the stakeholders together, getting them to agree on what’s being developed, but being flexible in the way that you develop it. And I think that’s what we’ve really tried to implement here at PSI.

Rightley:              I’ve heard somebody called it that it’s the [wagile 01:20:41] methodology, a little bit what we practice because Waterfall methodology, if you’ve heard of that in software development, and that comes from electronics actually. So you add the Waterfall with requirements and design, you put that together with a sprint-wise development during the implementation phase, and you have [wagile 01:20:58], I’ve heard it called. So the way that, I think, like I said, it just gets a bit of a bad rep. And I think that it can be applied in a lot of different disciplines effectively. You could speak more to electromechanical than me for sure. But it needs to be built and deployed within a framework of good stakeholder agreement, and requirements, and knowing how you’re going to test it on the backend to make sure that that thing that you developed agilely actually does what it’s supposed to do.

Dan:                       I think we’re nearing the end of the time you’ve promised me. So I really appreciate Rightley, taking the time to come on and talk with me. If it’s all right, we’ll put your contact information in the blog post when we post this episode, and folks can get in touch with you if they want to if they want to pick your brain a little bit more.

Rightley:              We’re always happy to help. Getting somebody off to start the right way, it benefits everyone. So we’re always happy to take a phone call and help someone out.

Dan:                       Great. Hey, well thanks very much Rightley.

Rightley:              Thanks for having me.

Dan:                       Take care.

Written by Daniel Henrich

Written by Daniel Henrich

Director of Marketing at Archimedic

Smithwise + Catapult = Archimedic

WALTHAM, Mass., May 20, 2019 /PRNewswire/ — After announcing their merger last month, medical product development firms Smithwise and Catapult rolled out their new brand today, Archimedic.

Eric Sugalski, CEO of the joint entity, explained how they settled on the name. “As we brainstormed a new name, we knew we wanted it to reflect the medical device industry we serve.” Hence the -medic part. “But,” he continued, “we also latched onto this character of Archimedes. He was a truly remarkable figure in ancient history–an engineer, mathematician, inventor, and strategist. Though he discovered solutions to different types of problems in a long-ago era, our team takes inspiration from his creative legacy as we solve modern-day healthcare challenges.”

The firm’s logo is inspired by the Stomachion of Archimedes, a dissection puzzle wherein pieces are arranged in various configurations to form a square. The Archimedic icon is a section of the best-known Stomachion solution.

“There are more than 500 ways to assemble the fourteen pieces of the Stomachion puzzle,” said Andy Zielger, COO & CTO of the new firm, “Each solution is challenging and elegant in its own way. To us, this was a clear analogy for what we do here. Many technical, regulatory, clinical, and commercial factors come into play during the medical product development process. At Archimedic, our role is to work alongside clients and determine how these pieces best fit together to uniquely solve their commercialization puzzle.”

By joining the two firms, Archimedic is able to offer expanded electromechanical, software, systems, and quality engineering and industrial design services to the medtech industry. A larger team of medtech experts means deeper expertise in a number of industry verticals, including diagnostics, drug delivery, and advanced surgical systems.

“We’re excited about this new brand because it reflects so many of the things that are important to Andy and me about our partnership,” Sugalski added. “More than that, they’re important to the clients we serve and the team we lead. Under Archimedic, we get to bring the best of who we were together into something new. We can’t wait to keep building on this foundation.”

About Archimedic: Formed in 2019 by the merger of Smithwise and Catapult Product Development, Archimedic is a full-service medical device developer. We help innovators struggling with technical, regulatory, and manufacturing challenges accelerate their next new products along the path to market. Our clients span established medical device manufacturers, top-tier academic hospitals, and venture-backed startups. We specialize in advanced medical systems, including telemedicine and diagnostic platforms, wearables, drug delivery devices, and surgical systems. Our client projects range from proof-of-concept prototypes to high-volume production design and manufacturing transfer. Visit us at www.archimedic.com

Media Contact:
Daniel Henrich
Director of Marketing
dhenrich@archimedic.com
(610) 455 4255 x 735

Written by Daniel Henrich

Written by Daniel Henrich

Director of Marketing at Archimedic

Catapult and Smithwise Announce They’re Combining Teams

WALTHAM, Mass., Apr. 4, 2019 /PRNewswire/

Two medical device development firms, Catapult Product Development, Inc. and Smithwise, Inc. announced today they have agreed to a merger in order to offer expanded medical device development capabilities to their clients.

“I’ve long described us as partner organizations,” said Eric Sugalski, Founder and President of Smithwise, “we share the same values and mission, we serve the same customers, and we offer complementary strengths to device innovators.”Though both firms bring mechanical, electrical, and software engineering capabilities to the medtech industry, they specialize in different areas—the Smithwise team skews towards mechanical engineering and industrial design, while the Catapult team has deeper electrical and software expertise in-house. “Together, we’ll be able to better serve our clients,” said Andy Ziegler, President of Catapult, “instead of regularly bringing the other team in as a subcontractor to supplement existing capabilities, we’ll be able to make immediate decisions on project resourcing and expedite our response for clients. Eric and I began discussions last year after realizing that our clients will appreciate being able to directly leverage our combined expertise.”

The leaders of both organizations were emphatic about their desire to communicate that this is a partnership of equals. “We’d like our customers and strategic partners to understand this merger is a meeting of the minds, not a case of one firm being absorbed by the other,” said Sugalski. “We also want them to share our confidence that this relationship is already tried and tested—we’ve worked closely together for years across many different projects. In many ways, we’re acknowledging a reality that’s existed for some time and now we’re formalizing it. There will be some new questions to resolve in the coming months but, overall, we’re simplifying things for ourselves and our customers.”

Both engineers by background, Sugalski will serve the joint enterprise as CEO, while Ziegler fills the COO and CTO roles. The new firm will combine Boston area offices with no staffing changes anticipated for the Boston or Philadelphia teams.

An announcement regarding the joint firm name will be forthcoming. “Stay tuned,” said Sugalski.

About Catapult Product Development: Founded in 2012, Catapult is a full-service medical device development firm, specializing in console-based diagnostic and therapeutic systems, minimally-invasive surgical and diagnostic tools, and a wide array of portable and handheld medical equipment. We work extensively with startups to enable their core technologies, as well as supporting leading device manufacturers and academic centers as they accelerate critical device development projects towards commercialization.

About Smithwise: Founded in 2009 as Boston Device Development, Smithwise is a medical device developer that helps innovators struggling with technical, regulatory, or manufacturing challenges with their next new product. Our clients span top-tier academic hospitals, established medical device manufacturers, and venture-backed startups. We specialize in connected medical devices, wearables, and surgical systems. Our client projects range from proof-of-concept prototypes to high-volume production design and manufacturing transfer.

Media Contact:
Daniel Henrich
Director of Marketing
dhenrich@smithwise.com
(610) 455 4255 x 735

Written by Daniel Henrich

Written by Daniel Henrich

Director of Marketing at Archimedic

ActiveProtective Announced as Extreme Tech Challenge Finalist

R to L, ActiveProtective CTO Wamis Singhatat, CMO Drew Lakatos, and CEO R. Scott Jones pose after being announced as an XTC Finalist at CES in Vegas last month.

Like many great medtech companies, ActiveProtective started with a clinician recognizing a problem as solvable and working towards a solution. Dr. Robert Buckman wasn’t alone in realizing how devastating a fall can be for an elderly patient. But, as a trauma surgeon who saw patients facing life-threatening consequences after suffering hip fractures, he wanted to find a way to shield those most at risk.

A third of Americans over 65 fall each year and many of those falls result in broken hips. Hip fractures are often associated with a rapid downward spiral for elderly patients, who must endure invasive surgery, recovery time immobilized in bed, and, usually, a less active lifestyle moving forward.

ActiveProtective was born from Dr. Buckman’s quest to prevent injuries to seniors, rather than just treating them afterwards. Their solution is a high-tech belt system, one that monitors and analyzes the motion of the wearer to recognize a fall in progress in milliseconds and deploy airbags to shield the hips before impact.

After many prototype iterations, user interviews,deployment tests, and investor pitches, the ActiveProtective team was among the ranks of promising tech startups selected to participate in Sir Richard Branson’s 2019 Extreme Tech Challenge. The team also made the down-select to the semi-finals, where companies were invited to pitch before a panel of judges at this year’s CES conference in Las Vegas. It was there they learned they would continue their journey as a top three finalist to pitch the Smart Belt to the celebrity tech mogul in person this April–on his private Necker Island.  

“We’re so proud of our friends at ActiveProtective for the way they’ve driven this technology forward to this point of being recognized as a medtech leader,” said Eric Sugalski, President of Smithwise. “I’m honored our team has been able to support them in their mission throughout the evolution of the ActiveProtective smart belt. Know that the whole Smithwise team is rooting for you.”

You can see a video of the ActiveProtective Smart Belt deployment and listen to Eric Sugalski’s interview with ActiveProtective CTO Wamis Singhatat on our blog here.

Written by Daniel Henrich

Written by Daniel Henrich

Director of Marketing at Archimedic

EPICASE DEMO

Epinephrine Phone Case

Dr. Ed Pribitkin of Thomas Jefferson University Hospitals demonstrates EpiCase, a device to ensure life-saving medications are always in reach.

Dr. Pribitkin stopped by the Smithwise booth during this year’s Advamed MedTech conference in Philadelphia to demonstrate EpiCase, currently in development with Jefferson.

MedTech Mindset Podcast: Clinical Evidence Insights with Joe Popowicz

Launch Episode

This episode is a great way to tell if this podcast is for you.

Eric Sugalski and Dan Henrich sit down to discuss the big picture of bringing a new piece of medical technology to market. We touch on product development and design, regulatory pathways, clinical evidence, go-to-market strategy, intellectual property, and other important topics.

In coming episodes, we’ll explore these topics in more detail with guests who are experts in these areas and guests who have recently been through the process. 

apple-podcast Listen on Google Play Music Stitcher_logo spotify-logo-png-file-spotify-badge-large-png-1280 rss

Episode Transcript

Dan Henrich: Hello and welcome to the very first episode of Medtech Mindset. I’m Dan Henrich your host, and I’m director of marketing at Smithwise, a medical device product development firm.

I’m gonna use this first session to kick things off, and let you know what to expect from this show. We’re gonna be talking with guests who are experts in different areas of medtech. Including product design, clinical trials, regulatory, market strategy, funding, things like that. We’ll also bring guests onto the show who have had recent experiences commercializing new medical technologies. Some of these might be Smithwise clients. And others are just gonna be friends and colleagues we’ve met working in the industry. We wanna hear about their ups and downs, and try to draw out some lessons from their practical experiences for you our listeners.

For this first installment, I sat down with the president of Smithwise, Eric Sugalski, and we talked about the big picture of bringing a new piece of medical technology to market. Our conversation touched on a lot of themes that we’re gonna develop more fully throughout the show. So I think it’s a great introduction to help you decide whether or not this podcast is for you.

Now, just so you know a little bit more about him, and why I think he’s worth listening to. Eric is an entrepreneur and a mechanical engineer by training. He’s got extensive experience working in the medtech arena. He’s held engineering and leadership roles with IBO and Insight product development. And he’s even lectured in the mechanical engineering program at Massachusets Institute of Technology. He holds a bachelor’s degree in mechanical engineering from University of Colorado Boulder, and an MBA from MIT. Eric founded Smithwise in 2009, and he continues to lead our Boston and Philly teams. So let’s get started on Medtech Mindset by jumping into my conversation with Eric.

Eric Sugalski: Hey, what’s up Dan?

Dan: Hey Eric, how are you today?

Eric: Good, good. So, what are we doing here?

Dan: This is our very first episode of Medtech Mindset. So this is our chance to kick off and grab everybody’s attention. Explain to them why we are launching this podcast.

Eric:    Okay, okay. Sounds interesting.

Dan:    So I thought you’d be a good first guest. Because we are often approached by a prospective client or a new project, and the first words out of their mouths are usually, “I have this idea, but I need a prototype.”

Eric:    Yep, all the time.

Dan:    And so I thought it would be good to begin with that idea, because it’s probably the idea in the mind of some of our listeners. And we wanted to talk about the different phases of things that they need to think through before they get to the stage where they need to build a prototype.

Eric:    Got it, got it. So, you’re right. We hear 95% of the time, when companies come to us, usually at the early stage. They have in idea, the see an opportunity to make a difference with a new medical technology, and right off the bat they jump towards, “How do we build this prototype to really demonstrate the idea.”

Dan:    Right, so I thought it would be good to use this first chat as a chance to take a step back, and talk about the things … Where do prototypes come into play, but more importantly, the process of bringing a new piece of medtech to market. What are the steps that you rally go through? And I think it would be good to take a step back and talk about defining the bigger picture of the need. Where does your idea fit in, and what’s the real value that you see if everything goes right throughout the building process.

Eric:    Yeah, yeah. I think that that’s a part that a lot of times gets glossed over. There’s an awareness to a particular medical need initially, and that leads to a quick idea session. And then people become fairly focused on that idea. And that makes sense because that’s where the commercial opportunity is, that’s where the creative process starts to kick in. But, in our point of view, we think that there’s a lot of benefit in going back to the need, to really make sure that the solutions that we’re building off of are really founded in … They’re grounded in a very strong need.

And we follow a process that is advocated and spelled out pretty well in the BioDesign book that coursework at Stanford. And really coming up with the need, it comes to three components, there’s three parts to it. The first is really looking at who specifically is the patient population that you are targeting, right? So, in many cases a common mistake for startup companies is that they try to address too large of a patient population. They try to say, “This product is going to be for everyone.” But realistically in medical device development, it is much more effective to be laser focused on a very specific patient population first. And then if you’re successful there, then you can expand into other markets. So we think that that is the first part. Who exactly is your user? Who is the patient?

From there, it’s looking at what is the problem? What’s really going on with the patient that deserves an additional solution? And how is this problem being addressed by other solutions? Whether those are products, whether those are services, whether it’s a workaround that a patient is implementing themselves. There are often a variety of ways of solving a problem. And so, developing a landscape or understanding what all of those problems are, or what are those ways of addressing a problem, that’s an important part of the process.

Dan:    Yeah, so it’s not really just, “Has this technology been commercialized before?” Right? It’s, “How is this problem currently being solved? And is it a problem that’s appreciated by the market already?”

Eric:    Right, right. Yeah, absolutely, absolutely. And then the third piece is, what’s happening right now, what is the outcome of this problem? Right? So how are you going to quantify this outcome in such a way that allows you to determine if your solution is really addressing that problem that you spelled out, with the specific patient population?

So it’s those three components. It’s the patient population, the problem that’s facing the patient, and then the outcome that is really worthy of solving, [crosstalk 00:07:28] solving that problem.

Dan:    And ideally, you should be able to tie all of those things into a very succinct needs statement right? That contains each of those three elements.

Eric:    Yeah, absolutely.

Dan:    And if you can’t do that, then it’s probably a sign that you haven’t really dialed into the problem that you’re solving.

Eric:    Right, right, yeah, yeah. And it’s very, very common. All too often, we see pitched [inaudible 00:07:53] from startup companies that spend a ton of time talking about their technology or their solution, and they have not even clearly spelled out the needs statement. So it’s a really foundational part of the process, and in many cases, companies should really be spending more time refining and spelling out that need to make sure that they’re solving a real problem that needs to be solved.

Dan:    Yeah, I think that’s something that struck me a couple of weeks ago. You and I were down at UPenn for that biomedical engineering student pitch meeting. And there were groups of some really talented and bright engineering students who were pitching health related technologies for their project that they’re working on. And in many of the cases it kind of seemed like there was a technology in search of a problem, rather than the other way round. That’s sort of what you might expect to see from an undergraduate student, but it doesn’t end with graduation. That’s something that people are not necessarily appreciating throughout the normal course of study to become and engineer or a business person or whatever. We still often see, even funded medtech companies, who haven’t really dialed into their proper needs statement and the problem that they’re solving there.

Eric:    Yeah, I think that what you mentioned about the engineering students, that happens everywhere, at all universities. The schooling of engineers is very solution oriented, right? You get your problem sets, those are given to you. And the job or the responsibility of the engineers is to really create the solutions that satisfy those problems, right? So, there’s very, very few parts of the engineer’s curriculum that’s focused on identification of the problem, right? So this is something that’s very, very common, it’s not intuitive to engineers or people that have a technical focus, to really be thinking more about that need and the problem and the patients. But it’s a super important part of this process.

Dan:    So, I guess then it becomes really important for, particularly if someone with an engineering background has an idea that they think might have a great application in healthcare, it’s really important to get clinical input early in the process, right? And understand how things are done now, and get some honest reactions to your potential new way of solving this problem.

Eric:    Yeah, so there’s a lot … One of the challenging things about medtech is that, the people that are buying the product are not the people who are using the product. So, the clinicians who are going to be using the product, a surgical device or a diagnostic system, they’re certainly going to have influence into the utility of the product, and how it’s going to compare to the other products or services that are currently being used. But they’re one of many, many stakeholders in this medical device procurement system. There are hospital administrators who need to really crunch the numbers to understand, does this make financial sense? There are regulatory bodies who might get in the way of this product from ever seeing the light of day. There’s the end patients who need to be adherent with certain technologies in order for them to be utilized.

Dan:    And there’s the payers right? Either the public or private payers, Medicare, Medicaid, or a private insurer, and you need to prove to them that the overall cost using your solution is going to be less in the big picture.

Eric:    Yeah.

Dan:    Than whatever the standard of care is.

Eric:    Absolutely. And that could be possibly the most critical aspect to really understand. What is going to drive change from a payer’s perspective? Whether that’s CMS or whether that’s private insurance. So yeah, these are all key things. But to your earlier point, it is definitely important as engineers are coming up with these ideas, to vet these concepts with clinicians. But they’re not the only stakeholders that matter in this really complex industry that we’re in.

Dan:    Right, right. So let’s talk about … Say you have an idea, you have a technology. You think you have an application for it in the healthcare space. And you’ve done all that leg work. You’ve got your needs statement, you’ve got some at least preliminary feedback, at least neutral feedback from clinicians or from people who are going to be working with the products itself to say, “yeah, this is a real potential solution to an existing problem.”

Dan:    You have your idea, and you want to start developing that. Let’s move into this talk about, “Now am I ready for a prototype?” IS that when I start building my first … Ordering parts and soldering things together, or are there more things that need to come into it prior to jumping into that process?

Eric:    Yeah, sure, Great question and a common question that a lot of early stage companies have is, “What should be my next, most logical step that’s gonna help me build value in the company?” And the way that I think about this is, when a company or new idea’s just getting off the ground, the inventors of this new technology, they have this very optimistic mindset. They are imagining what the world could be with this new solution that they are creating. And that leads into new concepts, and eventually this concept for a product that could result on a medical technology or medical device. So, it starts with optimism. And you need to have that optimism and opportunism to get to that point, where you have something on the table that you can evaluate.

But now when you’re looking at what’s the next step in product development, you need to kind of flip a switch. And you need to go from being an optimist and an opportunist, to being a skeptic. And being a skeptic changes your thinking a lot. I makes an individual think not about why the product will work, but more of a why the product is not gonna work. What are the reasons why this product could fail? Premarket, postmarket, whatever may happen, whatever the case may be. What are all of those factors? Then … So there’s a number of these factors, there’s regulatory risks, there’s clinical risks, does the product work in humans or with humans? There’s IQ risk, is there other technology that’s going to block this from ever coming out? There’s the payer risk that we talked about, there’s user compliance or adherence risk. There’s market risk, is the market going to be big enough to drive the investment that’s needed to move this technology along? So there’s all of these different risk factors. And so founders of new companies, inventors of new technologies, they need to get into this skeptics mindset, and they need to think about why might this product fail?

Dan:    Right. So, is that maybe … Something that is occurring to me as you’re talking about this is, is that maybe why we see so many new startups that are two person operation, right? And there’s very different personalities sometimes when you meet with a team. It’s a tow person team, and one of them really seems to be just boundless energy and ideas, and everything is kind of like roses and sunshine. And the other person is kind of a Debbie downer.

Eric:    Yeah.

Dan:    Is one way you could interpret it. You need both sides of those ways of thinking. And it can be difficult to combine that into one personality.

Eric:    Yeah, absolutely. I think the way that you put it is right. You need to have that optimist, the energy to move things over, but then you also needs to have the critical eye that’s questioning things.

Dan:    Yeah. Yeah. You know, my dad’s a mechanical engineer, and it always seemed to me when I was a kid, he was just such a downer on things. And one day he turned to me, and he said, “You know it’s my job to think of everything that could possibly go wrong, right?”

Eric:    Yeah.

Dan:    And when he explained it to me like that, it really put thing into perspective. He’s derisking all day everyday.

Eric:    Yeah.

Dan:    Basically is how he has to think.

Eric:    Yeah, very true.

Dan:    So, I think that concept of risk is interesting. Particularly in the medical device, medtech arena. I guess because people often talk about risk related to medical devices, but they mean it in a very particular area of risk. Which is basically what’s the risk to the patient if this device fails, right? So then, you were talking about other areas of risk. Regulatory risk, market risk, right? So talk to me about how you move through each of those areas, and go about trying to reduce your risk in each of those different sectors.

Eric:    Yeah, yeah, sure. So, as we started out, there’s also technical risk, and that’s probably the easiest one to tackle first. There’s a question about viability. Is this idea going to really work? And so the natural way to approach that is to come up with bread boards or test beds that allow a team to understand what the technical limits are of an idea. And so, one of the ways that as an engineering firm, here at Smithwise, one of the ways that we tackle that is, we try to simplify and isolate the key technical risk areas. So if there’s a core mechanism that really needs to fit within a certain size in order for a product to be viable, then we will just isolate that one mechanism and we will focus on iterating that in a very, very rapid way. If it’s an electrical subsystem that needs to be developed so that it can be managed, it can provide all of the functionality in a very low power environment, then we might isolate that electrical subsystem so that we can iterate that technology.

I think one of the approaches that does not work when you’re at the very early stages of looking at technical risk, is to try and merge all of these different things together, and create a single cohesive prototype. The reason being is that when you put all of these things together into a holistic prototype, the challenge is that, number one, it’s gonna take you a really long time to get there. And then number two is, when something goes wrong, you’re not gonna exactly know why or where it went wrong. It’s going to be a little bit nebulous, right?

Eric:    And then I guess the last reason is that development of technology, product development is a lot about iterations. And you wanna be able to reduce the size, the length of an iteration cycle as much as you can.

Dan:    And the expense, right?

Eric:    Yeah. Money is short for a lot of companies that are developing new medical technologies. So if you isolate that technology into a core area, it allows you to iterate that one specific subsystem much more quickly. And then once you get all of the performance of those subsystems the way that you want them to be, then you pull them together into that cohesive working model that demonstrates the overall system level functionality you’re looking to achieve.

Dan:    Right. So you can have a prototype that maybe is your electrical components prototype, your mechanical components prototype, your human factor prototype, right, that is, does this feel natural for the user? You might never tie these things together during the first prototyping phases right? That might be the next thing down the line after you’ve isolated each of those systems.

Eric:    Yeah, absolutely. And so I’m glad you brought up the human factor and usability type of prototyping. If I have a new medical technology, let’s say it’s a wearable. And it needs to be used by a person at home, and they need to be wearing this product for ten hours a day, hypothetically. If I’m testing out an idea, do I really need to have that mock up or that prototype fully functional in order for a user to give me feedback on it? Probably not. I can come up with a mock up that is very simplistic that just focuses on the key usability attributes that are gonna matter to that individual. So this could be a non-functional mock up that you take out to users, get their feedback on it, and better yet, it’s multiple mock ups. Because you’re simplifying things, it’s really just a dummy shell of a product, you can come up with six or eight different versions of this, and test of these versions with potential users. It’s a great way to get a lot of that longer term user usability and concept preference feedback to help you steer that direction.

Dan:    And that might really impact your design process very significantly, right? If you’re deciding where to place a sensor, and you think it’s gonna be going on someone’s wrist, but it ends up whatever, going around them in some way, or hanging from their neck or whatever the case may be. That will very much impact the rest of your design process with how all of those components function.

Eric:    Absolutely. It’s gonna drive all kinds of requirements, it’s gonna drive the size and the shape of the housing or the package that all of the electronic are gonna be contained within. It’s going to define whether it’s going over garments or under garments, directly on the skin, or hanging off a pocket or a bra strap, you know. It’s all of these architectural requirements from a usability standpoint are going to drive the design. So it’s really important to be thinking about that stuff up front. If you focus on technology too much at the front end, and you ignore a lot of human factors, it could be a rude awakening when you go out and get feedback from customers, and you realize you’ve developed the wrong product. And now you have to go all the way back to the drawing board, and start exploring these new configurations from scratch.

Dan:    I think that maybe some, or a lot of people have in their minds when they say, “I need a prototype” what they really have in their minds is, “I wanna be able to hold something in my hands when I make that Shark Tank like investor pitch. That is gonna look really slick and impress somebody right upfront.” But really, most of the prototyping process is really about clearing what isn’t right about your current design, right?

Eric:    Yeah.

Dan:    And so you can change it the next time round.

Eric:    Right, right. Prototyping is really in my perspective, it’s a learning methodology. It’s a way of thinking to test out your ideas in a very rapid way. So, yes, everyone’s goal is to have that cohesive prototype that demonstrates the full functionality, and it’s the right form factor, and it’s the right cost structure, and it has all the embedded functionality. That’s where everyone wants to go. But the way to get there is by taking this isolated approach, right? Isolating your risk factors, iterating those risk factors individually, and then merging them afterward. So, it’s a different approach than most start up companies take, but we believe it’s the one that results in the most efficient process.

Dan:    Hey listeners, if you have a great medtech story to tell, or maybe a suggested guest we should have on the show, or a topic in medtech you think we should cover, send me an email at marketing@smithwise.com. Or use the contact us form on our website.

So one other area that I wanna make sure we touch on is the regulatory approach. I think often people think of regulatory approval as kind of like once they get that stamp of approval from FDA, they’re home. They’re free and clear and now they can bring the product to market. But all that means, is that the FDA’s not gonna stop you from marketing your product, right? So, let’s talk about the different approaches to overcoming that regulatory hurdle, and then what comes after it.

Eric:    Yeah, yeah sure, it’s another factor that needs to be considered very early on in the process. For some products, like you mentioned, if it’s a consumer wellness device, a wellness device, maybe you do have the option of it could be marketed as an unregulated consumer product. Or, it could also be marketed as a regulated medical device. And it’s a really important topic for companies to consider at the very early stage, there’s implications to either one of those [inaudible 00:25:34].

Dan:    Sure. And that decision will really totally determine your whole go to market strategy, right?

Eric:    Exactly.

Dan:    Are you marketing it to consumers? Or are you marketing it to payers?

Eric:    Yep, yeah, yeah, yeah. Absolutely. And it will also drive certain design elements. So the design of the product, it may be of a different cost structure if you’re marketing it to consumers, rather than trying to get a product to be purchased by hospitals, right? So, these decisions that companies make at the very early stage, they have longer terms consequences that people need to be aware of.

But back to, there’s a number of other ways that you can get regulatory insights. For the longest time, people were fearful of getting together with FDA. They were fearful [crosstalk 00:26:23].

Dan:    You don’t want to be on the radar.

Eric:    Yeah. That they were gonna give you the black mark, and you were never going to be approved once you got that black mark. So FDA has evolved immensely int he last decade. They have programs now for doing informational sessions where you can collect feedback in an informal manner with FDA officials. There’s pre submission meetings where you can present the endpoints that you’re looking to achieve, an animal model that you’re looking to support. An IDE application, and collect formal feedback from FDA. So there are some really great ways to collect feedback from FDA, and it’s an important part of the process. Companies should not be avoiding FDA no until it’s too late.

Because again, if you wait too long and you get a response that, after you’ve invested an enormous amount in product development and clinical affairs, then you’re going to have to spend a lot of time and a lot of money redoing all of that front end effort. So, again, it’s about thinking about those longer term consequences, those longer term decisions, and trying to figure out how can I get some feedback as early on in the development process as possible.

Dan:    Right, and that maybe ties into another sort of premarket thing you need to worry about, which is intellectual property and patents, right? So, we talked about what are the other solutions to this problem? The fact they might not be just a similar piece of technology, right?

Eric:    Right.

Dan:    But when it comes to exploring existing or prior art, right? How do you go about that process?

Eric:    Yeah, so there’s a few key pieces there. There’s first looking at what is out there, what does the current patent landscape look like? And oftentimes the way that this is started is individuals, engineers, or people that are founders of the companies will hop on Google patents or the USPTO website, and start to do [inaudible 00:28:34] style searches. Looking at typing in key words and finding the patents that are most relevant. Once they find those initial patents, then following the references and citations that link to the most relevant patents, that’s a great way to get an initial pass of the overall patent landscape.

So, understanding that patent landscape at the front end is pretty critical. A lot of times investors want to know, have you got a formal legal opinion of freedom to operate? That’s different level of patent scrutiny, and it’s usually a pretty costly undertaking. So in most cases, startup companies that are resource constrained do not invest in that until a little bit further along in the process, unless their investors are insisting on it.

Eric:    But you at least need to do preliminary due diligence to understand what IP is out there, right? And what IP is protected. Because just because there’s no product on the market that utilizes this technology, doesn’t mean that somebody doesn’t hold the patent to it, right?

Dan:    Right, I mean, that’s a great point. There’s a lot of patents for technologies that are not on the market. And so you do have to be looking at the patent database to see if you’re stepping on another company’s patent.

Eric:    Another good source of looking at products or products that have become commercial or were commercial at one time, is in looking at FDA’s [510(k) 00:30:15] database. So this is of course limited to products that are 510(k)s, but this allows you to type in a certain classification code, and identify all of the products that have been cleared for 510(k). So that’s another good way to get a basic understanding of what products have historically received FDA clearance, and maybe what products are still on the market in a particular category.

So, all of these things that we’re talking about are strategies that you need to begin defining very early on in the process.

Dan:    What about your go to markets? How do all of those tie in to your go to market strategy? And making that ultimate go, no go decision that your investor is going to have to make of, does this market opportunity justify the amount of investment that you think is needed upfront?

Eric:    Yeah, yeah. So, one thing that we didn’t talk much about yet, but it’s a really key aspect of go to market strategy for medical devices, is the clinical risk. So how do you, how does a new company prove that their technology is superior from a clinical perspective than the standard of care? And this is interwoven with the market strategy, right? There might be some clinical work that is needed for regulatory clearance, but there’s another level of clinical work that is often needed to prove the value of a product related to the competition, right?

Eric:    So that type of clinical study might be looking at reduction in readmissions. Or it might be looking at reduction in a certain cost element. Or hospital stay time. Whatever those end points are, you need to identify how am I going to prove to the medical community that this technology is superior? And so, whether it’s a 510(k), or whether it’s a PMA, you really have to be thinking about that clinical strategy. How am I going to prove that this is better?

And so that often feeds the go to market strategy. If you can conduct that clinical study in a really efficient way, and present the data such that it is a cost savings to a hospital, then maybe the hospital is the payer. If instead, you are looking at providing a product that’s falling under an existing reimbursement code, and you’re looking to do this more cost effectively than competing technology, then that’s another way to get hospitals to consider your product or technology.

In certain cases, there is no code. For a lot of [inaudible 00:33:06] devices that are being developed and new PMAs, there may not be a new code, or code that’s available. And so this can be a much more lengthy process. But it’s one that needs to be considered really early. What does that clinical study need to look like in order to compel CMS to set up a new code, and to provide the coverage that’s going to be needed to justify this new medical technology down the road?

Dan:    Right. So that’s an example I guess of how your regulatory pathway is going to very much spell out or help define your business plan. Because if you’re going to market via a 510(k) pathway, versus a [inaudible 00:33:50] pathway, that makes a huge difference in your time to market, right? Which translates into overall cost of bringing the product to market.

Eric:    Right, right. Yeah, so that’s a good point. If you’re looking at the [inaudible 00:34:05] 510(k) pathway, then you may need to run some additional clinicals. And there may be uncertainty about the coverage, or the coding that’s going to be available to that product longer term. So again, looking at that regulatory pathway very early and using that as a key point to make your architectural decisions about the product development, that’s a really important consideration at the front end.

Dan:    One of the things I wanna make sure our listeners understand in this first episode it that, we’re trying to set the stage here for what it takes to bring a new medical product to market. Whether it’s a medical device that’s regulated, or whether it’s a consumer wellness product. There are all of these different areas that come into play. We’re going to be, in the coming episodes, sitting down with both experts in these particular areas, because you should always have expert opinions as you get further down the track. And we’re also going to be sitting down with folk who have been through this process recently in maybe a new medtech start up. So, I think you and I are both really looking forward to those conversations. So we have a great slate of folks who are signed up to come and have those conversations about clinicals, and what do investors look at when they’re deciding whether or not to fund a new company? And what’s the process for determining what the existing IP is? And how do you approach the FDA and inform your regulatory strategy and all that.

So, I think this is gonna be a really great series, especially for people who are early on thinking about how to begin that process.

Eric:    Yeah. I think that’s dead on. So we are, at Smithwise, we’re focused on product development, right? We’re focused on a lot of the engineering. The design, the manufacturing of new medical products, but one of the things that I realized throughout my career is that the product development of medical technology is complex. And you really need to be considering all of these different factors that we just discussed. If you try to develop a product in a vacuum, then you’re gonna have some big nightmares to address later on. And so bringing in these experts to talk about all of these areas is going to help us better understand how to integrate those aspects into product development, and it’s hopefully gonna allow our listeners to get the insights that are needed to shape their product development strategies as well.

Dan:    Yeah, I think what we’re really talking about is going in to the product development and the design and engineering phases of your project with your eyes open to the different hurdles that you need to get over in these various areas. It’s a little bit like that Gilligan’s Island special, where the Professor gets back from the island and he’s been inventing in a vacuum for the past 10 years, right? Nd he’s got all these great ideas, but then he brings them back to civilization to find that they already exist.

Eric:    Yeah, right.

Dan:    So, I think a real theme that’s gonna come out here is, the earlier the intervention you can get, the better input you can get from people who have experience in these different areas. Whether it’s clinical, or legal, or regulatory, right? The better off you’re gonna be throughout your product development process. The faster you can iterate and bring your device to market, and the lower you can keep your costs. So I think that’s part of what we’re hoping this podcast series really helps people think through.

Eric:    Absolutely. Well said.

Dan:    Well Eric, thanks for sitting down today, I’m very excited about kicking this off, and I think you are too, and we’ve got a very good slate of people who are ready to talk about these issues with us.

Eric:    Yeah, Dan, should be pretty exciting. Looking forward to it.

Written by Daniel Henrich

Written by Daniel Henrich

Director of Marketing at Archimedic