Vault Within a Regulated Industry: Regulate Your Vault!

RAY O'MAHONEY: Hello, and welcome to my class, Autodesk Vault within a Regulated Industry. Just a bit about myself, my name is Ray O'Mahoney. I am technical manager within Symetri. I have 17 years plus experience in both the product design and manufacturing industry.

One of my passions is really about delivering on data management projects, both at a national level and an international level. So I have plenty of experience working with multiple organizations collaborating with each other in different [? GEOs ?] and so forth. I really am passionate about keeping up to date with the latest technology advancements and innovations. I think it's important to understand what's going on in the industry, what are the market demands, what are the industry challenges, and how we kind of overcome those and feed into those and come up with strategies and ideas.

Now, I'm hoping, today, that you are going to get the following really kind of good idea of what my class is. And I've got some set objectives that I put together for you. And it's really around, number one, to kind of get an understanding of the regulated industry standards, what's out there, gain awareness of some validation steps that are required if you're going down the validation route, and again, some tips and tricks within the data management solution and the [INAUDIBLE] Vault.

And more importantly, and one of the big key areas we need to focus on is really learning about integrating workflows with other business areas. I'm going to talk about that, and we're going to expand on that as we go throughout my presentation. One thing that I kind of want you to note is that I've put a handout together. And within that handout, I've put some additional resource material in there.

I've also put extracts of some procedural documentation that could benefit you as well and kind of give you a guidance and an idea of what the steps would be. I've also put in some configuration information to already watch out for and what you can do now out of the box and bring it a step further, also some tips and tricks. And really, and I suppose that's more important to a lot of us, but one thing that I really want to consider here is your next steps. What are the next steps outside of this class?

Before we go into this in earnest, what I really want to talk about is I want to talk about what is the impact of getting this wrong. What is this class all about? This class is really to kind of enforce the idea that we need to regulate our data. We need to have controls and procedures over our data, specifically within a regulated environment.

You can take many examples in cases where you may not have the procedural controls over releasing certain information, and you might have information used incorrectly or the wrong version of the wrong revision. Well, on top of that, we need an auditor. We need the information of when it was released, who it is released, what was done by it, what particular date, for example. And this is just one of the key areas, especially in the industries that I'm talking about today. We cannot get this wrong. This would have impacts downstream if we get this and if we share the wrong information and we don't regulate our data within the environment that we're supposed to.

You're here because you may have to regulate data in your company. These are some examples of industries and companies that I've worked with within the data regulation. And a lot of this would be food and beverage, for example, medical device, pharmaceutical.

One of the key areas that we need to realize is that when we work in these industries, we work with regulatory bodies. You can see on this particular slide, I am talking about a regulatory bodies in different jurisdictions. These are some of the regulatory bodies that you may be familiar with. But I'm going to focus on one particular one, which is the FDA, which is basically the US Food and Drug Administration regulation. This is probably one of the most widely used and widely known of the industry regulatory bodies. But the solution we're going to talk about today is Autodesk Vault.

And just for some stats for you, for example, if I'm manufacturing a product, a medical device, a pharmaceutical product, a drug product in Ireland, I want to sell that product into the US market. In order for me to do that, I would need to abide by the FDA regulations. And I'd have to be keep compliant to those regulations at all times during the manufacturing process, right through from start from design to concept, right through to product, product being made, I have to be compliant within that regulation.

An interesting stat on this slide is, really, FDA regulation, you may think it's an American regulation or a US regulation, I should say. But this is typical to many, many jurisdictions. I've only picked Ireland. But we've got to remember, an interesting stat here, there's 136,000 plus foreign facilities producing product, medical device pharma product, for the US market, all abiding by the FDA regulations. So it's an interesting stat for you all.

In essence, it's all about adherence to procedures and protocols, the requirement and the company policies in place around this regulation. Again, as I said, ultimately, we're going to use Vault to address the issue around compliance and maintain compliance within the regulations. And just moving on from it, this is a good image. This is kind of explaining, in a nutshell, why it is compliance. It is a mixture of requirements, laws, rules, transparency, and policies. And it's very interesting how the sequence works in actual fact, in industry.

Now I want to talk a small bit about the product itself. But before I talk about the product, I want to talk about businesses and organizations. Businesses have strategies in place to make a change, to improve. Strategies have outcomes. And outcomes are really supported by capabilities.

Now, I do see a business value in offering a controlled data environment, the delivery of which is consultancy, training, technology, consultancy being the standardization of the data and the workflow and the process. The training is training people to do it. And the technology is Vault. Really, what we're trying to do is utilize Vault to create a single source of engineering truth. One common thing that I'd like to share about this, it's really about people, process, and data automation.

But expanding on my last point, Vault is so much more than just a design and engineering tool. It feeds information to quality assurance, facilities, production, operations, quality control. So we're going to explore and expand in Vault capabilities throughout this presentation or throughout this class, I should say and explore how we can connect and share data to other departments.

One of the principal tools I would like to cover again within the application is really Vault Data Standards. Vault Data Standards is a way of standardizing the data and input that information into a PDM solution. It allows us to create new files in compliance within the regulatory bodies. In this example to the right, you can see very quickly that this is a customer example of how we actually modify and build on DS to improve how they bring data into the Vault, location, save location, file naming, file numbering, et cetera. And again, I'm hoping to show that in a bit more detail towards the end of this class.

When we talk about regulatory bodies, and again, we have a specific focus on the FDA. The FDA consists of a code of federal regulations. It's made up of 50 titles which represent a broad area of subject to federal regulation, excuse me.

Within those 50 titles, there's a title that we're going to focus on, which is title 21. This title covers various aspects of design, clinical evaluation, manufacturing, packaging labeling, and postmark surveillance of medical device. The part would in that, we call it part 11, covers a specific area with data.

And this brings me on to my next point, which is really around 21 CFR Part 11. Title 21 [? quarter ?] federal regulation part 11, all about electronic records and electronic signatures and sign off of documentation. How do we achieve this? We ensure the security and integrity and [? confidentiality ?] of the data. That's a high level objective of 21 CFR Part 11.

How do we achieve it within the application? We achieve that by appropriately technical features in application plus supporting SOPs and training procedures. And also, to manage the risk, we assess and document the risk to data and product quality and patient safety. Remember, we're working in the medical devices of pharma industry. These are key terms that we'll be using throughout the presentation.

One thing that's critical to all this is an audit trail, traceability. We all know when something goes wrong, the audit becomes one of the most important items. If a project, our product, is a success, no one cares about the audit trail. To be able to automate the audit trail rather than going through email and Excel and so forth, it does save so much time and give people the opportunity to work more valuable work. Audit is the single most important functionality of any data management system.

Now, I talked about regulatory and FDA. But I also want to talk about good manufacturing practice, GMP. But also, I want to talk about AMP, which is basically good automated manufacturing practices. And the reason why I say this, it's various bodies outside of the FDA produced guidance to help us understand the regulatory body and title and part and always try to achieve compliance.

So there's guidelines set, guidelines there from various bodies, that kind of helps us along our path when regulating the Vault. It really applies to controlling and distribution of the data of the use of the GMP data, really around the GMP data within an organization. Earlier, I said about people, process, and data automation. The gap, as you can see here, is about connecting people, process, procedures, premises, and products.

So it's a bigger picture, and we're part of that. Like anything, you really have to determine the risk. One of the things is, if GMP data, you need to determine the integrity of the data within a solution. You need to determine the criticality of the data, which is my point in the previous slide.

And also, you need to scale your validation activities around those activities, around that data, and around the functions to control that data within an application, people, process. Any risks to data, any jeopardization to data, has a risk as a direct impact to the quality of the product. If it's released to market, it has an impact on the patient or the health and safety of that patient.

Put yourselves in the shoes of what an auditor would ask. Can you demonstrate to an auditor that the system is working? Can you provide a documentation to prove that the system is validated? Even if you are not using the application within the validated system, what assessment has been done to counter that decision, and where is the proof? And then you also have to document the sufficient training and the assessment of people using the system.

So you can see, it's a very interesting conversation we have with auditors and how we work within the regulatory environment. And it's a very, very tight thing. And it's a good thing to experience as well, and to learn and learn more about how we actually operate. I would like to bring onto the next step, and it's really about, how do we solve business challenges? I've been lucky enough to be visiting companies and talking about data within a regulated environment, talking about the challenges they have.

And it's really a common theme. The CPDM is one piece of the puzzle. They want to control the regulatory data. They want to collaborate. They want GMP compliance.

They want to put in procedures. They want to look at workflows. They also want to look at current process and procedures, connecting to business areas. Systems and, ultimately, criticality. Along with many other objects, you can see I could fill this slide for a day. But this is just some of the commonalities we have with our discussions. These are the keywords that we come across quite a lot.

And we need to investigate that. And we need to overcome those challenges. And a lot of times, it could be done with the production pressures or not taking the time off to validate the system. So it's important to understand why and take the time.

Next thing I would like to talk about, the validation and protocols. So what's really important is the steps. And I assure you there's a bit in this. But this is not huge. This is just a sequence of events and plan that we go to for any particular implementation or validation process we do.

One very important thing, create a validation plan. Define the responsibilities and the activities and deliveries. In this case, you'll see that it's very important to have a plan up front. And I've taken a little snippet from one of my documents, and it's really about, just in this case, really focusing on planning out a migration from, say, a Windows Explorer to Vault.

What are the steps? What do we need to do? You can see here, we've got expected result and actual result, pass, fail, and date. So we really do have a record of everything as we go through the process.

But as I step into this bit further, I kind of want to bring up the first step. It's all really around the user requirement specification. What's the user requirement specification or URS? The URS is basically a goal and purpose. The organization has a goal and purpose, wants to be GMP compliant. Its listing of its detailed requirements in order to get to be GMP compliant. But it also goes through process and functional requirements.

This really is an organizational document that will be put together to meet their requirements. For example, I want to restrict user access to certain information. I want to quality control and improve certain information. I want the system to handle multiple users with specific rights.

I want the system to generate specific file formats, PDFs, et cetera. With that in mind, you can see this particular document here is basically an example of an extract from the URS. And this is something typical that you would see in the first stage documentation as part of the validation.

Moving on to the second step, what we have is an FDS, which is basically a Functional Design Specification. It's in response to the URS or User Requirement Specification. It's acceptance of the criteria. It's the FDS details, the exact how are we're going to meet the requirements of the URS.

How are we going to meet the organizational requirements with a particular application, with a particular function. And we would document that. For example, from a security point of view, as in my previous slide, we can configure a Vault for security access to files.

We can configure [? DCO ?] for an approval to approve files. These are generally the responses to what URS would typically have. And again, this is kind of a brief kind of update or kind of extract from the procedure documentation for our NFDS. Again, some of these will be in my handout for you.

Moving on to the third step and one of the most critical steps in the validation process is risk assessment. In this situation, what you really need, or this point of during your validation exercise, is you need all subject matter people together. You need to have IT, quality, engineering, sales, facilities, you need everybody's input into this. And it's very, very important to understand that and to get everybody's point of view.

You also need an application expert, a Vault application expert on hand. And you'll run through some typical tasks to demonstrate how you're going to address the requirements to have them URS. Please be aware, any customizations or anything like that you do within Vault or Vault configuration, that will be subject to heavy validation activities, because it's something you've developed yourself.

For example, notification to approver, can improve access to document? Can they delete the document? Can they approve the document to the correct stage? Can they electronically sign the document?

So I'll just go back. This is just a very quick example of the risk assessment document, just a very quick template. Again, you can see it's very structured. You can see potential failures, failures, and record in the data [INAUDIBLE].

Moving on from this, what we then do is we look at the implementation qualification. And this is, really, verification of all the installation and configuration as part of the FDS Functional Design Specification. We verify all the defined procedures and deliverables are ready, the documentation is ready to be followed and the SOPs are in place to be followed for both installation at this point. And ultimately then, we move on to the configuration.

So this is really where the IQ comes into place, the implementation qualification. Again, this is a very typical kind of extract of that, basically a checklist, making sure that we record every kind of detail we have within the station, both client and server side. Next, we look at the operation qualification.

This is normally done in a test environment. And this is where we actually do the testing. We test, review the requirement, test the functional design spec, test everything that we put together and proposed. We go to the test scripts and execute those.

One very important thing at this stage is, we have a document test plan with expected outcomes. From there, you document the results. And more importantly, you identify any deviations that you may have, and you report back to the validation team.

We finally move on to, and again, before I do that, apologies, I just want to kind of give you an idea of just a snippet of just what kind of steps will be taken within that particular stage of validation, and again on the OQ operation qualification. We're now looking at the PQ, which is basically the performance qualification. And that's really where we are working with files in a real production environment. We're managing over a period of time.

But initially the first days, the first weeks of normal operation, by real users doing real actions. And that's where you really test a product. We monitor everything, and we monitor the SOPs. And we look at the behavior and hoping that it is as expected.

If there are any anomalies reported by the users, we take that into consideration at this stage. And what we then do is we go to the validation team, and we may even have to go back into the operation qualification stage, maybe for additional configurations that we might have not caught early. So there is a circle, or a part of [? source ?] going, to where we can fully document any deviations revalidate those, and come back into production environment.

Nine times out of ten, we resolve the deviations and sign off in the system at this point. The final step in all this, and again before I jump, this is another extract just from the performance qualification, very similar to the OQ. But again, testing live on the test environment.

The final step, really, in all this, is the O&M Operation and Maintenance. Remember, we need to maintain the validation status throughout the operation phase. We need to maintain that the system needs compliance and maintains its validation status throughout that phase.

We need to ask ourselves, what is the impact of making a configuration change? What if IT or a member of the other business units make a change to configuration? We need a way of monitoring that. We need a way of capturing that information. Remember, Vault really doesn't have a way of controlling or documenting or giving us an output of what user has been added, what user has been added to [? DCO ?] routing. So we need to put the SOPs in place to take care of that and to manage that.

Just a few bits in the Vault configuration. I just picked a few bits that I felt that was appropriate for this class. One of the things I like to talk about is failure to prepare and prepare to fail, such a true saying.

You need to put the time in. You need to understand what the organizational requirements are. What do each business units do? How do they collaborate? How do they share information now? How would they like to share it in the future?

This will lead into what you're going to build and your FDA, so how you're going to configure the system. But another thing to consider here is the future and future proofing system. Look at the system requirements. Try to think of two or three steps ahead where possible. Think of a 4 to 5 year plan.

What are the company's plan? What are the company's strategies to roll out updates to software? What version are we going to be at in two years time? Those are things you need to consider upfront.

And this will ultimately minimize the validation exercises going forward as well. You need to understand IT infrastructure, the architecture, and security within the organization. You turn based on how you connect today. You need to understand what are the setup.

What is the setup? Is it domain? How is your network set up? Are you connected to both the GEOs? All those things need to be considered.

Moving on from that, one other particular area that's very important to me is, and recently we're doing a lot of data management installations on cloud op. So we've done a lot in On Premise, and we do have cloud. And I just want to kind of illustrate a few things just to be aware of, especially within the regulated environment, that you need to be aware of if you're planning to use a cloud solution.

Windows Authentication, I'm a big fan. There is tools like SSO out there now from Autodesk. And there's things like that to work with this as well. So this is very important. It's one of the key areas and one of the key areas is going to be developed quite a lot if you go through this exercise.

How are you going to restrict people to this? IP restriction, domain restriction, domain groups. And upfront, be aware of the cloud security. Be aware of the security policies around cloud. Share with IT, discuss with IT. Get Autodesk involved early on in the stage with this. These are some good and challenging conversations we do have with customers and organizations.

Before you start in earnest, you should really look at setting up a development environment that will allow you to set up test runs, set up the application, working with non-production data. But not only that, it allows you to work within their infrastructure, to test things like support applications or dependent applications. Look at IIS, look at SQL, look at replication, backup protocols. The quality assurance environment is really about where your test platform will be, where you do your functional testing. You will demonstrate to the customer the functional design specification also.

And finally, the production environment. So the production environment is your last bit where you will complete your configuration on a quality assurance environment. And then you move that configuration over to the production environment.

Few things to watch out in the Vault configuration. Number one, support applications, where are they going to be installed? How are they going to be installed? What versions they are?

Server rules. Remember, you're working in large organizations, and some of these organizations will have the specific groups to take care of this. And so you need to be aware of this and notify them up front.

Security measures around ports. Are you going to use a specific port? Again, are you going to use server certificates, for example? Finally-- it's not finally, apologies, is Windows Authentication. How are we going to do that? How are we going to roll it out? What domain groups do you set up?

And one of the big things for me is really around, there are file security will involved. Making sure that you map this out, who's got access to a file in what stage. That's a very big thing for me. It's one of the things that we really work hard on, along with many other functions within the Vault environment. But that's one of the big things we really do work hard on.

And it's important to put a process out on that and work that out between the business units. Here, I'm just showing you something very simple. It's in relation to a very simple thing you do out of the box. When we started off working with Vault in a regulated environment, we looked at the simple things out of the box first.

This is a simple thing that, we're applying this particular functionality to an approver, where basically, when the approver logs in to Vault at this point, he connects, he or she connects, and works with the ECO. They're reviewing the information. But really, what I want to do, is I want to talk about approving it.

And normally, you can approve it [? by that. ?] But it's asking me, requesting me to put in my password again. It's like a second sign off. It's like data electronic sign off. And that's out of the box. And that's just one minor configuration change. I'm hoping to take that away today. That's just one very small thing, and we can do many other things.

The other big thing is metadata. Metadata is king. The more you put in, the more information you put in the file, the better it is for you, the better you get. And the output is much, much richer on the other side, the more intelligent the file is.

I use the custom properties by setting values are required or not, and setting lists of values to standardize that. And I want to give you a good working example here of this, working in a real life production environment. I'm glad to say that my customer [? Dairymaster ?] allowed me to use this particular video in practice. So again, this is about use of data standards.

So when we talk about data standards, you can see we're just showing the Vault structure that they have. And this Vault structure is really built on data standards, Vault data standards. So now we're going to CAD application. We're going to start with a basic file.

We're going to do a basic design. We're going to put in the parameter information that we use from [? Venture ?] to design this particular component. We're going to finish out all the actual design work using the native tools within all [? Inventor. ?]

But when it comes to save, you can see very quickly, we can specify category. Once I specify subcategory, the automatic numbering scheme is applied. You can see that the required fields are automatically put in place for me to fill in. And I cannot get this file into the Vault without fulfilling all this particular information, as you can see.

Again, this is out of the box. This is stuff that you can do today. So again, as I work with the file, you can see now, I've got that metadata rich file. Now I'm bringing it over to the drawing side.

And with the drawing, what I can do is I can populate the drawing as well with that data. Moving on, I can start using functionalities like [? parcels, ?] revision tables, directly in the drawing environment to build up this information. Again, good use of my metadata.

When I take this to another level, what I want to do is I want to bring this into the assembly level as well. So with the drawing, you can see that I've completed up my assembly. And the same principle applies here.

In this case, I'm picking my DS on a particular file type. In this case, it's an assembly. So again, it applies a different category and different metadata fields that are required for Assembly file. A lot of work has gone into this data standards implementation. And there's a good reason for it, really around compliance and really building that regulatory information in and standardizing this information.

This is a big group of people designing on a daily basis. So we need to standardize the information, everybody working off the same information, the same guidelines, same compliance. So again, as we move across, that is the [? power ?] of this.

The other thing I want to show you here is really around DCO. Again, property information, the more information you have on the file, you can't have enough metadata. But this is a good example here. Where by in coming across, where I can grab this particular information, and I can come across here put in the information. But I got to set priority fields in here, find my dropdown list, fixed texts, so far like that, that I need to select in order to process, bring on this on its next steps, my apologies. So again, it's very important that we kind of build this up and have the information within DCO environment [INAUDIBLE] Vault.

One very good thing I find with this is creating new files. In this case, we're creating documentation of specific templates within our Vault environment. We're following a numbers scheme automatically, defined category. So even if I pick a defined category, pick the correct template for me.

I fill in the relevant information in here, which is key to the process. I fill in the description, for example. I fill in the project. And then I fill in the particular title.

So in this case, once I have this done, I'm now ready to proceed to bring this file and enter it into the Vault system. So again, if I click OK on this, this will push into the Vault system for me. The good thing about this is it's a metadata-rich file.

And when I look at this and when I open up this in it's native application, you'll see the metadata would be already in there. So this is a very good way of making sure we standardize the file formats, standardize the metadata in a particular file. So again, I hope you can appreciate the steps that were taken in this and the benefits of doing something like this as well.

I just want to talk about extending Vault capabilities. And I'm almost to the end of my class present slides. I really want you to focus on out of the box. What can you do out of the box today? You can talk about customizing reports and electronic signatures.

We can talk about Vault data standards, which I've just shown you. And we can talk about the Vault API. Now, the Vault API will require some programming. But I've seen some really, really good stuff done with the Vault API. And there's loads of resource material around that. And there will be resource things in my handout for you to review.

I would like to focus on third party add-ins, because I have a bit of experience with these. They really provide a platform with some functionality already built in, and are very much a very good add-in for Vault. And particularly, we've used COOLORANGE and our own tech, which is [INAUDIBLE] Vault, which allows us, for example, automatic generation of third party files, [INAUDIBLE] check in documents, email notification to users if necessary at a particular point or stage of different file.

So I'll entice you to explore those technologies. Think outside the box, and look at other solutions that are out there. But remember, any customization will require more focus on validation exercise.

Last bit, it's really about connecting other business departments. So in this case, we talk about re-bringing this slide back in again, which is all about design engineering, quality assurance. And this was shown on my first few slides in my class. But this is all about output.

We need to look at what file types need to output that you connect to manufacturing, you connect to quality, are you connecting to sales, for example? Are you connecting for review or management? More importantly, what I would do, and my recommendation is, if you do generate a file output, please ensure that it's attached to the file Vault, there is an audit trail that are being produced and where it goes.

Second-- thirdly, apologies, access, access to the information, restrict access to the information [INAUDIBLE] typical. Don't leave it open. Final bit, I'm hoping that throughout my class, that you're able to get benefit of just getting an idea of the industry standards, the validation steps required, a bit on the configuration optimization, and a small bit on the workflow and integration [INAUDIBLE] departments.

I will be going into more detail in my hand out in all of these areas. But just a call to action. Do not be afraid. This is a challenge you can win.

Feel free to reach out to me. I'm happy to share my experience, happy to share my mistakes that I've made along the way as well. And I'm here to help.

Contact your reseller. They're always willing to assist and help. And they know a lot about what's going on in the industry as well. And it's great to have them involved. On that note, I would like to thank you for your time today to listen to me in this class.