Transforming Ambiguity into Custom MedTech Automation Opportunities
AC engineers are experts at delivering medtech automation manufacturing systems for highly regulated processes which had been previously considered too complex to automate. Our deep experience across industries and the end-to-end product development process is integrated to your product and manufacturing processes. A lack of predicate solutions translates to custom and innovative manufacturing automation systems.
Medical device development is at the core of AC’s engineering history. We are experts at adapting to new design control environments quickly, efficiently, and thoroughly.
How AC can help you:
> Onshoring of MedTech manufacturing
> Increased consumerization of healthcare and speed to market for medical devices
> Solutions for high volume line OEMs not scaled for pilot line development
> Supporting MedTech Start Ups in need of complex manufacturing experience
> Handling of high value products with sensitive IP
> Integrating new technologies from other industries, such as IoT, into existing product lines and their manufacture
Sessions with AC Presenters from ATX West
Custom MedTech Automation Transcription:
My name is Jack Link, project manager for Andrews Cooper, two years here at Andrews Cooper, ten years in Med device manufacturing, started as a quality engineer, moved into manufacturing engineering and then into leadership. And here today I’m talking to you about MedTech and custom automation.
One of the things that we like to do at Andrews Cooper is talk the language of MedTech. We’re all very versed in ISO 13485 and 21 CFR Part 75. We understand process validation, we understand design qualifications and how it all starts at that very beginning of working with us. That’s a URS, that’s any other specifications requirements that goes directly into helping you guys build out what we call design qualification or DQ. And basically, what we’re doing is even at the very start of our design, we’re ensuring that all of your requirements and quality items have been met. And then as we move forward into the build and test site, which we call factory acceptance testing or FAT, we actually treat that like a process validation. So what you’re going to see is basically an IQ, PQ directly done on that tool so that your engineers can then take that documentation and win the tools on site at your facility, essentially copy and paste and execute that protocol. So no need to have some person come up with their own document, their own protocol without really truly understanding the tool. And that’s been a big help for our clients that we found, is the ability to take that work that we do and put it onto their validation documents.
Secondly, we talk about software validation. That’s a very scary thing for a lot of people. What we found is it’s really based on what you’re going to do with that custom software that we create for you. So, if you don’t have a team of software engineers that plan to customize our equipment later on or get in and optimize our equipment, if you’re going to rely solely on us to make that tool better, Then, what we want to do is what we call black box solution. That means that software is out of sight, out of mind, you don’t touch it, you don’t use it. It’s only there to function for your tool. And when we do black box software, a lot of the test scripts that we do in our software validation can be roped right into that operational qualification or performance qualification of the tool. It does not have to be its own standalone document.
The benefits of that also is we can simplify the other side of the software validation which is the 21 part 11 which is audit records, audit trails and we basically show with off-the-shelf software that you will have everything you need as far as user access rights and passwords. The most important thing is an audit trail for any process parameter that’s changed so in that tool if somebody changed a parameter or anything that’s going to affect the process of the output Of that product, you’ll know who changed it and when and what time. So if God forbid there is any other issues and we have to do a recall, the containment process there is going to be significant for you. Lastly, what we do on the software validation is storeable data records, what you call a device history record.
So this is all the information, the processing information, the batch, everything that goes into the production of that med device. If our tool is collecting that data, where does it get stored? How do we ensure you never lose it? And how do we ensure it doesn’t ever get adulterated? That, again, comes standard with our typical automation platforms, and it’s very, very easy for us to just use standard templates to validate that with standard test scripts. So right out the box you get our tool with the 21-part CFR Validation Strategy.
For those that are very mature and do want access to our software and plan to automate or continue to automate and improve and optimize our equipment, what we do there is basically do an entire software validation like you would see on product Software Validation v1. So that’s in the code or writing functional links to each one of the specific IRS requirements you have, or writing individual test scripts just like you would in an OQPQ for the equipment, but on the functionality of the software. That includes alarm checks, IO checks, it’s talking about any sort of bugs, it’s us trying to break the system through test scripts.