Hi everyone and welcome. My name is Sasuke Kisa and I was served as your moderator today. Thank you for joining us for today's webinar Pioneering E data exchange for quality and regulatory data. With Stackard as your moderator, it is my role to ensure that we make the most of your time with us. I'm here today with Mario Stauffer, Sebastian Awry, Stefan Pohm and Andrea Hildesheim. As a Product Manager for Digital solutions, Mahreus tries digitalization at the life science business of Merck JA Dempster, Germany. His His experience includes building business models and product strategies for digital products in the life science industry. In his previous role as a consultant to gain extensive experience across strategy, supply chain and digitalization in the life science and pharmaceutical industries. And during his PhD, he investigated how companies use digital technologies to strengthen their competitive advantage. As a global regulatory and quality compliance manager, Sebastian supervises the team for system maintenance and compliance services for BSF Pharma solutions globally. He's responsible for lifecycle management of rexolence within BSF Virtual pharma assistance. Sebastian has 25 years of experience in the broader field of regulatory and quality requirements in life science industries, starting from raw material qualification up to global operations and local registrations. And in his PhD, he investigated how to safeguard quality and complex natural mat materials like spices and herbs by applying modern FT and IRS methodology combined with computer based chemometrics for improved prediction models. Stefan is an accomplished manager for digital products with over 2 decades of experience in the chemical industry. He has LED various initiatives in sales and distribution pricing strategies and digitalization and his current role involves spearheading the design, development and implementation of strategic relevant systems and applications focusing on document management, machine to machine communication and associated interfaces. Stefan's expertise lies in system development, process design and adeptly management business requirements to drive strategy success. As a product and marketing manager for digital solutions, Andreas drives digitalization for BSF Pharma solutions globally with a particular focus on digital customer services within BSS Virtual Pharma Systems. His experience includes Co creating and implementing innovative solutions with customers and building new digital business models. Andreas has over 10 years of experience in the fields of Business Innovation and digitalization, and during his PhD he investigated how companies can leverage the knowledge of sales people in the development process of new products and services. And before I turn things over to our presenter, I'd like to cover a few housekeeping items at the bottom of your screen and multiple application widgets you can use. They can also find our reaction button, indicated by the thumbs up emoji that allows you to give immediate feedback on the presentations, topics or anything that stands out. And all the widgets are resizable and movable, so feel free to move them around to get the most out of your desktop space. You also can expand your slide area, maximize it to full screen by clicking on the arrows in the top right corner, and if you have any questions during the webinar, you can submit them through the QA widget. We will of course try to answer these during the webinar, but if a more detailed answer is needed or if we run out of time, it will be answered later via e-mail, please. Now we do capture all questions. Yeah. You also will have the opportunity to participate in a couple of quick poll questions throughout the session, and I encourage you to take part in these surveys. If you are watching this webinar on demand, you can still submit the poll responses and questions via the Q&A widget. Yeah, the webinar is being streamed through your computer, so there's no dial in number. And for the best audio quality, please make sure your computer speakers or headset are turned on and the volume is up so you can hear the presenters. And an on demand version of the webinar will be available after and also can be accessed using the same link that was sent to you earlier. So that's it. First, from my side. It's my pleasure to turn things over to Mario, Sebastian, Stefan and Andreas. Great, Thank you very much, Saskia, and I'm happy to get us kicked off. And the starting point where I want to start our story is based in the travel industries. So it's an example that we all know that is a prime example of really good data integration that works across many platforms and that is under the hood actually pretty complex. And So what we already used to when when booking flights for example is to use one of many booking portals that were all connected to the multitude that there is of flight operators, maybe KLM or Lufthansa or Delta Airlines. And there's there's all of these flight operators that we actually can can can book flights through all of the booking portals that there are. And what is happening actually that these portals, they focus on providing the best possible customer and user experience with their user interfaces, their knowledge about the workflow, how people want to book, what options should be available. And all of these options under the hood, they're basically being being filled and populated through APIs that they use in API. And in our industry beginning the life science and pharmaceutical industries is often active pharmaceutical ingredients. And here it is application programming interfaces, so important to note. So through these interfaces, the booking portals capture or get information stored at these flight operators and they do it by using harmonized data formats for the time of departure, time of arrival, seat numbers, airline type, but also the meals. And if you're a vegetarian, this would also be covered in in the the options that are being responded from the databases right through to the booking portal. So you can indicate that you are a vegetarian while booking your flight and under the hood there is a pervasive connection about the that connects the data from all of the flight operators right to these portals. Now the question is, because we're in the other industry, can we can we take this blueprint and and maybe maybe apply some of these features to problems that we have in our industry. And one of the one of the pain points that we have is getting information about the quality and the regulatory compliance about our products of the supplier's perspective to customers in the farm industry and the biopharm industry. There's a lot that you need to know that today you get in APDF format. So let's double click on the situation today. So in that status quo section here on the left hand of the slide, you see that for example workflows such as a raw material that you want to qualify or select for a new project. There is things like the regulatory statements, nitrosamines and malarge and the specs that you certainly look at from a compare compliance based on what end markets you intend your product to sell into. There's all of these different types of information that you need and today you capture it either by sending a request to the supplier if they need to fill and then return or you go to their websites or web portals download the information and then have a mostly manually driven internal process for how to capture it. And if you have multiple sites across the world, this multiplies across different projects that you have maintaining eventually different sorts of information. Some might change over time. And overall it is a manual process that often times also includes some some manual copy pasting of information. And the vision that we pursue is to take the connection of suppliers of these raw materials to customers to the next level in the sense that as you see here on the right hand slide, right hand of the slide, the connection is being mediated by this robotic arm. So this means we want an automated data transfer that is based on the data standard so that our customers can connect with multiple suppliers and we can connect to multiple customers at all costs avoiding these point to point solutions that are eventually economically impossible to scale up. And so that's something that we have started to pursue with our partner VA set pharma solutions. And the yeah the benefits are something that we will get into in in just a bit. But one of the main things here is that these things are really important as we've seen also on the last slide and that's what we're working towards. And so to learn more about this, I would like to hand over the microphone to Sebastian question up to you. Yeah. So first exactly, sorry, go for it. So first we do have a poll question for you. So we want to ask you where do you stock quality and regulatory information, PDF, XML, text, word, pictures, etc. So yeah, you can select all that apply and a would be Document Management System, D, Laboratory Information Management System, C, Quality Management System, D Enterprise Resource Planning System or others. So we give you another few seconds to lock in your answers or answer. All right. Thank you very much for. Yeah, your participation in this poor question, quite interesting results. And, yeah, I hand over to Sebastian. Yeah, thank you. So in this in the light of this challenge that Marius had depicted, how to allow an automated exchange of electronic data throughout the chain in multiple steps, one of the major parts that is necessary to come over a critical mass is the question, how does the industry behave? Where can collaborations be placed? And of course as you see here on this picture, BSF with its virtual pharma systems rec students or also our collaboration partner, we have already started digital initiatives which Marius already mentioned might still be a stand alone solution in the relationship to the customer. And then the question is how in a long marathon of establishing a standard being accepted throughout the industry, can we get there and which stakeholders are important as a multiplier. So if you see here on the right hand side, it's not only the question of which players go together like we now did in a collaboration and start something, but also how can you build this up in a broader sense. And where as an industry association or where as maybe a standard setting organization that would say, hey, this is something that is so well designed or so important for the industry that we promote this and would always recommend this. You could even think this one step further and say why not also an an authority. Why would not maybe an authority say if I audit a site I welcome it if E data is used and I'm I'm not doubtful I I I I'm happy if it is validated and and as procedure. So this is something we see as the core basis for an IT protocol and we think that this is where where this where the journey starts at all. And we can also see this in the next slide that where do we start at all. So we did not create everything our own, it was already there, an ASTM standard which applied certain logic and a certain structure which more or less did what we then hopped on and developed further. So the ASTM E 307717 already is a proof of concept. Now what does it say? It is a protocol that says that certificate of analysis can be described with a certain language. XML you see on the bottom and all the things that you see and know and you are well experienced to in a certificate of analysis can be described. The important part why the C of A is of such interest is that it is repetitive. So a certain company would receive a batch from a supplier X and would receive a batch B&A batch C in the same logic later on with the same parameters but maybe different values. So here is a story that is standardized but with a certain change in the content. And that is where the interesting part is that this upscaling this over other documents that maybe behave similar but are slightly different, maybe have text, maybe have a different user reader circle. This is then the story of making the tool more broadly applicable. So the challenge then is how can you, if you apply a logic that works for a COA, describe a nephla taxim statement not only that one customer is satisfied with it, but as Marius displayed also the whole industry would simply accept it as a standard. So the multiplication in documents and the multiplication in players is the challenge for it. Why we said OK, this standard is a good logic, it is already working. It is a language that we know and how can we populate this now into the system of every player in the market when we go now into Stackard as we pronounce it as a standard for quality and regulatory documentation. Let's just look at it, what it is. Yeah. So we have now proposed to you that certain things are developed by us and are brought to the outside community. Well, what is it? In the very first very simple way, it is a text document that people can get from from the collaboration partners and it is and it proposes an E data format and it describes all of this in tables and everything. So having this document is the starting point for understanding what what you would need to do or understand to a document, how it should be designed. It. It is generally free of charge. It can be requested through the websites and if a company would then be interested in it and willing to collaborate with us, then it is of course cordially invited. And this is exactly the point from the previous slide where I said a certain group of people need to move it into a an amount where the market understands that this is not going to work. Now still, what does it say and this is maybe good to to mention it. When you talk about standards, it's always important to say what language do you talk at all, What do you talk about? And this is one of the major things that have been developed in this collaboration. The EDATA language describes the hierarchy, It describes terminologies, vocabulary. You could say if you talk about the language and this it does in an XML language. This together then allows the data can be transferred. So the one side says or states something in a certain logic and the other side exactly understands where a certain piece of information belongs to. As already said, it is an XML structure and the ASTM logic was simply applied over more documents and we started with a certain current scope as you can see on the left hand side statement I already mentioned, but also others manufacturing procedures. Of course some of the documents that are essential for raw material qualification phase. Of course not everything is covered because it's the beginning, but the interesting part for this scope of documents is where it is not everything the same. Why do I say this and why is it so important? If you think about a COA and you would have a document that is more or less maybe a COA but slightly different, you would only have a slight variation for the system to learn or to build more things where something can go wrong or is again the proof of concept. If you have text documents like an after text scene document or maybe you have something which is more complicated like a nitrous amine document, you give the system the chance to develop in a certain way That variability comes in and it broadens the proof of concept. The next step of course is then to say hey which documents can I add even more to it and we come to this in the data point. Now what does the document to those the stacker document to those documents In the scope you can see a preview on the left hand side. Simply a description of which elements in such document can be described. How Stefan is going to look into this more in detail on the following slides, but just as a sneak preview to it. If you imagine that a document has a headline, well, of course then the standard has to say. This is a headline, right? And this is the level of very, very tiny up building stories you could say that we have described in this document and I think that is where I hand over to Stefan to look into the details. OK, good. Hope everyone can hear me. Thanks, Sebastian. OK. So yeah, as Sebastian mentioned, I will give a little bit more insights on the technical aspects and how actually everything is looking like in the Stacker document and how we will retrieve this information in the future. So let me just move to the next slide, all right. So I will give you some examples how the, the structure and also how the the, the whole process will be in the future and also how this relates to industry associations. So here you see an example of a TSEBSE store document because as Sebastian mentioned already, the starting point is really the document. Yeah, it's the document that will be provided by the supplier and we need to basically extract the information out of this document, right. So and for that, we identified several sections within our stack of document. And as I mentioned before, I will do some examples here, starting with the material details. Yeah, for sure most of the documents are product specific. Yeah. So that means we have to incorporate a section that covers information about materials or products, the description potentially also the batch number. That's something that we need to incorporate as well and therefore we have this material details as well. What I would like to point out here is that you always need to take into account that potential additional elements or attributes can be incorporated as well. So that's the reason why we do work together and also continuously work on the standard. Yeah. So that's very important to mention. The second part that you see here on the screen is the statement data. So that's actually the essential content of the document itself. So that means you have the whole document text, including also some regulatory references, some document title and potentially also some information that is related to the original document management system. Yeah, so for example, the versioning, also the document language. So that's also incorporated into our standard. Moving on to more specific certificates or statements, I would like to tackle as well the elegance statement or the elegance certificate. Here you have several allergens listed and we also within our collaboration we talked about incorporating also these specific certificates that we are able to also identify the specifics for each and every elegant. Yeah, so it means in the stackard standard we incorporated for each and every elegant separate section that covers the name, the additional text and potentially also footnotes that will be added to the appropriate elegant. Because at the end what can be ensured is that we can ingest this information into the receiving system. So it means that the receiving system will also have everything ready and you can directly work with the information expected from the appropriate document. So as well another example here is that we incorporate as well some dates that was actually one of the, yeah, the bigger points because we uncovered that within all the documents we have separate dates or we have different dates that we need to cover as well. So for example, when a document was issued, the validity date for example and all these dates we need to incorporate as well. And that's also part of our of our standard. The disclaimer is part of that as well just to ensure that we have all the legal requirements mentioned in the document as well. And also the trademark is something that we need to incorporate. So now that you see some examples here of the of the documents where we expect actually the information, how does the process at the end look like at a supplier side, but also on the on the customer side or receiving system side. So let me talk about this here in a bit more detail. So how do we exchange the information between the supplier and also a customer? So it all starts with the with the source information. Yeah, as Sebastian already mentioned, it can be in several document types or in several data types. So be the PDF, be the document or even a table that is stored in the in the supplier system speed document management system or a Lynn system, whatever. So that means that we start with this data source and in the next step, because I mean we need to, we need to basically combine all the information appropriately. We need to extract the actual information that in most cases unstructured data. We need to move this into a more structured format as it mentioned here in XML format. And with this we definitely need to use our stackard standard. Yeah because that's actually the the basis of all our conversion and also the the use at the end for for the for the metadata that will be done uniquely be available for for the receiving system. Then in the next stage when we have the XML information or the the machine readable information ready, this will then be provided to the pharma company or to the receiving system or customer. This can be done in the push or pull version or no push or pull automated that we are able to provide the information than in the in the receiving system. So that means that on the one hand the customers will be able to pull the data from the source. That's can be done via an API for example, but it can also be pushed to a local server location on a customer side. These are the 2 main possibilities to provide the information. As soon as the information that is available on the customer side, then normally there is some human interaction needed. Yeah, because you need to, you need to see the data at the end. You need to ensure that the data is from the validated source and normally then this is something that should be done also in the initial data receiving. So that's the that's the next step. And as soon as you did that, you can then incorporate this information sort of quality and regulatory information into the local system, be it also here a lymph system or or any other quality system that can be incorporated here. So and to to sum it up here, is that the, the sacred. So that means our standard is the basis for this whole exercise, you know, so it means that we will be able with this structure, we will be able to to streamline the whole creation of the of the information and make it available for for any customer who would like to receive this quality and regulatory information. So then let's move to our next slide. So that goes a bit more into the conversion of whole information. So, so you see on the on the on this slide here, we have basically three different stages. The first stage that I would like to highlight here is the storage or at the end the the data that we will provide or that will be the basis for the conversion to an XML. So for sure the most important or the most easiest way to create information or to provide metadata to to a receiving system or to customer is the master data itself. So this is normally the the way to go. But in this case normally we have to also incorporate or to take into account documents from a document management system for example. And that's the reason why we basically have to take into account two different processes here. On the one side, we have to convert information from APDF from an unstructured format into an XML format, so a machine meter format, but also incorporating master data in this case and that's the actual data conversion. So and also we are currently working on this functionality with with with NER. So that means that we can extract the information from the actual documents and convert them into a a machine readable in XML format. And again here I would like to point out that Stacker, it will be the, the standard that we would like to incorporate into the industry that this will be the way going forward in the future to provide information to to customers or to receiving systems. And then in the last step we can incorporate then the the process of providing the the data at the end in the in the quality management system of the receiving customer for example via interface as I mentioned before, be it via push or pull, but the data at the end will be immediately available. So that means there's no need to expect the information it's available. You can already work with the information by doing analysis or doing dashboards or whatever. One additional point I would like to mention here, Currently the Stacker document covers 9 different documents, but in the future, what can be done as well? And that's also one of our things that we incorporate and we would like to tackle as well, is not only take into account quality and regulatory documentation per say, so certificates or declarations, but also thinking about a broader scope like change notifications. So it means that you can incorporate change notifications as well and attach them to the actual documents. Yeah. And do make sure that we can basically also provide this information in a structured and in a streamlined format. OK. Then tackling the point of the the whole industry what we do as well as we are working together already and that was already mentioned one of the slides before together with bio form. Yeah. So here are two screenshots that are part of the of the disco work streams or the visual integration of sponsoring contract organization. And I just would like to frame it that and we are sure that we know where we are currently working on. Yeah. So on the left hand side you see the whole, the whole alignment structure and where we are playing here. So we are working towards the the standardization of the data structure and to make sure that we have a clear structure and we have a clear standard that we will provide in the communication between the sponsor and the contract organization or customer and supplier relations. So that's very important and it's also quite important to get the feedback also from bio form on also the experts and also from pilot customers that we are absolute sure that we incorporate most of the requirements also into into our standard. And then additionally to that what we would like to do as well as with this whole collaboration that we that we do, we would like to help the industry that customers or any company is able to move up in the digital in the digital maturity level. Yeah. So here where we are at the moment or a lot of companies still are in a in a more manual fashion and we would like to move into a more, yeah, automated way that we can share really data between companies and to make sure that we have a more streamlined in the more robust and more effective, more effective process. OK. So this was the more technical aspect. And I would like to hand over now to Andreas to give more a summary and what are actually the benefits of this whole of this whole collaboration. So over to you, Andreas. Thank you very much, Stefan. And I think it fits quite nicely, Stefan, because you have a question in, in the chat. So there's a person asking here how it is with safety data sheets. So why they are not included currently in the standard and going forward when they will be included. So maybe I think it fits quite nicely to the more technical part and where stickers started. So do you want to keep the answer that one before I conclude? Sure, yeah. So the perhaps I will, yeah, kind of frame it a little. In the beginning when we set up the the whole scope of the documents, we selected a certain set of documents that that was in scope. And therefore we selected two things like the aflatoxin statement like the the nitrous amine and some because they are straightforward. We wanted to start small, Yeah. So that means that we are able to first start with a with a set of data, but it's actually a very good point to incorporate also safety data sheets. Yeah. So that's definitely on the on the radar as well. But this I mean can be done then in the next stage. But a very good point and thanks for the question. Perfect. Thank you, Stefan. So now I will continue with the, with the, with the presentation. And so after you have now seen what M stack that is and how E data exchange is technically enabled, let me quickly summarize what the benefits of E data exchange with Stackard R So first of all, I think it's clear that exchanging data electronically increases speed and efficiency. Why? Because quality and regulated data does not need to be exchanged manually via e-mail or mail any longer. Instead, customers who receive E data can instantly access and use the content. Secondly, E data exchange increases data quality and integrity. Why? As customers are linked to directly to us as suppliers, they can be ensured that the content and documentation is always up to date, so the risk of data quality issues is significantly reduced. And thirdly, there's an increase in flexibility as customers can access the E data from their own quality and regulatory systems using their own technical infrastructure and IT landscape. Moving on, the question is how we will go on from here. So we have published the first version of the Stackard standard guide in June this year. By including customer feedback and also developing the technical structure to Sebastian's point earlier, this standard is accessible for all of you. And so, but the question now is what, what do the next steps look like? So currently we are talking to a couple of pilot customers in the industry who have an interest in and a potential need for E Data exchange. And in those conversations, we basically try to better understand what the customer requirements are regarding what E data documents should be shared. So to that one person's common safety data sheets might be one of the feedbacks that we receive is maybe the next documents that we might want to add to the to the standard. We also try to understand what customers, yeah, want to use E data for and then what kind of systems E data needs to be stored and processed at the customer end on the receiving party's end. And of course we seek to generally better understand what the technical requirements are at the receiving end by taking the customers technical infrastructure into consideration. And I think this was also the first poll question that you that you answer to get a better understanding what kinds of systems you are currently using at your end. Then based on this feedback that we want to receive through this customer conversations, we want to evolve the data standard by adding new documents to the standard, which in turn we think will make will make it attractive to more customers and partners in the industry. And of course we intend to operationalize the standard with the first pilot customers to receive to receive E data. Then let me conclude with the very last slide which summarizes a little bit the learnings of of today's session. There were a couple of people who joined a little bit later. So, so, so I go through this points here real real quick. So what did we learn today? Firstly, we have learned that there are various industries today that already use E data. It brought the applied system solutions Marius was talking about. Yeah, the airline industry here as an as an as an example. And we also know that the pharmaceutical industries face some face some obstacles in exchanging supplier data efficiently. And that was basically the main driver why we as PSF together with our collaboration partner have started the Stackard initiative. Secondly, we have learned that Stackard enables an automated E data exchange in a standardized way. But as my colleagues have outlined, Zika describes terminologies and structures for a defined number of documents typically used in material qualification. We have also talked about that content from quality and regulatory documents are compiled in a defined file structure allowing computers to consume the content within the system landscape of the receiving party and that the proposed data formant is XML. We have also learned that key benefits of E data exchange include a reduction of manual work effort for for for individuals and that machine to machine connections will lead to a higher level of data integrity for the yeah companies working in the pharmaceutical industries. And then finally going forward, we strive towards a higher number of described documents that we can add to the standard and to work with more players in the market to either pilot E data exchange and expand the network in general. So this concludes the presentation part from our end. I think very much for listening to the presentation. I think now we are open to receive an answer all of the questions that you might have. Yeah. Thank you very much. And before we welcome to our QA part, I would like to ask you, are you interested in a follow up conversation to explore how to use E data for your company purposes? Yeah, we will give you a few seconds to answer this question. So, yeah, thank you very much, Maurice, Sebastian, Stefan and Andreas for this great presentation. Yeah, as already mentioned, now it's time to answer a few questions that have come in from our audience. But before we do, I would like to remind you that it is not too late to send us your questions now using the Q&A WID Church. This also, yeah, will apply to all demand views. We will try to get through all of them, but if we, yeah, run out of time, we will respond to you individually. And as a reminder, this webinar will be available on our website soon and all participants will receive an e-mail notification when it is available for viewing. Yeah. So I think our first question could go to Marius. From your point of view, what are the most challenging hurdles to be successful with this newly developed standard? Very happy to go into this. So from our point of view, we have proposed a standard to the industry and the word standard is only a standard if it is adopted. And adoption is really the keyword. And the greatest challenge of Buffalo. There's many good ideas at the outside world how to harmonize and standardize things, but you also need the right partners to do it. And when we think of partners, we certainly have a bunch of different players that we think of. We've already heard pilot customers are very important to get the the market fit, so the the solution and problem fit right. So we're in conversation with pilot customers to learn from them how we can develop this in the best and most useful way. But then we're also in conversation with industry associations who can both discussions for how to make this widely adopted. And then at some point in time, we certainly also need to go through a standards organization. And I think yes, we are not a standards organization. We can certainly make a proposal to the industry. But as the adoption is key, we need at some point in time a a party with with more authority to really say, OK, that's what we're looking at and all these other forums. And then when it comes to implementation, the technology providers are also key. So on the technology end, there is a lot of of cheap technology like APIs and all these these interfaces to push and pull data between companies that we can leverage. And that's why I think it's the perfect point in time to pursue this effort, right. Yeah. Thank you very much for this great answer. Maybe we'll come to the next one. Stefan, I think this could be one for you. How do you see the transition going, for example, from COA to E COA? Is it a legal issue if you have two certificates at the same time? Do you need a clear cut in case ECOA and COA are existing in parallel? What happens if there was an error and one content is not the same as in the other certificate? Yeah, so I think so. First of all, it's a great question. I was expecting that question already and I think I can basically tackle the next 30 minutes answering that question to open up for a discussion I think. So in principle just a couple of words. I think it's important to understand that we're still talking about two different, two different files. So basically two different data. Yeah. On the one hand you have the, the fixed and static PDF data, yeah, including some, some values, yeah, mostly Co as are containing parameters and things like that. On the other side, you have the XML data that is mainly foreseen to be processed by a machine. Yeah, so that's that's one thing. And also I think that we will continue using PDFs in the next 5 to 10 years minimum, even when we adapt the standard and when we implement the standard in the industry, what we can do is or what are the, the principles to make sure that the data will be expected in the right way is that you're using AI and also text mining to extract the information from the original document or even go with the metadata? Yeah. So it means that you expect the information and provide this to the to the customer at the end, in particular, in the beginning, you have to ensure by a human being that the data will be checked. Yeah. And also that you will consider also a validated environment or a validated system environment. Yeah, because with the four eyes principle, you can ensure that in particular the first documents that you extract, that they are extracted or that the parameters and the data is extracted in the right way. And as soon as this was done, you will be basically be able to be, yeah, more or less 100% clear that always when you extract information from a from an original document that the, the content that you provide to your receiving party or to the customer, that's the data at the end will be basically more or less the same. Yeah. So but again this, this can be extended. Yeah, much more. But I think that's, that's, yeah, we need to ensure that the data that you provide that this will be the same more or less than the original PDF format. Then we have another one. Another question, of course, is it possible to extract information from a scanned certificate? Yes. So that's a, that's a clear answer. I mean, yeah, that's there, there are, there are some documents, I mean it's always depending on the quality, right. I mean you have, you have documents that are hard to read, yeah. And this can be sometimes sometimes difficult but the information what we learned so far also from hard to read documents, you can extract the information as well. But again, related to the original comment I made, we have to take into account that you first need a human intervention. Yeah, in all the cases you need to ensure that the that the document first will be checked when you extract the information. OK, then there's another one. Do you plan to provide analytics in your platform? I guess that's also something that I can tackle, but please also the others feel free to to jump in. So we are not there yet to provide analytics yet. So the the scope that we have at the moment is to learn when we provide information to potential pilot customers. So that's that's important that we would like to understand what's the the data that we provide, how this is transferred and also how this is consumed by the receiving party. And for sure, in a later stage, you can for example provide dashboards. How sufficient is the data that you provide? Yeah. So because at the end, as I mentioned before, you need to extract it from the original document and for example, you need to provide a certain confidence level that's nearly 100% that you are sure that the data you expect is right. These are the dashboards that can be provided, but you can also go a step further and provide additional services. So for example, that customers will be able to also convert their own documents. Yeah. So that means that they have their own documents and can extract the information directly. So these are all the things that are that are in our minds, but we are happy to to, yeah, continue some conversations also based on the questions here. So that's, that's that's actually a good question regarding dashboards. Absolutely. OK. Thank you. Maybe this one could go to Maurice or Andreas. Where do you see the standard in five years? OK, I I'm not going to stop Maris and then you can add to this. Yeah. No, go ahead, please. OK. So we've come some way to to come to this point and I think in five years what's important for for this to really bring value to the industry is adoption and to drive adoption. We need the right partners at hand. I think on the trajectory there, we need a handful of committed pilot customers to explore what could be the best way to really bring this information exchange to the next level because I think the status quo is less than optimal given the technologies that we have at hand. So in five years, my vision is that we have a powerful team that has developed a set of standards. They can really support one of the key use cases, let's say material qualification or material selection in its entirety. So what we have proposed is only a set of nine different information pieces. Certainly there is a lot more and that's what where we need to close the gap, but we can't do it alone. And so that's where in five years we have a workflow covered. We have a powerful team spending the industry at hand and that's how we deliver and and make digitalization happen in the industry. So yes, feel free to comment on that. Oh, you almost covered it all. But I would totally agree that that our path, what I said before is really tough now to to make this close connections to customers to get a better understanding what these requirements are. Because at the end of the day, we can only make this a prominent standard in the industry. If you truly understand what this customer needs and requirements are and then how far we have to develop the standard further by adding new documents, tables and things to the standard that are of value to our customers. And I think if we do a good job there and I'm satisfy the needs of of our customers, we will be in a good place to really drive this standard further and make it something that's valuable to the Pharmaceutical industry. So I'm really optimistic about it. That's great. Anything that you want to add to this or shall I give you the next question? Next we can move on to the next question. Yeah, all right. I think this could go to Sebastian or Stefan. Can you give some examples what was discussed during the collaboration sessions developing the guideline? Yeah, yeah, of course we can give a few examples. It has been a great time with big challenges. But as you see in the result now, it was very fruitful and it was just to make this clear, it was a group of different professions that set together, so interdisciplinary exchange. And I could for example. So Stefan brought the one example with the date before already. But I can also tell you that if you if you put three or four companies documents together that describe their regulatory document to aphotoxins or whatever it might be, it is already very different even though the topic is the same. So just imagine that a regulatory reference is given, it can be long, short, abbreviated, whatever. And even though those tiny things seem a bit bureaucratic, but you have to tackle them and you have to take a decision how the standard then who deals with it and you come to the next document, you come to the next question. If you have a long quality document describing your GMP status, the question is what do you do with you know, 3 pages of 20 paragraphs, how do you deal with them. So it's a bit technical, a bit bureaucratic and we simply sliced that into pieces and just went through question, question, question, took decisions and that was one of the hurdles. Of course it took time, but it was also then the the, the steps to success, I think, yeah, I agree. And I I just would like to add that the, the collaboration between the, the partners here, it was great. Yeah, because even between our companies there's a huge variety of the documents, yeah. And that was great to see how different the the documents are and and therefore it was I think just to to to frame it, I think we discussed roughly 100 questions at the end and also made decisions out of that. Yeah. So and also tracking that that for the future we will be able to also provide that information to potential partners that we know. OK. For example, the format of our dates is always according to an ISO date format. Yeah. So and that's that ensures that also here we are in alignment with existing standards already. Yeah. So but again that was great, great collaboration and the dates is also one of my highlights. Yeah, all the different dates that we that we capture and then all the text information and so on and so that was that was interesting. Yeah. Well, then we have another one for review and manufacturer qualification, print out copy is required, that's your XML data, have print out facility with proper authorization E signature, yeah, perhaps that's that's also something that can be handled through a lengthy conversation or also discussion. So in principle you have to also differentiate again between the the static PDF format that can also be assigned by an E signature for example. But the XML is again mainly used for a machine consumption basically. But what are also things that we that we yeah discussed in our collaboration is that if we would like to visualize again an XML content, Yeah, so because at the at the starting point you have the PDF then you move this into a machine readable content and at the end you would like to ensure that you make this available again. But the question here, and that's also part of our conversation, is that necessary that you first use the PDF, make a machine readable content again, pull it back into APDF? Yeah. Or using the original PDF. So these are all the things that we need to consider. And also that on a legal perspective, we need to also discuss them. Yeah. Is there a need to sign an XML document, for example? So these are the things that because it's completely new. Yeah, we are, we are just starting with that. So and therefore these are the things that we need to discuss and we need to ensure that we go in the right direction. Yeah, I can maybe shortly add on that you have, you have directly pasted Stefan into the right question is as I said earlier, can we have an authority maybe jumping on the train and in the latest standpoint, I don't know, maybe in five years or whenever there is an acceptance that a validated E data exchange has its proof and signature already in it. So let's not think about that. Someone needs to print out because you print out since 30 years. So let's rather think about what can be a future solution where the secured information can sit in the machine. So there's a There's various approaches to it, but the question is already pointing to where we need to work on. I think we have time for two more questions. What from your expert opinion, what a company interested in such E data need to do to get started? Yeah, I think first and foremost a certain interest and an appetite to digitize the process. I think this is, this is very important. I think there is a huge potential in working towards a digitization of this, of this whole process going away from the from the PDF document into a machine readable content. Again, we will still continue providing the PDFs. We will not say, OK, just get rid of the whole PDF documents, just providing XML. I think this is not nothing that we can do right now. And I think to get started, first of all, yeah, again is the interest also to ensure that you have a good knowledge of your own system landscape. Yeah. So that means that starting a conversation, you have the right people. You have to or you need to get the right people on the table and make sure that you have a good conversation, including IT, including quality that you know, OK, what are, what is the data, what is the, the actual process behind the scenes. Yeah. So that means when we provide the information, what is actually the, the consumption of the data in the receiving system. So these are the things that you need to think of. But I can just emphasize if you are interested, I think there was another question like this. If you're interested in that, reach out to us. And yeah, start conversation and be part of this, this great journey. All right. Then our last question would be, is there a need for technology standard in times of powerful AI? Yeah, this is Sebastian. Everyone of us can talk lengthy about this, but I think we need to be very careful to not throw everything in the same bowl and then stir it around. So of course if you use AI wisely, you have as maybe one company certain benefits from it, right? You get information in and you can apply some model to it and then AI helps you. But then you just solved your own little problem, maybe with a high effort standard always helps the industry to broadly simplify something where later on everything is clear and everyone can hop on the train, so to say so. And then you could even maybe combine it and say why wouldn't the standard itself use AI to do something. So AI itself is not the solution to everything, because applying it correctly also costs a lot of money, time and efforts. This is a bit a provocative statement. All right. Yeah. Thank you very much for all the questions you handed in. If we did not get to your questions or question, please feel free to e-mail our press presenter directly to register for future webinars or yet to access our archive Webinar library, please visit our website. And yeah, I would like to thank Marius, Sebastian, Stefan and Andreas for today's great presentation. And also thank you to our audience for joining us. And yeah, have a great day. _1732520885127

        _1732520885356