Performance Qualification (PQ) Expert Panel Discussion
Full transcript below:
Ann McGuire
Hello, everyone.
My name is Ann McGuire, Product Marketing Manager at Arena, a PTC business, and today’s moderator. On behalf of Arena, I would like to welcome our customers to this event, titled Arena Performance Qualification or PQ, Partner and Customer share. We’re excited to have you with us today. Our most recent session was called Arena Validate, Meet the Experts. If you didn’t get the chance to attend that event, you can watch the recording and other past events in the events app.
Introducing our panelists, Jason Gromek has over 19 years of medical device design quality system, quality engineering, and regulatory compliance experience. Jason’s expertise includes design control, QMS development and implementation, project management, medical device software, CAPA programs, electronic QMS implementation and validation, FDA inspections, and remediation projects. Before MEDIcept, he was Director of Engineering and Development at Meditech Spine.
Clarke Madigan has over 10 years of experience in medical device companies, including experience with QMS implementation and management, new product development, process quality, and post-market quality. He is the Quality Assurance Manager at Instylla. We will start with this poll. It asks: Have you done PQ testing on your Arena system yet? All right.
So out of the people that have responded, about half of them have already, and then we have some that are planning to within the next three months and some that are planning to do it after three months. Before we begin the question part of the webinar today, I’d like to bring in Jason, so he can introduce MEDIcept.
Jason Gromek
Thank you, Ann, and welcome everybody.
MEDIcept is an international consulting company. We specialize in quality regulatory and clinical compliance, not only for medical devices but also IDE (investigational device exemption). We were founded in 1996 and we’re based in Ashland, Massachusetts, which is just west of Boston. Our partners, we have five partners combined, we have over 125 years of combined med device experience. And 32%, approximately, of our clients are international. So not only we’re domestic, but we’re also outside of the U.S. We’ve contributed, led, or assisted on 625 regulatory submissions.
We’ve been involved with multiple consent decrees, warning letters, decertifications, and many, many, many hundreds of notified body major findings, internal audit major findings, things of that nature. Our clinical division has assisted in 40 or so clinical trials involving approximately 1,400 sites and over 12,000 subjects. These are all the services that we offer. If you guys look on the far right-hand column, process validation and software validation is a little piece of what we offer, but a breadth of services, full service, turnkey, quality regulatory, and clinical device company, or consulting company.
So we can help. We work on all kinds of devices, everything from blood testers and small software-based things, the big capital equipment, x-ray machines, anything Class I, II, or III U.S. This is our team. Our main core team. Dave Rothkopf is our president. We have five partners, as I said, the list on the left-hand side. And then we have senior staff members and quality regulatory and clinical. So why do we need to do validation testing?
So validation is required by 21 CFR 820.70, which is the U.S. regulations. It’s the FDA federal law. And then ISO, if you’re a contract manufacturer or you want to distribute your product internationally. It’s required by ISO 1345. So it’s all classes of devices. It’s not just, if you think you’re exempt, it’s Class I, II, and III or Class I, IIa, and IIb, and III for outside the U.S. There’s a lot of attention paid to this and audits and inspections, and we’ll talk about the process that goes into validation for the graphic here on the right.
We’ll talk about this throughout the presentation today.
Ann McGuire
All right. thank you, Jason.
MEDIcept has been a true partner for Arena, offering your experience to over 20 customers in the U.S. and abroad to complete their software validation of Arena. Let’s bring Clarke into the conversation. Clarke, could you share your experience with Arena in software validation and a little about your company?
Clarke Medigan
Yeah, thanks, Ann. Our company recently started our pivotal study for an IDE trial and we’re working towards pre-market approval as a medical device company.
So we typically have a very thorough process, audit process associated with the pre-market authorization that accompanies that IDE study.
So we are concerned about our regulatory compliance because we know within the next few years FDA will come knocking on our door and require a review, not only of our clinical data but of our full system.
We were concerned with our compliance with the FDA regulations and the ISO regulations and ensuring that we could complete the validation in a compliant way. Our company adopted Arena in 2019, which was the start of our configuration, and we completed it in early 2020.
Ann McGuire
Great, thank you.
And the first question is for you, Clarke. Why did you engage with MEDIcept for PQ?
Clarke Medigan
At the time when we started working with Arena, we were at 18 total employees, and that includes departments that weren’t involved in quality systems.
So within the quality team, we only had three people and we were a very small company to take on such an effort as PQ, we felt at the time.
And we also had a little bit of an experience gap with mainly new college hires and people that had come straight from larger companies that all had a software validation-dedicated department. We felt we really had a knowledge gap in this area. So we reached out to some contacts and found MEDIcept who we had worked with several times on this kind of Arena validation before.
And we didn’t have the internal resources to be able to do it. So that’s why we reached out to develop the PQ process and protocols with MEDIcept.
Ann McGuire
Great. That makes sense. Our next question is how should people prepare for the PQ process, whether they engage with a partner or not?
And again, let’s start with Clarke.
Clarke Medigan
In our process, before we started with the PQ validation, we had to get our configuration set.
So it took us a few months of working with our solutions architect to make sure that all of our configuration was set up.
About 80% of the way through that process is when we started talking about how we were going to validate the system and engaging with a partner.
And the other key point is that we put our software configuration specification into our quality system as a document, a REV control document in revision control.
And that was where we documented our initial configuration that we would be performing the validation on to document the initial state so that we could write our PQ protocols to that configuration.
And then finally, right as we were wrapping up that configuration is when MEDIcept started helping us out with our process.
Ann McGuire
Great. Jason, can you expand on that question for us?
Jason Gromek
Absolutely. It’s part of the PQ process that follows IQ and OQ, which are installation qualification and operational qualification. So for this process, a customer or client is required to generate the documentation themselves. And so, if you’re preparing with a partner, then obviously we’ve been through this before. We have many templates that are stock items based on out-of-the-box functionality. But it’s just the customer is required, you guys are responsible for setting up your own, figuring out the requirements, and then setting up your workspaces and then getting everything ready to go.
And then once you have your solutions architect, once you get your production workspace ready to go, then we copy over to a validation workspace and we validate in the validation workspace. We’ll talk about that a little bit. Generally speaking, this is the process. Once you are getting to the point where you have to validate any of the plan, and then you define your requirements, you test, and then report. And then whatever comes out of that report, then you want to formalize it in the procedures. So through the course of our experience with Arena, which now is probably about five years or so, we’ve developed the plans.
The plan is pretty much templated, and there’s a lot of, it’s about 80%, every configuration is about 80% the same, but then there’s an element of customization. So based on our experience and based on the experience on working with Arena, we can save companies a lot of time and money in setting up the plans because the clients don’t have to do it themselves. So when we were working with Instylla, when they were ready to want to engage us and they were ready to start the validation, we brought down the plan, we also implemented some procedures to validate too, the SOPs procedures.
And then we brought them to the plan. And then we worked with Clarke and team to get the plan complete.
Clarke Medigan
Yeah. And it was good for us to partner with MEDIcept on that plan because where we were starting from was a place with no SOP on software validation within our quality system whatsoever. So MEDIcept actually gave us the SOPs to put into our system that would define how the plan was developed. And then they were able to provide us a plan that had a good starting point for us where we were able to adapt it, that 20% Jason mentioned, to have our own internal user needs addressed and be able to begin work on the requirements after that.
Jason Gromek
Once you have the plan established, then we move on to the requirements. So Arena does a very good job. They offer a validation package that provides for every release. They provide all the IQ and OQ data that we need. All the infrastructure requirements, the functional requirements, that’s provided by Arena. We then, as part of the master validation plan, we have the requirements of the system proof, the client or customer, and then we also have risks associated with that. And so those are all identified, they’re all numbered, they’re all traced.
And I make sure ISO 14971 requirements, not only your FDA and other ISO requirements as well. There are two different types of requirements around the system. There’s one of what the system does and then what the system needs to do for your company. And so once we got the master validation plan done, we got the requirements done and the system risk analysis, then as part of the master validation plan, we worked with Instylla to get all of these documented and identified.
Clarke Medigan
Yeah. And so, one thing I’d bring up on that point is that it was very confusing for us at first, was that Arena provides you a user requirements specification, which sounds a lot like the user needs of the system, but those are independent documents. The user needs that Arena has identified, the user requirements specifications, is for Arena’s general customer. What they’ve identified is something that their customers would require in an electronic system; but the user needs for Instylla, our company, are different from that.
They’re the needs that we would evaluate against to ensure that Arena met all of our requirements of an electronic quality system. So in theory, user needs should be developed even before you’re selecting a system for validation. And that’s something that we learned as we were going through the processes. The user needs are really the bare bones requirements for what we need from a system. And the PQ process is to test, to make sure that the system meets all of those needs. So things like document retention, document storage, controlling of quality templates were all critical user needs for us that we were able to address through our PQ validation.
We worked with MEDIcept to come up with those user needs. They provided the bare-bones template for us with a templated list of about 12 or 15 user needs. And we adapted those and added our own as we felt we had additional user needs for the system. And then we compared the functionality of the system against those user needs and added the risk assessment to make sure that we capture all of the risks of the system and that we are able to effectively validate to mitigate all of those risks that we’ve identified.
Jason Gromek
Once all of that stuff has been identified, we go back to our … One point to make there on Clarke’s statement is that we’ve done this so many times with so many different customers and we’ve seen pretty much all configurations, all installations. You have your base worlds in Arena, so what we validate is we validate worlds and workflows. So some of the worlds that you validate are item masters, and change control, and things like that, some of the workflows that you validate or whatever you create in your quality world, if you do NCR as capital’s complaints, whatever’s in that that’s customized, we validate or whatever is built.
Arena does offer some out-of-the-box templates now, some of the quality processes, but based on our history and based on our relationships with Arena and companies like Instylla, we have a lot of templated predefined solutions for this stuff that say, we’re starting from zero, we’re starting from a position of what we’ve used in the past. Once we identify everything and now once the master validation plan is approved, then we move on to writing the test protocols and test cases. They all link back to the master validation plan, everything ties back to a requirement, everything ties back to a risk analysis.
We go through and we test that we generate the test protocols. From a objectivity standpoint, we usually either have the client approve the test protocols and then we execute or vice versa, just because you don’t really want to execute your own test protocol. And then you move on to the actual testing phase. So for this particular instance with Instylla, they did their own testing.
Clarke Medigan
Yeah. And what I’d say about that is through executing our own testing, we had about four or five internal people go through the PQ tests. We had a number of different protocols and they would go through and execute the protocols. And that was a big exercise for us in learning how to do software validation. So it was something that we could have easily farmed out to MEDIcept and never thought about it again, gotten quality documents back. But in this case, we wanted to develop that internal expertise to be able to not only execute protocols, but go through the process of analyzing the protocol and make sure that we were in a position where when we make configuration changes in the future, adding new quality templates, that we would have the internal capabilities to be able to perform those changes without having to go to a third party every time.
So we have successfully done probably four or five different validations of adding on new quality templates or activating new functions in the system that allowed us to perform those independently. So it’s a good learning process to have your organization go through and execute those tests on your own.
Jason Gromek
And then once you’re done executing all the tests, we write the final report with the customer or with the client. And if there’s any procedural changes that need to happen or any work instructions, SOP that need to go into place, that happens and you follow the way you report. And so it either gets audited and inspected, or you have to assess the next Arena release against it.
Ann McGuire
Great, well that sure sounds like a good partnership with MEDIcept’s experience and processes paired with Instylla’s knowledge of their quality processes. The next question, people were interested to learn how 21 Part 11 compliance relates to PQ. Jason, let’s start with you on this one.
Jason Gromek
So Instylla actually did the most comprehensive validation of the Part 11 that we’ve experienced. Arena out of the box provides the technology for Part 11 compliance, but they don’t actually claim Part 11 compliance. So there’s a multitude of things that go into it for that testing. Once you go through and validate it and put some SOPs in place to handle the documentation and QMS side of it, you can wholly validate Arena against 21 Part 11.
Clarke Medigan
Yeah. And to what Jason said, we did a pretty extensive, we called it a regulatory protocol, to ensure that we were Part 11 compliant by going through each step of Part 11 and having an objective verification that that was met by either system functionality, Arena’s provided documentation, or our own internal processes, which I think was a good practice because Part 11 is outside the normal validation process.
So some of the steps are easily checked off by Arena. They just have redundant backup system functionality, which includes one user to one login.
The password requirements are all met by Arena, and those are all technical functions that Arena covers.
But there’s certain parts of Part 11 that Arena can’t cover for you. It’s things like electronic signatures.
You have to document that an employee has acknowledged that their electronic signature is the equivalent of a handwritten signature. The requirement that you notify FDA of using electronic signatures at your business.
The other big one is protocols and procedures in place to ensure that all employees have adequate training to be able to use the system.
And all of those are things that Arena could never do for you. So just to make sure that we had it all documented neatly and covered all of our bases, we wrote a protocol that went through each step of Part 11 and worked with MEDIcept on developing that and making sure that we had accomplished a validation or had the procedure in place, or Arena had the IQ and OQ testing done to ensure that we satisfied each requirement.
So now we have this one clean document that demonstrates how the system is Part 11 compliant for us.
Ann McGuire
Great. Thank you. And this is usually the most popular kind of category of common questions when we do validation topics. So please feel free to ask those kinds of questions by using the question feature. The next question is, what are the best practices to minimize the PQ effort? Let’s start with Clarke.
Clarke Medigan
Yes. One of the challenges that we ran into, and I think most medical devices, even most life science companies will run into, is that you usually don’t start out with a huge infrastructure investment into an electronic QMS system. That’s something that usually comes.
For us, I think it was three years down the road after the company had been established that we were finally looking into scaling up into an electronic quality management system.
So what that leaves you with is this huge pile of paper system, paper documentation, and established way that you handle your CAPAs, your nonconformances, your change control that is in conflict with Arena’s default template.
So one of the challenges we ran into was adapting the Arena template to meet our QMS.
And I think one practice to minimize the effort of the PQ process would be to do with the reverse, to have more updates of our own internal procedures to match the Arena templates because the Arena templates are more covered by the IQs and OQs use of Arena. And you’d have to do less PQ on that.
And I’m sure Jason has more established PQ protocols for those templated Arena suggestions. So if you adapt your process to that, it’s easier to validate, the more you customize it, the more you add in your own attributes and your own templates, the more complicated it gets when you get to the PQ validation.
Jason Gromek
I think that’s great.
Just to add on to what Clarke said, minimize customizations. When you try to adapt your paper system to Arena, there’s a lot of opportunity for it to not be efficient. So if you can understand the Arena functionality, and people understand the functionality there’s a lot of best practices. The solutions architects offer up a lot of best-practice solutions. So listen to them, obviously when you’re doing the implementation piece of it, because then when we get to the validation piece of it, again, you’re minimizing the customization.
So you’re handing it over if you partner with a partner such as us, the expectations are aligned across the board. You also want to keep it as out of the box as possible. I know now that there are some templates and some guidelines, there’s some templates provided in the quality world—leverage those as much as you can. And engage with a partner. That’s the sales pitch one-on-one. We’ve done this dozens of times, so we can save your company time and money by helping you out and doing what we’ve done for many other companies.
Ann McGuire
That’s all really good advice.
Thank you. We have another question, which is for thinking about the future.
What do you do to maintain PQ as Arena provides a new release four times a year or so? Well, let’s start with Clarke.
Clarke Medigan
It is a responsibility and effort to maintain it.
So the process starts when we get the impact analysis, the validation impact analysis. And usually you get that a few weeks before the release after the sneak peeks are all over and the documentation has started. And that’s the key document for assessing the impact of your validation. So you can go through that document.
You can look at each of the changes and they outline the impacts to the different validations that have been performed from an IQ and OQ standpoint, but it also provides you all the information you need to assess whether or not it’s going to affect how your PQ validation is impacted.
So when we go through that effort for every release to analyze each of the changes, see if it’s going to impact our workflows, how things work in the system, impact the way attributes work and perform that assessment.
And then once the software validation is live, we’ll go through the practice of implementing all of the Arena IQ and OQ documents.
And then if we had to, we would revalidate a PQ if that was part of the impact analysis, but we haven’t had to do that yet in any of the, I think we’re up to five or six releases since we went live with Arena.
And then the good thing about the Arena changes that I’d highlight is most of the time when it’s additional functionality, like new kinds of attributes or new functions within existing attributes, the default will be for it to be turned off.
You’ll have to actually go into your configuration and activate that feature for it to impact your validated status. So for an assessment purpose, when they’re releasing it, it’s really easy.
You just say they validated that it works and we’re not using it, so we don’t have to redo our PQ validation.
But if you are going to implement it down the road or even right when it goes live, then you would need to address it in a PQ validation.
So that allows you a little more time if you don’t want to implement a feature right away to think about how you want to implement it and how it will impact your PQ and what kind of protocols you’ll have to develop for it.
Jason Gromek
Just to add on to that too, Instylla does it on an annual release basis, I’m sorry, on a per release basis. You can also do it on an annual basis too, where you can build it into your internal audit schedule or your management review schedule where you actually go back and look at whatever the current release of Arena is and go back and do that assessment as well.
All of the PQs and the protocols, and stuff that we design can be executed at any time, as long as there’s no significant change in the software because they’re built on the on the individual process flows.
So the 80% that is common does not change, the 20% that changes should not change as long as the customer and client does not change their info.
So to add on to what Clarke was saying is that you’re sitting in an audit or an inspection and they pull up whatever version of Arena you’re currently using, they want to see the trace back to the original validated version.
Ann McGuire
That’s all good information.
Finally, are there any other lessons you’d like to share with the audience today?
And we’ll start with Clarke.
Clarke Medigan
One of the things that I call “a lesson learned” would be, I was shocked to hear during our process of asking me to participate in this panel, that a lot of life science customers don’t subscribe to the validate package, which to me seems like a huge regulatory risk.
So that has been, we’ve seen a big shift in the last five years or so where there’s a lot more competence within auditors, third-party auditors with regards to software validation.
So they used to be able to get away with a minimal amount of work and they look at it for a couple of minutes at the end of the audit, and that would be that, but that’s not the case anymore.
There’s been a big focus on software validation, especially when it’s used within the quality system that all this IQ and OQ documentation is required for. That’s something I would definitely highlight.
And then the other thing I’d add is we’ve taken what we’ve learned from this validation, and we’ve applied it to other software systems within our processes. So it wasn’t just a one-time get-it-done kind of thing for us. We learned how to use it. We developed the procedures to be workable for more than just Arena.
So we’ve actually taken the same process and applied it to two or three other of our electronic systems that we use, especially now that we’ve had to go more electronic over the last year. And it’s allowed us to be confident in our validation and be able to be comfortable with our compliance.
Ann McGuire
Great.
Jason Gromek
And as Clarke said, the process doesn’t change.
When you’re validating non-product software, the process doesn’t change. So you need the plan, you need the requirements, you need the risks, you need the test protocols. It’s just scaled down to more of an ala carte setup with this. So, because we’ve done this so many times with the Arena, we can easily after a conversation, a quick conversation, we can figure out what the install looks like, and then we can provide a quote and timing relatively quickly. Another good piece of advice is once your production space is ready, copy it over to a validation workspace because you don’t want to pollute the data in your production workspace with your validation data.
When you validate, you’re actually going to be running the system, you’re going to be creating document numbers. You’re going to be creating complaints. You’re going to be creating CAPAs. You’re going to be creating emails. You want to make sure that the system’s working, so you don’t want to pollute that data. So copy it over to a sandbox environment. If you don’t buy the validate package, this is another one. I assume everybody on this call probably has the validate package. As Clarke said, it’s going to be virtually impossible to do the IQ part yourself, because you can’t. The servers are out in Arizona and nobody knows how they’re installed or whatnot.
So you can’t really do a true IQ, OQ, PQ validation. You can do pieces of it, but you can’t do … You can, but it’s just, it’d be very time consuming and very cost prohibitive. Also again, we’ve done this many times, so partner, find somebody that’s done it. If it’s not MEDIcept, find somebody, but obviously come to MEDIcept. We’ve done this many times and we’ve gotten this process down, like I said, not from only a cost-efficiency standpoint, but also a timing and a deliverable standpoint.
We do it pretty quickly.
Ann McGuire
Great. Thank you so much.
That’s our final question for today, and we have one more poll question, which is, do you plan to partner to achieve or maintain PQ? All right, I’ll share. And for here, of the people that do plan, and a half don’t, and the bulk of the people don’t know yet.
So maybe that’s why they came today. And now we’re getting close to questions here. We had a great time sharing with you and we encourage you to stay for a few minutes of questions and then also the raffle. You can submit your own questions anonymously using the “ask a question” area or upvote the question that someone else has already asked. Votes help us prioritize the questions in case we don’t have time to get to them all.
But like I said, they are, oops, they are anonymous. So if you don’t get your questions answered, please remember them and send them into support and we can help you out from there. All right. So I’ll read the first question here. Let’s see. And then for Clarke, how much time do you need for maintaining validation after each Arena release?
Clarke Medigan
Typically we need, I call it four hours on a regular basis. So included in that is review of the impact analysis. Then once all the documents are available, incorporation of the Arena IQ and OQ into our quality system as a document within our quality system. And then update our software master validation plan to reflect compliance with the new revision. So I’d say the caveat to that is we haven’t had to execute a PQ test yet for release. We haven’t had a major change that impacted the way that our user needs were met.
But if that were the case, typically a protocol takes one to two business days of dedicated work to get a drafted, released, executed, and report written up. So I think that’s probably a fair estimate of how long it would take.
Ann McGuire
Great. Thanks. And then Jason, we have a big question for you. How long does PQ typically take and how much does it usually cost with MEDIcept?
Jason Gromek
The No. 1 question, how much does it cost. It takes anywhere from four to six weeks, and that’s assuming everything’s in place, your validation, the environment’s in place. We do require an email address. We need a unique email address to validate. So we need that. We need a point of contact with the customer. Assuming all that’s in place, it takes four to six weeks. And to date, we have not had one exceed $20,000. So from a cost-savings standpoint, it’s pretty efficient.
We’ve done big ERP systems that have been $0.5 million. So it’s pretty cost efficient. Not saying you might not be the first one to go over $20,000, but if you don’t customize needs a lot of out-of-the-box solutions, then we have not had one go over $20,000.
Good. All right. And then circling back to requirements. The requirements world is included in the Arena Validate package for IQ and OQ. So if you, the Arena customer, want to investigate requirements world functionality, using them, validating them, you can contact your account manager or customer coach for more information. And I think that’s it.
Ann McGuire
Oh, let’s see. This is somehow back to requirements, another requirements question. Clarke, was requirements included in your PQ, or are you using the requirements world?
Clarke Medigan
So we went into requirements and we investigated it. But at that point, our requirements of our designs were set in our paper documentation and we didn’t want to have to recreate it in the electronic system. So we didn’t end up using requirements in our instance of Arena.
Ann McGuire
Okay. And then this one, I think we talked about this a little bit with maintaining PQ, does MEDIcept design PQ so that it can be reused for future releases?
Jason Gromek
As long as there are no major changes, and by major change probably about a year ago, there was a user interface change where the colors and everything changed. So a lot of that stuff had to be, it doesn’t necessarily have to be redone, but you do test cases. And when you do test cases, you do screenshots and you walk through exactly what the user’s going to be doing in Arena. So they are designed to be reusable. The only time that you would have to reuse them is if there was a new feature, a new request, or something we need to do impact analysis on, or something changed that we’d have to reuse them, but yes, they are designed to be reusable.
Ann McGuire
All right. And then follow on to Clarke, Instylla, do you revise for future releases?
Clarke Medigan
If we are re-executing a protocol, we go back on the front end of doing any revisions to the protocol, run through it, make sure it still matches everything that’s within the system, that the workflow is still the same that’s in the protocol. If there are differences there, we’ll reconcile those differences before we execute so we don’t end up with a ton of deviations at the end of the report. Typically, we’ll revise them. It’s not usually a huge revision. Usually, it’s adding a step here or there or updating some field text, if that’s changed.
Ann McGuire
Yeah. That makes sense. Okay. I guess this could be for either of you, so probably both of you get ready with the answer. In your experience, what are some of the areas that auditors pursue for software validation of Arena?
Jason Gromek
I can go first. Typically, you’re sending in an audit and they say, have you validated your software? And you say, yes. And then they say, can I see it? And you show them the documentation and they say, okay, so that’s about it. So they look for IQ, OQ, PQ, and I’m not putting down auditors by any way, shape, or form. It’s just, you get a lot of varied backgrounds when you get auditors. If you get somebody that really knows software validation, then they’ll dig into it. If you get somebody that’s just looking to see that you did it, then you’re going to get that.
Again, the whole IQ, OQ, PQ, it goes around process validation, does the same thing around non-product software validation. So it was basically what they’re looking for. They want to make sure that you identify the requirements 14971, looking for risk analysis. So we provide that, and then you test cases and traceability, so we can provide traceability from the beginning to the end through the validation process.
Clarke Medigan
And I would add to that. What we’ve seen is that they’ll mainly look at the software master validation plan. They usually key on any deviations there or any failures you had during your protocol execution, they’ll look right at that first and then go into those in great detail before they go anywhere else. But then the second thing they’ll look at is to do tracing of your requirements, making sure that they trace to your risks and making sure that all of your requirements and risks have been adequately addressed within the protocols.
So what they’ll do is they’ll look at software requirement number one, user need number one for Instylla, and then they’ll look at all the risks associated with that, and then they’ll dive into the protocols and reports and look for where those were addressed as part of the protocols in reports to ensure that the requirements were met.
Ann McGuire
Yeah. Here’s another common question. How do you validate “backup and restore”? Let’s start with Jason.
Jason Gromek
So same deal. You validate what your testing. So when I’ve gone through the sales process with Arena, they have SOC compliance or SOC1 and SOC2 compliance with their data center. Some of the backup and restore functionality is covered with that, the redundancy and the 99.9% uptime and stuff like this are covered through the SOC compliance. If we wanted to do this, in cases where we’ve done the backup and restore, it is just the same thing, is sort of a validation workspace, you kill it, you delete it. And then you get with one of the solutions architects and have them put it back up and make sure that the information is there.
Ann McGuire
Good. Do you have anything to add to that, Clarke?
Clarke Medigan
So for backup and restore we relied on the Arena validation for that since it’s something that we couldn’t really simulate internally.
Ann McGuire
Yeah. All right. So Jason, do you validate Arena integrations with other programs such as NetSuite?
Jason Gromek
Absolutely. Anything that you’re using, if there’s hooks in and out of an ERP system, CAD systems, NetSuite, again whatever the installation is, those all fall under customization. So the more integrations you have with outside systems, you got to demonstrate that the hooks are in place. The stuff comes in and picks up at the right time. It gets pushed and pulled at the same time or at the right time. But yes, absolutely. So with those, there’s going to be a different set of requirements built around those that we have to establish.
Ann McGuire
Yeah. And I imagine, especially at an Arena to ERP integration would be pretty, that’s pretty normal. You probably have templates and kind of experience with that.
Jason Gromek
We definitely have experience with it, so yes. A lot of different systems.
Ann McGuire
So thank you for sharing with us today.