 Yes, thank you. Thank you. Thanks Dimitra. I've actually known Dimitra for quite some time and we actually talked together in Switzerland beginning of the year. So it's been interesting to see the development around this space, and it was interesting. This is my first time to Berlin and just going through this conference, I realized that there's a lot of maturity already. So I actually tuned my presentation a little bit because I wasn't quite sure where we are, but there were some really good conversations, and hopefully we'll just add on to this. As Dimitra mentioned, I work for a company called Psyngogenics. It's a private company in the life sciences industry. And what I'm doing there is basically building very large-scale open technologies, very much with the idea of interoperability by design, machine readable data by design, and very much this idea that you can build large-scale sophisticated software, small APIs. And that's really the core of what we're doing. And it's very much in line with the work that I was doing prior to this job that started at the beginning of this year. I was the chief software architect at the Center for Disease Control and Prevention in Atlanta. And during my time there, we developed what is now in the open domain as open CDC. So it's very much along those lines. Anywho, so I'm not sure about Germany or Europe as much, but certainly in the U.S., when it comes to proper health care, there's a question of do you have the means? Do you have enough wealth? So there's many articles and just news about this, you know, do the poor deserve health care? And at times the data actually doesn't back it up because they can't afford the medicine, they can't get the treatment on a timely basis, even their information isn't really received on a timely basis. There's lots of examples. This is one that I found personally kind of egregious is from CNN just a couple of months ago. This pharmaceutical company CEO decided that it was a moral requirement, not just profiteering, to price gouge, you know, and you can go and look it up and increase the price for a ball of medicine for urinary tract infection to about $2,500 for bottle. So I don't know if that's a moral requirement, but I think the way it is right now, at least in the U.S., they're able to get away with it, right? And I think that's something that, you know, is symbiotic of many other problems that are in the space, such as it's largely opaque, people don't really know where the prices come from, the information flows slowly, that there's a lot of inefficiencies, et cetera. I think most of you guys know this. Here's the top 10 most expensive medicine in the U.S. That's a lot of money for one ball of medicine. So, before I go much further, who in here is in the health or pharma space? All right. About five or six. Like I see you guys probably know what I'm talking about. And I've talked to Dimitri quite a bit. I know that there's some similarities and there's some differences between, at least here in Germany and what we have in the U.S. One key one is this. In the U.S., we don't have this idea of a universal ID, right? So if I happen to have seven different providers and they use seven different systems, I am at the very least seven different people under systems. There is no ID that ties me together. I think in Germany, at least that's not as much of a problem. But in a second, you'll see why that is a problem as we talk. All right. So anybody heard of, you've all heard of Moore's law, correct? Yeah. Who's the technologist here, by the way? All right. Good. Maybe 30% of us. That's excellent. So Moore's law is effectively technologists getting faster and better every 18 months, give or take. Who's heard of E-ROM's law? Ooh, that's good. They usually have like nine or maybe just one person. So E-ROM is a literal opposite spelling of Moore. And it's not my thing. It actually exists. And it's really indicative of the big problem in the industry in that over the last five or six decades, as Moore's law has led to more and more innovation, more and more cost savings and doing things faster at a lower cost. It's been the exact opposite, as you can see with the blue line in pharma and life sciences, where the return on R&D research and development has been declining. And that is one of the reasons I alluded a little bit earlier about the price gouging. That's one of the reasons why companies are going to feel that, well, maybe it's okay to do so because they're becoming less and less efficient in actually going through the full life cycle of drug discovery and doing what they're supposed to do being patient oriented. All right. So how does this stuff tie into blockchain? And I do want to kind of be intentional. Those of you guys, I know we have a good group of really well-informed folks here. And of course the conference title is Blockchain for Science and as was my title, Blockchain for Life Sciences. However, I think it's important to understand that if you're specific about a blockchain release, when we're talking about the sequential linking of blocks, that's really kind of where the idea comes from. There's a genesis block. There's a history that's retained forever. However, distributed ledger technology is a bigger concept than that. It's similar in the context that you have data that's distributed over many nodes. However, you don't necessarily have a genesis block. You don't necessarily retain the entire history depending on which protocol you use. And for what I do and the work that we're doing, we are actually implementing DLT as opposed to blockchain per se. And I'll get a little more specific, but just it's important distinction. And the other thing is, I'm a huge believer in the public DLT or public blockchain. For many of the use cases that we're dealing with in healthcare, public health, public causes, life sciences. And there's many reasons for this. I'll get into it in a second, but I think largely in order for us to build the network effect, we need to allow people to join in, join in in a permissionless way. We need to really think about long-term governance because when you have a private network, it's easy to get started. But if you have global problems, if you have problems, health problems that cross boundaries, cross geospatial and geopolitical boundaries, you really have to think through this. Because if you're a little governance group of three people, the three leader nodes, if that worked for 10 nodes, would that work for 10,000 nodes across different boundaries and different geographies and different time zones and things like this? And I'm a big believer that at least for most of the things I'm looking at, public is the way to go. Honestly, if I'm being overly facetious, I think a private blockchain has no more than a sexier name for an extra net. Ultimately, you have a leader node with unilateral decision-making ability and it's opaque. So if you buy into public blockchain, I think you really need to understand it's way more than just technology, right? The technology is actually the least interesting thing about it. To me what's really interesting is this idea that you have a gaming theory concept, token economy. I think you have to really explore that, particularly if you think in large-scale blockchain and public blockchain. The other thing is this idea of how do you affect human behavior. Somebody mentioned this a little bit earlier, I think it was in some of the earlier morning conversations. You're asking people who've been comfortable putting all their data on Facebook for 15 years or a high or long. Michael Zuckerberg's been doing this. To now say, hold on a second, the data is actually going to be sitting on my phone. And I'm going to have to maintain some kind of a private key and figure out shared secrets and things like this. That's a human thing, right? So this idea of a decentralized culture is not easy. And it gets into all kinds of things that are way more interesting, I think, than just technology. All right, moving on. So I think I've largely mentioned, in fact most of you guys have largely mentioned this already, so I'm not going to belabor it. In the world of DLT, what I'm looking for, as well as security and trust, everything starts with trust. If you don't need to infuse trust, you don't really need a blockchain or DLT because why bother? I mean, if you're working with seven people and all seven of your friends and you know them, don't bother. It just isn't worth it. But I think this idea of machine-based consensus is really, really important. And hence, what I was referring to, a public DLT. I think, and again, there's many different consensus algorithms and you have to pick and choose the right ones. If you're thinking about Bitcoin or Ethereum as an example, they use proof of work, right? Which is by design slow, by design inefficient, by design it delays things. So there's a sinking period. By design, every node has a copy of all the changes before a transaction is validated. But that's not every consensus algorithm. And there's a lot of ones. Again, smart contracts, lots of people talk about this. Last but not least, I think it's really a thing through this native cryptocurrency. And again, a cryptocurrency is not... Yeah, I think the name is kind of confusing and maybe a little misleading. It's not just about a liquid digital asset that you can trade. I think you really need to think about it as some kind of utility token for your network. That has some kind of intrinsic value or unit that you can exchange. Anyways, I think some of the folks talked about this at length. But anybody heard this, be grateful from... So go and look it up, be grateful. It's John Oliver from early in the year. Yeah, exactly. So the thing with blockchain is it's tamper-proof, right? But be careful because if you put garbage in, now you have tamper-proof garbage forever, right? If one of your blocks happens to have garbage in it or if you have a smart contract that's to cut bad code in it, guess what? I mean, it's a pain in the butt to change that. So there's a price to be paid for having this immutable or I think it's really tamper-proof technology. Another thing is this. So this lovely statue here, our little cat. That's a physical thing, right? It exists. It's on this table. Okay, so I want to put this on the blockchain. That's analog. Blockchain is native digital and it's virgin territory. Nothing exists on it. So now you have to uniquely describe this or this class, right? So that is not a trivial challenge at all. In the world of health, almost all the health is legacy health data. It exists in existing electronic medical record systems, electronic health record systems, many other payment systems, et cetera, et cetera. That's so-called off-the-chain. How do you map it uniquely to the chain? Trust me, it is not a trivial challenge and many people don't think about this very carefully. I did mention this and I think this whole idea of scaling the governance is really, really, really important. Because I hope all of you guys want to do big things. Our focus here is science and collaboration and that's a really big thing. I'm working with some folks around clinical trial collaboration and it is largely scientific. But we want to scale it. We want it to work across the globe. So think about the governance. Even if you start with software, how is it going to work as you go from your little community to your county, to your country, to your region, to the world? It's not trivial and also you have to make sure it's not just about software or people. It's a combination of the two because at some point you're going to have to deal with things. Now a good example is the fork that happened with Ethereum and Bitcoin. Now if it turns out, if you look at Ethereum, well Vitalik has been an electoral decision-making. He decided a few years ago that, oops, we lost all this money, he decided to create a fork on Ethereum. Is that a good thing or is that bad? I don't know, it depends. But if you have millions of users, is that a bad thing? It's a really bad thing. It kills governance. It kills trust. So we've got to really think through that. Anyways, be grateful. There's a lot of use cases here that I think, I've actually explored almost all of these and I'm going to talk about the tracking the generic drug supply shortage problem in the US. We have a real video, an example of that. We've built this out. But there's many. Who can tell me what's missing? Anyone? What's a big one that's missing? No, not quite. I'll tell you because you don't have that much time. If you notice, I don't have anything there about a master patient index. I have nothing there that's about, at least in my world in the US and what I'm dealing with. And the reason is this. The trigger to anything that goes to the individual patient level is identity management. A large-scale identity management that works across all the chains. It's completely unrealistic for anyone chain to be their chain. That's crazy. I mean, we love Hedera Hashgraph, but by no means expect that's going to be the chain. And a lot of Ethereum people like Cosmos was here earlier and we've got the Lightning Network, all this other stuff. Bottom line, I think the chain of chain thing is going to happen. But are you going to have identity management across all of this stuff? And if you don't, the idea of doing patient master index or anything at the patient level is probably not realistic, at least my opinion. So what you see here is largely about aggregate data, largely about anonymous data, largely about maybe data that we're using that's already in public form because it's already been anonymized or redacted or something like this. It's not at the individual patient level. And that's a key, I think, key qualifier. So, I like this code. It's not the mountains that we are, it's the pebbles in your shoe. In my world, the pebbles in your shoe are data. Most of us in the world of healthcare and life sciences are on the left side of this picture. Who's on the left side of this picture dealing with internal data sources? Okay, who's on the right side dealing with real-time data streams? Okay, go and mug that guy. He knows more than the rest of us. But the thing is, the value is on the right side. Okay, if you're looking at the left side, your internal outdated data sources, or in our case, largely published public data sets, you're basically his hindsight. You're forecasting based on what you already know. But that data is often old. In my world of public health, at times it was years old. Sometimes it was many years old. That's not really good, right? I mean, when we're going right now, we're real-world evidence, and that's a big thing. I think you hear a lot of pharma companies and other folks talk about it. Whether it's patient-generated data, whether it's wearable data or whatever else, clickstream, social media, you name it. You want to be on the right-hand side. Now, if you go, the closer you go to the right-hand side, as this picture proves, the more value you're going to get from it in this inside continuum. And it makes sense. And if you do anybody, I know I was talking to several folks and they're into machine learning and AI. The more data you have, the faster it is. In most cases, you can get greater insight. There are some exceptions. So that's the idea. And again, in our world of trying to understand a patient. So the patient, I think to me, has three pillars of data. There's a clinical data, which I think most of us are familiar with. That's in the electronic medical records. There's the genomic data, and one of our speaker's colleagues was speaking about that just before. It might have been Conrad, I may be mistaken. And then there is your lifestyle data. If you have the three, now you have the whole iterative. Now you can really see the insight. And I think that's one of the reasons why we're doing what we're doing. My company is because we're really trying to build systems that allow us to get to the right-hand side of this. I think what you'll see is this, and I think it's already happening. Facebook and Amazon and Google have largely grabbed a lot of data and they largely control and manipulate the internet. But I think it's also quite likely that in this distributed computing world that that could happen, particularly companies like IBM and Consensus as the quote-unquote leader and governance for this decentralized computing, they could effectively create the same thing. That would be a terrible thing. That would be like the worst of both worlds. Going to do difficult things with decentralized computing and yet giving control of the data to one or two entities. We shouldn't do that, right? Certainly not for our health. I'm a big believer in this last bullet point that we really need to create open technology as pipelines, as conduit. So the data doesn't move. In fact, in the U.S., if my medical record data exists on a particular electronic health record system, it's likely that system, the software, has a license ownership of my data. And I mean, they do. So the ability for me to move it is not really there. But the ability to create conduits to it in an open way, you can do that. And that's kind of what we're seeing in this space. Again, I'm not sure how big open APIs are here in Germany, but I'm guessing you guys are probably quite advanced in this thinking. And the U.S. has actually been pretty late, but there's all kinds of new movement around this place. Largely based on the 2016, what's called the 21st Century Cures Act, where it's now law that every electronic medical record and electronic health record system must, through an open API, provide at least basic health data for any other system to use with consent. I mean, it's not willy-nilly, obviously, but with consent. And that's a big thing. And that's leading to all this stuff. You look at Apple, which is not the company you would typically think of as being open. They have lots of open APIs from the Apple Watch and the Health Kit. They can use through fire to get to other things. So this is a movement, and this is really kind of our thinking. And this is kind of what I think of as building open software. I think of it largely as what a theme park would look like. So if you go to Disney Euro, you pay, I don't know, 99 euros to get in. For the day, you get a wristband, right? That shows you've paid up and you're yay high and you can go on a fast track or whatever. But if you go from the race track to the lake to the roller coaster, the experience is different. It's not the same experience yet. You haven't left the theme park, right? The souvenir shops are the same, the security guards are the same, the monorail is the same, etc. It's the same thing with software. The fact that we can have an API gateway just like a turnstile, you go and you get a session token that allows you to traverse different playgrounds such as right at the very top. We have data set alarmization, which is what we use. Here on the right, we have DLT. Apologies, I still washed it out. For doing blockchain type things, whatever. But the important thing is these playgrounds are not coupled together. You could have one construction firm building your DLT and a whole different one, you know, building your, I don't know, machine learning. And they all work because they all follow the open API spec and they all use an API gateway. I'll give you a little example. Everybody's been to Amazon.com, right? The homepage. All right. How many APIs do you think go behind that page? Anyone know? Any ideas? Not quite. That's my look. But that's a pretty crazy thing, though, right? The homepage has over 200 small pieces of software in it. That's why we think this kind of idea works. If you're interested, you're more than welcome to read this blog that I wrote about a year ago when I was at CDC. That's really what we did at CDC. That's what we're doing for Open Pharma. It's obviously more than just functionality. We have a blueprint layer, which is largely open source software. Really, the secret software building software in this way is DevOps. Modern DevOps to do automated continuous integration, automated continuous development, automated monitoring at the microservice layer, and so on. All right. I won't get into a software 101 in this, but this is roughly how you do it. We like to make our APIs, our application programming interfaces, really singular and atomic. Like one API does just one thing, like get something as opposed to get it, dedupe parts and things like this, just do one thing and do it well, make it small and make it very easy to deploy. Then what it looks like as an actual application is something like this. This is a real application. This is our data set and my session application. This is exactly how we built it. As an example, if I take the advanced reporting API or the risk scorecard API, those are repurposed in several other applications. And by the way, one of the things we're doing is we have a marketplace just like the Apple marketplace, where any one of you guys can go in and use our APIs amongst your own. You could use our data lake, you could use our search, you could use our DLT, whatever you want to do. But you don't have to be coupled to the rest of the theme park. You just use the specific things that you need. I think that's a very important concept in healthcare. It's really largely understood in technology because that's how technology has been built for a long time. Well, at least five years, maybe 10 years. But in healthcare, we are largely lumbered to this giant monolithic applications where you make one change. It takes a year to make it that change of production. And that's just ridiculous. That doesn't allow you to do world data. You're stuck. And I think that's a common story. Okay. So I mentioned open farm a little bit. It's not by any means the only one of its kind. Just in the life sciences space, there's OpenCDC, which is, again, myself and my team built that and released a public domain. And there's OpenFDA, there's other ones as well. In many other industries, there's many other ones, particularly in the AI and machine learning space. There's a ton of open AI and machine learning libraries and frameworks that encourage you guys to look into it. Okay. So how does this tie into the super ledger technology and blockchain? So this is what we've done. Again, I know it's very hard to read the details and you don't have to worry about it. But really the idea is this. For tracking generic drug supply problems in the U.S., there's a cast of characters that we have to identify. The FDA is a regulator. They are the user. They are the ones who want to know what's going on. But then there's active and inactive manufacturers. There's distributors. There's group purchasing organizations that purchase at large scale. And then there's pharmacies. I'm simplifying a little bit, but that's largely what the space looks like. This is the architecture we have. Again, it's actually pretty simple. It's largely based on using asynchronous message queuing using Kafka. Well, for this POC, it's using the Amazon SQS. Simple queuing services, but we're using Kafka for production. But it's a pretty simple architecture. This is not that difficult, right? What's important though, and somebody else mentioned this. It was in the panel right before me. I was getting ready, didn't pay enough attention. But the fact that we have the blockchain or in this case, Hedera Hashgraph, it's what we're using, that's not that interesting. Because nobody really cares. What they care about is what does the user experience look like? The consumer grade. And I would encourage you very, very strongly. You got to think noise versus signal. There's so much of a blockchain and DLT that's noise. Think of it as plumbing, as infrastructure. I fully believe that in 5, 10 years there will not be a single blockchain conference anywhere because there is not a single SMTP conference anywhere. SMTP is protocol used for getting your email, right? Back in like the early 90s, there were SMTP conferences. But it's plumbing. It's the pipes that connect things. So I don't think, honestly I think this thing is going to be infrastructure. What's really interesting is what you do with it. So this is a video of our work. Hopefully you can hear the audio. Hello and welcome to our proof of concept demonstration of Open Pharma's generic drug shortage application powered by Hedera Hashgraph. In the current version of this use case, we are oversimplifying the manufacturing issues in order to show our solution to make the generic drug shortage information publicly available quickly and accurately in real time. Our login page will provide proper authentication verification for allowing access to the authorized profile view. As an administrator, I am able to view and act as all user profiles. This use case contains several user profiles, such as the FDA regulators who can view all the incoming information in real time, FDA inspectors who can instantly create and submit inspection reports on factories and manufacturers, distributors, pharmacies and group purchasing organizations who can easily perform actions such as reporting new facilities, updating their current status, as well as report generic drug shortages on the fly. Going back to the FDA regulator team view, here you can see our recently reported drug shortage with Everest Group. You will also notice that the live feed allows all new data coming from all users to append to this list and update our bar graphs for real time updates of the generic drug ecosystem. The FDA regulator team is also able to filter out results and focus on specific user groups, such as manufacturers where you can view factories and inspections, as well as distributors, pharmacies and GPOs where you can see all generic drugs in stock or in shortage through bar graph visualization per user group as well as specifically within each facility. That concludes our POC demonstration of Open Pharma's generic drug shortage application powered by Hedera Hashgraph. Thank you for watching. I think the most interesting thing about this is really that concept we had at the very beginning that we are trying to build near real time data systems. That's really the gig. And that's why we chose to use Hedera Hashgraph for doing this because it's not to get too technical, but it uses what's called the asynchronous Byzantine fault tolerance. Consensus algorithm, which is very, very fast. And the technology essentially gets you to a validated state of a transaction within about two seconds at about 100,000 plus transactions per second. So all to say, if you want to track something in real time and you want to have some kind of a DLT back end, at least in our opinion, it's a pretty good option. It's not the only one by any means, but it's a good one. Now to be clear though, this is not a blockchain. There is no genesis block. It uses what's called the directed acyclic graph consensus. There's pros and cons with that, but nonetheless, it meets our needs. And again, going back to my comment about infrastructure, if this works, if this provides your trust, cryptographic trust, if this provides you the speed, if this provides your transparency, then does it really matter what protocol you use? That's our thinking. Anyways, just to wrap it up, this is kind of the roadmap, if you like. This is the way we go about doing this. As you can see, this is largely about open source, open technologies. I didn't mention this, and I'd be happy to offline it if you like, but I'm also a very big believer that in order to make this public DLT work, you have to use micro payments. You have to have services that can be consumed with minimum amount of payment so you get customers immediately. So it's not free, and you don't have an advertising model. You're not trying to create another Google, but the per-transaction fee is very, very low because you expect to have a real-time system with many transactions. Anyways, that's all I have for you. Thank you.