 Hey everyone and welcome to another edition of the hyper ledger healthcare special interest group presentation series. My name is Mike McCoy. I'm the chair lead. We're also joined by our co chair lead in Erica beer bower who's here to help us with notes presentation, etc. But today we have a special guest. It is the CEO and CTO of Previci. We have Mahesh Balan and Ashish Kirchania, the who are able to present today, Vera cred and their coven 19 vaccine distribution tracking application. Mahesh and Ashish. Thank you so much for joining us today. Please give you some introduction on yourselves and what you're going to be able to demonstrate for us today. Great. Thank you, Mike. And thanks to the LF Sega for giving us this opportunity to talk about verifiable credentials and you know how you know the more immediate application of it, which is potentially the covert 19 vaccines. So, here we have today. I'll introduce both our both ourselves in the interest of time. I'm Mahesh Balan, the CEO, Ashish Kirchania, the CTO is on also on the call, and we are a Chandler based company. And we have been working in this area, specifically, specifically verifiable credentials over the last year. We have partnered with very well known name in that space, ever name for those who have been following the verifiable credentials ever name is one of the key contributors to hyper ledger indian 80s, and we are using ever name agents in constructing our solution. And I'll go into that in a little bit more detail. Our specialty really is we come from a long history of working in CRM loyalty and such enterprise cards applications. So, be partnered with ever name so that we can bring the solution and our strength is integrating things with existing systems which is what we probably have to do in cases like this, and delivering hopefully a seamless solution to the end customer. So I will talk more in detail about that so let me share my screen at this point in time. And Mike, you can let me know if you can see my screen. Your screen can be seen. Right. Okay, so, like I said, yeah, you know we have been in this business for a while, but I'll just get to in the interest of time I'll just get straight to you know I won't go through all our introductory slides that we normally do, but we'll just get to the problem right. And so what are we trying to do here. I think everybody is grappling with the problem of. Once we have a vaccine, or even in the situation that we have today which is to, you know, testing people, how do we bring people safely back to work, or to a public place with a better assurance that you know we don't have infected people within the group spreading disease right so that's the big concern for everybody, and I don't need to overstate that. So, the idea behind verifiable credentials is as follows right. Medical doctor or nurse who's issuing the credential who's actually giving the vaccine is probably recording that information in an electronic health record system and this is typical for the workflow that happens today. It would be great if at the same time that they issue the vaccine. They are also able to issue a digital credential, right. So, that is one use case that we can talk about there are also others in which this could be done in a batch mode and so on and so forth but we'll just talk about this. So, somebody walks in, takes the vaccine, and there is an opportunity for us at that time since we know the person who took the vaccine to issue a credential that is digitally secure, and that can be put into a mobile app so that in the mobile app there is for the want of a better word a wallet so to speak right and in this digital wallet you can store one or more credentials. This credential is tamper proof because it has got cryptography behind it. Once the person receives and accepts this credential, they can at their own will. I mean this is the important point to stress that this data about their vaccination is under the control of the person or the patient who took the vaccination. It's not being distributed behind the scenes. They are in control of it. They could potentially present that to verify, it could be an office building, it could be a public place that they have access to such as a football stadium. It could be a number of use cases. One use case which is more applicable again might be travel, right. So, recently IATA announced, as a matter of fact they have partnered with Evernim themselves to issue an IATA app, which will not only hold a digital credential of your status but will also hold digital credentials for your passport, kind of a digital passport. So they are kind of building on this technology and those might be the most immediate use cases because as you know international travel is governed by various rules from multiple countries and IATA was quick to recognize that something digital has to be built besides all the other forms. As you know traditionally people receive vaccination results in some kind of a yellow card which is the international standard. What we see now as you might have seen on Twitter feeds of people getting vaccinations, you know, the CDC issues a card. All of these of course are not tamper proof. So the idea of a digital credential is to make it more tamper proof. One thing that, like I know that Mike and I were just talking about this just before the start of this call. There is a number of people here who are highly qualified, probably even better than me, you know, in various technologies when it comes to verifiable credentials. But there are others who are equally knowledgeable in other areas. So, but they may not have a complete understanding of the technology. So I'll just go through the fundamental principle in here, right. So think about the first kind of agent in this business, which is the issuer, a doctor's office and nurse, a garment agency, and they are the ones who are able to see that Mahesh has shown up here they do some verification to make sure that he's Mahesh he's eligible to take the vaccine. And they typically give the vaccine and record that information in an electronic health record system. And once that is done, they could issue a credential. So what happens is the credential is nothing but a digitally signed document for the want of a better word, right. So there are standards called the W3C the World Wide Web credential verifiable credential standard which specifies how such a document can be delivered. So this document is digitally signed by this issuer and given to the holder, which in this case is me let us say, and I have a mobile app which has the facilities for a wallet that can securely store this digital credential. Now, a person I then go on and go to, you know, go to my place of work for example, there can be software put in place that can, that is called a verifier, essentially what it does is it asks for the digital credential. In the digital credential, there is a signature or the public key of the issuer. So this uses the public private key cryptography. I'll explain a little bit more in detail in a second. So let us say that they are able to determine that this is digitally signed by an agency and how do they find that right. So what happens is, typically the issuer registers their public key in some kind of a data registry. This data registry tends to be a blockchain because that makes it, you know, a distributed key management system so to speak, instead of the centralized system which is subject to, you know, failures and so on and so forth. Think about a blockchain as a registry that typically never fails, there is at least one or two nodes up all the time that somebody can use to read the data. So the issuer registers their public key, of course they keep their private key secure and they use their private key to sign this document, right. So the public key is available, we know that this is CVS pharmacy, for example, and that information is available here. So when the verifier actually reads this document takes the public key and checks against this, they are able to say, oh, okay, this is CVS that's in a list of approved issuers that I can accept. So the idea here is the verifier does not have to make a phone call or have some direct communication with the issuer to see that hey, did you really issue this to Mahesh so that's the whole idea of this verifiable registry. The verifiable registry also holds some other metadata, which essentially, for example, this particular document right what is the format of this document it is nice to know that and put it in the registry so that a verifier can check that. If this is the format of the document, for example, it is a COVID-19 credential, then they will be able to ask the right question of you, right, which is, and when I say when they ask the right question of you it's an electronic question. So when you present your credential, that is a secure communication established between your phone and this particular verifier. They are able to then ask the right question because they understand that you know what is the nature of the credential that you have and what they are interested in so they may ask a question, such as, hey, what is the date of vaccination that you undertook right. Because if it's within six months that's the only information that they may need. So this whole area of how the presentation is done can be can get quite complex as a matter of fact. It is possible for you to hold multiple credentials one for a COVID-19 vaccine and one might be a digital driver's license so for example if you're getting into a sporting stadium they might have a composite question right that is, they can say from your driver's license to know your date of birth to make sure you are above 18 and from your COVID-19 credential, I want to know the date of vaccination so that it is within the last six months for example right. So these kind of proof requests can be can be composed. One more thing that I want to talk about in this context is the fact that the verifiable credential standards, along with hyper ledger indian Ares also allow for what is known as zero knowledge proves right so the idea is me as holder is in the definition of some knowledge right or some credential, which in this case is a COVID-19 credential, and I don't even have to disclose the fact that I took the vaccination yesterday, I might just be able to disclose the fact that I took the vaccination the last six months, or that I am above the age of 21 without disclosing my date of birth so these kinds of actions are also possible and are part of the standard. This gives us an opportunity to truly be secure and be able to only disclose what is minimally needed for the use case that is at play, for example entrance to a public event that is minimal information that you need to have just to make sure that you have all the right things right. One more thing before I go further in this is and is the fact that I just want to be clear that the issuance of verifiable credentials is just one only one part of for example the whole COVID-19 vaccine situation that we are in. It is still left to public health experts and others to specify the protocols which are outside of just presenting the credential. Now that I know Mahesh has taken the COVID-19 vaccine, what else should happen when he goes back to work. All the existing the current for example the current recommendation is you still continue to socially distance because you could still be a carrier you still wear your mask and so on and so forth. So this does not change any of those things all we are trying to do here is to make available a more secure document besides a printed paper document and in many cases. These things will not simply completely override what is happening today. Some people may not have access to phones and so on and so forth. So the existing methods will continue to work and this is just an additional layer that offers potentially some speed and security. For example in the IATA use case they explained quite clearly like as much as this this piece of presenting the credentials and so on and so forth can happen in real time. They plan to do this ahead of time electronically. So in other words gather the information, take your permission and be able to verify against the countries that you're traveling to against all their rules and come back and say whether you've met all their criteria. Because the COVID-19 credential is just one part of the story. Right, so we have another 20 minutes. So I'm going to now run through a series of quick demos about two, three minutes. The first demo is going to be how our product works, right? How an issuer can say fill out a form and we are going to show that this is a prototype and then I'll talk about the other cases. Fill out a form, issue the credential to a holder. The holder goes to a verifier and the verifier is able to verify the authenticity of that particular document as well as look into the attributes of that document. That's the first demo. The second demo we show is closer to what will happen in real life, right? We don't expect a doctor or a nurse to be logging into one more application and typing in one more set of data. As a matter of fact, the situation where we are right now, we are just trying to get vaccines into people's hands, right? So we then show on the second demo how we could integrate with a system like Epic, which is a popular electronic health record system. Now, this is a little bit of a looser integration. We have access to Epics. They provide an open fire standard sandbox that developers like us can get access to so that we are able to showcase how electronically we can pull the records from Epic as opposed to somebody typing in all the data. Now, in the real world, we will actually hopefully have the workflow completely integrated in with the actual electronic health record system. This will be the third demo. We have built a complete seamless integration with salesforceswork.com, salesforcesreleasedwork.com specifically for, you know, taking care of COVID-19 in the distribution of vaccines and doing contact tracing, providing dashboards to health authorities, as well as they have a vaccines module, which is for the scheduling and issuance of vaccines. So we will show how our product can be integrated into an existing electronic health record system so that the workflow is reasonably seamless. So all that the person has to do is the data is already entered into the electronic health record system. They just need to push a button there and then have an exchange with the holder straight out of that application. Right. So that will be the third example and time permitting on the fourth video, which is again just a few minutes, we will show some of the details behind how this works. For example, I talked about this verifiable data registry. We will show how in our product that you can create a brand new schema and register it on the data registry, which in our case happens to be the sovereign blockchain. We are right now in these examples that you see connected to their test network, but that's how it will be. Then we also show you how you can do what are called proof templates. So the issuer uses the schemas that we register and the verifier needs something called a proof template, which essentially says what are the questions that the verifier software needs to ask of the credential or off the holder. You know, hey show me this attribute in this particular, you know, credential, so we will show those two time permitting so I'm now going to jump straight in into the demos which should take only about 15 minutes or less. So let me start with the first demo. So today I will be giving an overview of the very credit application powered by Previci. We will go step by step in the user creation and credential issuance process, as well as how the information can be verified by a third party. In this scenario, a patient has just received their vaccine and are requesting a digital certificate from their doctor. The patient's mobile device is displayed on the right hand side of the screen, while the doctor's view is shown on the left. First the doctor creates a user for the patient. In this case, we'll call the patient patient one. After creating the user a QR code will appear on the screen. Now on the app, the patient must scan the QR code, establishing a secure connection between the doctor's office and the patient's mobile device. The patient will receive a notification of the connection request. Once the user has accepted the connection request, the doctor may continue filling out the patient information. This is the credential vaccine one. And the schema that we will be using is the Salesforce Health Cloud Immunization Schema version one. Here are the attributes the doctor will fill out for the patient. Once all fields have been completed, the doctor will issue the credentials to the patient. The patient will receive a notification that the credentials have been sent to them, where they can then review and accept the credentials. The patient may take their mobile device to a third party, for example, airport or sporting event, and may require verification that they have received the vaccine. Switching users, the third party screen will now be displayed on the left hand side. To verify the patient's credentials, the third party will simply go to the proof request page located here. Then they will select the type of certificate they would like to request. In this case, the Salesforce Health Cloud Immunization Schema. This will generate a QR code that the patient will scan using their connect.me app. The patient will receive a notification of the proof request where they can review the information that will be sent to the third party. Once the information has been reviewed, the patient can approve the proof request by selecting share attributes. Once the connection has been approved, then the information will be sent over to the third party verifier. Okay, so this, as I said, you know, this is more of a demonstration of all the steps involved in this, you know, process. The first is the gathering of information about the vaccine itself or the vaccine details, which in this application sample, we show somebody filling it in. Like I said, in the real world, that will probably come from an EHR system. So most likely all that the person needs to do is just verify that it is the case. And then we push that data and we talked about connect.me app. That is, for example, Evernim's publicly available wallet. It's free. Anybody can go download that. And pretty soon, I'm sure we are going to have a variety of wallets. For example, the IATA application is also a wallet application. And compared to this, I'm sure a number of public wallets will be made available. And I think some of the challenges that we as a group here, for example, in hyperledger life, LF is really trying to standardize these so that we don't have a mishmash of technologies, right, that a verifiable credential issued by anybody should be acceptable in multiple wallets. A verifier should be able to use the standard protocols to be able to talk to, you know, a mobile wallet, for example. So those are the kind of things that I think, you know, are forthcoming in our first attempts to get this technology off the ground. An example I'm going to show you is a little bit more deeper integration. For example, how we can integrate with an electronic health record system such as Epic. So I will show that now. In this video, I'm going to show you how the PocketCrad application integrates with the Epic Healthcare System. In this scenario, a patient has just received an immunization and are requesting a digital certificate from their doctor. The patient's mobile device is displayed on the left hand side of the screen, while the doctor's view is displayed on the right. In the PocketCrad application, we've created a tab for Epic immunizations where the doctor can search the healthcare records by patient ID. Now the doctor finds the immunization that the patient would like a copy of in selects issue. This generates a QR code for the patient to scan using their Connect.me app. The patient will receive a notification of the connection request. Once the patient has accepted the connection request, the immunization record becomes available to the patient as a verifiable credential. Now the patient may present the credential in their mobile device to a third party, for example, airline or sporting event that may require proof of immunization. Alright, so we showed a deeper level of integration in this particular workflow, right? Again, like I said, in the real world application, you might not even have to, you know, do this first step where you saw somebody typing in an ID and so on and so forth. That is certainly better than filling in all the data. So that is just to show that with the open integrations offered by many of the EHR systems and they have been doing this for a long time for other reasons, right? Electronic health record systems have to exchange data with a number of parties in the life cycle of a person's, you know, medical history. So this is not new. We will continue to exploit those in building solutions. Now I'm going to show you a third example where the integration is a little more deeper. So we are kind of progressing along the line to see how a real world application will probably look like. And in this case, we are going to show it with salesforcework.com. And you will see that essentially the person does not have to leave the EHR system in order to issue this credential. And so let's go take a look at that. In this video, I'm going to show you how the PocketCred application integrates with salesforcework.com. Salesforcework.com is an electronic health record system released by Salesforce to specifically address the management of vaccines, tests, and contact tracing for COVID. In this scenario, a patient has just received an immunization and are requesting a digital certificate from their doctor or nurse. The patient's mobile device is displayed on the right-hand side of the screen while the medical professional's view is displayed on the left. In the salesforcework.com application, the doctor or nurse finds the immunization that the patient would like a copy of and selects issue credentials. This generates a QR code for the patient to scan using their mobile wallet app. Here we are using everynamesconnect.me app. The patient will receive a notification of the connection request. Once the patient has accepted the connection request, the immunization record becomes available to the patient as a verifiable credential. The credentials issue directly from salesforce, allowing for a seamless integration with PocketCred. Now the patient may present their credential and their mobile device to a third party. For example, airline or sporting event that may require proof of immunization. PocketCred is a product built by Previci and will be available in the Salesforce. So you can see here that this whole workflow happened within the context of salesforcework.com. And the results are even displayed here at the end wherein you can see that this particular person has accepted the credential and the healthcare professional did not have to leave the Salesforcework.com application in order to issue this credential. So now in the very last demo, we have still a few minutes, I will show how some of the details behind the scenes, right? How do we create a schema? How do we create a proof request or a proof template which can be used by the verifier to check for attributes within a schema? So that will be the last presentation and then we will have I think plenty of time for questions. In this video, I will be giving a brief overview of the administrative setup in PocketCred that is required before we can issue and verify credentials. Schemas are used to specify the attributes of a credential issued by the issuer and proof templates are used by the verifier to check for those attributes. Let's begin by creating a schema. On the schema page, the issuer has the ability to create and manage schemas that are written to the ledger. Here I will create a sample schema where I'm able to specify different attributes. Each attribute has a type that is managed internally. As you can see here, we have string, number, email and date. Now that the schema has been created, the schema ID and credential definition are written to the ledger. If you need to make any changes, you can add additional attributes and update the schema. Each version has a new schema ID identifying the version. From a schema, you can make a proof template. This template has the same attributes as the schema with the restriction that the attributes have to come from the credential definition with the corresponding ID. Now I will go ahead and create this template. The template will be used later when we run a verification. Now that we've created our schema and proof request, let's issue a credential. In this window, the issuer specifies the schema and version. Based on the version, it will prompt for the appropriate attributes. So in version one, we do not have the patient ID information. Selecting issue triggers a notification in the app. Now that the credential has been accepted, the digital credential is stored in the user's mobile wallet. Let's take a look at the verification process now. The user has taken their mobile device to a third party and needs to present their credentials to the verifier. As the verifier, we navigate to the proof request screen where we send a proof request for the template we just created. This can be done independently of any existing connection so any user can scan this QR code, establish a connection and be asked to provide a proof for their requested attributes. Finally, we can confirm the proof request was sent back and these were the fields that were provided. All right. So in that example, we saw how we can actually create a schema, register it with the blockchain and then you saw the creation of a proof request. We showed a very simple scenario wherein all the fields of the schema are being verified in the proof request. Like I told you that does not have to be the case. You could even have a proof request wherein you say, hey, I just want to look at the date of issue of the vaccine or even some kind of a Boolean where it's a check wherein you say that I don't even need to know the exact date as long as it's within the last three months and things of that nature. Right. So those are made available. One thing that I want to just point out before we get to questions is just some architectural elements right for example, the Salesforce example that you saw really what we are doing here is how did we build that particular application right. Salesforce allows you to do what is called as a package wherein you can add elements to their standard application and then deliver it very easily so that it can be actually literally purchased off a Salesforce store called the app exchange. So you saw that we are able to build a package, which goes directly into the immunization screen in Salesforce for example, and then we've customer buys and installs the package, they'll get that button that you just saw, and the all the underlying elements or code that we have put in so that it can actually be an issuer. Right, so behind the scenes, what is really happening is that we have our software available, you know, which is basically headless at this time it's just a bunch of rest, rest API is if you think about it. And behind us stands the agent from Evernim. So the power of Evernim's agents is as one of the key contributors to these projects Hyperledger Indian Ares, they pretty much handle the state machine of all the protocol requirements behind the scenes so that we are simply able to use their SDK and perform the various functions that you saw right, the issuance of the QR code, the establishment of communication which is secure between the mobile agent and, you know, for example the issuer that particular thing is called DITCOM or decentralized ID communications, these are all again standards. So bottom line, the agents provided by Evernim handle the complexities of protocol, as well as, as we look down the road, some of the things Evernim's agents are now used in production in a number of actual real world applications for issuance of credentials, they're highly scalable and so on and so forth. So as we go along this journey, their experience and their expertise in not only maintaining the existing protocol stack but also updating this vastly evolving area will be very valuable for us as application developers to be able to deliver a solution quickly to the market. So, with that, I think we are right on the 40th minute. Mike, I'm happy to hand over to you to, you know, coordinate the question answer session. Just let me know. Ashish, thank you very much for the time, the details of the diligence and looking to provide not only the lay material but also some of the technical diligence as well. Questions, anyone please feel free to either put it in the chat and I can respond and say your question, if you're more comfortable that way or you can go off mute and ask Mahesh and Ashish directly as well. Hey Mike, it's Erica. I have a question. Go ahead. Yeah, I was curious I was listening to another presentation yesterday, a similar solution to this and I was wondering what stakeholders you think will be involved, or, or really going to drive the adoption of something like this. And how do you even go about bringing this to market or where do you even start. Yeah, there's been a lot of issues with that, because there's quite a few different stakeholders that are trying to drive this forward. Great question Erica. Very important to point out right, for example, what's going on in the world today right let's take the US we are just trying to get the vaccine delivered right, I mean people are driving through I mean there's all sorts of issues right now to just get the vaccine. So I think the initial adoption in in our estimation will come from something like the airline industry or the travel industry right, whereas you know, I remember 30 years ago I was planning to make a trip to, to Africa on some consulting and I was asked to go take the yellow fever shot. And then actually you know they give you a card to go with that right so that there is a long history of these types of requirements for cross border travel. So that might be area number one right which we think is likely to adopt this simply because it eases a lot of burden, and you know a lot of verification issues that come into play. The second area that may be more applicable is employers right employers and many instances have said, hey June and July is the time we are going to bring back our employees safely right. So maybe they would be interested in something like this. As a matter of fact, the, as you might have perceived the digital credential issue is not restricted just to the vaccine, even an employee badge, along with their some, you know, some, some kind of a demographic such as facial ID or just a photo might be stored in this digital credentials right. It could be even Mike and I were just talking about that before this call, if for those who don't want to use a phone there are actual cards digital cards available which can act as a wallet. So we can see a use case where in a company has a number of factories and you know even spread across across the country or even across the world. And one easy way in which at least for those who have taken the COVID-19 vaccine, they could avoid testing them or you know some such protocol. So they may be the second set of candidates who might employ this in a more of a close system. They will have some say over their health care providers after all they are footing the bill, and they might come to some agreement so yeah this is really a question, which is a difficult one of getting multiple stakeholders to arrive. We think the path would be like this, you know something existing like the airlines and travel industry and then employers and then maybe other public health institutions. Yeah, thank you for answering that I know the other some other people working on this are more targeting the vaccine manufacturers and regulators. So that's why I asked, I think it's hard because it's kind of like who's gonna make the first move. And clearly, the what is in their mind right now. You know, I mean the, the administration that's coming in today has said that their goal is to get 100 million vaccines done right. So, layering on even this extra layer. And that's why I was emphasizing how the workflows need to be made so simple right, the one that I showed shows an actual terminal and so on and so forth. I might have to build a mobile version of it to quickly issue this somewhere else and so on and so forth so I think that's where the rubber meets the road. Hey, sorry, I'm a question that kind of follows up with Erica's point is that I've been told from from, I guess vaccine manufacturers and distributors a little bit that they're not looking to have many other mobile applications or projects come out because they, because they don't want to confuse people with too many different mobile application or digital passport representation. I'm sure you're aware of that challenge as well as a startup coming into this type of environment and space. What do you say to that challenge and, and, and if there's a way you can potentially overcome that because I do know about the and others like that, that that manufacturers are telling me, hey, we don't want to make too many copies of the same. It was the same project. Good, good point. I really, and I think this is where this is literally where I think this community like what is gathered today, and the CCI community, who's the sister community which has come on. These are the things that we can make sure, for example, today, none of us worry about how a camera works right, whatever type of phone that is right. So, in a similar fashion. It is possible to standardize. For example, if all wallets, whether it is the IAT a wallet or any other wallet that is out in the market, are able to read a QR code like what I showed and establish, you know, what what is called did come which is secure if that can be standardized so that it really doesn't matter when I as a small software developer put this in a lab or in a doctor's office, and I generate a QR code that is accepted by any mobile app which says that it is a digital wallet right so if we can standardize that piece, then we can continue to issue credentials in other words we don't need to own all the pieces of this puzzle right. We could be a verifier, and it can verify any credential issued as long as they conform to the standard and again as long as the communication between the mobile and back and service can be standardized so I think that is where you know, prototypes, standards, sample apps, this is going to help try to consolidate this industry. You're absolutely right. A mishmash of mobile apps that don't talk to each other would be really not very valuable. For example, in the airline news case, even if there are existing free wallet apps, I'm pretty sure that they would prefer to have their wallet app wrapped into the airline app itself because it does a number of other things it has loyalty built into it which is by the way it's another area that we are focusing on and quite incidentally that's how we stumbled upon this verifiable credential story itself and the kind of pivoted to building what we are building this week because we were using verifiable credentials for that use case. For example, for the disabled, each of these groups will have some vested interest in, you know, kind of attracting the customer to download their app for not just this purpose. So our hope is the standards are strong enough that across the apps that customers use for whatever interactions they have, for example, with transportation service that they'll be able to incorporate this piece, and it should reasonably work by accepting credentials which are to a standard. Real quick, if you could just say technically what are the technical components so that back in the systems can talk to each other what is that. Yeah, so don't take more than 30 seconds because I want others to get their questions. Yeah, no, no, like I said the bits and pieces are first the credential standard itself the credential needs to adhere to a standard and not just be some random digital document right that is the W3C verifiable credential standard model one. And that's an evolving standard. The second piece is the registration of the public key right so that is again a standard that is evolved by Hyperledger Indy. So, if people conform to that particular standard in writing to the registry, the communication between the mobile app and the back end you know whether it's an issue or or very fire, that communication is called did calm you know, decentralized ID communication that is another W3C standard. So all these standards, you know they are conformed to will go towards building a common infrastructure. So I have a question if I may. Yes, Anton. So thank you very much Mahesh for a for a nice presentation so my my one of my concerns for for digital vaccination certificates it's is that it may add an additional admin burden for the healthcare personnel. We have seen at least in Scandinavia where I'm based that what really slows down the vaccination process is the administration burden for the healthcare personnel. So, what are your views on that I saw that you could incorporate your system into one of the bigger vendors epic journal system but what do you think it's feasible to to have this kind of system without getting any additional admin burden for the healthcare personnel. Yeah, that is a very good question, Anton. So, so the challenge that we have is in if we try to do this in some kind of offline fashion right and let's say hey, just get send me or email address and then, you know, I'll get this I'll let the, you know, for example, the person simply says, Okay, you know, the just this person needs a credential that's all I'm going to record I don't have time. This will happen in the background. So some of the security aspects of that start to get a little weak, you know, so what we are trying to exploit here is the person is here in front of you. We need to take great care and verifying that it is actually Mahesh he's not got some other comorbidities that prevent him from having this in other words this automatic verification happens right. But to your point, this right now we are absolutely stretched. If that extra two minutes can be used to inject one more person. That is what everybody wants right. So, it's an interesting question maybe there are some off like I said you know just specifying this, and then later on sending them some kind of a QR code by email that they can actually incorporate into their mobile app, something like that might have thought about having designed a system like that but we might have to do that in order to make this more accessible in an offline fashion as opposed to burdening people right in the front lines. Now, it will also change with time. For example, let's take the vaccination procedures that we go through on a yearly basis right. It's almost without any difficulty that this time of the year you can walk into any pharmacy for example in the United States that's how I took my regular flu shot just walked in. The person said hey just sit down here. They literally in the day entered a bunch of information into a system and they gave me the vaccine right so it might get to that kind of a situation where we integrate this in into the workflows of all the regular outlets, and that might be for the next cycle. And for this cycle to your point, we might have to come up with, you know, some offline method to deliver this credential, but then again we have to think about the security aspects. Jim has raised his hand please ask away. Yeah, and Mahesh gave a great overview of it I would I would just add what LaMetic is encountering in our work with Providence Health Systems much as Mahesh said and the question, you know, was originally posed how not to impact the workflow and the difference between folks that you're bringing in they're already in Epic and so it's an extension of what you're doing with them in Epic and adding the vaccination to the record to something like Microsoft turning their campus into a max vaccination where the where the entire goal is shots and arms. Some of that also depends on the locality and what their relationship is with the immunization system information systems so regardless of the physical encounter and the mechanism for actually getting the shot in the arm you are supposed to be documenting it somewhere and that is supposed to be going in some specific way to get the transparency to your State Department of Health. And so we're looking at, you know, either direct engagement scenarios like Mahesh described pulling the information from Epic, or if the individuals aren't necessarily part of that provider organization and in the EHR, you know, where the information is being captured into the system. Some attributes and then the vaccine information or some method of bulk upload or ultimately some interface with the state immunization system to be able to go back and provide that that credential to the individual after the fact but but to Mahesh's point and as the question was posed. Injecting this into the workflow right now is just a challenge because everyone has a slightly different workflow and different levels of panic about just getting the vaccines out there. Good point, Jim. Thank you for that insight from your real world implementation practice. And back to your point, I think we also have the challenge of first gathering additional information, you know, exactly like what you said, for example, adverse reactions have to be recorded. It's not just the first 30 minutes that, you know, today that's what is done, you know, they're just asked to wait for a half an hour, and then hopefully nothing adverse happens but adverse reactions can happen later too. So we need some electronic method to capture this so that, you know, all this can be, you know, dealt with in a better way. Again, excellent insight, the fact that this potentially could go into a vaccine registry could mean that we could at some future point in time you can make an appointment and get all your vaccine credentials, hopefully, you know, not just this one, but your complete load of vaccine credentials. Children need this. I mean, I have a daughter who potentially switching schools for high school and I'm sure we have to go through the complete rigmarole of providing that blue card that she has and make copies of it and things of that nature. So I think that is a longer term look at this to see how we can simplify some of the workflows. Any other questions from anyone else? We can have time for one more. Excellent job, Mahesh. Thanks. And you did a great job at CCIS. Okay, thank you so much. Thank you all for your patient listening. Thanks for the questions. I think this kind of interaction is what and all these questions are what makes us think today's question about offline. I'm sure it will set me and Ashish to go back and talk to our team and say, hey, what are potential answers to these type of things. So thank you so much for your feedback and your patients through this hour. Absolutely. It's very timely too as we had our hyper ledger APAC team give a presentation on verifiable credentials. Actually, I believe it's coming up on the 26 as well. So very timely, very huge topic within the hyper ledger and blockchain circles we're all in. And I thank you everyone for taking time out of your Wednesday to be part of this presentation. Mahesh Ashish, thank you as well. And have a good day everyone. Enjoy the rest of your week. Thank you. Thanks Mike. Good job.