Add Sponsor Validated with airSlate SignNow

Add sponsor validated

hi everyone thank you all for joining today's webinar how to ace your staff based EDC system validations for sponsors and zeros presented by FCC and QA CD consulting we appreciate you taking the time to listen in and watch our presentation today my name is Melanie Ciotti I'm a business development associate here at SCC and I'll be moderating today's webinar I have some basic housekeeping notes to share with you before we get started on introducing today's speakers first we are recording today's webinar and we get this question a lot we will be sending out the recording to everyone who registered for today's event as well as the slide deck so you should be receiving a link via email within the next 24 hours following the event additionally you have the ability to listen and via your computer speakers or you can call in with the telephone information provided in the GoToWebinar panel we'll be answering questions in a Q&A session at the end of the presentation so please submit your questions in the chat box throughout the presentation as your questions arise we'll review them off the end we don't have a chance to get to all of the questions we will try to respond to them via email and follow-up to the webinars and permit finally we'll be pulling the audience during the webinar so if you are at your computer and we greatly appreciate your participation it's a pleasure to introduce today's speakers Chris will vote principle at Q ACD consulting is an expert consultant for quality assurance compliance and computer system validation and the FDA regulated life sciences industries with over 25 years of experience Chris specializes in data integrity computer system validation and compliance GCP audits and training and quality system development Chris was a contributing member of the ISEE GMP laboratory system special interest group which published the good practice guide validation of laboratory computerized systems Chris was also a chapter chair and editorial board member for CIA's recent publications computerized systems and clinical research current data quality and data integrity concept quando n-- associate director EDC solutions at FCC has over 15 years of clinical data management and clinical programming expertise he currently man our EDC solutions and clinical programming department here at FCC Quan specializes and clinical data management system selection implementation and software validation and he also has experience in software Quality Assurance he has validated both internally hosted and staff based EDC systems for SVC and for other companies as well including validation of Oracle clinical RDC open clinica and I meant that you clinical for today's webinar Chris will share his expertise and discussing what auditors want to see in your validation documentation then you can adapt into intended use validation for sponsors and see arrows using staff based EDC systems Kwan women sharing best practices for implementing an ADC validation using FCC's intended use validation of I'm bed net clinical as the case study example and pulling from previous history as well after reviewing some key takeaways we should have about 15 minutes left Panther Q&A at the end of the presentation so like I mentioned before go ahead and submit your questions as they arise in the chat thank you again for joining us and with that I'd like to hand it over to Chris Thank You Melanie and I appreciate the opportunity to provide this presentation to the audience and to participate with FCC on describing best practices force software-as-a-service validation and what I'd like to do I perform a lot of audits for different organizations and I'd like to go through and describe some of the things to look for when an audit of a software as a service provider is conducted and also we'll go through some of the aspects of data integrity that's to the FDA and regulatory agency focus at this point and there's clear expectations that systems don't not only are required to be tested but we have to understand and ensure that they're used appropriately for clinical studies based upon the study protocol requirements and to meet ECP requirements just a quick overview of data integrity and again that's the key of any validated system is ensuring that the data that's collected and maintained is complete that is consistent and that its accuracy because that data is then used to support regulatory submissions and all data including data that is generated and maintained with a SAS application software as a service application is required to meet Alcoa principles the core elements for Alcoa include attributable all records and beta must be attributable to the person who answered or completed that data it must be legible and that's easy and straightforward with paper but legibility also includes the electronic records and ensuring that the appropriate formats and structure of the data is readable and viewable electronically as well for software source applications contemporaneous so data needs to be entered and the auto cradle needs to be for the date and time that the activities were completed and identified who actually completed that data data should be original or true copies of original records for electronic records the original records are actually that may be more difficult to have a true copy of an electronic record so some consideration is regarding validation need to be incorporated when you make backups and proof copies of the original record as well and all day they must be accurate and a lot of time as that is included and the ever text and the data cleaning processes and then for electronic records there's the concept of L flow alcoa plus all records must be enduring you need to have the records available electronically throughout the record retention time period for thee as required by DCPS the records must be complete which includes all metadata and any other attributes associated with the electronic data including audit trails the data must be consistent and it must be available for review during audits or inspections or review of Records for regular submission so what what is computer validation and why validate so computer validation is documented evidence which provides a high degree with Joran status system consistently performs according to its pre to current specifications and quality attributes and validation specifically is required by 21 CFR part 11 10a which states that for closed systems really all electronic record-keeping systems validation is required to ensure the accuracy reliability consistent intended performance and the ability to discern and valid or altered records so if you look at what we had talked about with data integrity the ability to discern invalid or altered records is really a data integrity principles so we validate to ensure data integrity so what is validation and some of you may be IT or QA professionals others may be clinical professionals so I'm going to go through basically what is validation from an ID from a user perspective and the validation is really just across if you have a manual process that the manual process is automated so if you identify with the key steps or for the manual process for example for an ADC system you have study setup you verify edit checks are accurate and complete you answer data there's data reconciliations on a database lock or other elements also the foundation is really automating that process and the back key deliverables when you automate a manual process for a validated system or the user requirement specification where you identify the intended use that information then is used to develop specifications for the system what the system actually will do to meet the user requirements and then validation testing and sometimes for users it's primarily user acceptance testing that we're really just verifying that the users that the system has been set up and configured properly according to the specifications and that's an independent process from the setup and configuration process so we're verifying that the requires have been that and I wanted to include a section here on this is software-as-a-service so it's a for a DC system that's common and some of you may be familiar with internal systems like maybe the older Oracle clinical clinical data management system which was installed internally at many companies and all the validation activities were completed by the user by the sponsor and the software the software was provided by the vendor and the vendor had an S DLC software development lifecycle process where they developed quality software according to their procedures and processes and then that software then as sold were provided to the sponsor and they installed the software on their servers and workstations the deliverables for validation typical deliverables and again your own SOPs need to be followed but typical rules for a and Cha relation would include the validation plan requirements functional specifications configuration specifications the vendor the sponsor would then install the software on the servers they would be assistant testing sometimes they may be called operational qualification testing and user acceptance testing there'd be a traceability matrix that would link the specifications to the test Backman tation a validation summary report will be generated summarized the validation activities and then there will be SOPs on using the system and maintain the system in a validated state and ensuring the integrity of the records that are collected on that system so that's normally for an internal vendor or internally hosted validation the expectations and then if you have a software out of service vendor there are some differences and how the validation is conducted so and for a software the source application the server is maintained and the software is installed and maintained by the vendor and they also take on their spots village for some of the validation activities the user or the spots are still a shock for for validation plan they're still responsible for determining the user requirements or the intended use of the system and they are responsible for conducting user acceptance testing and having traceability matrix and validation report and some SOPs as well for the use of the system however the vendor takes on some of the responsibilities for validation including in addition to their SPLC deliverables the rules that are generated as part of their software development lifecycle process they also generate functional specifications configuration specifications since the software and hardware is maintained and managed by the vendor they also responsible for installation qualifications and also doing the core validation of their product and they would have traceability matrix and their own SOPs as well to ensure that the system is used as intended they also need to have release management practices and then for any vendor and sponsor the quality agreement which defines roles and responsibilities which recipes will be followed how changed and goals managed and things like that would also be required so those are the key differences between a internal validation and a software-as-a-service validation all systems are still required to be validated the sponsor or the user is responsible for validation but on a software as a service platform the vendor assist in the validation process and supports the validation process for the sponsor okay and again the focus is on the intended use of the system as opposed to just testing the system that's how the system is set up to support a clinical study based on the protocol requirements the perception that many people have is a validation of the vendor Griffin the validation is still supported by the vendor software outsource applications but the user or the sponsor are still the primary they're responsible for the validation of the system second that they can rely on the vendor to support that as well but the user is responsible for the validation of a system if the navy c system is invalidated the ABC vendor will not get a43 it will be the sponsor business processes many times for vendor driven validation are not validated so again the intended use is the business process or the process that's set up to that's set up to support the clinical study based on the protocol requirements and to focus for vendors are typically on functional testing and it really needs to be law have the system set up to support a clinical study FDA they published a guidance document recently on the data integrity the guidance is specific to GMP s but the FDA data is data so many of the concepts within the FDA guidance can be applied to TCP as well and the FDA states that if you validate a computerized system but you don't validate fortunate ended juice you cannot know if the workflow in this case where the study has been set up correctly so a study or workflow there's no kind of decent computerized system that's checked through validation so that's an important concept to consider as opposed to relying on what the vendor knows primarily for testing the functionality of the system the MHRA also has a guidance document the guide original guidance document was published in March of 2015 again was for GMP as well but in July of 2016 the emitter a published a guide draft guidance of the same guidance document but it applies to GX keys so they are expecting the same type of controls for data integrity for GCP as they would before GMT data other graphic items reflects that I think FDA will follow that approach as well because again data is data you need to have controls for data but the right now the FDA got is only for GMP and the MSA guidance states that you're required to have an understanding the computerized systems functions within a process again the process to ensure data integrity for a clinical study for this reason just relying on vendor documentation and an isolation of the study protocol requirements or the system figuration of how edit checks are set up and things like that or user profiles are set up is not considered to be acceptable and they stay pacifically in isolation of the intended process for the users system the user study that's the setup within the system vendor testing is likely to be limited only to functional verification only and may not fulfill the requirements for perforce 12 occation or user acceptance testing again the user is the sponsor the vendor is not the user so user acceptance testing is called UAT because it's suspected to be done by a user representative chris before we go on to Quon you have some polls that you wanted to ask the audience so I'm going to pull up the first one right now if you guys can see it so if you can go ahead and answer the true/false question if you're at your computer you alright looks like we have about three-quarters of people who have answered so far so I'm going to go ahead and close the poll in just a few seconds alright so it looks like four so the true/false question is 21 CFR part 11 provides specific guidance on how to validate computerized systems looks like we have 23% stay true 65% safe false and 12% say I don't know Chris do you want to elaborate on that sure part 11 requires the the computerized systems to be validated based upon 21 CFR part 11 10a but it really only states at validation of computerized systems is required it doesn't say how validation is required or what the requirements are for validation but it only states that computerized systems are required to be validated a better use for GXP or jcpoa purposes there's other FDA guidance that discusses in more detail what the typical aspects of validation are and we went through those in the earlier presentation the user requirements evaluation plan and the testing protocol test plans and the system specifications the validation reports and so forth those are all elements of validation and part 11 again only requires has a statement that validation is required for GCP systems thank you now we have another one I'm going to show right now let's launch the poll commercial off-the-shelf systems do not need user requirement specifications true/false or I don't know alright looks like we have most people most attendees have answered at this point I'm going to go ahead and close the poll just a few more seconds and share that with everybody all right looks like most people said fall so close they're commercial off-the-shelf systems do not need user requirement specifications consensus seems to be false Chris would you like to elaborate everyone's correct because all all computerized systems that are used for GCC purposes need to be validated and you really can't validate a system without having user requirements because that again is the intended use of the system and otherwise you just have functional functionality that can be tested but it may or may not be used as part of the intended use of assistance to support a clinical study and now Kalon will take over the next part of the presentation Thank You mo and Chris so now we'll be going over the best practices on actually implementing during 10 deduced validation for your EDC platforms we'll take a look at what SDC did for the our i magnetic little platform which is a SAS based platform so looking at the four phases of validation again chris mentioned this earlier in his presentation you know system violation whether it's for intended user or not is relatively the same you have very similar phases for those for this validation process and so we'll be going doing a deeper dive into each of these phases on throughout the presentation so in general we have your planning phase four requirements analysis the actual u8t itself and then releasing and maintaining your valuated state thereafter so for validation planning thinking about the intended use validation the world of EDC platforms is constantly evolving and we've seen an increase in the trend of all-in-one platform so if you look at the metadata raised emerge-ii clinicals I'm n that you notice is there a lot of add-on module that are part of your platform you may have an ego functionality CTMS or CEC function a built in but as a CEO or a sponsor if you are not using that module there is no need to do that knowledge because you're again putting tenant use you're not using it so the key piece and validation planning is to determine the scope of the validation you know have all of your key stakeholders in the room and determine what you will be using how you'll be using it and if it can be validated again the key stakeholders you know involved in this valuation process are your process owners so for your data management team making sure that they understand how the system is going to support their processes they are also the end users so TP and mine site users monitoring monitors what their functionality needs to be from the endgame standpoint and make sure that those those components are validated and then obviously you do need Quality Assurance involvement in this step for a number of reasons want to make sure that you are meeting all the regulatory requirements in terms of validation as Chris mentioned earlier and also to review the components that we as the end-users can validate and lean on the vendors and go through the vendor qualification audits to cover the house how the vendor is going to do their implementation or releases for each version of the system and again remember that if we look at the internally hosted systems where you have ownership over the hardware you know that's one that you can't actually normally do a hardware qualification make sure that the servers are up to spec and can handle the volume and love that you're going to be using whereas you don't have that in a software as a service based platform and so it's going to be key for your QA team to go out and review the vendors capacities to make sure at least their equipment is up to par with what you feel the system needs and to make sure that they when they do their suffer develop they are within regulatory compliance because we are in this regulated industry the next phase is requirements analysis we do have several layers of requirements and Chris kind of touched on this earlier for the actual intended use validation the key focus here is on user and system requirements at this point you should have already covered your business requirements prior to selecting the EDC system so if you think about something that would be a business requirement it would be something like you know the system needs to be user-friendly it has to have a nice looking interface shouldn't cost more than X amount a month because we can't cascade that down to our clients or must contain high level modules such as IWR or CEC so those are your business model requirements those are more difficult to test and so when you're developing your user requirements and your system requirements need to make sure that they are clear verifiable and concise this these requirements when you define them really should state what the system should do not necessarily how the system will do it but because a lot of times there are many ways within a system that you can achieve the same and end goal and so you want to make sure that you keep your requirements at a level where you don't get too detailed and it becomes confusing for an honor to review the other key component here is to make sure that your regulatory requirements are included so as Chris mentioned earlier looking at 21 CFR part 11 you know there's a requirement for other trails and the components of what that audit trail needs so make sure that those are clearly laid out in your requirements analysis cycle part 11 if you are planning on using a system outside of the US and the EU for example you also want to make sure that your annex 11 requirements are also met they are similar to the part 11 but as you read through the guidances you'll notice that Europe does go a little more detailed in terms of your requirements and so you wanna make sure that that's kind of different planning on going global and using your receipts your EDC platform on the next slide we'll go over a couple examples of good and bad requirements so we'll take a look at that so looking up here on the screen so the first requirement here that's written has the system some prevent users from accessing the system upon multiple failed login attempts now from a testing standpoint or from actually from a reviewer standpoint what does multiple mean each person looking at this requirement can can take this as well I'm going to be more conservative I'm gonna say multiple multiple means at least five failed login attempts and another honor here they come and say well technically two is multiple that's more than one and so to help appease that when your auditors are looking at your documentation especially around your user requirements make sure that you can be a little more detail than specified you know what we really mean is the system shut prevent users from accessing the system upon three day login attempts you know you can have a discreet and objective evidence to prove that and there's no question in that when someone's looking at your documentation another example here again this is more subjective so the system shall stay hiciera quickly how do you define quickly site users and a lot of times we're very busy people and they may say you know what after 10 seconds if it's not done I don't like it so I was a business process owner we should come up with requirements to clearly delineate what our threshold is for CRF save time so we want to make sure in this case for example the system shall save is here within two minutes it's a reasonable time point looking at especially above the Edit check model the new functionality within systems that's typically a good time frame especially for any service that contain a lot of data points and the last one here is again the bad example here that the system shall provide an audit trail what does that mean if you're looking at a software development for me that can be something very different than what we have here in the regulated industry and so as for part 11 the system shall provide an audit trail with timestamps so that's attributable to whoever entered the data when they did it when they did an update to a data point when they inserted an idiot important when they deleted a data point so we're going to make sure that your requirements cover all aspects of that the next phase really is where the bulk of the work comes into place it is definitely the most resource intensive phase as we experienced here at FCC here you need to develop your test cases for each of the requirements as defined in Phase two you'll definitely want someone that has a system experts because they understand the system well and understand the best ways to create those test cases you'll want to make sure that you can do positive and negative testing wherever possible for example that you have a user requirement that a user shall be locked out after three failed login attempts the natural progression of things you would write the test case to log in three times incorrectly and and fail that case but again you also want to validate that you can log in after family only wants or only family twice so there is where your positive and negative testing come into play test cases should also be written in a manner such that someone who has never used a system would be able to execute that test case I mean you want detailed step-by-step instructions with an explicit result again this goes back to the notion of Alcoa so that you can do consistent consistently repetitively without failure and so regardless of cost on the user is you want to make sure that anyone can use a system they need appropriate manner the other thing to note too is a lot of times the strong system is a lot of times you understand where the buds are and you know where the workarounds are and so a lot of times they may skip steps within the testing process which again introduces doubt into your entire validation you want to create the traceability matrix as Chris mentioned earlier to trace between your test cases and your requirements this is going to help your inspector auditor look at your documentation in an easy manner a lot of times you're not going to have someone sit and review you know all 20 modules of your system but they may key in on your part 11 component and they can easily jump through those test cases and review that documentation make sure that your testers are properly trained in GDP and the validation plan itself again because part 11 doesn't talk about how you need to validate that should be deep enough in your validation plan and you want to make sure that you cover yourself and your testers to make sure that there are no gaps within your validation process the other thing that's a very key to this whole process is your objective evidence so make sure that you can use output directly from the system as you're executing a test case that has your results we've had you know I've seen users who do their validation just right as expected in their results or handwrite out the result that they see on the screen but that still can be questionable in terms of how accurate it is so anything that you can export out of the system for your validation if it's exporting a report or generating a CRF case book those are things that will definitely aid in your validation intended use validation and then the last piece here in terms of uet is as we all know there's no perfect system or perfect tester out there in the world it is expected that you will encounter failures during your system validation and that's perfectly normal they may be due to test your hair and skip a step or skips or if you happen to discover a system bug these fairies should all undergo root-cause analysis and a mitigation plan should be developed for each one of those and the mitigation plans can throw a number of different ways a lot of times the objective is still met you do have to put in a workaround and so that workaround could be part of your SOPs so that again is played into intended use validation and it's not just what the system can do but how your business process utilize the system to achieve the end result and perform your clinical studies the other piece of this again if it is a system like that can't be resolved being workarounds now's a great time to relay that information back to the vendor hopefully there's a strong relationship there and they can evaluate that and correct that bug as quickly as possible so the last phase our validation is your validation summary report so once your testing is completed and all the failures are evaluated and mitigated that we're now ready to release the system for use the validation summary report should include a fairly high-level summary of all of your testing and the results and any of those failures and mitigations this document is typically where your inspector or auditor would go first during the review of your intended use validation and so you want to make sure that you contain enough information there to satisfy them and hopefully they won't dive deeper into the rest of your validation at this point you'll want to coordinate your system release with all the SOPs that were written for your system at this point in time as well again making sure that because this is your intended use validation that your business processes are set your validation is complete for your system and any mitigation processes are also available at this time a couple of other things that come in mind so now that your value of the system and you're ready to run with it you have to think about future releases this is a kind of a key point with software's of service again because we don't own the servers we don't own the installation process as an end user of software's or service platforms vendors can more or less impose their will and release software at any given time so you want to develop a process on how to handle that you know when how often you should be doing testing when you should be doing testing is it only going to be you know after hot fixes or only after new functionalities introduced those are all things that we can work out internally within your company and plans for moving forward looking at this entire process again it is pretty resource intensive and so you'll want to develop a regression test suite to test your high risk items it can be a subset of what you've already done up to this point so pointing out the key components such as your part 11 test cases and your basic data entry cases that way for every new release you can always read execute that with standard regression suite they'll definitely save on time and resources and then you still make sure that your your key bases for your operations are covered for each release we're going to go through a little flow chart on the next slide about what to do and if your software as a service vendor gives you different options during the release process for new releases so the first question that comes to mind obviously does the vendor allow you to opt in or opt out of a new version I've seen in the past with on the council master they could say you know your study can stay on this for you throughout the end of the study and so you don't necessarily need to worry about upgrading and validating that new version but for most of us and most other platforms you don't get the choice they're going to do their quarterly releases every year so there's your releases and you have to accept that upgrade so what do you need to do so if your vendor doesn't give you the ability to top top you do need to regather your validation team and take a look at you know what does this feature release impact does it have new functionality that we need to test or they modify something that was previously tested and therefore could affect about a state of your environment and how does that affect your clinical study down the road and so if if you know that you have to accept the upgrade then you can push back in the vendor and ask them you know do you provide us a sandbox prior to releasing that change into production well we have as the end user have an opportunity to test those changes and that new functionality and if they do give you that window definitely try to be proactive and execute your validation with that within that time frame I know that using metadata rave they typically give you about a month's notice prior to a new major release and they'll provide URL owners with a test environment to do their testing provide feedback and hopefully if there are no major bugs then the release will happen after that month typing this up I mean it is the same way we work closely with them they gave us about three weeks notice on a release and we get about two weeks for testing and feedback and so definitely take advantage of that if your vendor does allow for that there are some vendors that don't have a capability and so you'll want to think about the timeframe post release into production when you can revalidate or at least Rivera fie some of the functionality again you'd want to do this as soon as possible after a new release typically two weeks to a month after that release it's going to depend on obviously the company's release cycles so after releasing two releases a year typically that month timeframe is okay you have time to catch bugs early on prior to the next release if they do do you know monthly releases obviously you can't wait a month to test that then you'll be cascading on to future releases so didn't want to make sure that that's covered in your classes with the systems that you're using and again the key thing here is to make sure that you're not putting your system at risk you are making sure that your system remains in a validated state and that if you do catch any bug they are caught early on in those releases and have minimal impact on your studies moving forward so that concludes the intended use valuation or case study of the SEC I'm Annette EDT validation we're going to take you to the key takeaways to ace your audits so again intended use validation as Chris mentioned is user driven it does need to incorporate your business processes in your user requirements the key thing here again as per the FDA and EHR guidances it is focused on risk to data integrity so making sure that it is attributable legible repeatable you know for your system as for best practice for easy implementation again here you can scope down this validation to only invalidate what you plan to use as part of your business processes or offerings so you don't have to run the full gamut of evaluating all of these other components that you don't plan on using down the road again make sure that it's a requirements that you've defined are verifiable and concise so that you can test them and then the key takeaway here as well is to make sure that you do have a process in place for those new releases because again software is a service it's something that we as the end-users have little or no control over and so we want to make sure that we try to maintain our validated state great thank you so much Quan and just we do have some additional resources here for the audience logged in and like I said before this will be provided via email both recording in the project so these are live links you'll be able to click on if you need to reference the FDA guidance adjourn as the other documents that Kristin quantum mentioned previously and at this point we're right on time for some Q&A we have some great questions that came in online I'm going to relay a few have done to Chris and Quan we should get through maybe probably five or so at least so the first question I have here Chris I believe this one is for you it says the draft FDA guidance is applicable to GMP as you said and why do we follow it for GCP okay that's a good question and those are draft guidance it as applicable to GMP currently but again data is data and it's collected on many cases the same way and as we saw with the MHRA guidance which was originally for GMP it was expanded to GXT the FDA concepts within the guidance the draft FDA guides can be applied to g8 JCP principles as well DCP data as well as well so although it's not required nobody this is required even for GMT it's all FDA best practice if you want to call it that but if the you can use the guidance to apply appropriate controls to ensure data integrity so TCP data as well thank you come on maybe this one would be good for you we have somebody who says they have heard of some EDC companies that offer validation packages and then I guess they just want a little bit more information on that are you familiar with that yeah that definitely is a good question there are several companies out there kind of caught on to this wind intended use Foundation and they do offer kind of prepackaged test Suites so they'll have SOPs and you know it kind of template in SOPs available test case and user requirements documents a lot of the documentation that you would need to perform your intended use validation now one thing to be aware of is again those are very cookie cutter and very cut and dry and very similar to what the vendor would do for their validation so again as Chris pressures on earlier you want you still want to have your validation team take a look at that package and evaluate to make sure that the components that you are testing our present and that you can expand on those if necessary so if you know you're going to be you want to evaluate their test cases to make sure that they are robust enough for your company standards make sure that your requirements are met and again these SOPs you want to make sure that they work within your own business practice so they can use them as a starting point but you'll definitely need to modify that to work with your company in with your clients so again it should reduce the number of resources that you may need a but initially but definitely tailor that to your company's needs thank you this is a great one so it does who has to perform the validation the sponsor or the CRO Chris maybe you could answer and then Quan if you have anything to add to that so and it depends on the delegation of responsibilities so the sponsor if they're managing the study and so forth they would need to do the validation for the system for the study and that the CRO has been delegated those responsibilities than the CRO would be expected to validate the system create edit checks for the study specific protocol requirements and so forth so it really depends on who is doing the work if the CRO is the user when they are assessing the data and verifying that the data is clean so if we're for example that would be at zero if the sponsor is doing it on their own it could be the sponsor or if there are shared responsibilities it would be the sponsor and the CRO that would perform that could perform the validation right thanks Chris I just wanted to add a little bit to that too a lot of cases especially on this your own side we actually had a lot of clients surprise when they come on Titan an audit FTC because they see that we actually have Internet use foundation for our GBC platform it is a new trend but traditionally a lot of folks coming on site would only expect a qualification on it of your EDC vendor and as Chris mentioned with the way that the industry is moving simply not enough at this point in time so want to be proactive as proactive as possible and try to do that into the goose validation if you're offering up that BTC platform as a service offering and we have another question that says what SOPs are needed for staff systems pretty clarify that a little bit sure if you go back to an entirely host and validation and system so a system that is not a SAS based system there are lots of SOPs that are required for security for example how do i how to assign user roles to users within the system or things like that could then restore of the data disaster recovery that there's a disaster at the end the computer computing a virus so you can recover the system and the data and so forth change control is another example so if there are changes and climb mentioned this during as part of the talk vendors can update their versions after they notify their customers and that's part of change control so in if it was an utterly hosted application that would be the changeful for the sponsor or the CRO that would be generated or follow an SOP but for software and service application it's really a joint process where the vendor the software asteroid under has a change cause that they were they notify their clients it may be part of their release management SOT possibly and then the sponsor or the CRO that's a change to assistant that they use for GXP GCP purposes so they would there be an expectation that they would also have a change control the document change to their environment and so those are the some of the SOPs that you would expect for a software service application the same essa page that you would have for an internal hosted application but some of the procedures are going to be managed by the vendor and some will be managed by the sponsor of the CRO and some will be shared responsibility sponsor out sources all activities to a vendor and DM group can that data management group be tasked and responsible for the formal UHE testing or does someone from the sponsor the actual file checker pharma company need to perform the UAT one I think this would be good for you sure and so again as Chris mentioned earlier to because at this point the sponsor has delegated all authority around that ABC platform to that vendor and that DM group the DM group would also be responsible certainly as the sponsor you would still need to have oversight over that process you don't necessarily need to do your own formal validation but it certainly behoove you to at least participate in it and definitely have oversight over that process so that would be similar to when our clients work with SDC they outsource the full data management to us and they audit our intended use salivation crook and because it's our our I'm in a system that we're developing internal I'm just perfect Kalon here's a good question for you how long should a validation take so maybe explain how long it took for SEC to do our intended use validation of I'm Edna and what you've seen in other existence as well sure so for SEC for the admin at platform it took us about three months to do again a lot of the resources went into developing the test cases and the modules making sure that our business processes were up to par for implementing the system the actual testing itself in terms of execution only took about a week week and a half again it's making sure that all of your ducks in a row all of your documentation is in the right place that takes the bulk of the time now again for future releases you're not necessarily evaluating the entire system again so you won't need that three to six month time frame you'd be using your regression test suite hopefully if you've developed one I'm the only testing team you function that comes out and so that should be reduced you know soon under a month which is why we gave that one month window earlier with respect to new releases and new functionality Chris I believe this question refers back to you some of your slides it says I've seen some staff systems when the user can configure the system but the slides indicate that the vendor manages configuration could you share some clarification around that and if that changes anything like validation in some cases the vendor can only configure their administrators can configure the system in other cases any vendor software allows Xero or sponsored users to configure the system so the situation then the configuration spec would actually be one of the sponsor or the CEO or CRO side of the validation deliverables and again that depends upon the system the capabilities of the system I've seen it configurations being controlled and managed by both the vendor or the CRO or sponsor and the DIF depends on the capabilities and that really should be defined within the agreement that the sponsor or CRO has with the vendor regarding who is responsible for which deliverables are vaccinations for the validation package yeah increase I like to add to that as well so again with the user configuration piece I can I've seen it in use with for example ability to rave where you have the software is configured initially right by the vendor that they program the application and they had that configuration piece of it but then when they release that client URL to each client or in sponsor a zero that utilized their platform they have the ability to do their what they call is core configuration so that core configuration is programmed for your URL only and so as part of your intended use violation you would validate that poor configuration so you want to make sure that if you have ten role setup in your core configuration that those ten rolls are myself correctly and the workflows associated with those roles are validated during it to the use foundation because metadata as the software provider doesn't understand your work phone again that's where the key differentiating piece is between intended use validation versus regular system validation great thanks for that clarification both Kristin Quan we should have a time for about one more question I have one here one could you explain a little bit more about what should be included in the regression suite I believe that's referencing that the high risk items that you're talking to a few slides ago yeah so as part of your regression suite obviously want to cover key components that could definitely impact your business and your business processes so obviously the key one that jumps been about to everyone all your English word requirements so with each release making sure that you do retest your part eleven requirements for an X 11 requirements that the audit trails are intact and that they're not affected you know by any of the changes or in the code release other components typically that will need to be tested during your in your suite would be your very very basic data entry steps making sure that the users can still enter data and that data is still sort properly in your system and then obviously if you are using the IWR component for your randomized trials make sure that you have making sure that randomization still works the subjects can subjects can still be randomized in clinical trials can still continue other things like edit tracks maybe trivial those again it's not a true impact to data integrity necessarily or directly and so those can always be resolved in a later time but as your course suite you want to make sure that part 11 is covered for sure okay so we do have a couple questions that we didn't have a chance to get to you so go ahead and share those with Kristin Quan offline and see if we can send those individuals the answers directly at this time I'll leave the GoToWebinar panel open if we have any last-minute questions that you would like for us to address offline other than that thank you all so much for joining and you should be receiving the link to watch the recording within 24 hours thank you so much