Static Documents to Structured Knowledge Regina Preysing

Yeah, hi everyone. I'm happy to be here. First of all, I'm from Germany. Uh, we're gonna talk about, um… Yeah, why we should go for digitalized documentation, why we could even say some. Kind of document management's out, information management's in. Um, and I'm… I'm here to just discuss this with you and try to. Find your ways. Into understanding this whole… thing what it's about, so… Yeah. Um… That's why I'm here. And, um, I will start to share my screen. If that's possible… Um, let me see… This is what we haven't tested out before.

Regina, tell us a little bit about your childhood. When you were a little girl in Germany, did you dream of growing up to be, um… regulatory consultant. Oh, no, certainly not. No. Instead, it was what? Um, I always wanted to do something with my hands. So I… and to do something investigative, so maybe become something like a… A medical doctor, but I didn't want to… You know, working. Kind of old hierarchical environment, so I didn't. I became an engineer instead. For constructing devices, like medical devices. Fantastic. And what has brought you to, um… you know, your current… topic. Like, how did… How did… how did that journey from where you were.

You know, as engineer, to structure documentation. Well, I spent about 15 to 20 years in. It, um, doing… business applications for various, um, large companies in Germany and throughout, like. Yeah, like, global companies and car companies, defense banks. Every kind of, you know, branch that you can imagine, and um… We always had to do with workflow applications. That is, um… cutting down processes into single steps and single procedures, and that's… That's the way of thinking I had implemented in those days.

And, um… Yeah, and then I came into medical device, um… software… system design, and then I saw, okay, they intended to write down everything in Excel files and Word documents, and then they… Even in the company where we had a kind of, um… Up-to-date, um… system to managing documents, which was an Excel table. I experienced that it's really hard to sit before that table and not to know, oh, has this test report not been written for this version? Or is it just not filed in this Excel table, or has someone made a mistake when filing it and giving it the wrong number so we can't identify it?

And then trying to find out what's the truth, and maybe having to go back to my test manager and telling him, okay, you forgot to. Maybe, uh, to upload this file, or is it there, and have these discussions that was really bad time, so I… I was going on to find a solution for, okay, how can. During the moments when our developers do their work. How can, um, the documentation they need for this work already. Be used for the regulatory documentation that was then. What I try to find out, and that's why I found a tool which managed to do so. And I still, uh, went on using it. By then, and then I was part of this team who created that tool.

And now I'm a consultant trying to bring this idea into the world. Okay, guys, you have to go on, please, and digitalize the documentation. Makes your work easier. Right? Pretty pleased, pretty please do that. Um, uh, so let's dive in. Yeah. So… Um, first of all, the question always is, why? Why do we have… to create all these documents that we have to bring, and then to FDA, or to notified bodies. Uh, what do we have to prove when we want to… So, evidence, and when we want to prove we are compliant to medical device regulations, so… Why do we need this detailed documentation? This is a question to you, and you can just, you know, use the chat and… give some ideas why you think we do have this document.

Why do we need it? Well, do we wrap around… wrap these, um, documents around the patients to save them? Yeah.

If anybody hasn't been promoted to panelist that wants to be promoted to panelist, just raise your hand. In the, um, with the virtual hand-raising thing. Sorry, I'm trying to do… Too many things once. Um, and we had a question, how do you register for, um, Leo's. Thing next week. It's just medgroup.biz slash calls. Is the single login for everything. Right now, it says register for Regina's, but underneath it says upcoming. So, you can, um, register for all upcoming calls by going to medgroup.biz slash calls. I'll put that in the chat. Um, and… Yeah, so let's keep going. Yeah, so we have a lot of… ideas why we want to have this.

These documents, and actually, it's, um, yeah, it's patient safety. But, uh, the authorities, they really want evidence that your processes and procedures and the products and the decisions that brought you to. Every single line of code, or every design decision are controlled, traceable. And risk-aware, and that's what they want to see in an audit. Um… Yeah, and that's why it's… it's a law. Uh, that you have to use this kind of documentation, which contains. All the information, how this product has come to life. And how it was made, and which procedures you said you want to follow to make sure.

It's the same product every time you produce it. So… so that's the reason why it was made, so actually this documentation contains all the information. About your product and about your company. And, of course, it's easier to create this documentation after the product has come to life. But it then will only have this information. For the auditor. And of course, that will save your company and cover your ass, but, um… Actually, this information could be used much better. If it was there before. And, like, here we have, um… an example of a situation.

Of the company of a ventilator, um, for… for… Yeah, for people in intense stations. Um, they have to be ventilated, so… And in South Korea, there's no nickel allowed in screws that are in such ventilators. And so the, um, manufacturer has… Either to take Prague from the market, or they have to exchange the screw. And now imagine what happens if you were the manufacturer. In your company, when this little screw and a ventilator machine has to be replaced. Where will people have to go, and how can they identify. Um, that… everything has been done, and the school will be replaced once the next product's going out. What do you think? Where will people have to go?

And how long would it take in a company you know. In the way that it's documented today. To make the screw really be exchanged in the next version of the docu… of the product, sorry. So you have to go to a lot of. Um, various… IT applications to various document files. Repositories to various, um. Excel files and adopt them all, and um… to know, okay, which documents would I have to touch? Um, who can do that work? Yeah, we were talking about this, um, yesterday. And, you know, it was really eye-opening that, you know, one tiny change, like a tiny screw for one country.

Impacts everything from supply chain, um, all the way across. The company, and that the number of places that needs to be documented and changed is… is incredible, so now imagine, um, a standard change. Coming along, like, 60601, and it's gonna impact the quality management system in the numerous areas and divisions of the company. You know, where entire protocols are gonna need to be rewritten. Now you're dealing… you're… I mean, the screw example is a small… Um, nightmare example in the, um… major regulatory changes, such as, you know, EUMDR or standard changes that have far-reaching impact.

Um, create a documentation nightmare. Um, of epic proportions, and then you… amplified that across 50 or 100 products, um. You're… you're… you're facing a virtual impossibility. Mm-hmm. That's even. No, yeah. Um… Yeah, I just… just wanted to comment on that. It is correct that, you know, obviously documentation is vital and essential. But one of the mistakes that I noticed within the regulated industry sometimes is that. We write too much. Into the documentation. In other words, we create. A documented, um… statement that sometimes is so strict.

So specific. That when we make a change, going to what Sean was saying. Now we are basically compelled to update that document. And to make a regulatory submission. Because of the specificity level that we put into something for which we may… we may not have had the need to have been so. So I think that the documentation is important, but sparked documentation is also important, and this is something that a lot of companies, uh. Do not recommend. So they want to be so specific, because they think the regulators will appreciate that. But then they're bound by such specificity. But now, whenever they make a change, they have to update the document.

That's especially true, I think, when you… in your QMS, try to be so specific in your process descriptions. That will really hang you up whenever you want to make change. Um, yes, we had an experience in a company where we did. Um, um… service for other companies for design and development of devices. And of course, we had a very small. And tiny process description in our QMS to be able to. Support all of these different products, yeah. That's something that's really important. Mm-hmm. Yep. And, um… In Europe, we also have these upcoming rules now for environmental.

Compliance, like, for CO2, um, reduction, and for… Avoidance of waste and all that kind of stuff, and this is something that even would apply to those crews and to other material in these kind of machines. They would have to be. Monitor it, and maybe changed, and other suppliers will have to be found, and they have to be bound into with, um… contracts on quality, all that kind of stuff, risk management will have to be adopted, there have to be many more hazards that could apply on the same. Components, they might not be hazards for patients, but they might be hazards regarding. Other regulations, and so… It's like, do you have to blow up your risk management file?

And sort them all again on a different order, or bring new aspects into it, and so… These are the current challenges that really appear. Uh, that might screw up the minds of the people who are. In charge of, um, managing all those documents. And, uh, would you agree? That when you have, um… just dedicated silos of documents, then it's gonna be hard to… to have the screw replaced? Um, yes and no. Depends on if you've planned it out. I mean, in the virtual system that I've created. That all these questions, we've built methodologies for doing that. Because a lot of startups can't afford to go digital or electronic, so… I see where you're going on it, but I want to… I want to know what the difference between digital and electronic is. That's kind of…

One of the questions I'm struggling with on you. Mm-hmm, mm-hmm. Well, actually. Um, digital and electronic might be, depending on who's talking about it, the same. Electronic is just the hardware, and digital is the software. Uh, but, um… For many people, it's already enough, uh, to have PDFs and a. In the file system, and our document management system, to call it its digitalized. Um, for other people, it's necessary that these PDFs are searchable. Which is already one step, and then it depends on which kind of search engine you are using. You can go very fast with it, or very far. But then, if you go farther, um… you may… you may be able, um, to even ask your information or your document system, okay, show me evidence.

So, traceability. Show me how do I get from a standard requirement. To the real process. Activity that is in your QMS, and where is the evidence that your people work according to this process. So show me evidence of the reports that are created according to this process, um. Definition or something like that. And if you can do that. Uh, easily, um, in paper files, nobody will harm you for that. If you just have one product, maybe that's fine, but as soon as you have to change it. Still, you will get into. Problems. You'll get into a lot of work that you have to do.

But how do you do it all in one system? Because, like, I've seen, like, and I'm using master control as an example. Master Control… We'll give you the where is, the documents, and the approvals needed if you configure it, but it's not going to give you the risk linkages, and it's not going to give you. You know, it's not going to give you… If you don't set it up correctly, it won't give you document mentions. So you have to, like, configure it. So. In your proposal, how do you solve all five of those with digital? Mm-hmm. Mm-hmm, yeah. Maybe I go a bit further, and you can maybe discuss this again, because we need maybe some wording.

To get into it. Um, and to discuss this further. So just, uh, let's imagine the situation of a recipe book. Okay? Um, the traditional documentation is like a recipe book. You have a lot of, um. A lot of single documents that describe. How something has been done once. Okay, how a soup was cooked once, or how you could… repeat exactly cooking this soup. Under the same conditions, with the same material ingredients, and so on. And it's static. It doesn't… it doesn't change. Maybe… maybe it has versions, um, then you will have to know which is the most current one. But, um, it's… it's… it's static, and if you are the one that creates the recipe book based on the ingredients you might imagine, then you will have a lot of redundant information that you have to create. Okay, cut the onions.

Cut the carrots, um, cook the carrots, cook the… the onions in oil, all that stuff, and this is redundant information that you will find in a lot of recipes all the time. And if you want to change it, like, you find out, okay, ah, there's not just one kind of onions, there are various kinds of onions, and now I have to. Um, to say, okay, there's this onions, red onions and white onions, and… sweet onions, and so I want to make that difference in some recipes, then you would have to repeatedly. Make that change in various of these documents, and this is a lot of… you know, work that's boring, and that doesn't make fun, and you don't know in which recipes would I have to replace this information right now.

And, uh, this is exactly the same. That the static information in static documents is… is… giving us right now. And then when you would imagine a digitalized, um… recipe book. Wouldn't have recipes, maybe even. It would maybe only be able to dynamically create a recipe for you when you ask it, okay, I have onions, I have. Carrots, and I have beans, please tell me what I can do with it. And maybe you would even give it the information about which tools do you have, and which, um, um… environment do you have to prepare? Um, to even, um, make it more, um, specific on which, um.

Menus, it could give you, or which meals it can suggest you. And that's just the… the digitalized way of knowledge management. It's dynamic, it has reusable components, it's much easier to be set up, you just focus on completely different, um… topics, like, you focus on the quality of your ingredients. You can differentiate between the kinds of carrots, the kinds of onions, the kinds of… Spices you have, and so on, and in the end, you have a much. More easier way to also make variants, um, of meals, stuff like that. And this is the difference between the traditional way of documenting.

Which is really telling you once. How something has been made once. And the capability of doing things, um, a standardized way. More than once, and it gives you the ability to change fast. To change single components without touching the rest. Um, and to be very fast in creating new combinations of what you already have. So that's the difference between, okay, a slow company. A company that… that isn't… isn't able to do fast changes, even may be reluctant to change. Be it a necessity to change components, or be it necessity to adopt to new regulations, or to new markets. So it's a company that might stay behind in.

Fast-changing situations like we have now. And the one that has a knowledge base, which is… um… concentrated and focused on the single information items and their possible linkages. And is able to combine this information in a rule-based way. Um, this organization can move much faster and change much faster. So that is the… that's the difference from seeing from above. And we have digital systems that do this kind of stuff in this world, since many years. Um, just an example from the real world, just imagine… We have so many, um… internet and IT applications, they can, um… They can be presented in various languages. Look at all the webpages that have various languages that can be translated automatically. This only works.

With digitalized knowledge systems, with digitalized term structure. It wouldn't work with, um… this, um, static web pages. Okay, and this includes mechanisms quite simple, fast, and easy to use. That allow, for instance, the change of the languages. Okay, just to give you an example of where in this world we are used to this kind of. Applications that allow the use of digitalized knowledge. Structured knowledge… Have you, um, an idea of what… This might… carry inside.

Is that something you would say, oh, it makes me fear? Um, I think I can't handle it, or do you think this could be something that can. Be done the next… He is in your life? Take care of digitalized knowledge instead of documents? Are you asking if we think this is possible? If the people call. Yes, yes? I'm asking about the feeling that it makes when… when you get, uh, this… this picture. It makes me excited. I don't know how everyone else feels. I mean, I was thinking about your example about the recipe book. Imagine if you had a GPS system that couldn't tell you when roads closed.

Yeah. I think Waze does that already, though. Yeah, it does. I'm saying that imagine if Waze wasn't able to tell you about road closures, because somebody had to go in and manually change it everywhere. You know? I know about Adobe Framemaker and Madcap FLIR. Is it something that's… Delivered to what you're saying? Um, I didn't catch you. Could you repeat the question, please? Um, I'm saying that I know softkers like Adobe Framemaker. And, uh, the other one is Madcap Freer. Which have, like, dynamic, basically, chunks of boxes. Text boxes, and then you refer them to… other documentation, and the idea is that the information is unique at.

Present at one place. So, once you update that. Mm-hmm. It gets updated wherever that's referenced in. Yeah, yeah, that's exactly a very good example for this kind of systems. And an example. Where it's used exactly for content management, that's where these systems reside, yeah. Faisal. Yes, uh, so I love this. I mean, I think I would want to give some sort of an example here. Or an analogy, because so much of the existing problem really relates to. Kind of the tradition of writing. Documentation. We are experts, we're writing these documents, we're reading them, and there is just a lot of redundancy in that.

That caters to the tradition of writing. But it is not necessarily as useful when it comes to the actual. You know, the actual, uh, problem. And so digitalized knowledge, I find it… I find it extremely poignant. I think it's… Uh, I think especially because of the tools that we have now, we can imagine that we can move beyond that. Paradigm now, where we can… we don't need to have these people that are sitting and catering to the tradition of writing and documenting in the traditional sense. It reminds me a little bit of, um, I read somewhere about how scientists would argue with one another maybe 100 years ago.

About how many teeth are in the horse's mouth. But nobody would actually just open the mouth and check it, because that would not be the tradition. The tradition would be. That you argue and you pose these arguments and have a debate about it. But really, that was not necessary once you could… you could have access to horses, I guess. But this, I really love this. I think it makes me feel like this is the fu- this is the way, not even the future, this is the now. And we, as regulatory professionals, should try and understand how… how can we help with this. Um, so I'm very, very. Positive about this.

Thank you. Fantastic. Deepa? Yeah, hi. Um, thanks for inviting me, and um… Um, I'm an ex-technical writer, um, and I work with. Uh, content, uh, component content management systems, and… Just a couple of things that have come up, uh, in… what you've said, Faisal, you mentioned, uh, traditional writing. One of the things, um, I think that has… the word has to be spread is that we have to move away from the traditional writing paradigm. Where we're writing linearly, we're writing from a beginning, and we're going towards the end. We're living in a world where we all contribute now, and so… The way that you write is, uh, has to change to, I'm contributing towards a pot.

And when you're changing towards that, what you have to then start doing is identifying. Different types of knowledge, and then labeling them as shareable. So, in the regulatory space, one of the things that I used to have to really work through, and uh… fight with is, like, safety notifications. You've got a safety notification, which is a danger, um, do not put your finger in here, otherwise you'll get. Electrocuted, and that's like a risk of death, so that's why it's danger. Um, now, you don't want to be writing that again and again and again, and if you're writing in a Word document, that's what you're having to do. You're having to copy and paste that several times.

When you start with a communal writing. What you do is you identify that risk, and so you go to the risk management database, and you say, there's. Three spots on the machine that need a danger. And so, we're going to work together and create one danger. For it, and anyone that is writing. Oh, you're muted. I'll unmute myself. Is that okay? Uh, now you're muted, Sean. I'm sorry that was my fault. Alright. Uh, yeah, so, um, we're all writing communally, and I thought you wanted me to shut up.

Um, we're all writing about this part of the machine, and so what we do is, rather than write my own new danger, I'm going to go and look in the pot and see whether or not there's one that exists. And then I'm just going to refer to it. And so the day that, um. That… we find a way through mitigation by design, to close that gap and make sure that it's no longer a danger. Every other part that is referring to that, once we change that one component. Every other part gets that update. So the ne- all we have to do is just. Publish a new one, and you've mitigated any risks of having different information. We forgot to update it in this one document, because that person was on holiday.

You've mitigated that by communal writing. Um, these frameworks have been in… they've been in use for quite a while, and in software documentation, Ditto was written for software documentation. Ibm proposed this system. Based on, first of all, let's… type… types of information. Let's say that… First, when we're going to write something, let's classify the different types of information that we're going to create. So we're going to create tasks, and so on. And that allows you to create your first compartment of. Information types. And then within that, then you can have smaller components. That address different parts. Yeah.

So, I want to make sure that, um, Regina gets time to get through her presentations. I'm gonna… Cut you a little short, I apologize for that. Yeah. No worries. But I would encourage all of you to, um, contribute your comments, um, in, uh, the chat as well. Um, and let's let Regina… Proceed, thanks. Yeah. Thank you. But, um… Yeah, Depot, that's completely true, what you said, and that's exactly the way, um, that these kind of systems are meant to be, and exactly like you described with the risk. Yes, there is a regulation that tells, okay, you have to identify in risk management which kind of dangerous or hints to the users you have to give in your IFU, and so it's easily to be set up just the way, as you just described.

And the advantage is you could show evidence to the auditor that there is a traceability from your risk. To your eye of view. And that's something that's very important, um, in terms of. Compliance and evidence for compliance, right? And so the conclusion table just here shows, um. The difference between document-based and knowledge-based. Uh, uh, information management. And, um, as you see, okay, in the structure here, you can read, of course, is files and folders, and on the other side, it's modular and classified items, just as you described it, Daipo. Um, you can make updates in document-based systems only manually, and you have to do them redundantly.

And knowledge-based systems, the updates can be done automatically, like you draw a report from a bunch of. Of information, and so the update is also consistent. Um, the search and document-based, um, um, systems is really… Uh, it's a mess, because you can only search based on names and on titles, and on… in document-based systems, uh, if you don't have a full-text search. System, you can only search based on the. Titles of the documents, and so I've seen discussions. In Teams, how these document names shall be created, if the company shall be. First, or the date, or the process name, and so on. And this all can be forgotten when you go and have a knowledge-based system.

Then you don't need to care for document names anymore, or data titles. Yeah. File titles. Mm-hmm. Um, the change impact in document-based environments is really. Um, big, um… you don't know where changes have to be done. And there's a lot of situations where you can include errors quite easily, because you just forget a single file, because you haven't found it or identified it. And when you have a knowledge-based system, the change is going to be transparent and traceable, and that's the important thing. For, uh, compliance evidence. And of course. And as document-based system, reusability is limited because you can't identify the content that you want to reuse. You might even think there must be something, but before you find it, you write it yourself down.

And another time, and so you create redundancy that are inconsistent. And a knowledge-based systems, you will have systematically approach on reusable content, and that's really… An advantage that saves you time and is therefore helping you with consistency. So if we go and have another… Um, idea, how can we start? Like, when you have already a system that's document-based, and you're in the middle of whatever you do. Then you need to find a way to start with a change. And so, the change would have to include, okay, I need a new structure, I need to have to create a structure for my knowledge that I have.

And I probably will have to… check out if there's a system I can use. To then manage my knowledge and do what I want. So, what you would want to do is… select, uh, current. Actions that you have to do, anyway. Like karpas, you have to solve, or, like, change requests which are open, or even in a request. For a new regulatory framework, like in Europe and the NISTRI. Adaption for cybersecurity. Of the company. Um, so that doesn't only apply to software as medical device, but also to any. Company that makes medical devices, even if they don't have software.

Um, so these would be the process activities that are the ones that. Are good to start with, because they have an end. And ended amount of… a defined amount of. Linked procedures and other activities that you can already combine it with. So, the first steps are, as Tripu already described it as well, so you have to define. Which information classes you want to include. You have to configure them in the application you choose to manage your information. Then you have to define, um, the relationships that this information classes can have. Um, and you would have to create items then, and link them accordingly. And then, once you've done that.

You can try to derive reports and create the documents that you usually would want to have. For whatever evidence you want to show. Um, and that's how you can also test your applications that you might choose, um. To work with, and this presentation has been done also for the European market. And the German market saw their startup and Empolis, which are German companies that deliver systems that could be usable for this, um, purpose and might not be known to you, but matrix Requirements has already been mentioned. Last time on Polarion maybe is also not so unknown. Uh, although it's now owned by Siemens, um, these are examples of.

Applications that are easy to configure. Uh, in terms of… you need to define your information classes. Our information types, and the relationships you might have. Um, and something like ambulance is even capable of. Keeping large information… and knowledge contents that can go through the whole company, through any process, so they are closer to a… component content authoring system, then, um… It's something like matrix requirements, which is quite straightforward as an ALM system. But can also be used for any kind of other information you have. To store and to manage. Yeah. So this is… Mm-hmm, of course.

Molly, does that answer your question? Um, so I guess what I'm struggling with is, you know, concepts between paper, virtual, digital. In EQMS. And, like, you've got those pilot tools. But I really want to see a demonstration of how those could be used, versus just a pointer, because… It's all fine and dandy to say you can do this, but until you actually see a live model functioning, it's hard to see the proof in the pudding, right? Does the pudding stand up? Yeah. Agreed. I totally, 100%. Buy what you've got here. These are… these are problems that need to be solved. This sounds like a good way to solve them.

But, like, is there… or do you have a product that's coming that we're going to talk about? Like… Or is this… are we just having, like, a… discussion. Um, this is… I'm not going to introduce a new product here, I'm just… I'm just trying to… Um, bring up the necessity, uh, of. Doing this change… giving you some kind of the idea, okay, there might be other… tools than the ones that we know in this world that are used for very similar problems. Very, uh, successfully. We just can look at those tools that we know for our, uh, for our, let's say, regulatory affairs and medical device. Um, area, and the tools I wrote here, matrix requirements, are Polari and CertHub, or AmpulisD can be used for this, um, tasks.

Employees hasn't been used for it, um… But the other ones have been actually created for it, so, like, I could show you an example, but I'm afraid we won't meet the timescale for it. But, uh, we can sit together in another meeting and go through it. Yeah. I would be interested in that, and… but the problem with all the tools you listed here. Yep. They're really expensive. And they're kind of… the UIs are kind of… You gotta really know what you're doing to navigate around them, and so for smaller companies, I don't… think that… that those particular tools. Are practical. Well, I was just thinking the same thing, Michelle. The challenge of it is, is my clients can't afford these tools, which… why they start with the virtual.

Exactly. But another thing to think about is we talked about this information and everybody contributing. Well, I guarantee you, you gotta validate the person contributing that. How do you ensure the person contributing knows what they're talking about? Because I can tell you there's… There's debates with people I know and respect, and we don't all agree on everything. So then how do you… if you're going to a digital world where you're not going to the right pathology, how do you review that in totality context? To make sure it's meeting the requirements. Exactly, thank you, that's another one.

And what do you do if it hallucinates? Uh, okay, that, uh, if, if we start introducing AI into it before, being able to manage what we do. Uh, we'll end up in a mess. So, actually, without, um, going into the capability of managing structured knowledge. Will end up in real big problems when introducing AI, Michelle, I'm completely with you when it starts hallucinating. And we can't see it because we don't… we don't have the means to find it out. Um, so when… when introducing AI, we needed to… write its output into a structured system so we can check whether the answers.

Are reliable. That's the first thing I would ever do. So, I'm a strong user of matrix requirements, and I can really show you what I think should be done. Using it, and yes, these tools cost money, you still would have to think about what it costs not to be able to do changes, because you are stuck in your documentation, not to be able to. Include automation by AI, um, that's the second thing. Um, but I believe that… With tools like matrix Requirements and other SIS tools, it's possible to. Uh, even combine, um, various companies in one instance. We've done that in Europe, we've done that in the Netherlands, especially for startups. Um, there was one consultant caring for more than one startup, and they used the same instance.

And… So, wait a minute, let me clarify before, because how do you… prevent… the confidentiality bridging, if you're merging or sharing content with multiple clients. Well, you have user… user rights, and you can restrict user rights to content. You may have. Especially with metrics requirements, have the problem that you can not prevent, uh. Currently access from the administrator side, but if you as a consultant. Take care of the configuration, um, you can avoid the problem of… of… clients seeing each other's content. You would then have to make sure they all have the configuration they need.

But they can be different, so there's no technical problem, there's an organizational problem of making sure they don't access each other's content. The other challenge I struggle with, which, um, and I absolutely love matrix requirements, but… things I struggle with is… when you're building a document, the amount of effort. Hmm… The knowledge is, like, 3 times the effort to get it. To establish it, then you've got to have the validation of the knowledge base of who's actually contributing, and then the challenge of it is there are human factor elements, we're not. The 7th grader looks at the screen and can't comprehend what's there, because it's not fitting the way their brain functions sometimes.

So that's why… you know, I've written high-performing documentation to where you can flow through it in a certain way, and it helps the brain process. When I look at Matrix, I can't always… there's users who can't always process what's there. Mm-hmm, mm-hmm. Yeah, yeah, I agree with you, but it's… that's the general problem of digital applications, that the way how our brain thinks, uh, might be away from the way how the UI is. But one thing. That is really what I believe. Uh, our real life is much closer to the experience of structured knowledge management than to the idea of a document. Because in a document, you have a… you have a bunch, uh.

A huge amount of information that was just created over a maybe large amount of time. But as a human being, we are always in a current situation. And so, we are much more in our brain used to have information snippets, rather than the whole overview. Usually, it's very hard to get that. So… so the… I think that regulatory affairs people and quality management people are used to working documents, but still, that might not be, uh, the way how the brain works. And actually. A data file, a file repository, like, um. File Explorer in Windows. This is not something our brain works with at all. It's completely confusing, and so that's why we can't even remember where we find things.

But we can work in structures, and so… Yes, these are all challenges that have to be solved, but if we use these as arguments not to go into that direction, and we get two different problems, which are much bigger. I agreed with you. I'm not using him as arguments, I'm more just bringing up, uh, contributing factors to the solution, because. While you… while you state this… the human brain doesn't function that way. I would beg to differ that if you actually did a personality analysis. That you're gonna find there's a group that does function that way, and then another group that functions very data-driven. And so that's… I really think if you break it up that way.

That's where you need to think about it more, is how does each personality type function in an information, and how do they process? Because they do it differently. Well, I think assure you, a tool like Polarion, or Certub, or Empolis, they have a completely different way of interaction, and they are much closer to. Um, to someone working on a screen. So let's move on. The good message that I wanted to bring is we are in a regulated environment, and that's why. We have a big advantage to getting towards structured knowledge, because. The standards and regulations we have, they are telling us what to do.

To, um, to cope with the situation. Because, first of all, what they do is they deliver a predefined framework. For what we have to capture. They really give us, um, the information architecture that we have to. Provide, and that we have to implement, so it really helps us to go… Through standards, um, and see the terminology they make up. Helps us to set up a structure. For this… for this knowledge, first of all. And the second is, um… They also have the classification and the traceability rules. So, um… Since we have the standards, and if you utilize them in a clever way, uh, we don't need to discuss, to argue, or to make really a big deal about, okay, how do we set up our.

Our knowledge management, um, architecture. And that's why it's possible to have systems like matrix crimes or Polarian, or even green light goo is making that even very strict, um, that come with a predefined, um, knowledge architecture that can be used. Very simply, um, to… at least get in touch with this way of documenting and learn it, and maybe then we might find different tools that do better, and then we change the tool. But we've learned how to handle it. And so, um. It may be an easy-to-use way. Um, like, we written here, each clause from the standard can be mapped to a field, uh, it can be a metadata tag, or it can be an item type, and so these systems are designed.

And so we can use them and just think of, okay, we can directly follow. What is in the standards? Because our knowledge structure has been created that way. And so when we just create items in that structure, we are kind of automatically compliant to what the regulation wants. And that's what I think is good news. Uh, that it's not that much freedom that we are left alone, but we have everything we need. To be able to set up the structure. And then we can use it quite fast. Um, so actually, um, the standard helps us to get the clear scope. Um, it helps us to get consistency. Um, it helps us… as I said, with compliance by design, when we use a system like that, we're getting closer to audit readiness, and we can use new standards, because we can.

Just use the terminology and the ontology that the standard provides. To include a new regulatory framework. And then use… like, information that we already have. Like, for instance, um, thinking about, um… standards for cybersecurity, risk management, we already have ISO 14971. That is telling us, okay, you have to describe a risk in a certain way, and the same way works when we go for cybersecurity. Just, it's not the safety of the patient. That's… that's, um, the focus there, and what the safety of the… of the system, of the company, or of a… a certain asset, which is still, again, a piece of equipment that we have already described in our QMS or something like that.

So, um… These revelations, they make it possible that the knowledge structure can keep. Also, no, um, frameworks. When we just identify, okay, where's the… where's the terminology aimed at, and which terms are the same, even if they might be different in various. Frameworks. And so that's how structured knowledge management system can help us also to go into new. Frameworks do not have to create another siloed information base in our company. Yeah, that's good news I wanted to bring, and there's another news maybe you might not all know in Germany there is this MDKU, um… um, community that… is exactly doing what I just described, is start setting up a structure.

A data model, uh, um, using the regulation and medical device. From MDR and from FDA. Um, so that nobody needs to think about and argue, okay, how… Are we going to implement that structure? But really to create a data model that can be used, then to inter… um, change… Um, and transfer information from manufacturers. To notified bodies. So, notified bodies won't have to do… a full-text search in documents anymore, but they can really use the same information structure. That the manufacturer is using to create the documentation. And that then will really make a big difference in, uh… quality and speed of… certification and applications.

I think, Christina, what would be excellent, if you were going to do a follow-up presentation, is if you were going to engage with a new client, what steps. Would you walk through to start and finish, and kind of giving a really good example? Because, I mean, this is all theoretical. Mm-hmm. And that doesn't help me see the product, and so it would be great to figure out what the product is. And so, like, if you were going to engage with one of my clients, what's the first steps would you do? How would you get them engaged? What would you… and then give an example, maybe take a document and a product.

You know, in IFU, a QMS document and an IFU and walk them through converting it to digital. I think that would be helpful for us to have a visual. I don't know, Michelle, what do you think? Mm-hmm. Well, as I said here. You should maybe go and start with a kappa, actually. File, which… Yeah. Yeah, I think, you know, everybody is gonna agree that everything you just said is spot on. But… how do we move from talking about it. To doing it. I think that that's the conversation when we have a follow-up presentation on this, that we would love to see. Yeah. And not just… and not just in a demo, but, like.

Yeah, yeah. Of a thing, but, like. Yeah. Yeah. Yeah. Right. What's the recipe to go from… document to digital management, that's… what's the, you know… Because I'm not seeing the end product, and so it's like… Yeah, I mean… I don't even see the recipe. I've seen… I see… I… I think I'm gonna make a soup. I think. Now, I don't see in… like, am I gonna put in a teaspoon of salt? Am I gonna put in a tablespoon of salt? Like, I wanna… I wanna see, like, the recipe exactly like I'm supposed to implement it. And how I'm supposed to implement it. Like, when they tell you. Do the… this… Um… I'm trying to think of some of the recipes, where they explain every step and how you're supposed to.

Cook with that stuff, like, saute it, then wait, then blanch, you know, blanch and put in water. Those kinds of things. Like, how are you gonna actually do this? Yep, exactly. So, we're running out of time. If anybody wants to put in any solutions. To this, into the chat, please go ahead and say, like, I use this. Or, I don't know what to use, or, um, where do we go next? Um. And ideally, ones that do not cost. Um, five… five figures a year. Arm and a leg. Yeah, because the startup, the whole reason they go with virtual is because they can't afford it. They don't want to put that cost into. Right.

Implementing it and maintaining it, and validating it. Really, the validation is the cost. But… So, how would we do this if… in a virtual system? Because that's how both Nellie and I run our quality management systems. Hey, Sean, maybe a suggestion would be to have Regina do a follow-on presentation a month or two or three from now. On what they're doing in Germany. Because that's a… that's an actual implementation. I would love to hear how they're doing that. Mm-hmm. Right. So, what Regina mentioned, we're already doing something like that with our, um… this summer requirements and test cases, basically the verification part as well.

Um, so instead of, like, um… And the software that we use, it has floating licenses, so instead of, uh, you. Paying for every user account. You just pay for the number of accounts that can be simultaneously active. So, we could have, like, up to, like, almost unlimited users. But we just have to pay how many users can be active at a time. So, we get a chance to play with a very expensive software. Uh, without that… 5-figure, 6-figure cost. And that's Helix ALM. Okay. Yeah, yeah. Yeah, there's probably other systems coming up right now. Uh, that might… might fulfill more, uh, requirements, um, from the, yeah, let's say, license nature and, and, and monetarian nature and so on, like SolTap also isn't so expensive, um.

And for this is of a very high, um, capability of functionality, and it is also about 600 euro per month, but for 20 users, not for 3. Yeah, yeah. So, like, it got, like, everything. Forward traceability, backward traceability. So that's… that's… Red balls, trace matrices, the whole thing. Yeah, Alexis also. So there's, there's… there is tools, uh… Um, I haven't been through all of them, not everyone wants to tell that, um, and maybe we need to look into other. Industries as well, not just our own one. Um, but the message, I hope, is clearly understood right now, that we really need to strive for.

Changing our thoughts about documentation towards. Um, structured knowledge management. That's my message. Thought it. Thank you for your time, um, and a final reminder that next week, uh, Leah Wisner is going to be giving us a sneak preview of the impact of 60601 IEC 6060601 Edition, 4th edition. Um, and spoiler alert, huge changes coming to your QMS. So, um… Yeah, join us next week, bring a friend. Join MedTech Leading Voice Exchange, follow MedTech Leading Voice, support one another. I loved, I loved, um, Deepa's message about everybody contributing. You know, when we work together, um, we can do great things.

Thank you all for participating, thank you for your time, and I hope that you. Um, have a great, great week. Thank you. Hi. Thank you. This is great. Have a great weekend. Hasta la vista. Hi, everybody. So…