NATAN: Mark, welcome to Augmented. It's great to have you.


MARK: Yeah. Looking forward to the chat with you.


NATAN: You know, I think we met about a decade ago at MIT. And I think you gave me one of the first lessons into, you know, the wonderful world of regulated industries up close and personal. Mostly, if I recall, the discussion was around the dynamic between how hard it is to adopt new technology in this kind of environment. It's been a while. 


You've been with GSK since 2002, so you had a long journey. Maybe we start by quickly introduce yourself, and what you're doing today at GSK, and how did you get there, so we can set up this conversation that we have today.


MARK: Yeah, sure. Thanks, Natan. So, as you said, been at GSK coming for 21 years now, so I joined in 2002. Today, I'm head of quality tech for our manufacturing and supply chain area, so that's all of the quality control and quality assurance IT systems that support our business. How did I get here? A pretty interesting journey, I think, for what is today an IT practitioner. So, I started in development as a development engineer working on processes.


NATAN: In the lab. 


MARK: Yeah, in the lab, yeah, lab coats. Literally doing process experiments, scale-up, transferring processes into pilot scale, and then manufacturing scale. I then got interested in manufacturing technologies, and I think that's when we met. Actually, a decade ago, I was leading a group that was looking at new manufacturing technologies. And then, through various twists and turns, I took a role in what is R&D tech now. And then, I started looking at the IT systems that support our R&D organization. And then, that evolved, and here I am today, running quality IT systems for manufacturing.


NATAN: We'll dive into quality pretty deep today. But can you share, like, one important drug or pharmaceutical you're really proud of that you worked on? So, people get an idea of what kind of work you actually did before, like, you know, doing the stuff we're doing now, which is, like, architectures. [laughs] And is it this cloud, or is it that cloud? And people should remember that the work we do is actually to save lives. It's not that complicated.


MARK: As you can imagine, I've worked on many GSK medicines and assets. So, I think if I go back to my R&D days, and, actually, this is a bit of a sad confession. But anybody watching who works in early and late-phase development in R&D will know that you know, after 20 years, or ten years, or however long I spent doing that. Actually, it's very few people who touch medicines that actually make it through to file and launch, right? So, we had an incredible attrition there. 


But I did work on one asset in R&D that finally launched. It was an oncology asset. That particular asset is no longer with GSK, but it was filed and launched. And as part of various divestitures and various things that happened in life, that's now in the care of one of our other competitors. But yeah, it's an incredible feeling, I have to say, as a research scientist, when you see the fruition of all the work you do. And it's, to some extent, you're always standing on the shoulders of others, right? 


So, I was a small little cog in the drug substance trying to figure out how we were going to make the actual active ingredient that then goes into formulation, and, of course, there's all that work, and then our commercial teams that promote the medicine in the marketplace. So, it's a combination of a lot of work. But yeah, being able to see the actual fruits of that labor turn into a medicine that you know is going to go to patients. And, you know, in the oncology space, as I'm sure you can appreciate, those are pretty ill patients and often have very few therapeutic options on offer. So, I think when you are involved in oncology medicine, it has a big impact. 


But yeah, I've worked on lots of other medicines. I've worked on GSK's antibiotics products, diabetes products, respiratory products. I've sort of touched them all over the place, either through troubleshooting or these medicines go through their own lifecycle, so it's not like you file and launch them and they just, you know, they stay static. Invariably, we have to enhance the process in some way or make some sort of changes. As someone in that CMC background, I've had involvement in, you know, many of our medicines as we go in various roles and guises. 


NATAN: I hear this perspective, you know, from a bunch of life science practitioner executives. I'd say one recurring theme is that drug development is slow for a reason, but then, again, everybody wants to speed it up. There are obvious reasons why you want to speed it up. There's so much technology out there. There's so much need and, like, we got, I think, a pretty good wake-up call. Granted, it relaxed a lot of the traditional regulation that we see around development of drugs and, of course, referring to the COVID pandemic. 


And this is not necessarily just drugs-drugs. It's also like, hey, we need this testing kit. We need to get it out because we need to test millions of people; otherwise, this thing is getting out of control. Or we need to speed up clinical studies that used to take years and years, and we need to crunch them into six-month period.


Help me sort of evaluate this state. So, on one hand, we have proof that things could be done faster. You can argue better and safely. You know, just empirically, like, you look at the amount of vaccines out there from GSKs and others, they're pretty safe. And, like, the data also supports it, I believe. On the one hand, like, the traditional cycles are still very slow. How does quality and technology play into that? 


MARK: Yeah, and listen, I mean, you're touching on a big question here, one which I'm not necessarily fully qualified [laughs] to comment on, right? But I have an opinion, having worked in the industry for some time. And I think one of the things I would say to you is that you always have to look at processes. And you can argue about whether a process is fast or slow, or whatever the case is. But you can normally optimize processes across different dimensions, right?  


NATAN: Mm-hmm.


MARK: And the reason I explain this to you is, I remember many, many, many years ago, we were involved in a situation where we were asked to reformulate one of our antiviral medications. The story goes: it was delivered through a respiratory device that wasn't formulated for pediatric indications. And as a company, we were asked to do an emergency reformulation in order for it to be used under a clinician's guidance for a younger patient, a pediatric patient. And, I mean, it's many years ago, right? [chuckles] We're going back more than a decade ago now. 


But the incredible thing is something crazy, like, the call came in on Friday, and by Monday, we had sort of reformulated it into...I think it was an oral solid dose kind of tablet, right? Now, you look at that, and you think, wow, normally in our development cycles, that would take a good couple of years to do reformulation. So, how come we can do it in sort of three days, or four days, or however long the time was, right? But, of course, the difference was we only generated one tablet. [laughs]


NATAN: I see.


MARK: And that's what I mean, right? But what are you trying to optimize for? So, I think a lot of the timescales are because we're trying to optimize at a level, right? So, we're trying to produce a medicine that's, by and large, safe for the broad spectrum of the population. We're trying to produce it so we can reliably produce it and supply it. So, the last thing we want to do is, you know, we launch a medicine. You get good efficacy, but then you can't manufacture and supply, right? That doesn't help anybody, either. 


So, I think when you look at those timelines, you've got to understand there's a whole number of things that are being optimized. But, to your point, though, I think the one thing COVID definitely woke up the industry to is, if you have the will, how fast can you move, right? I mean, this has been well-documented, and people don't need to hear that from me. But it's incredible how fast, you know, various organizations were able to bring a COVID vaccine to market, right?


NATAN: Yeah.


MARK: And trust me, every single pharma company in the world has taken a look at those timelines and looked at their own processes and gone, huh, okay, that's interesting. Now, look, some of that's going to be sustainable. And we can adopt that, and we can change our processes. Some of it is going to be quite exceptional, right? Because I think everybody recognizes that COVID situation --


NATAN: Was pretty extreme. 


MARK: Yeah, a good government regulator, pharma industry, patients, everything convoluted to have an attitude that was very amenable to acceleration, and that was right and proper. But that's not always going to be the situation with other sorts of medicines. 


But I think to your point, Natan, we know there's huge opportunities for us to accelerate. And, you know, I think it's in everybody's interest to get that acceleration right. And I think, paradoxically, you know, I think sometimes it can feel like industry regulator, payer, patient...it's interesting. It can sometimes not feel like they were pulling in the same direction. But actually, if you think about it in terms of acceleration of innovative and novel medicines to patient, everybody is aligned that they want that faster. [laughs] So that, I think, we can all agree on, right?


NATAN: Yeah, we can all agree on that. And that brings us into the world of quality technology. I think what I've heard, you know, one way to summarize it, look, when it comes to quality of a mass-produced pharmaceutical, we're talking about the supply chain game, and a numbers game, and the statistics game. Let's talk a little bit about how it's done today. [chuckles] 


And so, one thing I recall you telling me in one of our conversation that kind of stuck with me, you know, that if an alien came and walked through a quality lab, they would go, like, "What are these people trying to do?" And I was like, what did you mean by that?


MARK: Yeah, I remember the comment. I think you got to understand my comment on two levels, right? So, on the first sort of superficial level, what I was trying to say was a bit of a tongue-in-cheek comment about the flow of people and materials in a quality lab. So, what I mean by that is, how intuitive is the process being followed? 


And I think what you've got to understand in a pharmaceutical quality lab, in a commercial space, it's not like an R&D lab where you're doing discovery and science. I mean, really, a quality lab in a pharmaceutical setting is pretty much an operation, right? It's very repeatable. The test methods are scripted. The samples flow in, and you really want to flow them through and get them to -- 


NATAN: The data collection.


MARK: The data collection, the data insight, and all the rest of it, right? And you know, because you've visited some of the labs. It's not immediately obvious, you know, what's going on. You've got benches. You've got instruments. But you can't conceive the flow of samples and materials by just looking at the lab. Even if you see the operations in action, you can't necessarily figure out where's the start and the endpoint, right? It doesn't look like an automotive assembly line where it's very clear: you have the chassis at one end and the finished car on the other end.


NATAN: So, a lot of trust on the people. 


MARK: Yeah, and there's not a lot of what I would call orchestration going on. You're relying on people's memory about what they need to do. And I think on a deeper level, actually, so you've got that sort of superficial tongue-in-cheek kind of expression, which is a bit of an engineering mindset, right? I'll walk into a factory in any industry, and as trained engineers, you can kind of look around, and you can kind of go, okay, I know what sort of industry I'm in because you diagnosed the vessels or those assembly points, or whatever the case is. So, as a chemical engineer, you sort of grasp what sort of industry you're in. 


I think on a deeper level, though, my comment is a little bit about the deeper level of, well, what is the QC testing process actually trying to do? And a real paradox here which is, I would say, the vast majority of analysis that we do in a QC lab, we are just confirming what we already expect. So, we're not really trying to generate new data. We're just getting the result, that 99 point, whatever percent of the time we would expect to get. 


Now, clearly, occasionally, we get the result we're not expecting, and that's the whole point, right? So, you can then take intervention there. But that's actually quite rare. And I think this gets into the whole industry debate about parametric release and analysis by exception, right? Do we really need to test every single sample? Or can we start using modern technology approaches which monitor your process? And then you get into, you know, a different testing paradigm.


NATAN: So, that means the quality is built into the processes, or sometimes people call this approach quality by design. That is very interesting from two perspectives. One is the technology process mindset to support that within the organization. The other part that is required, I think you would agree, is how does the regulation think about quality by design? 


MARK: Yeah, and, actually, you know, in fairness to our regulators, it was the regulators that introduced the concept of quality by design, right? So, now I forget the exact years but somewhere around 2010 [laughs], it seems to me, and corrections if I get the years wrong. But somewhere around there, we had the various key...what are called ICQ harmonization documents came out. There was 8, 9, I think, 10. 


And, you know, they dealt with process analytical technologies, how you use inline outline testing, and then it got into this idea of quality by design. And, for the audience, so without getting into a lot of the technical details, I think the strapline that I remember when the regulator started to talk about quality by design was, basically, this idea of, look, stop testing the quality into your product, and start designing processes where you're very clear about what the critical process parameters are, that assure your critical quality attributes, right? So, design that into the process. 


And, actually, we made a lot of progress. And now I think, though, there's an evolution here. And I think we haven't—I mean, my view anyway—this is my personal view—we haven't quite got to the full vision of quality by design, which is actually, if you really design quality into your process, and you really have the right level of process control, and you're very clear around your process parameters are, and you've got the right level of process analytical technology deployed, you shouldn't need to do the end product testing, right? Destructive end product testing. 


Now, of course, there's a risk-based approach. And I think both industry and regulator, you know, we're sort of moving our way towards that. And, you know, it wouldn't be right for me to say that that is fully locked in today. But I think both the regulator and industry recognize that that's where we want to get to, right?  We want to get to a world where we're not having to destructively test the product to assure the quality of the product. 


NATAN: So, I guess the follow-up question to that would be, what is actually missing to get us to this promised land or more closer to that? Because I kind of agree with you, like, I don't think quality by design and its features, including inline testing and, you know, fully orchestrated labs, would or need to, not just would, do away completely with end-of-line testing. 


Because sometimes, depending on the product and the lifecycle of the product, I don't know, we talked about batch sides of one tablet, you know, the world is moving to, especially in the biologics, custom-made very specific formulations. I don't think they're going away completely, right? But let's discuss a little bit. So, what is missing? What would usher this further?


MARK: I think the one thing that's missing is there are genuine gaps in the science and technology of testing, right? So, there are certain methods, if you like, end product testing methods that are very difficult to automate or translate into some sort of inline outline technique. But that gets better all the time, right? So, then there's --


NATAN: So, it's, like, inline spectrometer are becoming cheaper and more accessible, for example. 


MARK: Yeah. And you've got, like, Raman, and all sorts of different techniques you can use in powders. And also, the modeling is enhancing as well, right? So, if you think about plastic tablet dissolution testing, you know, can you get to a place where at your particle size distribution of your various excipients and drug substance can be used to model a dissolution profile of the drug, and that modeling gets demonstrated to be accurate enough that you can forego the dissolution testing? So, there's lots of people working on different things, right? So, I think that's the one piece, that the science is not static, and there are some gaps in the science, and that's moving forward. 


I think the other thing, and you hinted on it there, right? Which there is this conundrum, and we come back to the speed, right? [laughs] You mentioned everybody wants to accelerate, right? So, we always want product understanding and process understanding to assure that we've got the right product quality, right? But there's no doubt in my mind that if you want to move to, you know, a true kind of parametric release-type paradigm and you're going to use modeling to understand all the different phenomena and avoid testing, that does put a significant additional requirement into your late-phase development.


You've got to generate the science and the data to support that process understanding. And I think we are in a bit of a trade-off there because, as I mentioned to you at the start, right? When you asked me, well, how many medicines have I touched? Sadly, until we get the attrition sorted out, a lot of the medicines that CMC practitioners would work on don't actually make it to file and launch, right?


So, you are in this sort of conundrum of, well, how much effort do you put into that? Now, don't get me wrong: we put all the effort that we need to to ensure patient safety and get the right product profile. But in terms of actually doing some of the sophisticated inline outline-type of pieces, it may be more expedient to have a sort of end product testing-type paradigm rather than trying to use a modeling approach or whatever the case is.


So, the other breakthrough there—and I think this is where there's a lot of interest in the industry—is how do we optimize late-phase development? How do we get better at using automated platforms to do late-phase development research? And how do we use modeling and various digital knowledge management systems to capture that data more efficiently, right? Because if we can get more efficient about that, I think we can get to a further place in terms of the file and launch place where we hit commercial manufacturing with a much richer and deeper understanding of the process, which then lends itself to this kind of parametric release-type paradigm.


NATAN: Yeah, and, you know, I'll add to that. And obviously, you know, this is a topic dear and very near to my heart. And I think you categorize this very well. It's kind of like the edict. It's like Donald Knuth, who is, like, one of my favorite computer scientists, used to say, "Premature optimization is the root of all evil." And, like, he said it in the context of, you know, computer science because, you know, software engineers will also build, like, really complex things. 


And, you know, when our software fails, people also could die, you know, if that software runs in a critical, you know, real-time computer that, say, runs a 747. You know, things like that happened. You know, software quality is also a very important thing. When I think about this, it's, like, it's so difficult to kind of get to automation that is perfect and very agile. And so, like, the cost, complexity is so high compared to the potential benefit.


In that spot is where I say, well if you enable the people who are more agile and easier to quote, unquote, "program or automate," if you give them the right information, and you give them the right orchestration around their jobs, there's actually a sweet spot. And I think we're starting to see it and not necessarily just in quality labs but also in R&D labs, or places where you want to even just capture [chuckles] what's going on, you know, let alone repeat it. 


So, like, sort of, like, this idea that the digital tools can help people become more repeatable to a degree but yet not over-automate or over-engineer too soon. So, do you see that? Is this something that you think about as a general approach at how you design your labs of the future? How do you see that play out?


MARK: Like any business, right? If you want investment for new technology, you're always going to have to grapple with, well, what's the payback, right? Payback, efficiency gains, or productivity gains, or quality gains [inaudible 17:09]


NATAN: Or safety.


MARK: Safety gains, whatever the case is, right? So, you're always making that trade-off. And yeah, I remember a senior executive once shared with me a quote that's rung with me forever, which is: when investing in digital, you can very easily become a more expensive version of what you are today, right? And I think his point was; you look at automation, lab automation, sometimes it doesn't make sense, right? Exactly for the reasons you're talking about, right? Maybe you don't have the level of repeatability. You don't have the volume. And so, it's not always the right thing. 


And I think even in the digital space, there is a diminishing return, and you called it complexity, right? And I think there is a diminishing return where actually, no, you've hit the sweet spot where you've probably got the optimum for the circumstance you're in at the moment. And that might be a blend of...I'd hate to say paper and digital because I don't think [laughs] there's ever a blend on that front, right? I think we clearly need to move to a paperless-type environment. But you get my meaning, though. I think when you're looking at IT systems, you can often design in too much complexity. And then you start to negate the benefits.


NATAN: Very easy. You know, we're coming up on our time for this episode. So, we might need to schedule another one that is more focused on the future. But maybe we would set it up with a couple of thoughts and recommendations that you might have for practitioners who are, like, trying to grapple with the same sort of issues we discussed today. How would you guide if you have to think about your two or three top recommendation to folks trying to get their labs, their quality labs, ready for the future we're discussing here of quality by design? What would you be guiding people to think through?


MARK: Yeah, I think my first guidance would be this idea that systems act as mirrors of process, right? So, when you deploy a system, what you actually get is a mirror of yourself in terms of your process. And so, my first guidance would be to say, well, before you look into the mirror, actually, just look at the process yourself, right? But this is, you know, maybe a question we would have come to, which was, what's the good and bad of digital deployments? And I'll tell you, the bad I see is always when we don't think through fully the reinvention opportunity of a digital deployment, right?


NATAN: But that's a great second recommendation, like, do the pros and cons tally of what's digital doing for you, and what it's not, or where it might hurt you.


MARK: Yeah, and really try and reinvent, right? 


A couple of other things I think I'm really interested in...and you mentioned quality by design, right? And you were probably talking about quality by design for product quality. For a long time, we've been advocating we need a quality-by-design conversation for IT systems [laughs]. Just like we should stop testing quality into product, we should stop testing quality into our IT systems. Now, I don't have the answer to what that looks like. 


But I think for practitioners, both on the regulatory side and the business side, we really need a conversation about computer systems validation and how we just, like, reinvent that and do that in a different way for both interests, right? We all want the same outcome, which is quality software. I think we need to figure that out. That's one recommendation. 


And then I think the third one, which I think is a big opportunity, is I don't think we've quite got our heads around yet about how we will deploy artificial intelligence-type of solutions in a quality lab setting for product quality. There are great opportunities there, right? Huge opportunities. But I do think there's either a perceived or a real blocker where we can't quite get our heads around exactly how you deploy those types of systems and assure yourself that you're going to get the result you want. But I think that would be the third thing that I'd want to recommend that people really lean into and start thinking about.


NATAN: This is awesome. I got to tell you, you know, on the number two and three, it's like, on the validation, you know, I was thinking, like, who's validating Excel? And I think the answer is, like, no one [laughs], you know.


MARK: You can validate a spreadsheet, right? 


NATAN: No. The spreadsheet itself? Sure. And the use of it in a process? Absolutely. But I'm talking about the actual core software. Like, nobody goes through the specs of Excel and says, like, give me all the, you know, functionality, and make sure that each regular expression is performing perfectly. And Excel software has some minor bugs. 


So, it's kind of, like, a little bit of an interesting situation there. I cannot agree more on the AI comment. It's, like, both an opportunity and a threat. I can't imagine what is, you know, some GPT hallucination finding its way into, like, GxP dataset, probably disqualify, I don't know, hundreds, if not thousands, of person-year work in an instant. And so, yeah, there's a long way to go. 


But this is actually great, you know, cliffhangers for additional episodes that we'll have to do to tackle computer system validation and the role of AI. Mark, thank you so much for coming on. 


MARK: Yeah, it's a pleasure.


NATAN: Really appreciate it. It was a great discussion, and we'll see you soon again. Thanks a lot.