On-Demand Webinars

Webinar Transcript

 

Marianne Calilhanna

Hi there. Welcome to the DCL Learning Series. Today's webinar is titled "Map or Scrap? Consolidating Data Between Inherited Enterprise Systems." My name is Marianne Calilhanna and I'm the VP of Marketing here at Data Conversion Laboratory, and I'll be your moderator today. A couple of quick things before we begin. The webinar's being recorded and it will be available in the on-demand section of our website at dataconversionlaboratory.com.  We invite you to submit questions or comments at any point during today's conversation. We'll save some time at the end to be sure we can address all of those.

 

So I think everyone here really understands that technology plays a critical role in the life sciences. Accuracy, traceability, compliance, along with speed to market, is critical. By improving content and data management, IT systems and program management, you can streamline scientific research and drug development. Data Conversion Laboratory, Court Square Group, and JANA Life Sciences developed this learning series to address how technology can contribute to your success. This is the final webinar in our series and in the handout section in GoToWebinar, you'll see a document titled "DCL Life Sciences Resources." This has links to all the other webinars in the series that you see listed here. And we invite you to revisit and watch those on demand and please feel free to share those with your colleagues.

 

Before I turn it over to our speakers, I'd like to give a quick intro to Data Conversion Laboratory, or DCL, as we are also known. Our mission is to structure the world's content. Our services and solutions are all about converting, structuring and enriching content and data. We are one of the leading providers of XML conversion services and an industry expert in SPL conversion for global pharma companies. If you have complex data or content challenges, give us a call. We are truly happy to help. Today's speakers: I'm happy to introduce Mark Gross, President at Data Conversion Laboratory, Keith Parent, CEO at Court Square Group, and Ron Niland, President at JANA Life Sciences. Welcome, gentlemen.

​

Keith Parent

Thank you. 

 

Ron Niland

Thank you, Marianne. 

 

Marianne Calilhanna

Keith, could you tell us a little bit about Court Square Group? 

Keith Parent

Sure. Court Square is a managed service firm. We manage infrastructure for life science companies in our audit-ready compliant cloud environment, specifically designed to host qualified and validated applications. And we have a specific application called RegDocs365, which is a qualified and validated content management system specifically for clinical and regulatory data. We use that as a platform for hosting lots of different data across the board, all the way from the beginning of the startup of a company all the way through to them submitting to the FDA and tying into manufacturing. Next. 

​

3:49
Ron Niland

As for JANA Life Sciences, we're a third-generation family-owned company founded in 1973. We are certified to ISO 9001:2015, and we just completed our second audit associated with the new standard ISO 13485 for medical devices. We're basically a technical services company that focus on technical documentation. Like our partner here, DCL, we also work in the areas of XML and DITA.  We provide not only technical writing, but also engineering services. We're a project ties company with project managers at the heart of each and every project we do, and really beyond content development, I would say the other area that we focus in on is related to operational excellence, just ensuring that processes and systems come together and enable a company to be not only efficient, but compliant.

Keith Parent

Right, now as we get into our webinar for today, I think that this is something that I just want to talk to everybody about. If you've seen the other parts of our series, you've seen us go into a lot of detail around metadata, around the data itself, the content across the board. This particular one called "Map or Scrap?" talks specifically about enterprise systems and what happens with all of those old systems that you need to know, configure into new systems and tie things together. So we wanted to have one webinar that basically talked about some of the issues you're going to deal with, and we're going to make this a very practical one. There're going to be a lot of conversations. You can look at Mark and Ron and I, and you can see that we're no spring chickens and we've been around for a while.

​

So we've seen a lot of these different types of systems come and go. And we want you guys to learn a little bit from our experience of having to deal with those. So this first slide, we're talking about technology roadmapping and the fact that whether it's pharmaceutical or med device or biologics, we're talking specifically around – there's always this transition of continuum of systems, where you go from transitioning from early research, you then have to get into clinical systems and regulatory. You're dealing with the regulatory authorities. And then if you're lucky enough to have something that gets approved, you now have to go into manufacturing and post-launch and all the things that happen along that spectrum, looking at your product along the way. And in that spectrum, you've got all these different systems and those systems have to talk together.

 

Our goal is to make sure that when we are dealing with this continuum, that it's as easy as possible to talk and transfer data. There's nothing worse than data that gets lost, or you have to clean that data. We far too often have to deal with a lot of these projects where we're actually cleaning data. And it seems like that's a tremendous waste of money and time and effort in this industry and it happens far too often. Mark or Ron, you guys want to comment on that? Mark, you're on mute. 

​

Mark Gross

Yeah, no, I don't think I have any further comments on this over here. Maybe Ron does. 

​

Ron Niland

Yeah, I guess my general sense is when it comes to data, it's sort of living and breathing information, right. And with that said, there is a lifecycle associated with it. And so data is coming and going. It's living, it's breathing. Ultimately it may be dying, if you will, when it gets archived, put into its final resting place. But if we think about the aspect of broader industries, biotech and pharmaceuticals and med tech, there's absolutely this imperative to just continually define new products. And those products need to be brought to market as quickly as possible. And it's the systems that are helping them to do that, right?

 

7:55
But I guess the issue is increasingly the connectedness of the systems is an imperative just to ensure the efficiency, to bring these products to market as quickly as possible. Otherwise, some of these products may end up coming to market sort of falling flat, if you will, because they got one thing wrong. And that was timing. And timing is such an imperative. 

 

Keith Parent

I think one of the biggest things in this industry when we have to deal with data is the fact that if you are successful and you do go to market and you do launch those products, all of a sudden the data that you collected all along the way to get to that point becomes even more valuable because if anything happens in the future, you've got to be able to go back to that. And if you go back and you're asked by a regulatory authority to find data about something happened in an early process, you better be able to find it. So being able to do tagging of that data and being able to search through that data is a really important thing that is almost unique to some of the stuff that we do in this industry. So that's one of the reasons. On the earlier webinars, we talked a lot about, how can I get to that data and find it? Why don't we go onto the next one, Marianne? 

 

Ron Niland

Yeah.

Mark Gross

And I would just comment on Ron's comment about data going through its final resting place. I'm not sure it ever really goes to its final resting place. So it's really important that you be able to get to it as Keith mentioned, and also to be able to deal with that data and get it and to be able to, you might say to be able to convert it into what you need today. there's a long product life cycle, it could be seven, eight, 10 years ago that this material was done. It's not the same, but it doesn't fit the same way it did before. So just support on that. 

​

Ron Niland

And then on the tail end, those regulatory bodies are requesting information be kept for 20 to 25 years. So if you look at it in aggregate, you could have several decades worth of information that you'll need to consider and manage. 

 

Mark Gross
Right.

​

Keith Parent

That's exactly right. And later on in the webinar, I'll talk about a specific case that we worked on over the course of time. So, one of the things, first thing we're going to talk about is why the need for migration? What's all the things that we have to do? Well, you may hear the concept of a legacy system. What is a legacy system? And in this particular picture that you're seeing, for those of you that are computer history nerds, you're going to find out this is the ENIAC from many, many years ago, I think Marianne suggested that this was out of Philadelphia somewhere. But our goal was that there's going to be lots of – and if you're in this business for any length of time, you're going to find that every system becomes legacy over time. Whether it's an older version of a piece of software, the hardware may go out of existence. A lot of hardware vendors aren't here anymore, but a system becomes legacy when it's no longer functioning for the requirements of the business and you have to move things off into another system, or you have strategic directions that change the way you want to look at things.

 

So our goal is to figure out how do we take the data that's created in some of these systems and be able to use that going forward or going backwards? You can't always keep a legacy system running forever. I can guarantee you that this system that you see here isn't running today, and it's not running anything, computing wise, and you probably have more computing power in your iPhone than what you're looking at in this room right there. Next. 

 

So some of the things that we talked about when we're dealing with legacy systems is, do we have to run dual systems? And what does that mean? Running dual systems means that we're going to have an active system going while we're starting up with a new system. A lot of the pitfalls that we have in that regarded potentially double data entry, integration challenges between multiple systems, or siloed application and process knowledge. We see this time and time again in numbers of different areas. Can you guys talk about any of the other pitfalls that you might think about if we're going to have multiple systems running at the same time?

 

12:02
Mark Gross

Right. I mean, one thing you're going to have is different information coming from different systems. So you always end up with, gee, how come this doesn't reconcile with that? And that's, I think, a huge issue and just getting from – everything is so integrated today, if not in the systems themselves, but in how you use information, that you're constantly moving things back and forth, with all the errors that might come over there. So, integration has become just a huge issue all around. And as you move forward, every year, every month sometimes, you're putting on new applications and new information. So this is a constant problem of how do you get the information over into your new systems, so? Rambling a little bit, but this is what we've been doing for 40 years. 

 

Ron Niland

So I would say that there are two elements that are primary issues for companies. One relates to effort. Studies will show five to 10 seconds if people don't know where to put something, can't put that data or that document into a system within five to 10 seconds, they won't. So if you have dual systems and one is easier to work with than the other, then it's very likely that you may end up finding people are using that and the data is going there, the document is going there when perhaps it could have, and should have gone into the other system.  But the other element on the backend here is understanding decision-making in the organization and the idea of being really confident in decision-making that's based on data, data-driven decisions that will require you to have that single source of truth of information. So if you've got parallel systems, then invariably you have redundant data. But then the question is, how well is that aligned and how well is it cleaned? And if you have data that's coming through one that's a little dirty, it may adversely impact decision-making. 

 

Keith Parent

So let's talk about some of the advantages of having dual systems; are there some? Well, in fact, there are actually some. One of those could be that if you've got a part of the company that you want to spin off and you're using certain applications for that part of the company, it might be easier if you're going to be spinning off part of that. So you keep those on those systems and those systems might actually go with that company. I've seen that happen numerous times over the years I've been in business. And the other one may be, you might, might want to focus that usage. So you may have a certain set of people or a certain product suite that is in one area. 

 

It's not going to go further than where it already is and you may want to just keep it on that. It's not worth migrating all that data. You've already gotten to a point where you're okay with that, everything that's there. I know we have a case in point where we actually hosted for a major pharmaceutical company, a system within our data center was running on an old deck here and they basically needed to go in once a quarter to pull data off of that system and we had that running for about 10 years within our data center. And finally, they shut it down. They had no other way of getting data off of that, and they wanted to have that running. So while they had a drug safety system, that was the production one, this one still ran in parallel because they didn't want to have to migrate any of that into the new system. How about you guys? Other advantages you might think about for running on a dual system? 

 

Mark Gross

I mean, it's always a cost benefit analysis. So sometimes you do have these. I think the other place where you might actually want separate systems is for security reasons. I mean, where you want to segregate information so it's not reachable to other places, so. I mean, there are legitimate places where you do keep completely separate environments, but whether you really want to keep separate – that doesn't mean it has to be different data structures in different data sets, they really just need to be segregated. So I think that's a legitimate reason where people will want to keep things separate.

 

16:12
Another thing is what you're saying, Keith. It just, it doesn't pay. It doesn't pay. You need this for another five years and 10 years and the cost of moving it over is just going to be higher than just messing, going in once a quarter. That's a classically good reason to just keep things the way they are.

Ron Niland

I would just add onto that a few elements. One is cost. Sometimes you might have one system that is much more cost efficient. For instance, let's say for archiving purposes. So, I'm currently working with a company and they realized they have an aspect of redundancy, but there's a cost benefit in going with one system, using it for a specific purpose. I think purpose-built systems, when you think about that concept, is another reason for the advantage, meaning within certain departments and functions, they may have a very significant set of work practices that they need to adhere to. They may have work styles that they're accustomed to, and for that reason, they may lean toward having that system stay intact, if you will, and running to some degree parallel.

 

I think I had seen this where, with mergers and acquisitions, there's a period of time given to that other company, if you will, to continue working with their system. And there's an aspect of the rationalization, harmonization that might take 12 to 24 months. So those are some advantages, but especially work styles. Individuals develop work styles. Ideally they're aligned with their work practices, their SOPs, and work instructions. And if they're going to a new system, then there's a need to develop updated documentation. And so sometimes companies don't want to go there in terms of updating work practices and SOPs. In the case of a merger and an acquisition, that might be a perfect example where the acquiring company may say Hey, let's give the organization time for it to settle down. And let's set a 12-to-24 month timeframe for bringing together the systems. And in that interim process or period, they might not choose to deviate from the processes just to ensure there's continuity in the work. 

 

Keith Parent

We're going to move on to the next slide, but before we do that, I just want to say that particularly for fit-for-purpose applications, things like in the lab or on the manufacturing floor, particularly in this industry, you're going to see that there's some things that may need to be running while you have other systems in place. So how about let's move on to the next slide. 

So now when we're talking about enterprise system integration, there's a bunch of different areas that we want to look at. What are the things that we look at when we talk about integration? Functionality, the user base, and searching. So let's talk about functionality first. The best does not always win, and integration with critical systems. What does that mean? Well, the best does not always win: let's talk of a merger and acquisition. I've been involved with a number of these over the years where very large pharmaceutical companies buy other very large pharmaceutical companies. Some of them may have just invested in a new system and they have it out there and it may have far more functionality than another system. However, the user base at the other company is used to the older system or a different system with less functionality and the cost to migrate or bring everybody onto the new one would be far more than what they want to spend as part of that acquisition money. So they would end up staying with the one that has the larger user base.

 

20:01
So those are one of the things that you deal with talking with functionality and user base, and then also those critical systems. How do I tie things in to something that could be critical? Is there a time period that we need to deal with? How do we try to tie those together? Ron? You want to jump on that?

Ron Niland

Yeah, so you're right. I'm not a spring chicken. I'm definitely a chicken though. But when I was a spring chicken, one of the first acquisitions that I was involved with was with Pfizer and Warner-Lambert. This was an $80 billion acquisition. And the day after the acquisition announcement, I was tapped on the shoulder and I was told "You're going to work over the next few years in creating a harmonized, if you will, landscape between development and medical affairs." And when we went in, we looked at the systems being utilized by Warner-Lambert. It was a little bit of an "Aha" moment where people then found themselves thinking, "Hey, they actually are more progressive than we are." So it can be a very enlightening experience to go through and do that very deep analysis of the systems. But in the case of Pfizer, while they were acquiring, I'd posit to say, very few people came from Warner Lambert to the new company. And so that ended up being an issue around the users and their comfort level with the new system. So it's a little bit of a balance, where, yeah, that functionality might look great, but if you don't have users that really understand how to maximize that functionality, then you may sort of dummy it down a little bit. Not that that's the right descriptor, but you know what I, hopefully, know what I mean. 

 

Mark Gross

All right. And I mean, you sometimes do have to dummy it down. That's for sure. It's also, it's a time-consuming task to really combine the systems, so. And it's not done in one day, but I think the danger is that you sort of leave it and never do it. So, I've come across companies that three or four or five years later, are still siloed in a way which is not helpful to the company. And rather than taking them, putting there a plan where over time you put together the systems is also, it gets left aside. And I think siloing the systems has a big cost to it. So I think one of the things that is important, this is part of the plan to be able to know how you're going to do this and make sure that you don't leave things on the wayside. 

​

Ron Niland

If I could just pick up on that last note there, Mark, in terms of siloed systems. One place that you will know you have siloed systems in your company is when it comes to search, without a doubt. And this will end up being, I think, an aspect that companies increasingly will want that enterprise-related search mechanism. And at a minimum, you have to have your systems integrated, but ideally you're doing this rationalization, you break the walls down in the silos, but through the search engine capacity. 

 

Keith Parent

Yeah. That's a great topic, Ron. And one of the things I want to bring up was that in both webinars two and three of our series, we talked a lot about metadata taxonomies, and we talked about content structure and systems integration. So if you go back and look at those webinars, you'll be able to see a lot more of the detailed aspects of that, but the concept of finding data and where that's going in the future and one thing that we're all working on are things now – and I know that DCL is – this is one of the major areas that DCL deals with, is getting that data in a place where when it goes from one system to another, we can make sure that we can find that data and we link it. One of the biggest issues is going to be structured versus unstructured data and how we get to that data. There's a lot of new systems and we're seeing a lot of push into machine learning and AI to help us be able to find some of that data across all these different systems. So I think that's going to be a major push in the future for how we can tie some of those together. 

Mark Gross

Absolutely. And also making sure you're the proverbial apples and apples. That you're comparing apples and apples. Data changes how you use it changes. So I think there's a need to make sure that the data you're looking at and information you're looking at really matches together. And it's like pharma companies are more and more data enterprises today, just totally dependent on the information they've collected, both the data itself and all the textual materials and written materials and everything else. So I think it's really – and the length of time it's there is more and more important be able to use it all, otherwise you're at a disadvantage, and there's a high cost to that. 

 

Keith Parent

Marianne, the next one? So some of the reasons that we have migration events, we talked a lot about the data and the need to migrate data, are a number of different things could happen. Merger and acquisition was one of them. We talked about, maybe their company has a cloud first strategy. And we want to go to applications in the cloud. Maybe there's a new system. The system we had, the company went out of business, or we need to get a new software vendor that comes in, or there's new technology, something brand new comes out and we're just going to shift everything over to that.

 
Each one of these, and there are many others, but they force us to think about migration. And those are some of the events we deal with. Some of the thoughts that we had as we were putting these slides together, we're talking about not all content needs to be migrated. What does that mean? Identity of cradle to grave content? And we'll talk about that as part of this discussion, and then chain of custody may need to be considered. And we'll talk about what that means too. Why don't we kick it off and just talk about not all content needs to be migrated? What does that really mean? Mark, you want to handle that one, or Ron? 

​

Mark Gross

Well, I think we've touched on it all. It's really some data will never be needed again. So, I never throw anything away. I'm one of those people. So I find it's hard to do, but some data will not be needed again. And some data is truly archival. It will never be – you won't need to pull out things for any future analysis. So, it's important to get those things out of the picture because there is a cost, certainly, to everything, but I think all the live information that people are using, this can go back five, 10, 15, 20, and as Ron said, it could – regulatory requirements may go even further back – is information that either should be migrated or maintained in a form that it could be migrated at a later time if need be.

 

Ron Niland

Yeah, I guess one aspect of this presentation is focusing, if you will, on content. And then, what is content? That is both data and that is documents. When it comes to documents, you can absolutely see where, with technology that's evolved over the years, increasingly you can do versioning of a document within that singular document. The way it works, as we know, in years prior, was people would create the versions and versions and versions. 

28:02
And so there's an aspect of trying to understand where the live wood is versus the dead wood. And that's a very detailed and labor-intensive process, to be honest with you, that one needs to go through. With that said, there are tools that both DCL and Court Square Group use for effectively looking at documents, comparing and contrasting them, trying to see which are different or which are completely redundant. And then try to then understand what your underlying versions and understanding the parent and child data, parent and child documents, that's really an imperative. But going back to Mark's point, when it comes to archiving data, sometimes you say "You know what, let's not move this off the file server, but let's encapsulate it." And so that no one can go in, heretofore, and alter it so that if need be, we can show it to a regulatory body. But versioning is one aspect in the encapsulation or some other aspects that I would say factor into the equation.

 

Keith Parent

How about on the identification of cradle to grave concept and what does that mean? In my view, when I talk about cradle to grave content, we talk about that fact that I started with a system and when I end with that data, so if I have a drug product and we need to make sure we're looking at it over a 20-year period, can I make sure that the first systems that we put that data into were somehow migrated over the life of that content so that we can actually get back to that early system? Or do we have some kind of event the middle there that we have to deal with and make sure that we can at least find that data at the end? So those are areas that we've had to deal with in numerous occasions. So I think you have to worry about that, particularly when you're defining metadata, defining taxonomies, how do I find that data, how do I make sure that it's transferred correctly into any new systems that we're dealing with? 

​

Ron Niland

In a few areas where this comes into being, or for instance, with the TMF, that aspect of really understanding the life cycle of that document and how it was being utilized to basically make decisions and enable a clinical trial to be executed, you need to show that lifecycle, if you will, and for instance, when it comes to a protocol and all of those addendums that might happen and not just in one country, but across the globe. And you can see, like suddenly it can get very, very complex. If you had multiple addendums across dozens of countries, which often happens in areas, but especially in oncology, if you are looking at an oncologic agent and you have one chemo backbone used in one country versus another. Another area is around batch records, right? You need to be able to show that that life cycle, if you will, the batch records over time. And that's, those are just two areas where it becomes much more pronounced in terms of that need. 

 

Keith Parent

One of the last topics I talked about was the chain of custody and the concept of chain of custody, and to some people that means different things to different people. I've recently been involved with a number of cell therapy companies and dealing with autologous cells and dealing with patient. Needle to needle, they call it. So basically from the patient back into the patient, and you're doing something with their cells. So the concept of making sure that the data that identifies what you're working on, you have a very clear chain of custody all the way through it and you see new techniques and new technologies being added. 
Things like blockchain, which are being used pretty heavily in Bitcoin and the whole financial world, is now hitting our world where those things are helping to try to track and trace all of those products all along the way. And I know track and trace in our industry has been huge, particularly for counterfeit drugs and different things that we have to deal with. Comments, guys? 

 

32:04
Ron Niland

Well, it makes me realize that we perhaps should have added a bubble around regulatory changes. In fact, regulatory changes could dictate whether you need to migrate or not. And for instance, the IDMP, which I think we may have talked about in either the first or second webinars series, IDMP, that Identification of Medicinal Product, is definitely something that helps a company and regulatory bodies understand the integrity of that chain, if you will, but including as it relates to the component parts of a pharmaceutical. So yeah, I would say that we should add that to this, perhaps, maybe before we post it, I guess that's not possible because the video will be posted to the webinar. 

 

Mark Gross

We can always add an addendum on that, but yeah, the whole area of counterfeit drugs and making sure that you've got what you think you have is a problem. That's certainly not an area of my expertise, but I keep on coming across it in my readings. And it's an issue, not just in drugs, it's an issue with all kinds of products, so it's a whole new dimension that needs to be added over here. 

​

Keith Parent

So we talked a little bit earlier about the whole concept of system integration and being able to search and find data. The concept of mapping that legacy data and metadata is this definition. A lot of times these are triggered by M&A events. So you may have some vendors come in to help to pull things together. They may define, they may look at mapping all of your data across multiple systems. I know Ron and I have been brought in on a number of different occasions to help do some of that. And the reliance on outside vendors to drive convention, sometimes internal politics within some of these large organizations cause some strife between different organizations. So sometimes it's just easier to have an outside vendor come in and help you lay that out and say "Okay, here's how we should go. This is the most cost-effective way to go forward and to drive that." There may be some reconciliation event that forces a change for those as well. Ron, you were going to say something? 

 

Ron Niland

Yeah, I'm sorry to cut you off there, Keith, but yeah, that aspect of the prickly pear is something that for sure needs to be considered when it comes to assessing systems for rationalization. Because going back to that aspect of users having a preference of work style, there's going to be sensitivity in the organization. And you may very quickly hit a nerve in discussing the rationalization of someone else's system or another department's system. And yeah, I would agree with you, Keith, that it is very helpful to have a seemingly neutral party there to help facilitate a conversation and really get the group focused more on the pros and cons and the features and benefits of the different solutions and guide the discussion.

And at the end of the day, if you are rationalizing and you are putting a system to bed, some people may not be happy with that. And the way to ensure that it's a win-win-win situation is to go through a process and really make it abundantly clear to one and all that, hey, you're doing what's best for the company. You're thinking short and mid-term, and perhaps even long-term. You've weighed the pros and cons. You've looked at the features and benefits and you make a collective decision. Now, not everyone will ultimately agree with the decision, but the idea in an organization is once you make that decision, ideally through consensus, then everyone should stand behind it. But yeah, again, having an outside party to help broker, I think could be very, very helpful. 

 

36:08
Mark Gross

Yeah, I would, I would, just, your phrasing of "seemingly neutral," I think a person does have to be neutral and has to be clearly neutral. But just as an aside, the real difficult issues on these are the people issues. The mechanics of it and the metadata and the mapping, those we can solve and our experts can solve all those things. But the people issues that you're bringing up are really the tough ones. And if somebody out there is going to not accept the decisions, it's very easy to sabotage a process without anybody even realizing. So it's really very important to get buy in, and it's not an easy thing to do, but it's –

 
Ron Niland

No, it isn't. And I just want to just go back to that aspect of the seemingly neutral element, because at the end of the day, if a vendor is brought in to support, right, the question is, who brought that vendor in? And do they have an allegiance, if you will, to the person that hired them? But yeah, by all means, Mark, I agree with you. There has to be that neutrality. You need to be seen as sort of the Switzerland of decision-making and I think all three of us would say that we're very system agnostic. 
We're here to help companies understand how to structure their data better, how to integrate in a more seamless fashion, how to increase the efficiency. It's not about us. It's about ensuring you, your business objectives are met here. 

 

Keith Parent

So I also think there's a way when you think about – we talked about mapping legacy data, and you think people think about legacy as, it's got to be an old company with old systems. The reality, it could also be a stake change in the company where you go from an R&D company into one that's now going to have a full product out there, or now, we now just got funding, and now we're going to hit a regulatory issue that we're going to have to deal with. So that concept of reconciliation event could be one of those things where I'm now going from R&D. 

 

I now have to go into more cohesive systems and kind of tie those together. So you can take that opportunity to take local file shares or things in Box or Dropbox or Ignite or different areas and pull them together. I know that we deal with that on a very regular basis when we're using that as kind of a forcing function to help companies look across the spectrum of all their data and say "Okay, how do you really want to have that?" Because right now, one of the big issues that we hear: "I can't find anything." or "It's always over here," or "I can't map that drive" or "I can't do this." So we use that as a reconciliation event to help companies identify "Well, how do you want to find it? What do you want to do? What's the way that best suits the way you guys want to move forward?" and then we use that as a way to say "Here's how we're going to map it. Here's how I'm going to tie it out. And here's what you're going to be able to see going forward."

 

And that's usually a way that people can look at it. I mean, think of in practical terms. You've just moved into a new house and you've got boxes and boxes of stuff, and it's kind of overwhelming that you've moved all this stuff out. Some people hire a third-party person to come in to help them just to organize. So you have these organizers. We're organizers for the closets. Your data closet is what we're going to organize and that's what you think about there. Other comments, guys? You ready to move on? 

​

Mark Gross

Now, so your analogy, I think, points to something very important. So one thing people do when they move is they just take all those boxes and put it in the attic and never really look at them properly. And then it disappears anyway. And really, the movement of data like this is a time when it's really important to not just move things over, but to make sure that you can find it at least at some level so it's not just moving the boxes, but the contents of the boxes need to be, they need to be organized. 

39:54
Ron Niland

And I think it's fair to say, we go into the attic, we also go down into the basement, right. And we need to understand in totality where the data is and then just help rationalize it. 

 

Keith Parent

So how do we do it? How do we rationalize? How do we bring these things together? How do we map? So we talked a lot about multiple production systems. You may end up having to have multiple production systems that feed into each other. You may end up putting a clearinghouse system between those systems because you don't want to break that, or you may have invested heavily into something. We might have different departments using different platforms. If that's the case, and you keep them separated, you may need to do some of that. Or we might have customized processes that we've developed to deal with different silos of data and how they do that. 

 

There might be some practical reasons for doing what you do and maybe merging that data or migrating it or centralizing it. A lot of times they're going to see the shift from centralized to decentralized and then from decentralized back to centralized. Our industry is not any different than any other industry and you see this across the board. Every 10 years or so, some new thing comes out and we're going to be doing this pull towards the center and then breaking it back out again. And I think every time you have a different set of executives come into a corporation, they've got to show their way and do that. So we do that through lots of different things with the systems. Comments, guys? 

 

Mark Gross

No, I think you're absolutely right. I don't have anything to add to that. 

 

Ron Niland

What I would add is just around policies and procedures. So yeah, with this expansion of some of the platforms that are out there, it's making companies look at their policies and procedures very differently. Meaning, today it's much easier to think about enterprise content management and using some of the platforms. And I'll just throw one out there. I think it's called Microsoft, right. Within Office 365, you've got basically dozens of apps and many of these are associated with their ability to manage content. And so it is easier now for a company to look at their policies and think about retention, retention records, retention of records in particular, right? And there's also the aspect of how people are managing the information, which historically in life sciences happens quite a bit in email.

 
And people historically have felt like "Well, I've got my folders and I can keep these ad infinitum," but many companies are now rethinking the aspect of the retention of not only records, but records within email. And so they can institute policies, and they are, using platforms like Microsoft to say, your email is transitory. You've got basically 180 or 365 days in which to manage it. 
But thereafter, that stuff needs to either be put in an archive folder, if you will, within Outlook or within that resident system. And it's something that companies will do to mitigate risk, right, their exposure. And there's that addiction that we have to Outlook in particular, right, email for managing information. And it's not really an enterprise content management solution. I mean, it's a point solution that was designed 30 plus years ago to share information, but it's not enterprise content management, but, I would posit to say, Office 365 more holistically is, and then the question is, if you go there, then it's not for the faint of heart. Policies and procedures need to change in the company and it needs to be driven from the top down too. 

 

Keith Parent

Sounds good. Marianne, how about let's move on for this because I know we're getting short on time here. 

​

44:00
Ron Niland

Yeah. So, they say –

​

Keith Parent

Ron, you want to –

​

Ron Niland

 – if you don't know where you're going, I think it was Yogi Berra who said it, you'll end up someplace else. And you're not necessarily being given signs when it comes to this rationalization work. But what you have are steps that you can consider following. And the thing is to go into it sort of open-minded and really think "Okay, anything and everything is up for grabs," meaning even that system we just implemented a few months ago might be worth reconsidering. So you need to think about what are your objectives in your defining a strategy, if you will, for your data and your content? And you need to think about the drivers and technological change of underlying platforms is what we're talking about here. You may also have imperatives within your business. You may have CAPAs that you're dealing with and you need to put in a better quality management system, as an example. You may have –

​

Keith Parent
Ron, one of the things – 

​

Ron Niland
Yep.

​

Keith Parent
One of the things I want to add to what you were saying is when I was thinking about on the slide earlier now, and for this one, it's one thing to be a sponsor and have lots of data and lots of systems. But if you're also a consultant or a CRO working with lots of sponsors, you may actually have to deal with lots of different systems across those sponsors. So being able to figure out how your systems can work with their systems is as big a part of some of this stuff to do. So when you're visualizing that roadmap, how am I visualizing how I'm working with lots of different customers or lots of different sponsors across the continuum as well? 

 

Ron Niland

Yep. Yeah, so, the identification of where the systems are going, that's a requisite and on this slide here now, sort of shifting what we're looking at, it's basically, it's a very simplistic roadmap for an organization and it goes over multiple quarters and it's broken out in this case by aspects of infrastructure, needed improvements, aspects of integration. This is a very simple rendering that anyone can very quickly absorb and sort of get a sense of where they need to go over a period of time. But the fact is you can make it much more complex. You can break it out by functional areas in the company. You can show the interconnections between these systems. You can show the connection with documents as well, but having a map is something that will enable you to have a discussion with a group and get sort of everyone, if you will, on the same page. So there're outfits that offer templates in this case, this one is from Roadmunk just as an example. Next slide. 

 

Keith Parent

Next, Marianne. 

​

Ron Niland

So, when it comes to that separation between data and documentation, this is a little bit more focused, if you will, on the documentation side, the idea of enterprise content management. And I just labeled this the Roadmap to Nirvana, but you can see this was developed by AIIM International so they're being given credit. And it was a rendering that basically shows the value of an enterprise content management system from capturing the information, storing it, ultimately preserving it, and then delivering it, but delivering it across a multitude of channels, as you can see in the bottom right quadrant of the graphic. But having a sense of where you want to go with these platforms is important. And having a visualization means like this is, it's invaluable because a lot of people, when they hear enterprise content management, they don't really think of all the component parts, but as you can see here, we've got about three dozen different component parts.

​

48:02
Keith Parent

You know, Ron, this picture brings up something that, this area in the middle where it talks about STORE, it brings up a number of things that I've had to deal with over the course of the years in that, when people are taking data or they're archiving data, a lot of times they cut it to a CD or they put it on tape, or they do something like that. I've had numerous occasions where people have put it onto media, but they no longer have the equipment that can actually read that media anymore. So as well as you're looking at your data, you have to look at how I'm storing that data and do I have a process or any defined methodology of making sure that that archive data stays current with the technology that we have in-house? 

 

So those are other things that we as consultants to the industry have to think about for our client base because sometimes they don't. A lot of times you may have a business unit that says "Hey, I'm turning this over to IT, so it's IT's problem." And for them, they don't really think about some of that until somebody asks for it. We talked a little bit earlier about that lifetime and having something for 20 years. Well, that one time you get a request from a regulatory authority to look at something years back and you can't get that off that tape, now you're scrambling to try to find somebody who can deal with that. So those are just a quick comment that I wanted to make sure I brought up as part of this. 

 

Mark Gross

The technology is so that it's not just that you can't read it, but maybe that nobody can read it at this point. I mean, the storage technology has shifted so quickly over the last 30, 40 years. There's a technology that's only 20 years old but it really is very rare, very hard to find somebody who can read it. So it's a very good point you bring up, Keith.
 
Ron Niland

Yeah. We didn't even go into the element where, some acquisitions, you get a room of documents and they're in boxes that you need to manage. 

Keith Parent

I just talked with a customer just last week, a potential customer last week that talked about a phase one, phase two clinical trial that they had that they had done. They just got purchased with another company and they want to be able to take that old data and be able to do something with it. It's not in digital form. So how can they find anything? So we're talking about how do we digitize that, put it into a form and then put it into an ETMF or something that they can actually search. So that's a real life example of what happens out there. This slide is a slide from one of our earlier webinars. It talks specifically about that metadata mapping, the identification of fields, determining the overlap, and then looking at the numbering schemes and how we can tie that together. 
Again, it's all about the data. It may nothing to do with the systems they came from. It may be the data that comes out of the systems. And how do we keep that going to a point where we can keep shifting that along to different systems along the continuum? Next, Marianne?

 

One of the big things that we have to think about, particularly in this industry is the audit trails and the governance of that data over time and where it goes, even though we shipped from one system to another, to another, what happens with the audit trails from the legacy system? Are we making sure that we're taking into account the fact that we have to see how somebody changed something in that last system. Are we taking an exportable audit trail so we have them as part of the artifacts going forward? When you start with a new system and it's a fresh system, we may start fresh from this one system and go forward for anything new, but we have to keep that legacy data and somehow be able to get back to it and lock that down. And if that's the case, are we locking it down and we're not migrating that stuff? Are we keeping that in a place where we can still get at it for those audit purposes when somebody's coming back to you, particularly from a regulatory body or a partner? 

 

Many of us have our small pharma or biotechs, and we have a large partner. They may want to be able to look at that data or be able to do something with that data. So we make sure we have to maintain access for audit purposes and make sure they are still searchable and you're able to get to them. And that governance plan says you've got to have somebody, whether it's a data archivist or somebody that knows how to get to that, they have access to that, and maybe you go to a central authority within your company that they can actually find some of those things for you. Those are some of the things that you have to think about when you're putting these together. Mark, I know that a lot of your systems are specifically built to do some of that for these companies, so they can get back to some of those systems.

​

52:14

Mark Gross

Right. It's specifically built to that. But also it's something that definitely comes up fairly frequently, where a customer has information that's been collected over a number of years, and there's a need to go back and get an audit trail on where it is. It's really important that every time you move data, every time you've changed data, you've maintained the information about what happened at that point. So, yeah, I think we've talked about this a little bit til now, but that's really, audit and then going back to it is something that really does come up fairly frequently, certainly with pharma data, certainly with legal data, it's all very important. 

​

Keith Parent

And you can't rely on emails to be able to find your audit. That's not the way it works. 

​

Mark Gross

Yeah, I mean, a lot of times you end up with, before you've taken on the control of it, is that becomes a very manual process. So you certainly want to avoid that in any new systems that you're doing.

​

Keith Parent

Marianne, how about popping to the next one? Here's a couple of key points I think we wanted to make down that we had talked about ourselves. Can we export the data in a format that is retrievable? If the system isn't going to be around and we're not going to have that system, can the data be exported to something that we can either read or search, or be able to do something with it? That's one of the big things about maybe an XML backbone or something like that, that you put it into a place that we can actually get to that data. 

​

Mark Gross

Right. And a lot of times you think of a PDF file or something you're going to produce or just an image file and realize that those are not processable in normal ways. So if you move it into XML, you can actually use that information later on in ways that you didn't realize at a time to put it away. If you put it into a PDF file, that's really a print format in a way. And taking it apart later on becomes a much more difficult task. 

 

Keith Parent

Second thing was, do we need to keep an application going to access the data? If we can't export it to a format that there , can we keep that? Like I said earlier about that thing with one of our major pharma clients, we had a system going for 10 years for no other reason than they couldn't have it in any other system. So we kept that around and it was just easier for them to be able to do that. What are some of the best practices with data retention policies? Each of you guys have to deal with data retention policies on a very regular basis. How about some, couple of words of wisdom on that? 

​

Mark Gross

I'll leave this for you, Ron. As far as I'm concerned, data retention is whatever the legal requirements are, usually. So we do need to make sure of that and make sure they're there, but I don't know, Ron, what specific things that you've been working with. 

​

Ron Niland

Well, realizing we're running short on time, I would just say it's a good policy to have a data retention policy. 

​

Keith Parent

Very good point. And then locking down the data and making sure that there's only access to certain people that can get to it because you still want to maintain that governance that you had initially with that document. So don't put it in a place where it's open to anybody, making sure you're locking it down and that that data can't change. Those are going to be important things to think about. Next, Marianne. You can pop over to the next one and then right after that. We'll start getting into the use cases. 

 

Mark Gross

Okay. Okay, so just very quickly on a use cases. I mean, the place where we have a lot of experiences on, and there's a lot of our places where data is being used in the pharma industry, but certainly in structured product labeling we support close to I think 200 companies now where we're getting information in. So this is one way in which information needs to be moved to XML because it's required by regulation. In the United States now, soon in Canada, soon in other parts of the world.

 

56:06
So that's an area that we've been working with. There's other areas similar to that, where information's going to be kept in a very structured way. So a lot of what we do is make sure information is structured in a way that we can do all the things we've talked about at the beginning of this hour. And now I'll move this on to the next case; I think Keith, or –

 

Keith Parent

Great. And over the course of the whole webinar series. So thank you. Thank you for that, Mark. Next? So from the use case, from the Court Square perspective, we can talk about – we were working with a major medical device manufacturer. It was spinning off a pharmaceutical division. Their IT department didn't have time. They had a year's worth of backlog, and these guys wanted to be able to do a drug submission within a year. The problem was, they didn't have the capability resources internally to do it. We helped out by being able to take that data, not only getting them up and running with multiple applications in an audit-ready compliant fashion, but also being able to integrate those, train people on them, and do their submissions ahead of time in a very reasonable fashion, time dependent, got them going. And after two and a half years, we actually were able to pull that back into their IT department. We helped them put together the entire metadata setup and migrate stuff back into legacy systems or other systems that the company had. Let's go on to the next. Ron?

Ron Niland

Yeah, and with JANA Life Sciences, I wanted to just highlight a case study that's associated with enterprise content strategy and information architecting, basically. And it's a more recent example. Working with a mid-sized company grew, grew it in a very accelerated fashion over just a few years to where they're looking at their systems and they're thinking, well, now we need to get this rationalization, but especially from an enterprise content management perspective, i.e. documents. So we were tasked to drive the program management. As a company we offer project management services in a fractionated or full-time manner. 
And then at the same time, we were also tasked with helping them to audit their content. And we're talking the attic – the house and the basement – and really trying to put together a cohesive picture for them, but especially with their clinical data, for literally a decade, basically –

​

Keith Parent
Thanks –

​

Ron Niland
Pardon?

​

Keith Parent

Thanks, Ron. We're going to have to finish up. We're getting close on time here. 

​

Ron Niland

I understand. 

​

Keith Parent

And so let's put this up as a kind of a closing slide for the webinar. I just want to show everybody that the three of us, three different companies, DCL, Court Square, and JANA, we're in this together, helping you based on what we've done, our expertise across the board, whether it's data and content structure, hosting and applications and program and process management. All of those factors are needed when you're dealing with some of these small or large problems. We're here to help you guys. Last one, Marianne. Just a thanks to everybody that was on. Mark and Ron, everybody. Thank you guys. 

​

Mark Gross

Thank you Keith, for running this show today, and Ron. I think it's been great, it's a great program. 

​

Ron Niland
Yeah, I definitely agree.

​

Marianne Calilhanna
And thank you everyone who's taken time out today. 

​

Mark Gross
...these webinars. Okay, Marianne? sorry. 

 

Marianne Calilhanna
Sure. Thank you everyone for taking time out of their day to join us. This concludes today's program. I just want to remind everyone that the DCL Learning Series comprises similar webinars to this. We also have a monthly newsletter and a blog. You can access many other webinars related to content, structure and XML from dataconversionlaboratory.com. This concludes today's program. Have a great afternoon, everyone. 

​

Keith Parent
Thanks, everybody. Have a great day.