[00:00:05] Speaker: Hello and welcome to our webinar introducing Instron's next generation auto injector testing system. Thank you so much for being here. I'm Nick Ericson, your host for this webinar. Today I'm joined by Landon Goldfarb, Instron's Biomedical Market Manager. In this role Landon works closely with a wide range of organizations involved in testing medical devices and pharmaceutical products to better understand market needs, how to optimize testing processes, and he identifies trends where Instron might need focus for new product development. A perfect example of Landon’s role in action is the development of our latest generation auto injector testing system that he's here to talk about today.
We expect the presentation should take around 45 minutes, and if you have any questions, please use the Q&A to submit these at any time. We'll aim to address these at the end. I also want to mention that we are recording this webinar and you will receive an email afterwards with a link to the video, and it will also be available on our website. So with all that said, I will turn things over to Landon to get us started.
awesome, thank you Nick. Well good afternoon, good morning to those on the West Coast. As Nick said, I'm Landon Goldfarb, the Biomedical Market Manager here at Instron, and I have been in this role for six or seven years working with medical device customers and pharmaceutical customers trying to understand kind of what their innovation pathway looks like, how we can help them get where they're trying to go, trying to develop systems to address the biggest current and future challenges in their testing.
So I've had the privilege of working on this project with our engineering team and with our pharmaceutical customers to develop a test system for auto injector devices, which are quickly becoming more and more mainstream in the market. Throughout this webinar, I didn’t want to simply talk through the value of the new solution, but I really wanted to take our experiences that we've learned developing this product and really share that with all of our customers, because we've had the opportunity to try to test all sorts of different devices and drug formulations and understand how those variables impact testing — what works well, what doesn't work well — and I think through this process of trial and error we've really gotten a good handle on what the ideal auto injector test system looks like, how to integrate all of that testing into our mechanical testing system, and how to really optimize the results and the insights you're gaining about your products.
I just wanted to set the stage with that, that it's a little bit different from the standard product launch. I really want to make sure that there's valuable information that you can utilize starting today. So with that we'll kind of kick things off.
Just to quickly talk about the agenda: so first off I wanted to take the time to walk through our process for how do we know what this system needs to be, how do we define what capabilities the system has to have, what are all of the device variables that we need to compensate for, how do we make sure that the system works as well as possible for as many customers as possible. Because one thing we'll talk about throughout this session is auto injectors are not all created equal. There are different form factors, there are different formulations that go inside them, all to serve different patient populations. So there's just a lot of different variables to be aware of and design for.
Then we'll talk about the development journey — so what we went through in trying to address the challenges related to these variables, really making sure we had a full understanding of the requirements, not solely from our own internal thoughts but also working with partners within the pharmaceutical industry. And then finally we'll take a look at: well we've gone through this process, what did we learn, what does a full test look like, and then what are best practices for testing these devices, and how did we take all of that information and integrate it into this next generation auto injector system.
So to start off, you know, if you were to ask me five or ten years ago what is the most common pharmaceutical application that we get asked about, it would probably be syringe testing, maybe vial testing. And there's a lot less testing complexity with these kinds of devices. Really in terms of the interaction that a user has with them, it's primarily a force‑based interaction — they're doing break‑loose or glide force, they're removing a cap — all things that are just purely mechanical interactions with the device. With a vial similarly, you might be doing residual seal force, you might be doing a needle penetration force, but the overall functionality of the device and the complexity of testing that goes with that is pretty low.
In the last five years the demand for testing more complex devices and more capable devices like auto injectors has just continued to increase and increase. And the biggest thing for us is that there is such a massive leap in capabilities between a pre‑filled syringe and an auto injector that change how this device has to be tested. These devices have significantly more automated functions that all have to be checked to make sure that they're performing accurately and reliably. They have passive safety mechanisms and passive mechanisms that tell a patient whether the injection worked or not, whether the injection is complete, that lock out the device. These are all things that have to be confirmed after a device is tested.
And all of these automated functions, all of these new mechanisms of control for the device, just mean there's more that can go wrong. There's more ways a device can fail, and simply measuring the total force to use the device is not enough. You need to have a better understanding of how it failed, why it failed, beyond just the quantitative numbers. And those are really all kind of described in what are called EPRs or essential performance requirements. So we'll talk on the next slide about what are all these essential performance requirements and what do they require of a test system.
So when you look for formal definition guidance around these testing requirements, there's not a single source of truth that says “this is what you need to test” on an auto injector unfortunately. There's a lot of different places where you can get this information. The broadest term of all the requirements and most commonly used is probably within the ISO 11608 standard, which is the international standard that drives the testing requirements of needle‑based injection systems.
In the latest revision, the 2022 version of the standard, they introduced the concept of primary functions that deal with anything that will affect the efficacy of the delivery of the drug or could result in undue harm to the patient. So that's why there's a couple things that show up as a primary function but not an essential performance requirement. A perfect example for that is the needle safety lockout — it has an implication for the patient, but if that does not work, it does nothing to the efficacy of the drug being delivered to a patient.
So there are some nuances in what has to be tested and it really will depend on where you are in the device development process — whether this is a production environment, whether this is an R&D environment. And actually for the essential performance requirements, we've been waiting for a number of years from the FDA on formal guidance. In the last month they released their draft guidance and actually decided to change the name to “essential drug delivery outputs,” but essentially it's the same thing in terms of what they're referring to. So these are the absolute critical design outputs that have to be tested to ensure the efficacy of the device.
So I have those bolded here. The main ones are going to be cap removal force, delivered volume, injection time, injection depth, progression of the dose, end‑of‑dose indication, needle safety, and then activation force. And I've put icons just to highlight that these are not all force measurements. A lot of them are using some other measurement transducer — whether it's a scale or a vision system or a camera or a microphone — we have to integrate additional devices into a system to be able to fully evaluate these kinds of devices.
And then just looking comparatively to pre‑filled syringes, there's so many additional requirements for what is required to test an auto injector. On a pre‑filled syringe you would only be interested in the delivered volume piece that requires additional transducers for a system. Everything else is standard force‑related testing. So this really highlights that shift and that gap in requirements between pre‑filled syringes and auto injectors.
One other major difference between syringes and auto injectors is just the overall device variability. I kind of have this exercise to show: you know, a few different syringes — overall form factor is pretty much identical. They have the same features, they do the same thing. There are some potential differences if it's a safety syringe or just a standard pre‑filled syringe, what the safety mechanism is, if it's passive or active. But overall designing fixturing for one syringe would result in a fixture that works for most other syringes.
When we look to the auto injector side, it becomes quickly apparent that there's a lot more contrast between devices and there are many more opportunities for differentiation. So you could have standard pen‑shaped devices, you could have devices that have caps at different locations on the device, you could have devices that have a completely different activation mechanism between a button or the needle shield, and then you have devices that are a completely different form factor altogether.
The big driving force behind this is auto injectors as a combination product have to serve the specific patient population and indication that they're designed for. And inherently, because these are meant to be delivered by the patient themselves — it's not intended that a physician is performing this procedure — you have to design to the needs of the patient. And that can mean you're talking about a patient population that could be children, so maybe you need it to be as easy to use as possible. Maybe the patient population has severe arthritis and they can't hold onto a device with a certain form factor. So all of this will inform how the device is designed, and all of those design choices will in turn inform how we need to interact with this device on the system.
So there's also a good amount — and this is to more specifically kind of work through what different types of variability there are and what kind of impact that has on the test system and on your results. So the most basic one is: in the world of auto injectors there are typically two main activation types — you have needle shield (or two‑step) and button‑activated (three‑step). And the difference between those two will have a big impact on “well, I need to make sure my system can activate the device,” and the mechanisms to do that are extremely different. And your force profile, excuse me, will also look extremely different depending on which type of activation mechanism you have.
So that's just one variable. You also could have the internal activation mechanism, also talked about as the power pack, but essentially what is the means to push on the stopper of the pre‑filled syringe inside the auto injector to deliver the drug to a patient. And in recent years there have been new technologies being released for this activation mechanism. For the most part spring‑driven systems have been the industry standard for a long time. They're reliable, they're easy to manufacture, and they've worked extremely well in the past.
The big shift has been the change in formulation viscosity. There are more and more high‑viscosity products being brought to market, and due to the tendency for spring‑based mechanisms to apply a pretty significant force impulse when they're first released, and that resistance from the viscous fluid, there have been instances where standard glass syringes have shattered at the flange. And because of that, companies are investigating new technologies for activation that apply a much smoother force profile over the full travel of the stopper. So things like compressed air or electromechanical systems are starting to be used that will change that force profile to impart less force on the pre‑filled syringe inside the device. And this can have a major impact on the injection time, on the length of the needle, how it pushes the syringe out of the device, and all of that will impact how we develop the injection monitoring system.
Similarly, expanding on that, the drug formulation itself has a major impact on testing these devices. Throughout the development process we kind of always said: if we had to design this system to work for one device type with one fluid viscosity with one needle length, this would have been a very easy project. It's trying to make it work for the entire range of device form factors and needle gauges and fluid viscosities that makes it challenging and interesting. So the drug viscosity will have a major impact — like I mentioned earlier — on the injection time. But also trying to remove the last drop from the tip of the needle at the end of the test is very difficult depending on the viscosity of the fluid. It tends to be harder to move the higher‑viscosity fluids, and we needed to make sure we designed the last‑drop mechanism to support a full range.
And then finally, and probably one of the more apparent ones, is cap geometry. Pretty much regardless of device you're going to have a cap on it, and that's probably the one component of this auto injector that's going to be different on every single auto injector that comes to market. And that obviously means we would need a way to interact with every cap that comes on the market in a way that is not difficult to change out on the system. And obviously the different cap styles will impact how we fixture it, which will in turn impact the cap removal force that you would measure.
This is just to highlight the impact that all of this variability can bring, and this sets the stage for the challenges we had to work through to make the system as robust as possible.
So like I said at the top, this system was not developed in a vacuum solely from our own thoughts and insights. A big part of it was working with pharmaceutical customers from different segments — talking to folks in R&D facilities, on device development teams at pharma companies, talking to CDMOs, talking to contract test labs — really trying to make sure we factored in all different types of environments where auto injector testing is happening.
And really the two biggest points that were brought up, and were our guiding light when we were designing it — we always thought back to “does it help with one of these two requirements?” The first is: is the system flexible? And this flexibility is not solely in reference to the hardware, like being able to change out between devices quickly and easily. It's also the software: can I make a new method for a new device quickly and without having to lean on the vendor to support that? Do I have the confidence and ownership of the method to be able to make those changes independently? This flexibility is also critical for ensuring that operators feel comfortable being able to run different tests, and that's especially prevalent at a CDMO who may be working with different clients. It could be for an early‑stage device team who's working on evaluating multiple platform devices.
The second piece was root cause analysis, and this is especially prevalent in a production environment. The number of times I've seen scenarios pop up where we had one device fail out of a batch of a thousand, and we can't release that batch until we know what happened — what was the root cause? So it was really important for us to make sure the system has integrated tools to assist with that root cause analysis. Obviously there's no way it could definitively say “this is what happened” every single time because there are so many variables and some of them are inherent to the device. But we provide as many physical tools to review the data and what happened as possible to essentially safeguard that the system was working as intended, and you can at least narrow your scope for where you're looking for the potential issue.
When you look at the marketplace and what customers are doing now to test auto injectors, there's a good portion of the market that is still doing a lot of testing in a somewhat piecemeal manner, where they have different test systems to evaluate different EPRs for their device. This is not an uncommon scenario at all. But there are cases where a customer has kind of a standard universal test system to measure cap removal and maybe activation force; they then take the fluid that comes out into a beaker and put it into a separate balance to get delivered volume; they develop their own machine vision camera systems to measure the injection time and the needle depth; and then maybe have a microphone for the click detection. So that could be three or four different systems doing all of those tests.
And there are a lot of drawbacks to doing testing that way. I think probably the biggest one that may not be as apparent is: these are for the most part non‑reusable devices. You activate it, you can't retest it. So if you are essentially spending four times the number of devices to get the same amount of data analysis, that can be extremely expensive. And it may not even be just a pure expense — it may simply be that especially if you're on a device development team and you're supporting potentially a phase one or phase two clinical trial, most of the devices are going to be earmarked for that clinical trial, you're not going to get as many to actually do your testing with. So in many cases the devices are at a premium. They're not going to spend the money to have so many devices available. So if you could take what used to be done across four devices and do it with one, that can add a lot of value to a lab.
Not to mention the additional time required to do the testing and get the results needed. And then you have — if you’re making an in‑house homemade system — there's a good amount of time dedicated to that hardware development, that software development; all of that knowledge lives with the person who developed it, which can be difficult if that person moves to a different company. So you may not have the longevity of the knowledge of that system. And then you also may be spending a decent amount of time just collating all of that data from those four separate test systems into a single report. Not to mention you might now have four individual test methods that need to get validated across those systems, you have the costs associated with annual calibration on multiple systems, and then the idea of having to transfer that methodology to a production environment would be difficult, time‑consuming — all of the above. So there are a lot of drawbacks to doing testing this way, which is I think what really got us invested in developing a better solution for the market.
So using all of this information that we learned from our customers and that we learned from years of working within this industry, our main requirements for the system that we always looked back to were: one, we need to do the entire test sequence. You have to do a single test sequence to perform all of the necessary EPRs on a device to minimize the number of devices used. Two, we want to make sure the system has flexibility in device fixturing so we can support a wide range of device geometries. We want to make sure it can support the most common devices out of the box and then has the flexibility to support different new devices that are being innovated and developed as we speak with minimal intervention from us.
I think it's a big ask, but it was something that we felt strongly: we wanted a system that felt as comfortable in an R&D environment as it did in a full production environment. So that was a really big driving factor behind that requirement. And then the third was — I think the thing we realized quickly — that the injection monitoring component of this system has to be extremely, extremely robust to compensate for all of this variability that can exist not only in the primary container that is housing the drug but the drug itself. So looking at the fluid viscosity, the velocity of the needle coming out of the device, the depth of the needle, being able to support both subcutaneous and intramuscular injections — there is just a lot of variability that we needed to support in how we developed the injection monitoring. So yeah, that was what drove us to set the requirements and begin that development process.
So I'll walk through some of the challenges that we came across and important lessons that we learned throughout this development. A consistent thing I would hear from customers is they saw considerable variability in their cap removal forces. Part of that is: if you ask five people to develop a cap removal fixture, they'd probably develop it five different ways. Again, the ISO standard is extremely vague in how it describes its testing. It's unlike other ISO standards where they’re extremely explicit — “this is how you perform this test, this is how the fixturing should look.” The standard is vague purposefully because they don't want to stifle innovation. They know that devices are going to look different and they don't want to force people into a specific design choice because of the way the test is explained in the standard. So for that reason, a lot of customers do testing differently.
The biggest thing we learned immediately was that any misalignment in the system has a major impact on the cap removal forces. So if you have side loading, if you have any error in concentricity or angularity, we saw the cap removal force could artificially increase by 20%. So we knew that alignment was going to be part of our solution.
The second was how we actually hold onto the cap. Almost all caps have some sort of curvature to make it easier to pull them off for a patient. And because of that, it makes it much simpler to simply catch on that curvature, on that radius, to prevent the cap from moving upwards rather than having to clamp on it directly. Applying side loading to the cap, even though it is rigid plastic, still can deform it somewhat, especially because you have a relatively soft compliant rigid needle shield inside of there, and any sort of side clamping on that could affect the cap removal force. So we wanted to make sure we designed it to always hold onto the curvature, the flange of the cap, as opposed to gripping it directly.
And then the final question was: should we make a tight fit or a loose fit for how we interface with that cap? And we had different customers request different things, but we did a lot of testing and found that a loose fit that is not over‑constraining the cap resulted in better, more repeatable data, primarily because by leaving that loose you actually allow for some self‑alignment as you pull the cap off, which again helped reduce that variability.
So next we had a few challenges related to the injection monitoring, which I mentioned earlier is the source of a lot of the variability. The first challenge was: how do we create the best methodology for injection time? Injection time is inherently a pretty complicated thing to measure, and again the standard does not provide a whole lot of guidance. Not verbatim but pretty close, the standard essentially just says you should measure injection time by means of optical measurement or laser or gravimetric — pretty much the verbiage they use. So it doesn't even offer any benefits or downsides of any one of those options, it just says “use one of the three.”
We've had the opportunity to test devices using all three methodologies, and we've found that the optical measurement using a camera is the most repeatable and robust way to measure injection time to serve the largest range of different devices. Some of the downsides of using scales, using a gravimetric type of system, is you're relying on using the scale data to determine when sort of an end of injection is, especially if you're dealing with high‑viscosity fluid where there is a slow rise to a plateau in the scale reading. It can be difficult to decide what is the end of the injection — there's no clear point in the data.
With laser‑based measurements, you really want to make sure your laser is appropriately positioned to catch right underneath the needle. You need to make sure there's appropriate contrast and there's no light noise to interfere with the laser. If you have a product that is low viscosity and produces a lot of mist upon impact, that mist can greatly affect the performance of the laser. So there are a lot of potential downsides of using some of those other methodologies.
A camera‑based system tends to be the most robust and is really the most direct means of measuring the injection time because you are just counting the number of frames where you see fluid.
And like I said, there can be issues with stream continuity, especially for higher‑viscosity fluids, and spring‑based devices as you get toward the end of that travel of the spring — it'll push less and less — so you tend to get discontinuous drops of fluid toward the end of your injection, which can be really difficult for a laser or for a scale. And then I'll show you what those viscosity effects can look like on the scale readings.
So in this first graph, if you see, the blue is the scale value. This is an extremely low‑viscosity fluid and you have a very large impulse of mass and then it settles extremely quickly. And then if you were to look at an extremely high‑viscosity fluid — and I apologize, in this graph the scale is in red — you can see that there's almost no impulse whatsoever and then it slowly settles toward a point. So you can imagine trying to find a way to repeatedly measure both of those with the same level of accuracy can be difficult.
So what we've implemented with the camera system is: we have a detection zone where we're looking for fluid. Once we see fluid cross this detection zone, we start a timer, and then we set a defined-by-the-operator break timer that basically says “what is the amount of time between fluid detection to trigger ‘okay, my injection's over’.” So for example, by default it's typically set to one and a half seconds. So if I don't see fluid in my detection zone for one and a half seconds, that will trigger the end of the injection. So if you have drops repeatedly happening after the injection, those will still count toward the injection time. If you didn't want them to count toward the injection time you could simply lower that break timer to be 0.1 seconds or 0.2 seconds to not include those. Again, the standard doesn't say “this is best practice for what you should consider your injection time.” Different drugs, different devices, different indications are going to have different guidances for what should be considered the injection time. So leaving it open and editable by the user allows us to be flexible to support a lot of different injection profiles.
The second challenge was we wanted to provide more insight into the travel of the needle throughout the injection, and this topic came up more recently with the release of the 2022 ISO 11608 version. It brought up the concept of modified dose accuracy, which is essentially saying you need to ensure that your drug is delivered solely within the therapeutic range — so whether that's 4 to 8 millimeters of needle depth, whatever it might be for your specific combination product — it's just ensuring that. And the means the standard provides is a somewhat ill‑defined setup where you use a membrane to basically stop any fluid from reaching the beaker before a certain point in the therapeutic range. But the standard doesn't provide a lot of guidance on how that setup should ideally work — what is the thickness of the membrane, how taut should the membrane be, what material should the membrane be. There are all of these factors that they really leave up to a user to figure out.
And while being able to identify optically the length of the needle at the start of the injection isn't a direct replacement for modified dose accuracy, it at the very least gives you a good data point to know that my device is performing with the fluid starting in the therapeutic range — 90, 95, 99, 100% of the time. It can be used as a good potential quality check. It can be used as an additional data point when doing a device characterization earlier on in the R&D process.
There are a few different variables that will affect the needle length at the start of the injection. Some of those being the velocity of the needle — how quickly it leaves the device; the viscosity of the fluid — how quickly does the fluid start leaving the needle after activation; and essentially what we implemented was a way to use that fluid detection zone in a second function. So now whenever the fluid detection zone sees liquid, it will automatically trigger us to take a picture of the needle and get the needle length. And you can define how many frames you want to go back from when fluid is first seen. And like I mentioned earlier, those variables will often dictate what is the correct number of frames to go back. And again leaving this open‑ended gives the user the ability to really fine‑tune and optimize their injection monitoring for their combination product in a way that doesn't exclude them from testing other devices.
And then finally you have injection monitoring — our last challenge was making sure that the camera just has a good image of the needle to get the needle depth, because it's such a crucial measurement. And I won't say in all cases, but in most cases after an injection there's a drop of fluid left at the tip of the needle, and it's important to remove that to make sure it's not counted toward your needle depth. So we did a significant amount of testing to really validate what profile of air works across a range of needle lengths, needle gauges, and fluid viscosities. That was a lot of work to really develop that. Then we also had the consideration: well how do we minimize that air occurrence effect on the scale? Minimizing how much of that air reaches the scale, because one, we don't want to impact the readings; two, we want to minimize any evaporation of the fluid. And then the third consideration was: how do we make sure this will work for needle lengths between 3 and 20 millimeters to support both subcutaneous and intramuscular regions.
So putting it all together, this is just showing an example curve that you could produce using this type of system, showing all the key points: doing cap removal, activating the device, triggering the activation, you have the mass in blue, the forces in red, you have the mass profile over time, you have the scale capturing the delivered volume, and then you do typically a safety check of the device. You have the option to either go to a set load to ensure there's no separation of the device, or to make sure there's no excessive movement of the needle shield, or do a full defeat force where you actually try and cause a failure of the needle shield. Both can be done on the system, which was a big ask from customers who in the past had to use a totally separate dedicated system to do defeat force. And then this is just another graph showing a superposition of the mass and the microphone readings, to show the click detection on the device and how you can use that to confirm — it could be used as a way to do a quick gut check of the injection time. One characteristic that we get asked about — or have been asked about — is what is the actual amount of fluid still coming out after that second click. In some cases the second click is actually not — there's still fluid coming out of the needle at that point in time. And having all this data you could easily assess that. And then just showing there is some impact on the scale from last drop, but it's relatively minimal, and that also is picked up by the microphone.
So this is showing a full sequence running. For a two‑step device you're typically looking at a 45‑second cycle time to measure all EPRs. So it'll do the cap removal, immediately move the cap out of the way of the device, come down, activate the device, you'll have all the injection monitoring underneath — so that will include the scale, that will include the machine vision camera, that will include the microphone — you'll have the last drop to blow the last drop of fluid off the tip of the needle, and then we'll come back up and do the safety check, and then we'll put the device back down. So like I said, 45 seconds to a minute — it's going to be dependent on the injection time. And then for a button‑activated device it could be a little bit longer — minute twenty, minute thirty — just because there are a few more steps to activate it.
And then lastly I'll talk through some of the best practices we learned and how we implemented those in the system. The first one ties back to our root cause analysis as a key requirement for the system. We wanted to make sure that we had a full video file captured of the entire injection to be saved with each specimen so you can always go back and look at what happened. The number of times we've seen that just having that capability — to be able to go back and see “oh, for example, the needle came out at a pretty intense angle, maybe it was 60 degrees off” — that could have impacted the fluid going into the beaker, it could have impacted the depth of the needle that was measured. These are things that if you did not have that video recording, you'd have very little means to go back and identify what happened. Maybe you can do a scan of the device to try and assess it or disassemble it, but it's a lot quicker if you just have this video file available. So this is really important. A lot of customers with our older system — this was the most commonly asked‑for feature — was having this video recording. And the way we've implemented it, you also have the ability to pick a point on the curve and then see the corresponding frame of interest.
System and device alignment — I talked about it earlier, but really ensuring that the alignment of the system, the procedure to align it, was very simple and the amount of time spent aligning it was minimized. We don't want customers to have to realign the system every time they have to test a new device. So the way the device inserts were designed, you can change those out without actually affecting the alignment of the system at all. So you're minimizing that time. And the system was aligned with the cap removal position in mind, and that's important because that is the result that is so closely tied to alignment. You have a lot more room for potential misalignment with the injection because you are just activating over an open hole. So we wanted to make sure that the critical region to do alignment was in that cap removal position and everything was aligned based on that.
And then finally — having the opportunity to go to a lot of labs, see how they're doing testing — you know, especially GMP labs, a lot of places will have a notebook right next to the system, they do whatever they want to call it: daily check, system suitability. They have an SOP that's defining their procedure to check that each transducer is working at the start of the day. And that's a more commonly manual practice that is done with pen and paper to record the results. We wanted to completely streamline that process, digitize it, bring it into the Bluehill software so it leaves no room for error or misuse of the system for an operator. So having system suitability built into the software will essentially prevent them from running tests until it walks them through the process to evaluate the performance of the load cell, the camera, and the scale. And this will again help reduce the time spent developing your own methods, your own fixtures to do this SST, and just greatly increases the traceability of your SST. All of this data, all the reports get saved within the audit trail — they're all accessible by your lab manager. So it's just a much more robust, traceable environment to be doing this work. Since you're already going to be in Bluehill, it makes sense to have this process embedded into the software anyway. And the nice thing is it doesn't prevent you from using your existing process — you can build your process into a method in Bluehill and then prompt that method to be run for system suitability. So it's just automating that requirement to do these tests and preventing running the system for the day until these tests have been performed.
So that's all I have on the presentation side, but I hope there are some questions. And I understand this is kind of a lot of information to throw at once and some of it's pretty specific, so you may have questions that come up later. Feel free to reach out to us if you have something that comes to your mind later on.
So I have a question: how does this new auto injector system differ from the older auto injector systems from Instron? So kind of what I discussed already: some of the bigger hardware changes are going to be the introduction of the second camera for the injection recording, the use of the machine vision camera to now perform both the injection time and the needle length at the start of the injection. And then one of the — I would say one of the bigger changes — is really going to be from a software perspective. So I will share my screen quickly just to show what the actual method development looks like on the new auto injector, because it is very different from how the older system worked. So let me share my screen.
Okay awesome. So we really took a step back and almost built up Bluehill foundationally to work in an auto injector environment. So when you go to choose a method, you'll actually now see there's only two method types — there's an auto injector method and then a TestProf version of an auto injector method. So you don't see tension and compression because this system is dedicated to do auto injector testing.
So if I click on this method, kind of the first thing you'll notice is the specimen properties are now completely specific to auto injectors. They show typical device‑use terminology that you would use within the industry. You have the ability to change whether it's a two‑step needle shield or a button‑activated device. That will dynamically change what dimensions it asks for. And that will also change how it tries to control the test.
So if I go to test control — anyone who's used the older version knows, or if not, if they're familiar with TestProfiler — that's typically how the auto injector is run: it's a series of blocks to control the crosshead, all of the grips, how we interact with the device, how we interact with some of the additional transducers. We really tried to distill what is most important for running this test — what we know customers are going to need to do — to essentially only require the critical parameters that will have an impact on results. So your testing speeds, the forces that you're going to go to, how you want to define your safety check — are you doing a lockout or defeat force? What force? — all things that will have an impact on the device, on the results, and could be in a potential URS or specification for how to test the device.
And all the things you don't see are all the things that we can figure out in the background. Using the dimensions of the specimen we can figure out how to move the crosshead depending on what you're doing. We know when to open the grips, when to close the grips, when to take values from the camera. So all of that logic is behind the scenes. We have a lot of documentation to explain exactly what it's doing, but you can essentially walk up to a system with a device in hand, take a few measurements, know your critical parameters, and you can just run a test within five minutes. And if you were to ask somebody who was building a TestProfiler method from scratch to do the same thing, it would be considerably longer than five minutes. It would depend on how well you know the software. So I would say that's by far the biggest difference between the two systems.
So I have another question: without a full enclosure around the system, how does the microphone handle ambient noise? Yeah, so I didn't bring attention to this but the system — you can actually see it behind me — the system has a light curtain as the front enclosure as opposed to a physical door. A big part of the justification for that was we have a lot of customers who are testing hundreds of these devices in a single sample, and from an ergonomic perspective they really didn't want to be opening and closing a door for every test, twice a test. So having the light curtain was a much more user‑friendly solution. But we did do significant testing with some of our — we worked with a consulting firm, Team Consulting in the UK — they did some evaluations for us, and they actually did an exercise where they got a speaker, blasted some industrial ambient noise at 90 dB right in front of the system, and then essentially challenged it to still measure the clicks. And they found that the device found the clicks every single time even with all the ambient noise. And part of that is the microphone is actually inside the box where the injection monitoring is, so it's not as impacted by all that outside noise. So I think we did a lot of testing to confirm that.
I have another question: can I test other devices like pre‑filled syringes or safety syringes? So we designed the system so we could easily add different inserts to test different devices. So you're not limited to solely auto injectors. If you wanted to test just pre‑filled syringes you could do that. You still have the benefit of having the balance underneath so you could do pre‑filled, you could do dose accuracy, break‑loose, glide force, in a single test. If you had a safety syringe you could do cap removal, break‑loose, glide force, delivered volume, and then a lockout check. So there's a lot of flexibility with the types of devices you could put on the system and still utilize all of the capability and functionality of it.
So we have another question: can the older auto injector add‑on be upgraded? So at this time because of the overall difference in hardware, there's no direct upgrade path. It would be really just a complete changeover from the old one to the new one. We're certainly open for discounting and trade‑ins and making that incentivized for you, but because of all of the changes to the software, some of the hardware that's on it, how everything has been integrated with the frame — it's just a lot cleaner to do a direct replacement than a field upgrade.
I think that was the last question.
[00:55:45] Speaker: All right, well I am back. Thank you Landon, that was great. So before we wrap things up I just have a few quick notes. If any questions do continue to come in while I'm speaking, I will get those over to Landon afterwards and he can respond to those by email. I'm also going to be sending out an email with a copy of today's recording. And lastly a survey should pop up once this webinar ends — we'd really appreciate if you could take a moment and just let us know what you thought of today's presentation. So with that said, I just want to say thanks again to Landon for presenting today, thanks to all of you for attending, really appreciate you joining us, and enjoy the rest of your day.
Great, thanks everyone
