 My name is Cameron Gibbs. I'm a knowledge engineer with Crown Point Technologies. We've been supporting the Pistoia Alliance with the development of the CMC process ontology. And in this short demonstration, I wanted to walk through the prototype knowledge graph that we developed using the ontology in order to validate that it can answer all of the competency questions and use cases identified as a part of the development of the ontology. On our first screen, we're looking at ANZO. This is the semantic platform we used to develop the knowledge graph. Here on this homepage, we can see a rough breakdown of the different steps used to create our prototype knowledge graph. First, we onboarded some sample data. We can take a quick view of that sample data here. Our sample data represents two different recipes. First, we have some process data for monoclonal antibodies manufacturing run involving three different batches done at three different scales. We have process data involving measurements and recipe limits for both process parameters and process indicators. And we also have two files representing a small molecule synthesis manufacturing run. Each file representing a different site and each site at different scales, totaling five different batch processes once we onboarded this the data into anzo anzo will automatically put this into a graph format that we can then align to the ontologies we developed briefly we can look at we have we've developed a core cmc process ontology with many classes defining the different data objects the attributes that would make up the process data. Additionally, we have two controlled vocabularies that extend these ontologies. One vocabulary for what we call recipe component kinds. These are a general way of describing the different process steps that make up a pharmaceutical manufacturing process, as well as what we call parameter kinds. These are general terms to describe measurements, recipe specifications, as well as input settings that would be done during a manufacturing run. These were also imported into ANZO, and finally these were blended to create a knowledge graph. Here we can see the result of the knowledge graph. This view is not representing the instance data, but actually a view of the classes in the ontologies. For example, we have our batch run, we have our recipe components. The numbers in the parentheses represent how many data instances we have of each of these classes. And the relationships between the objects designate how the ontology encodes how these objects should be interrelated to one another. So we see a relationship between the manufacturing process alongside the recipe information and the measurement information as well, providing a continuous framework that can link all these data objects together and provide an unambiguous way of defining them and relating them in a way that both makes sense to a human being and is machine understandable. Let's now turn, we can turn and look at various dashboards and see how these solve the different competency questions laid out. Our first use case we identified was that of process definition. So this is the ability to provide a uniform, universal, and unambiguous way of defining a manufacturing process. I wanted to take a look at two different views describing how the ontology can support responding to this use case. First, we're looking at a graph view of the data objects. Now we're actually looking at instance data, and this graph view gives us the closest representation of how these objects are linked together. In a moment, we'll also look at a table view that'll be a little bit more familiar to what the eventual end users would actually be seeing. Here we can see first the different recipes defined in the ISSA 88 standard, which we've incorporated to provide a standardized way to define recipes and processes. We have our general recipe, which is the most general, non-specific form of a recipe in ISSA 88. This has various pieces of information linked to it, such as its ID, the product name that would be produced by this recipe, the manufacturing stage, whether it's a drug substance or it's a drug product. We have a title for the recipe and we also have a version for the recipe. And this general recipe also derives into the other ISA-88 recipes. For example, we have our site recipe. The site recipe can have a site that it's prescribed to. The site recipe also can derive into two different master recipes. In this case, we have two different recipes showing that a given recipe can derive into any number of different, more specific recipes in the ISTA 88 standard. Here we have, for example, a master recipe defined for the large scale, as well as a master recipe defined at that small scale. And finally we have our master recipe deriving into the control recipe, the most specific recipe within the ISSA 88 standard. Moving back over to the left we can also see the recipe components that are associated with the recipe. I pulled out just one structure of the different recipe steps defined by the recipe components for the general recipe, but this structure would be replicated for both at the site recipe as well as the master and the control recipe. Here we can see our monoclonal antibodies drug substance. It corresponds to a process recipe component, which is the highest level of the recipe component in the ISSA 88 standard. It will break down in turn to process stages. So we can see how the ontology allows us to define a series of process stages that make up a given process. And we can also link these process stages together so we know the order in which they occur at. Just for a single example, I've pulled out a deeper layer for one of the process stages, flow through chromatography. And here we see that we also have process operations that make up that process stage, providing a further layer within the ISSA 88 hierarchy. And again, we have an order of a pool process operation to being required before an adjust process operation before a different adjust process operation. And finally, we've broken out different actions, the smallest level of the ISSA-88 hierarchy beneath this adjust step. So again, we can see an order to these steps where sample comes before measurement process, which comes before a titrate action, before mix, before sample again, and then another measurement process. And so what we can see from this graph structure of the knowledge graph is how our ontology defines all of these objects that allow us to define a process and a recipe in a controlled, systematic, and uniform way. We can also look at this from a table perspective. We can see our recipe title, the manufacturing stage, whether it's a drug substance or drug product. We can see the overall process that it's defining, the possible sites that the recipe would be performed at, and the possible scales. And we see the process stages. Since we're in a table view, in this case I'm representing the order of the stages using a numerical scheme. Within, we have our different stages underneath monoclonal antibodies, drug substance. And we also see that many of the stages themselves have operations beneath them. We can click on a given stage, taking us to another table that will take us deeper into the hierarchy. So now we're looking at only the process stages and we can see all of the process operations beneath them, as well as the process actions underneath some of the process operations. So again, we have a fully precise and defined way of defining a manufacturing process in a uniform way that incorporates the ISSA 88 standard and provides a way to define a recipe at both the very very general level for that general recipe and then further more making it further more specific at the site level and at the scale level and eventually at the control batch specific level. All right, so that is our first use case, process definition. Now I want to discuss our second use case, the monitoring and control. This involves not just defining the process steps that make up a manufacturing process, but also the ability to track different measurements through that process, as well as controlling them by comparing them to the limits for the different parameters and indicators that the recipe specifies. So let's take a look at a different view. This graph view represents how the ontology allows us to profile a given measurement through a series of process steps. In this case, it will be a temperature measurement. So here, starting on the right side, we're starting from our master recipe, which defines a particular scale for the manufacturing run. That master recipe is derived ultimately from a site recipe which would further lead into a general recipe that I haven't depicted here. From the master recipe we've derived down into the control recipe and again we have a breakdown of the different steps of the of the monoclonal antibodies drug substance process. Here I've only pulled out a small number of them to make the graph relatively easy to view. We can see our drug substance itself has a part, our drug substance procedure, rather. We're using the procedure hierarchy of the ISSA 88 standard because now we are controlling particular batches and the recipe components are now equipment dependent. A part of that procedure recipe component is a unit procedure, in this case the production bioreactor step, which itself has three parts that make it up. Unit operations, the fill medium and equilibrate step, the inoculate step, and the fed batch step. Again, we can see not only are they all parts of the production bioreactor unit procedure, but they also have an order that's defined in the process recipe. All of these recipe components also are linked to a batch process itself. So we can see a batch process related to the overall monoclonal antibodies drug substance procedure. It has itself as a part a sub-batch run related to the production bioreactor step, and that in turn has three batch runs as a part corresponding to the different unit operations pulled out and we can see there's an ordering relation between these three where the fed the fill medium and equilibrate batch process comes before the inoculate batch process which in turn comes before the fed batch process so we can see how we can model the different steps that make up the batch process and how they relate back to that process that we've defined. Now we can build our way out from the graph to the measurement values. Each of these batch runs will itself have a monitoring process that could involve many different measurements as a part of it. Here we can see our data set has five different measurement processes a part of our general monitoring process looking at just one we're interested in temperature in this case we have a one a particular measurement process that has as an output a process parameter which has a value associated with it in this case 36.7 there's also a unit associated I had that I haven't displayed here and further one of our terms from our controlled vocabulary our parameter kind terms is used to describe the measurement output to indicate that it's a temperature measurement and we can see that this this general term is describing all of the measurement outputs from the different batch processes, allowing us to have a general controlled way to describe what kind of parameter is being measured in this case. So we are using our general controlled term for a parameter kind, in this case temperature, to describe all the measurements, making it easy for us to aggregate them together in a controlled way. Now this just shows how the knowledge graph has all the relations and the context to these different pieces of data. We can also see how we can view a profile of the temperature across all of the different unit operations at which temperature is actually measured. Here we're viewing one batch, the small scale batch. We saw some of these unit operations. I only pulled out three before to keep the graph relatively small, but we can see that there are actually five different measurements at the unit operation level involving temperature. And with this simple graph, it becomes quite easy for us to profile temperature across all of those different unit operations. Now, another part of use case two, monitoring and control, is not simply being able to profile one value, one parameter in particular like temperature, but being able to profile any given process parameter or performance indicator that would be measured during the process. And from the same dashboard, we can use our controlled vocabulary terms to easily, at a click, pick any of the measurements that we want to see profiles, and all of them that are represented in this chart. So we can quickly, using that different parameter kind viability, quickly rechart to find a new profile, or we can rechart to a volume measurement. And the chart, using the control terms for our unit operations, as well as our control terms for our parameter kinds can easily make these links. Now another part of the use case 2 is not merely being able to profile these measurements but also being able to compare them with the limits described for these values in the recipe itself, the specification upper and lower limits defined in that recipe. This is also something we can do easily with a chart. We have now our same measurement profile for temperature, and we've also charted the upper and lower limits that have been defined as a part of that recipe process. In this case, we can see for our single batch done at the small scale, at a glance we can see that the temperature measurements fall within the range defined by the recipe for this batch. We can also compare our upper, lower, and lower limits with our measurements in mass across all of the parameter kinds at a time if we want to. In this case, I'm looking at a single batch at the large scale. Here we see the scale, we see the procedure, the unit operation, the unit phase, the working day, the time at which this phase has been cycled within the working day, the parameter, whether it's a critical process parameter or not, the lower limits, the upper limits, and the measurement. All of this comes from our sample data that has been aligned to the ontology, and the final column has been automatically calculated within this dashboard to make a comparison from the measurement values with those upper and lower limits to determine if the measurement is out of range. And we see that we have two measurements that are out of range for this particular sample set. Both are interesting to look closer at. We can see that the lower and upper limits are much higher than the measurement value, indicating that there may have been something wrong with the sensor or the data collection process and in the second row we can see the lower limit is actually higher than the upper limit again indicating that that there is likely some kind of error in defining the recipe specification in this case but it's very powerful that we can calculate on the fly the comparison between the measurements and the upper and lower limits to quickly be able to see at a glance that there may be these issues with the data itself. And these on the fly calculations are all made possible because we have a context surrounding the data so that it's easy to understand what exactly all of the data objects mean, both in a human-readable way as well as in a machine-readable way. All right. Now let's turn to our third use case, that of comparative analysis. So this builds on our previous use cases to not simply profile measurements across a single batch, but to be able to compare those measurements across different batches, even if they're done at different scales or even at different sites. Today, this is a real challenge with the data, because when the data is collected at different scales or at different sites, the sensors used, the data systems used, even the personnel involved are all different. And so the label is often labeled in very different ways. There's often ambiguities across the different process steps or in labeling the measurement values. So being able to make these easy comparisons across scale and site would vastly reduce the effort in mere data manipulation so that process experts and process engineers can more quickly find the data that they need. Let's take a look at a cross-scale comparison of in this case a measurement of the duration of a process. And on this much more complex graph, we're now seeing how we can compare the measurements for this process duration across three different scales. First, we'll begin at the top of the graph and we can see that we have a general recipe. This will be shared across all of the different batch processes involved, and it derives into a site recipe. In this example, all of the batches are done at the same site, but there's three different scales involved. So again, all are linked to the same site recipe. But now that we have a divergence with scale, we'll see that there are three different master recipes branching off from the site recipe, each of these master recipes corresponding to the different scales involved. We have our master recipe for the large scale, for the small scale, and for the pilot scale. And each of these master recipes will itself branch down into that same structure we've seen a couple of times now. They branch down into the control recipe, the most specific recipe, defining a specific batch. And we have our recipe components describing the different steps involved. We have our procedure, our highest level recipe component of the monoclonal antibodies drug substance. This has as a part the production bioreactor unit procedure, and this has as a part the unit operation transfer step, at which point the duration of the process will be measured. We can see mirroring the hierarchy of recipe components, what you have a hierarchy of batches that are prescribed by these recipes. So we have our batch corresponding to the highest level, the procedure. This has as a part a batch corresponding to that unit procedure, the production bioreactor. And finally, we have our batch corresponding to the transfer step. Now that structure in the recipe and the batches is mirrored at both the small scale and at the pilot scale, but not only are these different recipe components linked by linking all the way back to the same site recipe, but they're also linked in being linked to the same controlled vocabulary term to describe that step involved. So in this case, we have our transfer recipe component kind term. This links across all of the different transfer steps across different recipes. That gives us a controlled way to ensure that we're talking about precisely the same step. There are recipe component kinds for all of the recipe components. I haven't pulled them out just to see the graph, make the graph easier to see. But there is likewise a controlled term linking all, linking the procedure recipe components and the unit procedure recipe components together as well. All right. Now, branching off from our batches, we have the familiar structure of the monitoring process and the measuring process with the measurement output, as well as the value associated with the measurement output. And again, we have our parameter kind, in this case duration, that's linking across not only the measurements within the different steps of a single batch, like we saw with temperature in the last use case, but also across the different measurements across the different sites. So we can see duration is also linked to the process parameter measurement that ultimately is a part of the pilot scale batch process. And similarly for the small scale, I simply haven't pulled out those batch processes to keep the graph manageable. And so here we can easily make our comparison of the process duration at the large scale and the process duration at the small scale by using this duration parameter kind to track that we're talking about the same measurement as well as the recipe component kind to track that we're comparing process steps in a controlled way. So we know we're taking those measurements at precisely the same point in the manufacturing process. I've also pulled out the recipe specification. This defines the upper and lower limits for the process parameters. We also have that limit defined for each scale for the different recipes, the large scale, the small scale, and the pilot scale. Here we have our upper and lower bound limits that we can then compare with our measurements if we wish. And those are also linked to the same parameter kind, again, giving us a controlled way to ensure that we're talking about all of the same, all of the same values, be they measurement values or recipe specification values. Now, now that we've seen this structure on the graph view, we can go back to one of our chart dashboard views and we can bring in the different scales. So now we can compare our temperature measurements, for example, across the different scales, in this case, small scale and pilot scale. And we can see that there are no temperature measurements represented at the large scale. Things are different if we change parameter kind. We can switch to viability, for example. And now we have all three batches represented, or likewise for volume. And we can see because we have a controlled way of describing the process steps and those parameter kinds that spans across the scale in all three of these batches, the chart can easily update itself and view and can make those comparisons for us. If we go back to temperature we can also see we have a small molecule representation as well. This was our cross-site view, now we have five different batches that are done at two different scales. We can see the two different sites represented here. And again, we can make that temperature comparison very easily across all five of these different batches, because again, we have a controlled way of describing our parameter kind and a controlled way of describing the different unit operations. And again, this demonstrates that our ontology provides a common data model that can span across any recipe, any process, has a uniform way of describing the process steps and the measurements that would be taken. Now, this is a cross-site comparison. On the graph view, we only saw a cross- cross scale comparison so we can end there with this quick overview Let me switch examples Here's our final view that we'll take a look at here. We're seeing a demonstration of comparing a yield measurement across two different sites. Here we're involving a different recipe now for small molecule, a synthesis recipe. So here we have our general recipe with the title of a general compound recipe to synthesize any kind of example compound. In this case, because we are cross-site, making a cross-site comparison, our general recipe will immediately branch into two different site recipes because the processes are done at two different sites. And we can represent the site being prescribed as well, linking both to that site recipe, as well as the batch at which the site is performed. And from here, from our branching site recipes, we have a familiar structure we've seen before. The site recipe will derive into a master recipe, which indicates the scale. We can see the link to the scale here. I haven't pulled it out just to keep the graph smaller. This master recipe will derive into the control recipe, which itself will have different recipe components allowing us to represent the process steps. So we have our synthesis procedure. This is linked to a recipe component kind that also links to the synthesis procedure step on the other site recipe. So again, we can see how that controlled vocabulary bridges across the two different recipes, giving us a controlled way to describe the same step in different recipes. The output step is a unit procedure beneath the procedure synthesis step. And yield is a unit operation step beneath the output unit operation step. And again, we have our three, we have recipe component kinds linking together these, the different recipe components across the, across the site recipes. Like before, we have our structure of three different batch processes that form a hierarchy that mirrors the recipe components. And like before, we have our familiar structure of a monitoring process being associated with a given batch, a measurement process being associated with that monitoring process, and finally, a measurement output. In this case case a yield measurement with the particular value associated with it and our yield parameter kind is itself linked to both both parameter measurement outputs in this case a process parameter measurement output that gives again gives us that controlled way to define the same measurement across different sites, making a comparison between these yield measurements not only possible, but easy to do. knowledge graph that was able to validate that our CMC process ontology, along with the two controlled vocabularies we've developed, is capable of responding to all three use cases, the process definition use case, monitoring and control use case, and the comparison analysis use case. Thank you for your time.
CMC Process Validation Walkthrough
CMC Process Validation Walkthrough by Birthe Neilson, Project Manager, Pistoia Alliance