Origami Leads to New Non-Profit

During the COVID-19 crisis, Archimedic collaborated with hospital-clients and fabrication partners to rapidly develop the Origami Mask.  This mask can be made from a variety of materials without the need for sewing or specialty equipment.  Within a very short period of time, thousands of masks have been deployed to healthcare professionals and vulnerable individuals to help mitigate the spread of the coronavirus. 

As an open-sourced initiative, Archimedic and collaborators have made all design files, material recommendations, and instructional videos available to the public.  Hundreds of individuals from across the globe have downloaded the files, and stories have been pouring-in from individuals building and donating masks to hospitals, nursing homes, and family members.  Furthermore, hundreds of open-source collaborators have joined the initiative to suggest design and manufacturing improvements, provide material and vendor information, and expand raise awareness of the Origami Mask as a source of DIY PPE.

Through this process, the innovators behind the Origami Mask determined that this open-source concept could be extended to address a variety of unmet medical needs.  Team members behind the Origami Mask used this project as launching pad for Open Medical, a non-profit organization focused on open-sourced medical products for patients and providers with urgent, unmet medical needs.

Just as the COVID-19 public health crisis has illuminated unmet medical needs during a time of public health crisis, many other patient populations, such as pediatrics and rare diseases, have been neglected by the medical device industry due to poor financial returns associated with limited markets sizes. The objective of Open Medical is to address these underserved patients by leveraging the talents and resources of the open-source community.

Open Medical is a 501c3 organization (status pending), which relies on the contributions of a broad base of members having clinical, engineering, design, marketing, and other backgrounds.  A robust community has been activated, and additional members are sought to help drive these important initiatives forward.  Please consider getting involved and contributing to the Open Medical Mission.

Your content goes here. Edit or remove this text inline or in the module Content settings. You can also style every aspect of this content in the module Design settings and even apply custom CSS to this text in the module Advanced settings.

Note:  The Origami Mask has been developed rapidly to address the needs of PPE during the COVID-19 crisis.  As a result, extensive testing has not been completed, and the Origami Mask has not been registered with or cleared by the FDA.

 Written by Eric Sugalski

Written by Eric Sugalski

Eric Sugalski is the founder and president of Archimedic, a contract medical device development firm with offices in Boston and Philadelphia. Sugalski has led the development of a novel pediatric life support system, cardiovascular implants, laparoscopic surgical devices, and an array of wearable diagnostics. In addition to his technical background, Eric provides companies with product development strategy that encompasses regulatory, reimbursement, and fundraising requirements. Eric obtained a B.S. in mechanical engineering from the University of Colorado Boulder and an MBA from the MIT Sloan School of Management.

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

The Challenge and Promise of Pediatric Device Innovation

This article originally appeared on Med Device Online.

By Matthew R. Maltese, The Pennsylvania Pediatric Medical Device Consortium, and Daniel Henrich, Archimedic

As a society, we seem to regard the lives of children as more innocent, precious, and worthy of protection than those of adults. This superior valuation of child well-being is not limited to people with children of their own, or those in attendance at pediatric device conferences: in an ongoing MIT study of human perspectives on how autonomous vehicles should behave in the event of an unavoidable collision, respondents regularly indicate the vehicle should be programmed to spare child passengers or pedestrians over adults.[i] 

However, the medical device marketplace for children does not reflect these values. There are far fewer pediatric devices than adult devices on the market, meaning one of the most vulnerable patient populations also is one of the most underserved. 

In many instances, this reality forces pediatric specialists to find alternative uses for adult devices to treat their patients. One example is a pediatric cardiologist using an adult biliary stent off-label to treat a four-year-old patient with congenital heart disease.[ii] A device designed specifically for that application would, of course, be preferable, but pediatric specialists have to make do, even if the available devices were approved by the FDA to treat a different condition in an adult population.

While devices designed for adults often are repurposed and adapted to treat children out of necessity, this off-label model comes with significant disadvantages. Adult devices often are ill-fitting in pediatric applications and, while physicians follow best practices, consult available literature, and take precautions to protect their patients, the safety and efficacy of devices used off-label has not been established through normal regulatory processes. Innovation or even design iteration of off-label devices is limited, as convincing investors to support a novel device with no regulatory or reimbursement pathway is challenging, to say the least.

Obstacles to Development, Testing, Regulatory Approval, And Reimbursement

The challenges of developing devices specifically for children are primarily market-driven. Objectively, we may believe children deserve access to the best and latest healthcare technologies, but the patient population of children with a particular condition (i.e., the market size) is comparatively small. This is not to say that viable business models do not exist for small medical intervention markets; certainly, compelling value propositions have been developed and come to fruition in orphan drugs.[iii] How to stimulate such an innovation and discovery storm in small medical device markets is an ongoing debate.[iv]

In addition to market challenges, some pediatric device concepts present unique technical challenges that can slow the development, testing, and approval process. A child may depend on a device to perform for a much longer time than an adult patient, and under different — often more active — conditions. A child’s growth also may pose a problem for the device’s function over time, especially an implantable device. Materials may be required that can stretch or be absorbed by the body, but this may not always be possible. Once implanted, a device’s performance may need to be monitored for years before its long-term safety and efficacy can be documented.

These challenges can make it difficult to offset the costs of developing, testing, obtaining regulatory approval for, manufacturing, marketing, and distributing new pediatric devices. Devices for larger adult patient populations typically are more appealing — especially to an institutional investor with a fiduciary duty to its clients — since they offer lower risk and promise higher return due to market size and time-to-market factors.

The good news is that a number of trends are emerging, and initiatives are underway within the industry and at FDA, that focus on enabling pediatric device innovation and smoothing some of the bumps in the road to market.

Pediatric Device Consortia

To help spur innovation in the pediatric device space, the FDA started the Pediatric Device Consortia Grants Program in 2009, with several pediatric device consortia spawned around the United States. In Fiscal Year 2018, the program funded five nonprofit consortia around the U.S. with grants of $6 million (up from $3.6 million in FY2013).

The consortia function in unique ways suited to the approach and capabilities of each member, but also share common characteristics. The first is a common mission to bring new pediatric devices to market to address unmet clinical need. The method to achieve that mission varies by consortium but, in general, each consortium a) oversees disbursement of seed funds to device innovators through an open competition, and b) provides expert advisement and in-kind services to assist innovators along the commercialization pathway.

Such advisement and services include assistance with clinical trials, regulatory strategy, value proposition validation, grant-writing, prototyping, and testing.  Each consortium is made up of industry and medical experts, who evaluate the merits of individual proposed projects and assist with decisions and commercialization.

Real-World Evidence (RWE)

As we collect, store, and analyze more data through the healthcare chain, the use of real-world evidence —“information on health care that is derived from multiple sources outside typical clinical research settings, including electronic health records…and data gathered through personal devices and health applications.”[v] — is gaining momentum throughout the device industry, which could pave the way for additional, faster approvals of devices intended for pediatric populations and indications, as well as inform innovators designing new pediatric devices and device trials.    

Both the FDA and industry players see the promise of these initiatives. In the past three years, FDA has issued two guidance documents on RWE[vi] and its applications to pediatric devices.[vii] RWE also was the theme of the 2018 Pediatric Device Innovation Symposium, hosted by the Children’s National Sheikh Zayed Institute for Pediatric Surgical Innovation.

Though the use of RWE comes with its own challenges (e.g., conformance to data quality, reliability, and privacy standards), the RWE initiative holds promise for pediatric device and drug developers as we explore more ways to collect and use healthcare data to inform clinical and regulatory practices.

Humanitarian Device Exemption

Similar in many ways to the FDA Orphan Drug program, the Humanitarian Device Exemption (HDE) provides a shorter regulatory pathway for devices intended to treat rare diseases or conditions (8,000 or fewer cases per year in the U.S.). This program exempts devices from certain effectiveness (but not safety) evidence requirements of the FD&C Act.

While there exist limitations to this program, HDE still provides a way to bring devices to market for very small (often pediatric) patient populations that would otherwise be commercially unviable. 

Additive Manufacturing / 3D Printing

Additive manufacturing (AM), more commonly known as 3D printing, is changing the way medical devices are produced within and beyond the pediatric sector. Rather than maintaining an inventory of devices in every possible permutation of size and shape, manufacturers and hospitals can invest in on-demand manufacturing.[viii]

Using 3D printers, devices can be produced in a growing number of materials, at comparatively low cost, and in very small quantities. Devices even can be customized to a particular patient (i.e., “patient-matched devices”), which can be especially helpful in applications like prostheses, where needs vary greatly between patients and change rapidly as a child grows. 

According to FDA guidance issued in late 2017, “AM has the advantage of facilitating the creation of anatomically-matched devices,” as well as facilitating the creation of device structures “that would not be easily possible using traditional (non-additive) manufacturing approaches.”

That said, the newness of AM-produced devices, and their lack of clinical history, introduce certain unknowns into the highly controlled process of device manufacturing. Specifically, the FDA’s 2017 guidance notes that the “innovative potential of AM may introduce variability into the manufacturing process that would not be present when using other manufacturing techniques.”[ix]


Though advances are being made, many of the initiatives above are in their infancies, with much more progress needed before we can declare them successful. Solving the problems of pediatric device commercialization will take more great ideas and initiatives than those discussed above. We need clinicians, engineers, entrepreneurs, impact investors, regulators, and legislators working in concert to build on our progress in this area. All of these players, and others, must come together to develop creative solutions to overcome the market challenges that derail so many promising pediatric device projects in today’s environment.

This article is based on a Archimedic podcast interview between Matthew Maltese and Daniel Henrich about pediatric device innovation; you can listen to the conversation here.

About the Authors

Matthew R. Maltese is the Founding Executive Director of the Pennsylvania Pediatric Medical Device Consortium, where he works to support early stage pediatric device teams as they progress towards commercialization. He is also Chief Innovation Officer at X-Biomedical, a medtech startup.

Daniel Henrich is Director of Marketing at Archimedic (formerly Smithwise), where he works to educate industry members about medical product development and how Archimedic can help their organizations advance healthcare through breakthrough medical technologies.

About The Pennsylvania Pediatric Medical Device Consortium

The Pennsylvania (formerly Philadelphia) Pediatric Medical Device Consortium connects Children’s Hospital of Philadelphia (CHOP) with the McGowan Institute for Regenerative Medicine and sciVelo, both based at the University of Pittsburgh. This new partnership comes on the heels of a five-year, $5 million grant renewal from the Consortium’s sponsor, the U.S. Food and Drug Administration. The mission of the PPDC is to support the development and commercialization of promising medical devices that address unmet clinical needs in children.

Written by Daniel Henrich

Written by Daniel Henrich

Director of Marketing at Archimedic

Overcoming Pediatric Device Innovation Challenges

EPISODE 7 – Overcoming Pediatric Device Innovation Challenges

In this episode, Matthew Maltese, Executive Director of the PA Pediatric Medical Device Consortium covers why it can be so hard to bring devices to market for kids and what we can do to help fix that. 

Matt and Dan discuss:

  • Current barrier to pediatric device innovation
  • How pediatric specialists operate without pediatric devices
  • Risk/Benefit rationale for small patient populations
  • Current industry and FDA initiatives to bring more devices to market for kids

Please note: We reference the Biodesign textbook in our conversation as a great resource. It’s available for purchase on Amazon here

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

Episode Transcript

Dan Henrich:     Hey, Matt.

Matthew Maltese:          Hey.

Dan Henrich:     Thanks so much for being our guest today. I’m really glad to have the opportunity to talk with you about pediatric devices and how we bring devices to market for small patient populations. I think you and I met for the first time last year at Children’s Hospital of Philadelphia at an event for FDA reviewers-

Matthew Maltese:          That’s right.

Dan Henrich:     … To understand what are some of the challenges for pediatric devices coming to market. I wanted to maybe take some elements of that event and those conversations and package them into an interview between us for our listeners, who may not be familiar with those challenges. Can you tell our listeners a little bit about why is it so difficult sometimes to bring pediatric devices to market and why are they different from devices for adults?

Matthew Maltese:          The challenge with pediatrics is that there are technical challenges associated with it. The growth of a child throughout the intended use of a device can be challenging, particularly for implantable devices. You can imagine a heart valve, for example. There’s wonderful unmet need potential for anyone who can develop a heart valve that’ll grow with the aorta or the other great vessel that the valve needs to go in.

Matthew Maltese:          There are those technical challenges, but then there are simply financial challenges. I’ve given talks around the country on medical devices and kids, and I will often ask the audience. I’ll ask them, “How many of you have parents?” And everybody puts their hand up, right? Everybody’s got a mom or a dad, or a mom and a dad. Then I ask, “How many of you have children?” A smaller subset of the group will put their hands up. Then I ask, “Okay, for everyone who has both parents and a child or children, if you had a choice to develop a medical device or other therapy or pharmaceutical that would save the life of your parent or save the life of your kid, who would you pick?” Uniformly, who would they pick, Dan?

Dan Henrich:     I’d pick my kid.

Matthew Maltese:          You’d pick your kid.

Dan Henrich:     Sorry, Dad.

Matthew Maltese:          Everybody picks their kid. Your dad would pick your kid too. Everyone uniformly chooses their kid. However, as a society, it doesn’t always work that way. In fact, it rarely works that way. We know that the marketplace for adult products, particularly, you take orthopedic products for the hip and the knee and elsewhere, there’s so much volume there. So many cases and so many devices to be sold that that’s where much of the attention goes.

Matthew Maltese:          It can be just very difficult to draw attention to the kids, because the populations, as you put in your opening remarks, are small, meaning there are few in the population in addition to be individuals in the population being small, physically small. That there are few in the population and so there can be challenges because the upside from a capitalist perspective is not as big. However, there’s still an upside. I think that’s there’s still an upside in most devices for kids.

Dan Henrich:     Are there VC firms or angel investors who specialize, then, in small population or pediatric devices?

Matthew Maltese:          There are. There are some firms that have, I guess, identified that this is something that they are interested in. More often than not, it’s individuals. You mentioned VC, so if we think about the stages of investing, the early round, the seed round, where individuals are involved who have enough financial resource to get something off the ground and enough business sense to identify a business opportunity, that’s where you’re most likely to find traditional investment, a willingness for traditional investors to get involved.

Matthew Maltese:          Venture capitalists, in the strictest term, are often spending somebody else’s money. They can’t really allow, just by their duty, they can’t allow these emotional matters to come into play, unless it’s part of their stated mission of their fund. Just as an aside, I’ve been working in this field for quite some time, and I’m impressed to find many, many individuals who have the means to invest and have some sort of connection to pediatrics. Maybe a child who was a pediatric patient or a sibling or a child who is a pediatric medical provider of some sort, and they are touched personally by this and therefore are willing to invest in some way.

Dan Henrich:     Given, then, the fact that there are many fewer options for a pediatric specialist when it comes to treating their patients, what does a pediatric cardiologist or a surgeon or anesthesiologist, how does he or she navigate that in terms of treating their patients with the devices available?

Matthew Maltese:          I once asked, I wanted to find out in my own hospital, the off-label use of medical devices. Of course, off-label means it’s outside the range of the FDA approved range for the device to be marketed. The uniform response was it was easier for my clinician colleagues at the time to make a list of the devices that are used on-label. That was the response almost uniformly. That’s how they do it. They patch, they cut, they modify when the pediatric specific device is not available.

Matthew Maltese:          That said, there are examples of pediatric devices coming to market even now. Where manufacturers who are being good citizens or recognizing market potential or a little bit of both or mission driven and can make something work financially, they will make their products, they will modify their products for the pediatric space.

Dan Henrich:     So, then, pediatric specialists, many of them are forced to sort of become device innovators on the fly, it sounds like. So I understand correctly and our audience understands correctly, if you have an off-label use, what that means is that the FDA has approved the device for certain types of use that are on the label. The manufacturer may not market it for anything but on-label use, but physicians can innovate where necessary to treat their patients using, basically, an unapproved use for a device that’s on the market. Is that right?

Matthew Maltese:          That is exactly right. A great example is cardiac stenting in pediatrics, where most of the pediatric stents are biliary stents from the adult market used off-label.

Dan Henrich:     How do physicians begin to appreciate whether a particular off-label use is an acceptable level of risk, then?

Matthew Maltese:          Oh. You know, I’d have to say that I’m completely unqualified to answer that question.

Dan Henrich:     That’s okay.

Matthew Maltese:          I wouldn’t answer that question. I think [crosstalk 00:09:27].

Dan Henrich:     We can cut it out.

Matthew Maltese:          You’d have to talk to a physician, but also, it’s going to vary from physician to physician and by the risk of the nature of the device.

Dan Henrich:     If we think about the fact that I’m sure FDA recognizes that it is ultimately, in the long run, better for the patient to have a device that’s gone through that learning process of is it acceptable risk benefit ratio for use in pediatric population through a regulatory pathway and through clinical trials, versus physicians who are doing what they need to do to treat their patients with the devices that they have. Is there anything going on at the agency to try to make that traditional pathway to get devices approved easier or less expensive or faster?

Matthew Maltese:          That’s a great question. There’s a new word out there, a new phrase. It’s called, quote, the New FDA. There really is a difference between the FDA of only five or 10 years ago and the FDA we see now. I think the things that I’ve observed myself and heard from others is much more collaborative, particularly at the pre-sub phase. Much faster. I think it’s been well documented that they can turn around approval evaluations much faster than they have in the past. It used to be that the standard was to go to Europe and get the CE Mark and then come back to the States for the FDA approval.

Dan Henrich:     For pediatric devices specifically or for devices in general?

Matthew Maltese:          In general. Very recently, I ran into a company from Norway working on a cardiac product for peds, incidentally, that was coming to the US first, because they just viewed it as a faster pathway. I think that there are great reasons to be very optimistic about all medical device development in the US market. That just extends to pediatrics. Let me just extend that a little further and say that there are specific people in the FDA and programs like the Pediatric Device Consortium program and other programs that are really designed to foster devices for kids, so there’s even extra reason to do kids first in your device idea.

Dan Henrich:     Can you tell me a little bit about the consortia? I know that you’re director, is that right, of the Pennsylvania Pediatric Device Consortium?

Matthew Maltese:          That’s right.

Dan Henrich:     Can you tell me about what those organizations are and what their mission is and how they work?

Matthew Maltese:          I can speak for our own organization, but I think in general the mission is to bring pediatric medical devices to market, period. That is the mission. As our consortium, the Pennsylvania Pediatric Medieval Device Consortium, we don’t care where they come from. They don’t have to come from the Philadelphia region, even though we’re branded Philadelphia, Pennsylvania. In fact, most of our devices that we’ve worked on come from outside of our region. We always just sought the best devices for kids and provided them with modest funding but hopefully better in kind resources to help them move their products to a point where they can get further funding and eventually make it to market.

Dan Henrich:     How many consortia are there?

Matthew Maltese:          There are five total in the United States, including ours in Pennsylvania.

Dan Henrich:     What about other initiatives at the agency? I know there’s a program called Humanitarian Device Exemptions. I know there’s a lot to talk about how real world evidence may be able to inform the approval process for new pediatric devices and making off-label uses on-label.

Matthew Maltese:          I could tell you what I’ve observed. I can also point you to someone at the FDA who might be willing to talk to you and can speak more, just has more knowledge on what all the FDA offers. A good example, though not pediatric specific, but I think something that will benefit pediatrics in a very big way is additive manufacturing, also known as 3D printing. The FDA has put a tremendous amount of effort into just understanding how additive manufacturing plays into the medical device market, because much of the value propositions for pediatric or other small volume populations pivots on the volume. For example, if you have to make something out of a polymer and injection molding is your manufacturing method, the molds alone can be tens of thousands of dollars.

Dan Henrich:     And depending on the size of the patient, you may need how many different sizes, right?

Matthew Maltese:          How many different sizes? Maybe only a handful per hospital per year or per month, but you still need them. 3D printing offers the great opportunity of being able to manufacture in very small lots. You can even envision the concept of a vending machine, if you will, that produces and sterilizes and packages a custom-sized medical device from raw materials and sits either at a centralized location close to several regional small population hospitals, or even in the hospital itself. So there are, I think, tremendous opportunities in additive manufacturing. That’s just one area that the FDA is working in, and there are many others, many others.

Dan Henrich:     What about all the talk around real world evidence? I know that in September, I think it was, you and I were both at a symposium that Children’s National hosted in Philly talking about real world evidence.

Matthew Maltese:          Say it 10 times fast.

Dan Henrich:     And how it may be able to inform and accelerate the device approval process for pediatric devices. Can you explain, what is real world evidence and how it might be able to …

Matthew Maltese:          Sure. Real world evidence is exactly what the name implies. It’s evidence or data or information that is gathered from real world experiences. To contrast what perhaps that means is real world is not the experimental world, like we might do on a bench top or with an animal in a laboratory, or real world is not what we might do in Insilico on a computer with various simulation packages that are available for simulating the laws of physics virtually. Real world is real world. Real patients experiencing real medical procedures with medical devices and all the other therapies that surround it.

Matthew Maltese:          I think what has really launched this is the electronic health record and the potential for connecting devices and in some cases the rich information that the device collects. You think about cardiac pacing now, where each device not only paces the heart but collects information at the same time. And connecting that back to the patient health record, which is then integrated into everything that that patient has experienced from a medical perspective throughout their course of care. That has great promise. I think, frankly, it’s something that we’re going to look back on and we’re going to be able to define much better years from now than we can define it right now, but the potential is great.

Dan Henrich:     Is the main appeal of that, then, that you already have these devices that pediatric surgeons and cardiologists and others, they’re designed for adults, they’re being used for children, and if we can collect that data on the off-label use, then perhaps we can use that data in lieu of or to make a clinical trial to get an on-label use approved?

Matthew Maltese:          That is one example.

Dan Henrich:     What about actually developing new pediatric devices, then? How would real world evidence inform that?

Matthew Maltese:          Well, I think the development of a brand new device that is being used for the first time will follow the traditional pathway of real world evidence generation, which is the clinical trial. That has been in place and will always be in place. The things that I talked about with regard to the electronic health record will presumably make those clinical trials easier or more informative or both.

Matthew Maltese:          There might be a way for this enhanced medical records to improve epidemiological understanding of disease in ways that reveal more information about unmet needs, and then spawns the development of new devices. I remain convinced that the best way to discover unmet needs is for innovators to be involved in the practice of medicine or close to the practice of medicine. That can be, for a practitioner, practicing medicine and, for an innovator who’s not a practitioner, being close to a practitioner who is practicing medicine and physically in the room when it’s happening so that they can observe what’s going on from a holistic perspective. And spending time with the patient, and spending time with the payer so that they understand fully what the unmet need is and how to intervene.

Dan Henrich:     So, then, could real world evidence uncover potentially larger markets than appreciated and mean that the traditional pathway to device approval is more viable for investors? Is that kind of the thinking behind that?

Matthew Maltese:          Most certainly. I think when investors, or I should say, when medical device innovators or even those who are working within large medical device companies who wouldn’t really consider themselves innovators, but maybe advocates for certain types of technology being developed within those companies, can look to real world evidence to help them justify to their own management a particular direction or course that they have to take.

Dan Henrich:     Something else I wanted to ask you about, this is a little bit of an ethical quagmire, but there is an ethical discussion going on when it comes to children and other vulnerable patient populations. There’s one side of the argument might say, really, we need lower regulatory barriers and less scrutiny for these devices because there’s such an unmet need that having something is better than having nothing, even if there’s a greater amount of risk. Whereas on the other side, and both sides of this argument are very understandable, I think, people say, no, since we have children who are not making these decisions themselves, they are unable to appreciate the risk, we actually need greater scrutiny, greater regulatory thresholds for safety and perhaps efficacy than we do for adult …

Matthew Maltese:          Great question. Maybe just a short story before I answer that kind of shook me at the time. It really brought reality to how I thought about my role in the world. When I was young and starting in the field, I was at an FDA meeting where we were discussing medical devices and medical devices for kids and the various medical and scientific aspects of it, and we were talking statistics and p-values. The kind of thing that makes geeks just drool at the mouth.

Matthew Maltese:          It was a public meeting, and a parent stood up and went to the microphone and said, “I have two kids, and they both have the same rare genetic condition. One of them has died, and the other one, who is two years younger than the one that just died, is going to die. We need to just take action. We need to do something, because their death sentence is already written.” I remember it very, very clearly.

Matthew Maltese:          I think that stuck with a lot of people in the room, and that situation that I just described, I think, has been rehearsed many times with FDA regulators who have had the challenge of trying to field that sort of a plea from the public, a plea from a parent who’s going to lose their child. No matter what, inaction means my child dies. And try to reconcile that with the law. It’s very challenging.

Matthew Maltese:          Fast forward to just about a year ago, I was at a conference where the concept of patient preference was being merged with statistics of efficacy. What a patient defined as risky is maybe completely different than what the p-value, if you will, which is a measure of statistical significance and it can be used to determine if one course is more risky than another course. How to merge those things together.

Matthew Maltese:          In kids, it’s a bigger challenge, because many of them just simply can’t talk, and then those who can talk, they really may not be able to … They certainly can’t express themselves in a legally binding sort of way. You can’t enter into a contract with a minor. So the parent has to be in place. But there is a template here for getting patient preference from kids. When we do any kind of medical study, research on kids, it doesn’t necessarily have to be medical research, we have to pass through the institutional review boards. If a kid, depending on where it’s being done and how the local IRB panel has determined, there’s an age of assent, which is a child can’t give consent, but they can give assent. They can say, “Yes, I want to participate,” or, “No, I do not want to participate.” Then the parental consent is of course what decides.

Matthew Maltese:          That’s an evolving space as well, where it’s clearly been determined that there is not a one size fits all measure of risk. It depends on the population, it depends on the disease, it depends on the intervention that’s proposed. And most importantly, it depends on the preferences of the patient as to the type of life that they want to live with or without the intervention.

Dan Henrich:     I would imagine that conversation is very different depending on whether you’re talking about a life threatening situation or a condition which might mean paralysis or some other type of very debilitating, ongoing condition, versus something that we wouldn’t call it elective in the adult care setting, but something where the consequences are much less significant. How is the idea of this risk to benefit ratio evaluated? Should the conversation in more dire situations really be about not risk first versus benefit, but benefit versus risk? Does that make sense? Which of those things should be prioritized in the more dire situations, I guess?

Matthew Maltese:          I don’t know. It really depends. It really depends. I think there are people more qualified than I to comment on the situation. I’m an engineer. I’m responsible for building the intervention. I always have to keep in mind the ethics of it. Having the right people in the room when those decisions are being made, the clinical care team, the parents, the child, the patient. That’s really critical, and that’s where the decision has to be made. That’s at the point of care.

Matthew Maltese:          Taking a step back to the point of FDA approval, I think it’s the same sort of template. You have to have a panel that represents the clinicians who are experts in the field. You have to have somebody who understands the regulatory pieces and what the statutes and the law say. Then you have to have the patient, and in the case of kids, the patients and their parents, a panel of them or a body of them, who are collectively speaking about these critical issues. Of, “I see what the mathematical risk is, but this is what it means to my life.”

Dan Henrich:     When do humanitarian device exemptions come into play in those types of situations? Can you talk a little bit about what an HDE is and what type of situation the FDA might grant?

Matthew Maltese:          I don’t have a lot of personal experience with them. There’s a certain threshold in terms of patient population, that if it’s below that threshold then an HDE kicks in. But still, it’s a challenging pathway to go through. If you really want to talk to somebody about that, you’ve got to talk to somebody like Seth Goldenberg or somebody like that. He could describe very well the ins and outs and advantages of all the various pathways. It’s a matter of debate, too, ongoing debate between the industry and the FDA as to what those thresholds, in terms of patient population, should be set at.

Dan Henrich:     I hope we’ve done a good job of framing for our listeners what is this environment and what are the different struggles and trade-offs that innovators are dealing with when they’re trying to develop new devices for kids. You’ve mentioned a couple times how important it is to have clinicians either innovating themselves or to be very closely tied to the team that is developing this product. It would be interesting for me to understand better, how does a clinician who’s practicing medicine full time, most of them got into that for a very specific reason and they want to be, whatever their hours are, not 9:00 to 5:00, probably. They want to be every day hands-on helping kids and their families. What’s the model for a clinician innovator who, maybe, is using a device off-label for years and developing their technique and really seeing, in a way that no one else can, the potential for a pediatric device innovation? What’s the model that you’ve seen be successful for bringing that idea to market?

Matthew Maltese:          Let me walk back my earlier statement about clinician innovator. There are certainly great examples of clinician innovators, but maybe introduce a new concept called a clinician needs finder and decouple that you have to innovate and find the need at the same time. You could very systematically, as a clinician, spend time just understanding the need and recruiting others who may join you in the innovation process, the solution process downstream, but at the moment that you recruit them, you’re in the needs finding space of just trying to figure out, what is the problem? Because there are scores of devices and other so-called great ideas that die downstream because the upstream unmet need was either not there or not well defined. Spending a long time on understanding the problem and understanding the unmet need is always warranted. You heard it here first, folks. Clinician needs finder. It’s a new person. It’s a new title. The next part of your question was, how does a clinician innovator go about innovating?

Dan Henrich:     Well, what’s the model you’ve seen be successful in your experience or even, maybe, now I want to refine my question now that you’ve said that. You’ve spent a lot of time working in an environment with pediatric specialists. They’re aware of these needs. What’s the mechanism for collecting all those needs at a big research institution? Is there a method, does it vary from institution to institution? Or is it on the clinician to go to the biomechanics research department or whatever it is and say, “Hey, I have this problem. Can you help me solve it?” Or is there a mechanism for collecting those needs?

Matthew Maltese:          I think that there is not a mechanism, at least in my observance at multiple institutions. There are a few spots that do it well. The Stanford Biodesign program I think is excellent, and Cincinnati has a great program, and others too. I think that, for the most part, the clinician needs finder is not a frequently observed phenomenon. It’s mostly the clinician innovator, who hopefully starts out as a clinician needs finder and then blossoms as an innovator.

Matthew Maltese:          I’ve also found that clinicians are, in many cases, pretty good engineers. There’s a little engineer inside every clinician, and perhaps there’s a little clinician inside of every engineer. What I’ve experienced, it’s not the rule of law. It’s not how the universe must work. It just seems to be how the universe has worked that I’ve observed, if you will. I think some things that I’ve observed that I think are positive is that there’s now a trend where clinician innovator is an academic path. Do you understand what I’m saying?

Dan Henrich:     Mm-hmm (affirmative).

Matthew Maltese:          Just to give a contrasting example, at my own institution, the master of science in clinical epidemiology was a common degree, master’s degree, that was sought by clinicians following med school. There’s an emerging pathway of clinical innovator, almost like an equivalent to that, that is now gaining recognition in the academic setting. I think the more that that happens, the more that the traditional professional promotion standards and pathways recognize innovation as a legitimate academic pursuit, that we’re going to see a lot more clinician innovators come to be. Some are starting it in med school. I can’t imagine that, myself. I can’t-

Dan Henrich:     How you could juggle those things, right?

Matthew Maltese:          Yes. If I could think of a time when someone doesn’t have any spare time, it would be medical school. What I’ve learned is that there are times in medical school, particular years, that clinicians in training have time and choose to invest their time in innovation. Then they maybe step away from it while they go through the more intense portions, and then they return back to it as they move on in their career. I think, as I talked about the FDA and the future being bright there, I’m also very optimistic about innovation being a more intricate part of academic medicine and people’s careers as faculty and med schools.

Dan Henrich:     Putting aside the need for more clinician needs finders, maybe we’re going to call them that, not necessarily clinician innovators, but what is the path that you have seen for a device to move from an idea that a clinician has or a need that a clinician has and an innovator who has a potential solution, to getting the funding to go through regulatory approval and get, eventually, matched up with a manufacturer or whatever that might be?

Matthew Maltese:          Persistence on the part of the innovator. I think that’s the one thing, persistence. Less brilliance, more persistence. Maybe this is just because it’s fresh on the brain, but I’ve had two instances where people I had met several years ago who just asked me for advice on an idea, and I threw some significant cold water on their idea for legitimate reasons, I think, and legitimate reasons that they admitted too. They’re back. They’re back three years later, and they’ve adjusted, they’ve adapted, they’re still working on the same problem, but they’ve reinvented. Reinvented, if you will. They’ve adjusted. They’ve kept going. That willingness to persist is, I think, the biggest thing that is the biggest factor. It’s good news that people who go to spend a long time in school, who recognize that your final end point and final diploma granting point is many years away, they tend to be persistent people anyway. It’s a good cohort to be drawing from.

Matthew Maltese:          I think the second thing is, of course, don’t be hung up on your solution, because when you do that, you actually narrow the potential solutions to the problem. This is why, I think, separating needs finding and solution generation needs to be two separate things, because if you’re a hammer, everything looks like a nail. If you come in thinking that I’m going to solve this problem by a new type of stent, everything that you do for this particular problem will be a stent, when it could be something else completely different that actually solves the problem, that’s part of the stenting process, but maybe a just completely different solution.

Dan Henrich:     This sounds like something I’ve read in that Biodesign book you have on your desk there.

Matthew Maltese:          We keep it right at the hand, right at ready.

Dan Henrich:     We’ll have to put a link to that when we post this on our blog.

Matthew Maltese:          I would, I would. Biodesign is not rocket science, it really isn’t, but it’s a great book and a great framework that the group at Stanford has put together. It’s really critical to read it and read it fully and rethink how you approach medtech innovation through it.

Dan Henrich:     Let’s talk about a clinician innovator team, we’ll call it, they’ve gone through the initial steps of the process by that book. They have a clearly defined needs statement, and they have evaluated different solutions and settled on a particular pathway for good reason. We often at Smithwise, in our early interactions, we may deal with an innovator who has an idea and a patent or is working on filing their patent, and the model in their minds is, get a patent, get a prototype, and then Johnson & Johnson or some other really big device manufacturer is going to buy this from me, and that’s going to be my exit strategy. That’s almost never what we actually see.

Dan Henrich:     I guess particularly within the pediatric realm where there’s all these other challenges, as well, to gathering funding, what advice would you give to a team in that situation, that has what you would call a very legitimate solution to a very real problem, but there’s a long way to go before their device is going to be snapped up by a manufacturer?

Matthew Maltese:          First of all, I agree with your assessment. It often seems like the inventor may have a tendency to overvalue the idea, whereas the investor or the eventual acquirer, which may be one of these large device manufacturers, they value the proof. If you’re steeped in academia, this is the equivalent in academia. If you have a theory for how a particular disease mechanism, let’s say you have a theory, and you publish the theory. That’s basically worthless. It’s your idea, it’s your opinion. Not proven. It’s not until you take it into the laboratory or take it into the clinic or do some other empirical study to show, or not show, that your theory is right. A patent is like a theory, and it’s not a theory about whether the thing will work. It’s a theory about whether the market will accept it and buy it. It’s a theory as to whether your idea will add value to someone else’s life downstream. The second part of your question was?

Dan Henrich:     What advice would you, perhaps have you given, to a team that has a really good theory and really good evidence to suggest that it’s technically viable, they still need to attract investors, they still need to prove that value to the market? What advice would you give them?

Matthew Maltese:          I think, first of all, just recognize that, as I said earlier, the idea is just an idea. There are several stages that you can go through to increase the value of your idea. I don’t mean to say value in the sense of how much money it’s worth. That’s not what I mean. I mean in the sense of how viable is your product in making a difference in a patient’s life. The confidence, if you will, that X years from now, your idea will blossom into something that can make a difference.

Matthew Maltese:          If you have an idea and you’ve built a prototype and you’ve tried it out on a bench, on a phantom, or a surrogate for a human, you’ve proven the concept. Okay, so now you’ve notched up the likelihood a little bit that your idea will have some impact on somebody’s life downstream. Then, you figure out your regulatory pathway and you start down the pathway. By regulatory pathway, I mean, of course, what is the FDA going to want you to do before you can be cleared to sell the product? It’s an animal test, let’s say, or it’s a test on a human and so forth. Each one of these things is a milestone and is a risk reducer, if you will.

Matthew Maltese:          Then once you have your FDA clearance, you’re still not done, because you have to show to the potential acquirer that there is a market for the product. You have to go out and, in a very traditional door-to-door sort of way, sell it. Sell it. Then people who buy it may find that it has value or they may find that it doesn’t have value. The acquirer is looking for those initial indicators.

Matthew Maltese:          Now, there are no hard and fast rules as to when an acquirer will flip the switch and decide to take your device on and proliferate it across the world to benefit the lives of millions. It depends on the device, it depends on the idea. With some ideas and in some financial climates, something might be picked up very, very early in the process. In other climates or with other ideas, the acquirer is going to want more evidence. The short answer is, it depends. I’m sorry.

Dan Henrich:     No problem.

Matthew Maltese:          That’s reality, it depends.

Dan Henrich:     I think that’s a fitting piece of advice in this environment. If it were easy, it would be done by now. Matt, I really want to thank you for taking the time to talk with us about this. I think those of us who are within the industry really see a lot of promise for things changing and developing with regard to pediatric devices and helping underserved populations. I want to thank you for the role you’ve played in that and continue to play.

Matthew Maltese:          Thank you, Dan. Thank you for focusing on pediatrics. It is who is most important to us, and so I’m glad that you and Smithwise are making this part of who you are.

Dan Henrich:     It’s our pleasure. It’s been a good journey.

Matthew Maltese:          Thank you.

Written by Daniel Henrich

Written by Daniel Henrich

Director of Marketing at Archimedic

Innovation Hurdles: Why Pediatric Devices Don’t Make it to Market

Photo Above: Session speakers (from L to R) Dr. Richard S. Davidson (CHOP), Greg Walters (Essential Medical), Adam Dakin (Dreamit Ventures), Matthew Maltese, Ph.D. (CHOP), and Eric Sugalski (Archimedic)

Runaway Train

Imagine there’s a runaway train barreling down the track toward four innocent people. You sit in the railway control room, your hand on the switch that would divert it down an alternate track where it will kill one person instead. Do you flip that switch? This was the question posed last Friday by Matthew Malteseto his audience. With nodding heads and hands raised slowly off their tables, most audience members seemed to agree reluctantly that sacrificing one person to save four others was the ethical choice in this situation. “Alright,” Maltese said as he looked around the room and saw consensus forming, “but how about now?” On the screen behind him, a photo of a little girl had appeared, replacing the faceless silhouette of the single victim the audience had just agreed to sacrifice for the greater good. Not a single hand remained raised.

Maltese was speaking to FDA representatives meeting for the day at Children’s Hospital of Philadelphia, where he serves as Director of Biomechanics Research. The room full of government regulators and reviewers were in Philadelphia for a course on pediatric orthopedic medical devices, visiting CHOP to learn about the clinical and regulatory factors that contribute to the current standard of care for children.

Course attendees heard from pediatric surgeons and practitioners, as well as other professionals working throughout the healthcare chain to bring the devices to market that will help children suffering from spinal deformities such as scoliosis.

Maltese’s session was a panel discussion titled “Capital Investments in Pediatric Device Development.” The panel included a pediatric surgeon, the CEO of a medical device company, a venture capitalist, and the president of a device engineering firm. These four panelists expounded for the audience the particular challenges pediatric devices face in their path to market.

Challenges in Pediatric Device Funding

Maltese also heads up the Philadelphia Regional Pediatric Medical Device Consortium, an FDA-funded organization working with players in the Philly healthcare hub to bring critically-needed pediatric devices to market. He opened this session with the train analogy to ensure that his audience was aware of the jarring realities that exist in the field of pediatric device development. In short, due to the respective sizes of the patient populations, it’s much easier to obtain the resources needed to bring a device to market for adult patients than for children. While it’s easy to say in general that researchers and investors should focus their resources on the devices that will bring the greatest good to the greatest number of patients, the calculus shifts in the minds of most when they consider one of the most vulnerable, and yet underserved, patient populations–children.

The skilled hands of orthopedic pediatric surgeon Dr. Susan Nelson (Univ. of Rochester Medical Center) guide those of an FDA representative as he places his first spinal screw on a synthetic model during a session break.

 Adam Dakin, Managing Director of HealthTech at Philly-based Dreamit Ventures, sat on the panel and emphasized the main challenge pediatric devices face in their initial review by investors. The first question, Dakin told the audience, is always “what’s the market size?”

Another industry member on the panel was Eric Sugalski, founder and president of Archimedic, a medical device engineering firm with offices in Philadelphia and Boston. Sugalski, an engineer and entrepreneur, explained that pediatric devices are often successful in obtaining their early seed round funding, perhaps in the neighborhood of $200-$500K. This initial investment helps the device clear early design and intellectual property hurdles, bringing a promising concept to the stage of a working prototype.

Most devices come to the U.S. market through the 510(k) Premarket Notification regulatory pathway, which depends on the ability to demonstrate that the device being reviewed is “substantially equivalent” to an already-approved “predicate” device with regard to safety and efficacy. Pediatric devices, however, often have no established predicates. In this case, a device must go instead through the Premarket Authorization (PMA) channel, requiring extensive clinical data to be generated, compiled, and analyzed.

 Todd Lexer of NuVasive demonstrates the MAGEC® system to course attendees during a session break, designed to reduce the number of surgeries needed to treat early-onset scoliosis in children.

This stage, Sugalski said, is where pediatric devices often hit a wall. Series A investments, “which can cross the eight-figure threshold,” typically fund the clinical trials needed to demonstrate safety and efficacy. However, investors are unlikely to shell out ten million dollars when market opportunity is limited by a small patient population.

This limited market opportunity puts an even greater-than-usual pressure on the device development timeline. Time to market is a critical component of the viability of any investment so, if regulatory review times and clinical trials can’t be compressed, an otherwise promising pediatric device may get left on the scrap heap.

Progress, But a Long Way to Go

The panel praised FDA for improvements made by the agency in recent years in fostering a more collaborative environment when working with innovators. “The interactive nature of the agency lately has been fantastic,” said Greg Walters, CEO of Essential Medical, a device startup based in Philadelphia. But, he added, FDA representatives should understand that time in regulatory review can quickly cut into and compromise the feasibility of a particular project, so it’s essential to be as efficient as possible in getting over that hurdle.

Dakin agreed with Walters that the relationship dynamic between the agency and innovators has improved. Early in my career, he explained, I would have described the process as “doing battle with FDA.” Now, reviewers are working to bring investors to the table in a spirit of increasing collaboration. Still, he emphasized to his audience, we as entrepreneurs can “live or die by one letter or FDA action,” so it’s important for agency representatives to understand the business constraints that determine whether a device ultimately makes it to market.

In order to better serve pediatric patients and bring them treatments that can improve or even save their lives, the panelists emphasized that regulators must continue to look for ways to reduce barriers to commercialization while safeguarding patient safety. Panelists pointed out that FDA has helped in many instances to shorten the review process by working out critical details through phone calls, rather than a series of official letters and responses.

“In a minute or less,” Maltese asked the panel as time was running out, what do you think can be done to change the pediatric device landscape and make it more appealing to investors? Sugalski seemed to voice the consensus of the group with his quick summary—structure things to make serving small but vulnerable populations more viable from a business standpoint. The traditional device revenue model is difficult due to population size but the government can help through tax incentives, grants, extended patent protections, and other tactics that have seen success through programs such as FDA’s Orphan Drug initiative. The rest of the panelists beside him nodded in agreement.

Written by Daniel Henrich

Written by Daniel Henrich

Director of Marketing at Archimedic