Compliance in the Cloud: What you need to know about computer system validation when moving your application to the cloud

Welcome to this, this this session today. Talking about compliance in the cloud. A topic which, is is really quite relevant, these days, and we'll begin to see the relevance. As we work through the presentation. We'll start off with just a bit of scope, then we'll talk about computer system validation. Just a a bit of a brief overview about, what it actually is and why we do it, really so that we set the scene for the for the for the slides and the the descriptions to come. Then we'll talk about what a cloud software as a service systems how they compare to locally installed systems, and particularly then how that, how that pans out in terms of the validation process and the validation documentation, while we look at the considerations that you need to that you you really should think about, when you're validating cloud software as a service systems, and we'll then end up with the vendor and, at the end, we'll take some, we'll take some questions. And I think I think I'm correct that you can you can start logging your questions as we go along, as, as, as questions, come to you. So, just just in terms of the scope, just, just that we don't, we will start up with the same understanding. During this, this this this walk through, we'll, we'll use Phoenix hosted and integral repository as examples of Suttara software, which is hosted in the cloud. There are others like Pinnacle twenty one, but, phoenix hosted an integration service rather good examples, for for this particular, webinar. They're both we can send them both to be commercial off the shelf software, so we don't have to worry about, custom development. And when I when I refer to you and your, I'm really speaking in rather generic terms about custom organizations. So it's directed at, as as you as customers, are using these systems. And sort of a bit of a caveat that, in recent years, there's been a bit of a move away from the the the rather vigorous total testing has been in in validation to a risk based approach and even more these days trying to really concentrate, the validation efforts using critical thinking, as well as risk based approach, aiming to provide a high level of assurance, and then we we see it now being called computer systems assurance rather than validation. But we'll assume that what we're talking about here is, when I talk about computer system validation, we'll include all those methods. So we'll keep it at a fairly high level without going into those those details. And, and again, another caveat that The information that we're presenting to you today is for your information. It's an overview, but you really do need to seek professional advice, from the appropriate, qualified people on validation topics before before you embark. So with those with those caveats in place, let's, let's see what sort of precipitates this type of discussion and and maybe why we're doing this, presentation today. The use of cloud software has been increasing over the last few years. And we see maybe questions like this, and not these exact questions, but I've, I've created questions which are somehow typical we get the questions of, his integral, is Phoenix hosted validated? And Sitaras validated the systems that they're supplying and can supply all the documentation to go with it, so I don't need to do anything. Is that right? I'm not going to answer those questions now. We'll come back at the end and see the answers to those questions. But they're they're they're not atypical questions. And you'll start to to see the answers to those questions as we go through the through the presentation. So what is computer system validation? And then we'll we'll ask about why we do it, but you'll see lots of definitions of computer system validation The FDA has one. It's here. It talks about objective evidence. It talks about software specifications conforming to user needs, They tend to be rather convoluted. One at the end can be consistently fulfilled. Maybe needs a little interpretation. The OECD, the one I actually like, it goes into more detail, and points out very specific things, like, demonstrating throughout a systems life cycle not just at a point in time, but for its entire existence, that it's good for its intended purpose. Provide the validation process provides a high degree of assurance, systems meeting predetermined specifications, So everything's embodied in these descriptions, but over the years, I've, I've rather come down to thinking it in a more sympathy in a more simple way. So in a nutshell, we think about does the system that we we're going to use do what users wanted it to do? Does it fulfill the basic requirements that, that we were after? Does it work reliably as intended and reliably meaning for the entire time we're going to use it, which could be years. Is it reliable? Is the validating that status main pain over that period of time, we don't validate systems at a period of at a period in time, and then forget it we have to make sure that the valid status is maintained over time. If you make changes to a system, it could have an impact on how the system's working. So you have to have the system under control and maintain that original validated status. And lastly, do you have documented evidence to support this? And this is possibly as caught in a regulated environment This is most important, and you can actually provide some evidence that you you've done all these things. And we we would those of us who have done validation for many years have been through this many, many times. Why do we do it? Well, the the answer is actually very simple. We have to. If you want to submit any, any sort of, Gxp days to regulate your authorities, you need to be able to show that your systems have been validated that they're performing according to your requirements, and they they work reliably. Fundamentally, that means that we're trying to reduce the risk to ultimately to clinical trial participants and patients by ensuring that all the safety data we generate is reliable. And it's that underpinning, that underpins a lot of what we do in the regulatory environment, and computer systems are no different. And of course, many of you would be aware that, there are consequences, public consequences for, for progression of regulatory submissions and documenting, deviations from from the requirements. If, your systems are inspected by agencies and found to be lacking in validation, they'll be publicly cited. So that's that's the sort of why we do the staff, what what we do, why we do it. If we think about using, if we think about cloud software as a system, cloud software as a service systems, and think about, Phoenix hosted an integral. What are they? What what do we mean by a cloud software as a service. Well, in in general terms, we can think about them as being computerized systems where the the application software or the system, the whole system is installed, managed, and accessed remotely from your user's side or your your organization. So it's somewhere outside. And that doesn't mean everything's managed by vendors. Companies companies, companies establish their own cloud based systems, their their own clouds, but those are under their own direct control. So there are no different responsibilities here to whether you're using your own in house cloud system or your own in house on-site system. It's a matter of responsibility and everything is under your control and, under your responsibility. Probably many cases under your IT department's responsibility. But where we the the third type is where we have a, is where we have a third party vendor. The vendor will be installing and managing the system. And in that case, some of those responsibilities are passed to the vendor. And that's the very important one, and that's the one that's the one we're going to be discussing, now as we as we progress in this, where where you have a third party vendor you have the sharing of responsibilities. In general, the advantages of using vendor hosted systems in terms of the customer, you gain flexibility. You can implement new systems very quickly. You can scale them usually very easily. You can reduce your own overheads, the need for maintaining the IT infrastructure, and your systems are generally up to date, and I guess there are there are systems we use every day where we don't think about it. They're in the cloud, and they're always kept up to date. We don't have to worry about them. And that's those are the big gains from, cloud services. The vendor, on the vendor side, they're now providing the platform, the application software, They're supplying a lot of the validation, exercises, and the documentation to go with it, and providing all the maintenance activities and system upgrades and those sorts of things. So those things that, are good for the the customer a sort of passed across to the vendor. The some of the considerations and risk for using vendor software, vendor hosted, systems. You are operating still in a highly regulated environment. And in that environment, you do not have direct control over the system, its implementation, its validation, and its maintenance. Those are all now being done by the vendor. But as a customer, you are still responsible for the data integrity and ultimately the, the patient trial participant safety. And really, in line with any other sort of subcontracted service, you might have, there are additional risks. These are these are some of them, but in general, passing some of the, your your passing work and some responsibility and certainly tasks across to your your subcontractor. And in this case, it's the vendor who's hosting your your your computer system. If we look at some exam if we look at the two examples we've been, we've been talking about, Phoenix hosted, let's have a look at that. It's a PK computational tool. It's a commercial software, commercial off the shelf software, with, with very limited configuration. It's hosted in the Amazon Web Services infrastructure. It's installed in a single tenant environment. For those of you who are not IT based, don't worry too much about that, It means you get a customer specific implementation. It's, it's implemented just for you as if you were, as if it was installed locally for you, it's installed in the cloud for you. And you log into it as you might expect to log into a local piece of software. If we look at, Sartaro's integral data repository, It's also commercial off the shelf software with limited configuration abilities. It's also hosted in the in in of Amazon Web Services, but this is installed in a multi tenant environment in the majority of cases. Which means that there is one installation of the system and every customer gets access to that installation. That's what multi tenants really refers to, and the use of the system is, is granted by, by license control and customer specific access, but you're still using the one system. You're using it as if you were the only user, but, you're you're using along with the loss of other people. And though that has consequences really in a way for the validation exercises. So we need to understand that not all cloud, software as a service implementations are equal. They're not. And you really do need to understand something about the system architecture before you start, thinking about the validation and use of the system. It does it can make a difference. So the golden rule those. Yes. Understand what it is you're actually using and how it's working. The validation processes, let's, let's let's have a, I think about that, and this is what, this is possibly the crops in it now. Let's let's just have something to compare with the let's think about a customer local installation in a in a simple way. Again, thinking about commercial off the shelf software, something like Phoenix. If you were installing it locally, you'd probably go through five general phases. Some preparation for your implementation. The implementation phase itself, some testing, you'll put it into use, and you'll need to maintain it, all the time you're using it. And these are the sorts of documents, typical documents that you would be expecting to generate during that process, has the customer doing it locally? You would certainly start off with some user requirements. Otherwise, you can't assess whether the system meets your requirements. You'll conduct some sort of risk analysis about the system you're using and the environment you're using it in. And you'd probably want to do some audit of the vendor who's supplying you the software. And I'll just point out here your you would then be auditing the vendor software development processes. In the implementation phase, you will have you'll generate a validation plan, which will outline how you're going to do it, you may, if you're building some some infrastructure, some servers, you might need to qualify the the building of the servers and you'll want to qualify the installation of the software. In the testing phase, you'll have your system test, maybe some acceptance test, traceability matrices, and validation reports to summarize the entire validation effort, And when it's in use, you'll have your policies, procedures, the training, the logs, access control, logs And when we come to the maintenance, you're typically thinking about incident management, change control, problem resolutions, backups, disaster recovery, that sort of ongoing maintenance, version upgrades, that sort of thing. I've listed at the top that, in some companies, you may actually have a formal, service level agreement with an IT department. Who is going to deliver those services, sometimes not, but there will be some understanding that an IT department would be would be handling these sorts of things. If we then compare that with the sort of process, we might follow for a cloud system, a software as a service, system, and think about the same five phases of our of our project. Starting off with what the customer might be doing, the customer still needs to generate those user requirements conduct a risk analysis, and perform a vendor audit. In this case, the the vendor audit although it might also be the software, we'll be auditing the vended the vendor systems around, the the implementation the validation and the maintenance of the system. So this is a this is a different aspect now. We're auditing our vendor's hosting abilities. If we think about the vendor, the vendor will be putting in place a validation plan qualifying infrastructure if it's required, and performing some installation qualification, running installation tests, They'll be performing system tests, acceptance tests, generating the traceability, and, validation record. To support the vendors, the side of the, of the process. But at the same time, the the customer also needs to be documenting these activities. So you maybe typically expect the customer to be having a validation plan and a validation report, which might summarize their own activities as well as what they're seeing from the vendor, and I'll come back to that. When it's in use, well, the vendor will be providing policies, procedures, access control logs, all those things you would expect. Because they're hosting the system, and those will be geared to the hosting and maintenance of the system. From the customer's own side, you also need policies and procedures for the use. You need user training, and you need logs. Of of of how the system's being used. When it comes to maintenance, well, again, this falls to the vendor. The vendor's hosting the system. So the vendor's taking care of the incident management, problems, change control, backup, and disaster recovery. But the customer needs to ensure that those things are being done, and that's normally wrapped up in a service level agreement. The contractual basis with the with the vendor to ensure that those things are done, and and they would meet the customer's requirements. So the focus of activities then, from the from the customer point of view, user requirements still needed, questionnaires, vendor audits are are really now an important part, a very important part. Of the cloud validation process. And you're really looking to see there, are you as the customer com comfortable with the vendors' processes and all the documentation that supports it, and does it meet your requirements? When you're conducting an audit, you'll want to conduct that audit based on your risk analysis, and being prepared, so that not not quite an instruction as it's written here, but being well prepared can ensure that you cover the the points that have highlighted in your risk analysis, you use some risk based approach to the to the audit because with the best will and you can't order everything. If there are gaps you find in the in the audit process, those you would want to assess and create some, remediation plan with maybe additional tests. And I would say then discuss with the vendor if there are gaps, they may be able to fill the gaps for you. So if you have that work with the vendor, The vendor importantly is providing all the evidence and the documentation on your behalf that you may need. So you do need to ensure that it meets your needs and you can defend it. But it's also not realistic to expect the vendor to be able to adopt your own documentation and your own processes it's more important that the content of those documents is acceptable. Then in terms of the validation plan and the validation report, this is very much an individual thing and may be driven by your own internal processes. But typically, the validation plan will include some summary of the process that you will use. It would probably include findings from the risk analysis process. It would almost certainly detail some feedback from your vendor audit and any findings remediation plans or additional testing that you might want to do. You could include there any lists of documentations that are available from the vendor that might be an appropriate place to record that. And details of the ongoing maintenance, even if that's, a reference to the service level agreement. And ultimately that report, that validation report is confirming that the vendor's validation and any additional validation that you've done is acceptable. So it's that overall confirmation that you're accepting that the the vendor's work, is visible. And the service level agreement, that's just restating, really what I said before, but it does define the responsibilities of the vendor to maintain the system, and it ensures that, the validated status is maintained throughout the peer reviews of the system. And it should it should include those things that we, we we saw before. And I I saw I saw this, in this quoted when I was doing some research for this. I think I quite agree that if it's not in the service level agreement contract, then you shouldn't assume that the vendor will actually do it. So this document becomes, really rather important. Just thinking then about Suttara and where Suttara fits, as a vendor. Suttara then is a has a really solid track record of, of building this type of software for the pharmaceutical industry. It understands the regulatory regulatory framework and the constraints of that places on users It does have well defined software development, process and procedures, and it has a very well established quality process. And Satara now has a well documented validation process for it's, it's it's hosted, cloud hosted systems. And those processes can reduce the overall risk and increase the insurance for for users. And I think that's a that's an important thing. What you're looking for is a vendor is, is is somebody you can you can partner with who understands what you're trying to do and has all these things in place. That's not always the case. As if you read case studies, you you will see that. So let's, let's, just move towards the end and look at these questions that we started off at the beginning. Are the integral Phoenix hosted, systems validated? Well, the answer is yes, and no. Sataara validates the software and the implementation of that software in the cloud as the software as a service. But that's only part of the overall validation effort that's required. So it's not the whole thing, but Satara does it's part as the responsible vendor. And Suttara has validated the systems and can supply the documentation. That's correct. So you don't need to do anything. Is that correct? Well, that's not correct. The customer still has to do quite a lot of work, not as much of the practical work but still responsible responsible for establishing that the vendor's work is appropriate and that it meets the requirement. And, Satara as a vendor, can provide that documentation that you may need in a in a way that, hopefully meets your meets your requirements. So, summarizing all of that The critical elements from the from the from the customer side of the the process, the user requirements, the risk analysis, the vendor audit, the validation plan and report to document all that and the service level agreement. If you if you if you familiar with the area, I hope you agree, these these do now tend to be the the focus of the customer's effort. And on the other side of it is the vendor has good procedures. You can have a a high level of confidence in how the system will be both implemented and maintained on your behalf, and that reduces your risk as a customer. And and gives you the assurance that the system will be will be delivered in a validated state and it will be maintained in a validated state. The last slide I have here is, a slide I extracted from a case study, which was published by the UK MHRA, the regulator authority in the UK. And I think it summarizes rather nicely the responsibilities here. Remember that from the customer's perspective, remember that the vendor may have produced the software or the system, but you're the one using it in your clinical trials in your safety studies, whatever. And the ultimate responsibility is with the sponsor. So you can't just assume that a piece of software has been validated Because if you make those assumptions that are not correct and it causes data integrity or patient safety issues, that remains the responsibility of the sponsor. Not the vendor of the of the system. So I think and the last the last point, which isn't on the slides, is that very much in this case, like any other sub- subcontracted service. There's a there's there's room for a good liaison and a good relationship between customer and vendor, to to make this, to make this a good, a good situation. Sebastian, and I'm, I'm wrapped up, quite happy to take as many questions as, as people have. Yeah. Excellent. Thank you, Clive. It was a great input And, again, please feel free to submit your questions, through the chat. We will address them. We have our experts Clive here and also Dave Baker and they're happy to, to take your questions. We already have I see two questions right now, and let me start with, that one. I want to know more, is the question. Where would you recommend me to seek advice or greet? More about what you are talking in the presentation. So he wants to take it, Okay. I'll I'll take that one. I I mentioned that at the beginning that you you need to to have some professional advice. I would start off people will either have access to an internal quality team, and though those will be the first port of call. If you've got an internal quality team, go talk to them. Ask, ask questions, try and describe what it is you're you're planning to do as a as a user and get get their input. If you use an external quality partner, then, yeah, again, talk to them. You can read around the topic. If you if you really want to, you can go to the Regulation Authority sites and read their requirements, their guidance, in the regulatory framework, search the web with care, not not everything is, read it carefully. Publications like the GAAP five guidances are very good and and written written very well and very clearly and give you good advice. There's no substitute for talking to people who are expert in the area, like your quality teams, and reading reading some of the good literature that's out there. And talk to talk to the vendor, you need to maintain some independence, I suggest, but, your vendor can give you maybe a lot of the information you need to go away and ask targeted questions. And so if it's our point of view, if you if you ask questions, then, then you can be pointed in certainly in the right direction. Okay. Thanks for that for that insight. Great. Before we take the next question, let me mention, a webinar we will be having this week. Actually, it's, on Thursday. You heard Clive talking about integral, and we will have a webinar where we will present the solution in in more detail. And, yeah, well, I will post a link here in the chat where you can sign up and learn more about our, solution integral. Alright. Let me see. And let me take that second question we have. Here, that came from the audience. And the question is what sort of validation documentation can satire provide to support customers? Any one? Dave? Yeah. I'll take it. Okay. I've I've got a backup slide. I thought this might come up. So I've got a backup slide on this as well. Okay. Right. Alright. So as part of a speaking specifically about Phoenix host, and I can touch on, integral in a little bit. But, During an audit what you'll be able to see are, the documents that that you would expect. And you'll read about you'll receive documents about computer system applicability assessments, architecture diagrams, risk assessment reports, we're in the process, not yet. We're in the process of, becoming, ISO twenty seven zero zero one. Certified for Phoenix hosted. All the tools that are inside of Phoenix Host and are already in scope of our ISO cert. And you can read about our annexA controls. How we implement them? We also read a business impact assessment and a Phoenix hosted software configuration specification, a maintenance plan you know, when we were when we're gonna update your system and and so on. And then, you'll also be able to read forms that, talk about the input that you've given us. And, the first one those you'll get is a, custom product deliverable list forms. So if there's a special report, or something else that you want. You can define it there. Also your, your specific configuration, which you know, are, are, are different for, for nearly everybody, although a couple of our customers are, are very, very close. You'll also have, things like, you'll be able to see our our deployment plans and then, Also, validation plans, how we intend to validate, the system that we're building for you. And from those validation plans, you'll, you'll see a summary report as you would expect to see that, has appendixes such as a test run report and then a, a traceability report. And then a list of all the documents that we have created for you, which is the last one on the list here. The software release report, And, for each Phoenix host customer, we offer, up to three hours of testing, to help Like in one of slides, applied slides, he spoke about, gaps, which would have come out of your gap analysis. If you're, if you're If your gap analysis shows that our testing misses a few things that you do, and generally these are going to be very specific things, and you're you're open to explaining that to us. We can write a a test that tests that, and then it will come out in your validation test run reports, your traceability report, which relieves you of the the need to to do that. And for integral, integral is a a multi tenant environment. So You won't see, you'll see all the documents that I just listed, but not the customer specific. Items because integral is integral. It's, it's made for everybody. But, but all of the documents that that I listed above I listed before will be available to you, except for like the customer configuration specifications and things like that. That's all I've done. And I would say I would I would tag on to that. So we we just talked there about the documentation for Phoenix hosted and integral. I did mention Pinnacle twenty one earlier on, and kind of the same, the same sort of thing, applies to Pinnacle twenty one. You get a full documentation list, which you can, which you can read, on which you can review under conditions with Suttara. Yep. And all Suttara's software, follows the same policies, SOPs, and work instructions. Regardless of what type of software it is. So you you can expect that, not just on the, the three products that we've spoken about, but any other Sartara product that you may get. Okay. Perfect. I should say. Perfect. Thank you for for the answer. We have another question that came through, and let me read it out. I'm not sure if Edex hosted is the right system for my small company. Versus working with an external vendor for completing Phoenix based analysis or GSP analysis. What is your recommendation considering cost and size of company. Just have a go. I'll I'll I'll take a start from. For a for a small company, The the advantages that we talked about earlier on, the the the idea that you can you can you can gain access to a system without having to go through the the process of buying it, buying hardware for and installing it, you basically just dial in and use it, is very attractive for a for a small company. And, of course, then it scales very well. If you suddenly find you you doubled your number of users, well, you just they just access this offer in the same way as before. Rather than having to install it or buy a bigger server or something like that. So in terms of scalability and flexibility of use, the the hosted systems work very, very well. And your it applies to everybody but you're guaranteed a level of performance, a very good level of performance, without having to upgrade your own infrastructure, I'm upgrading your laptop with more memory or whatever. It's, you you get that guaranteed level of performance. So it works very well for for for for small customers, as well as large ones, but it is that flexibility, the flexibility and scalability of the work well, but you still have to go through those validation aspects. But of course, then you're not having to do the the detailed validation yourself that you would do if you are installing it locally. Your your effort then is inspecting and verifying that your vendor has done all those things on your behalf. So it does save a lot of time. It doesn't mean, as as we said before, doesn't mean you do nothing. You can't just, you can't just buy the licenses, log in and start using it. For your regulatory work, you do have to do some some verification and work of your own, but it's not the same as, as doing it yourself in house. If if you're a small company. And I think another point I collect just from a a practical point you is that you can do an evaluation of, Phoenix hosted or integral or both. Right? To to see if it works for you. If you just describe to us the system that you want, we can build, create that system for for you, and you can run it for two, three weeks. You know, what, whatever you need to, to know, test it, run it, see what you think. When I was starting to work on this project initially, one of the my own personal requirements was that I could use it to do my daily PK work and achieve a state where I forgot that I was on a hosted system. And that, that happens quite often on these systems for me. I I've they're very, very responsive. You know? But, anyway, that that's all. Oh, that that's odd. On a practical level, I agree with you. And from a user's perspective, the I I would say if you're if you're the kinetics working at your desk, you should never really notice whether you're using locally installed software or or hosted software that should, should all look pretty much the same. It works the same way. Yeah. So so in a nutshell and in the spirit of validation testing, I would say, just test it. Mhmm. Test it yourself? Yep. Alright. Excellent. Thank you very much. By the day for all these answers. I don't see any more questions here in the chat. So I think that's it. Again, we will send you the, recording in the next few days. And, of course, you are gonna come contact us, any time to to learn more, about compliance and what we can do, to help you with your challenges. With that, we will wrap it up for today. Thank you to the audience again. And, to our speakers today. Clap and, and Dave, and with that, Okay. Have a nice day. Take care. Thank you very much. Bye bye. Thanks. Bye bye. Bye.