 Okay, and a good morning to Chad, and a good morning to Zaki, Alam. Good morning to Zaki. How are you? Very good. Your name does not look familiar. Are you new to the call? I was there a couple of weeks ago. Oh, excellent. Where are you calling from? I'm calling from Boston. Excellent. Great to have you on the call again. And Walter, good morning. Glad to have you on the call. Hey, thank you. Where are you calling from, Walter? I'm calling from Costa Rica. Ah, great. Good, good. Thank you. And just so everyone else sort of knows, Walter will be presenting at our next general meeting. So great. All right, well, we're just at the top of the hour, so great to have everyone. We have a great presentation today, and so I just wanted to get ourselves started. And as always, first of all, welcome to everyone, and I'm glad to have you join us. As always, we do record this presentation or general meetings, and so just FYI on that. As well, please take a read on our antitrust policy notice, which is on the screen right now. Feel free to read through that in your own time, but the upshot is it's all about being a good person, and so that's what that's all about. So thanks for that. And we sort of walk through this a little bit as people were coming online, but it's always great to sort of meet people that are fairly new to the group. And so if someone is new, it'd be great if they just introduced themselves briefly, talked a little bit about their interests in blockchain technologies and healthcare, and happy to have anyone sort of jump right in. Anybody? How about I'm going to just walk the list. Chad, can we get an introduction? And Chad is muted, so we may have to wait on that. Ken is Jensen. Did you want to say hello? Well, Ken from Central Health Systems in Virginia Beach, Virginia. Great. And is this a first-time call for you? No, it's like my fourth. Oh, okay. Oh, there goes my mind. I'm losing my mind, so. All right, well, thanks for that, Ken. Thanks. Go ahead. Yeah, yeah. And remind me again, what do you do on the East Coast, sir? I'm a senior systems engineer. Oh, yeah. Okay. I think I remember you. Okay. Great to have you on the line. Mark Krepels. Yeah, Mark Krepels, Chief Operating Officer, Instamets, based out of Philadelphia. Oh, excellent. Oh, great to have you, Mark. Thank you. Happy to be here. Excellent. Neil Morton. Sure. Good morning, Neil Morton. I'm a solution engineer for Instamets. Oh, excellent. Oh, you got a good contingent going, Brian. Excellent. Good to have you. And Zaki, we've heard from Walter. Walter, do you want to introduce yourself briefly to the group? Yeah, sure. Thank you. Well, I'm the CEO of World Sioux. And we'll be tools for their fabric and other block analogies. I'm not specifically from the healthcare area, but I'm a friend of Instamets, so I'm here. Yeah. And Walter will be, like I had mentioned, Walter will be speaking at our next general meeting. And for those of us that have actually done some development work, he and his team developed tools, one of which is Convector, which is sort of becoming the de facto tool for spinning up fabric installs. And so it's great to have Walter on the call today. And then it really in support of Brian and his team, because that's some of the work that they've, some of the tools that they've used through Instamet. And so just great, great to have the sort of the whole sort of environment here this morning. So thank you for that, Walter. And then of course, we'll see you in a couple of weeks, too. Yeah, sure. I'm excited about it. Thank you. Okay. So moving forward, I might have been on mute. This is Chad Small. Just good morning. Yeah, tell us a little bit about yourself. Good morning. Yeah, I'm just I'm from Bind. It's on demand health insurance. I'm the DevSecOps lead and I'm interested to learn more. This is my first user group session with so outstanding. Great to have you, Chad. Where are you calling from? Minneapolis. Excellent. And tell us a little bit more about what you do with blockchain technologies and specific? Well, we're just starting to look into it. It's we're about two years in and it's, you know, health insurance. So very interested. And this is one of our use cases. We're thinking about as we in the payment space between, you know, we're a payer in that space and with a network that we're building out to providers. So we think this is the future direction and one, you know, we're continuing to learn more. We're not prototyped or beta or anything around it yet. We're just still in a learning phase. Excellent. Okay. Well, good to hear. And of course, you heard that we have a few instrument folks on the call. So feel free to make connections if you possibly can because that's what this is all about. Thanks. Thanks for being on the call. Is there anyone anyone else that's new on the call that would like to say something? Okay. All right. Well, good to have everyone. I just it looks like Steven and Bob just got on the call. So good morning to those gentlemen as well. Thank you for joining us. Okay. So on the agenda, we have a community announcement, which really came up through the listserv. So Cambridge University is doing some work in the field of academic research as it relates to blockchain technologies. They're in the process of developing their the second edition of the global blockchain benchmarking study. And I'll bring this up. And so you can see this is the document that they are working on. I think this is probably the first version of the document. But what they're doing is they're really looking for some good resources that are out there that are already using blockchain technologies in a production environment. And they want to use that for for their inclusion in this document. So in this study, I would say. And so if you have an interest in getting your product effectively published through this this research effort, feel free to contact Mikkel and and and or Apple, and and the the links for their email are in the the agenda. And please, if you do, it'd be great if you could report that back to to the group here, because it's always it's always great to know that we have some some representation of the hyper ledger team out there somewhere. And so this would be a great opportunity. OK, any other community announcements? Anyone else working on something that they'd like to share with with the group here? OK, if you do, feel free to use Lyft serve. And of course, we also have an active rocket chat channel. Rocket chat is very similar to I know I just lost it. What's the equivalent out there? Slack and so so feel free to use our rocket chat channel if you if you want to take conversations offline or sort of correspond with a specific HCC member directly or a team of folks, because you can do that very easily through through the rocket chat product works very well. OK, well, with with I would just being very excited about this, Brian Bento, who's head of innovation for instrument is going to speak, give us a little bit of a presentation on some of the work they're doing using hyper ledger fabric in in the health care space. And so I'm going to hand everything over to Brian and Brian, if you want to take control, feel free to do so with your presentation and and go for it. Great. Thanks, Rich. Let me know if you guys can see my screen. Yeah, great looking good. All right. As Rich mentioned, my name is Brian Bento. I'm in the head of innovation at Instamed and been working on health care payments for over 14 years. So we have been looking at blockchain for a while and we decided to create this prototype to get a better understanding of how it works and the strengths and weaknesses. So that's me. So here's a true story. I have a friend named Steve. He visited his his doctor, his cardiologist. He was having chest pain after a bike ride over the weekend. And the doctor's office, they measured his blockage of his coronary artery and they said it was 98 percent clogged. The doctor was extremely scared that Steve was going to have a heart attack right then and there. So he called an ambulance. The doctor followed the ambulance to the hospital. They put an emergency stent in and over the next three to six months, Steve received a stack of paper bills from the ambulance, the surgeon, surgery center and several other business entities. And he half jokingly said to me that the billing dealing with the billing was almost worse than the heart attack experience itself. And it just continued to drag on. It was very complicated and his out of pocket expense was actually pretty reasonable because he has pretty good insurance. Yet still it was very painful dealing with all the payment aspects. What makes this so challenging is, you know, we have a three-party payer system and the patients are confused by the statements that they receive and the fact that they have to many times deal with separate payment processes for each provider and possibly separate logins. The providers complain that they're having to send on average three statements to collect on a patient bill, which is very slow and expensive. And health plans, they want an easy way for the members to be able to view their balances, pay their responsibility and utilize their apps and web portals and they want to improve provider satisfaction. So we had this thought experiment, you know, what would a system look like that would have provided a seamless payment experience for Steve? Given that in the U.S., the hospital employees, independent contractors and facilities are part of separate business entities. So we can't just assume, hey, everyone's going to be, it's not a single provider system, a national provider system, it's a very complex environment. And I can talk a little bit more about this at the end, but this is kind of food for thought. So a little bit about Instamed. So we're focused on healthcare payments and we have a healthcare payments network that connects providers, payers and consumers all across the United States. We're focused exclusively on the United States. And Instamed was founded in 2004 by Chris Sive, our CTO and Bill Marvin, CEO. We're focused on simplifying healthcare payments and we have many solutions like photo bill pay using our mogul apps that you can download for free from the app store and patients can pay all their bills. We have solutions for payers and providers for consumer billing, something called member payments. But we believe that we can take it to the next level with blockchain. We integrate with both provider and payer healthcare IT systems. And as I mentioned, we deliver payment solutions for patients and members. So the objectives for the prototype were to assess the viability of blockchain and healthcare payments. And we paid particular attention to authentication, authorization, privacy, and transaction processing. Our philosophy for the project was we wanted open collaboration with a diverse set of industry stakeholders. And I do want to emphasize that the version one of the prototype is what we've completed thus far. And now is when we're really opening it up to collaboration. We're now starting to focus on version two and we're taking input on what the V2 is going to look like. Interoperability through open standards and open source, focusing on the financial workflows, which is an area that is our focus. But we're also supporting, as you'll see, some aspects of the clinical side in trying to make that easy and something that could be expanded upon. Privacy and security are extremely important in healthcare. And we would meet HIPAA compliance. And we really did this to learn as much as we can. So the stack that we're using, hyper ledger fabric with the Node.js SDK, we're using Convector from Walters company, WorldSewoo. We chose to use Fire version four and the financial management workflow as an open standard. And I'll talk a little bit more about Fire later. Vue.js is a technology for the front end application. And we're using Forma, which is another solution from WorldSewoo that allows us to deploy our network on any cloud. And we're currently deployed on Google Cloud. So why we chose hyper ledger fabric? It supports rapid prototyping using the composer tool. Although the composer tool will not be supported forever, it was a great place to get started. It's open source and open governance and it's Linux based. It's modular and flexible and has a large community. So we definitely felt that it was a great choice and still has a great choice to build on top of. For Convector, it supports enterprise model view controller software development. It uses TypeScript models with validation attributes, controllers, unit tests. And it was just very easy for us to get started. It also has a layer of abstraction. So if we had to change the underlying blockchain technology, we could. It's open source and it's a hyper ledger labs project. It has great documentation, including tutorials for migrating from a composer, which we initially used to Convector. And it's a thin wrapper around the Node.js SDK. And so we still have access to all the other Node.js libraries and ecosystem. HL7 Fire V4, it is a standard for health care data exchange published by HL7. It supports both clinical and financial management workflows and resources. It's aligned with our philosophy of interoperability and open standards and not trying to own the standard for the network. And it currently has a very active community. And Forma, it supports multiple clouds. And even you can host it on your own privately managed cloud, which is how Instamed has its own privately managed cloud. And each participant can host wherever they want. And it was very quick to get started with. Here's a little about just the architecture and development. We use a tool also provided by WorldSubu called Hurly, which makes it really easy to stand up a set of servers on a single box. And then for the prototype, we hosted on Forma on Google Cloud. And now I'm going to jump over to the demo. All right, so hopefully you can still see my screen. Looks good. Yep. This demo is available to anyone in the world to play around with. It's probably one of the first and only health care demos that anybody can play with. So it starts with, and this will write to the blockchain running on through Forma. This application demonstrates three separate applications and perspectives. So first, as the provider, I would see a patient. I would perform one or more services. You can change the services, then you click Create Claim. Now here, we're going to submit data to a smart contract application running on the blockchain, which will generate fire-based resources. At the top here, we're going to show the blocks that were created and their color coded for each of the different perspectives. If you click on the block, you can see the hash of the current block and the hash of the previous block. You can also see the data that was submitted to the blockchain smart contract application. And I'll have in this tool called the Block Browser lets you see the data that was generated on the blockchain. And you can see here, this is the data that's actually stored on the blockchain, and these are fire resources. So now, after the provider submits their claim, the pair would receive the claim. You can change in the demo how much the plan covers. In this prototype, we're only supporting the happy path flow, and we have a really nice pair who's going to always approve claims. So now, data was submitted to the smart contract application called Adjudicate Claim, which will create the claim response for the provider. It'll save a patient account, and it's going to auto-generate the invoice for the patient. Now, the block from the pair will be created just as before, and you have the different adjudications for those charge items. Now, the patient would get an invoice, and they'd be notified of an invoice. They'd make a payment, however they want with a bank account, credit card, maybe in the future some cryptocurrency, who knows. But then, after they've made their payment, their payment would get recorded onto the blockchain, and their invoice would get marked as paid. So this would complete the complete payment process. All right, and back to the presentation. So in addition to the demo application, we also have released our GitHub repository, which is here. And some of the code is auto-generated by Convector. The main area of interest is this financial CC, which represents the smart contracts for the financial management workflow. This file, financial.model.ts, which I'll load here, is all of our models. And we built a tool that takes in the FHIR resources and auto-generates and translates them into Convector models with validation attributes. And I included all of the FHIR resources, both the clinical and the financial resources as well. So it will make it very easy for others to expand upon it and implement clinical workflows. And you can also see the different controller methods, which represent the smart contracts in this framework. In addition, we also have this page on our developer portal, which describes this project. We have a video. We describe the problem. We describe the prototype, how it works. And we're asking people from the industry to join the conversation. And we've been having conversations with people from the industry every week to discuss what they see as the next steps, answer any questions, and so on and so forth. The lessons learned. So during this process, as we were using FHIR version V4, we found that it doesn't have a patient payment resource, although it does have an invoice resource. And so we've been working with the FHIR community, specifically the financial management group, to add the patient payment resource. We also learned that there's too many resource definitions to translate them manually. So building a tool to translate them is a tremendous time saver, especially as there will be new versions of FHIR in the future. We found that Hyperledger Fabric in its current state, it is somewhat daunting to set up. We included a installation guide on our website so you can stand up our prototype application. And it has 16 steps. And also, there's a lot of confusion around blockchain and what it can and can't do. And it's important to note that it does not inherently solve identity verification and neither do public blockchains like Bitcoin, as they are anonymous. It's the member's responsibility to handle authentication and identity verification. The possible next steps for the project, working with the FHIR community, as I mentioned, we want to add some additional resources even to our financial workflow. We want to support more complex use cases in the financial workflow, including coordination of benefits, multiple payers, denials, claim resubmission, patient invoice disputes. We did this demo at our health care payment summit about a month ago. And we basically demoed for 10 hours and talked to both providers and payers. And some of this feedback is directly from them that they wanted to see more use cases in the prototype to see how some of these more complex scenarios would work. We also want to write to the blockchain as part of processing transactions in the instrument platform. That's one thing we could do. And read from the blockchain from separate applications representing the separate entities. We want to start discussing the creation of a broad consortium. We are thinking that rather than having separate small consortiums be created for different aspects of health care, it would be much better if a broad consortium for health care could be created that allows exchanging data, not just for one specialty or one use case. I have a really good friend who has a company. He's the CTO of a company that tracks donor organs from when they're taken from one individual and eventually when they get put into another individual. And they meet all of the regulations required for tracking that organ as it's transported. And rather than having to create separate blockchain consortia for each of those different use cases, if we could create one generalized approach and health care entities could join it once and be able to communicate securely and reliably with any of the participants, I think that would be a great thing to aspire to. And finally, we do have the clinical models. However, we don't have the clinical workflows implemented. So we would like to work with others who are interested in the clinical workflows and implement them on top of our code base potentially if they want to start with it. So if anybody has any questions, they can send emails to this email address. And somebody from our team will answer them. Excellent. Outstanding, Brian. Thank you. So questions? Yeah, it's Vipin. Yeah, hi, Vipin. Hey, how are you? Very good. Being the organizer of the identity working group in Hyperledger, I'm very interested in the last point that you raised, which was about identity. So does FIRE have an identity schema or a model? And if so, what is the bridge between what is represented on the blockchain as far as identity goes to the off-chain enterprise identity systems? That is my question. And also, I know that membership service providers in fabric is supposed to do that translation. And how do you have to create a bespoke MSP to do this? Or I mean, in other words, what are your thoughts on that? Sure. So I'm not sure if you're familiar with the CHIME patient ID challenge, but there was a, go ahead. No. OK, I think it was about two years ago, CHIME put together a prize for $1 million for a team to come up with an approach for a universal patient ID. And I competed in that challenge and followed it closely. A national patient identifier, if you will. And the result of that process of analysis, what people realized was that HL7, including FIRE, support they have a naming convention and a generic way of being able to pass identifiers. They also support passing along biometric data, including iris scans, retina scans, thumb prints, voice, et cetera. And I'm not sure how much you know about iris versus retina, but you can take a picture of somebody's face and their iris, even with a relatively inexpensive webcam. And there's 20 different, or I think 200, distinct characteristics of your iris. Whereas with a fingerprint, there's many. Yeah, I'm familiar with that. OK, so the idea was that in order to match patients across different organizations, that they would use biometric data. Unfortunately, the project never completed and the $1 million was never distributed. However, it seemed clear to me from the discussion that it was not tenable at this time to create a national patient ID and that the industry is thinking about using matching algorithms that leverages biometric data and otherwise. So in terms of the on-chain and off-chain, it's a very challenging problem. Health plans issue, not unlike banks, issue cards to their members with their policy number and group number and so forth. However, that doesn't help you across payers. So I don't think that we have the solution yet, and that's an area that we will need to discuss and have conversations about. How do you translate? Instamed is both a clearinghouse and a payment processor. We were the first integrated health care and payment transaction processor. So bringing those two industries together, we're very familiar with the way that banks authorize their card holders, if you will. And we've been thinking about this problem for a while, but there needs to be a conversation, for example, at FHIR to talk about this problem and interoperability. We're hoping to join and have a discussion meeting at the September FHIR meeting in Atlanta and having a working session to talk about interoperability because it is important. If you think about email, there's a simple protocol, SMTP. And all you have to do is you have an email address. If you know somebody's email address, you can send them an email. And they look up at instrument.com. There's a DNS look up. There are MX records that tell you which servers are hosting email for Instamed. And it works. Now SMTP has a lot to be desired. And this is what we've been thinking about, that it's very easy to spoof an email and make it seem like it came from the CEO of your company. And so that's one of the weaknesses of SMTP. A lot of companies have been created to create secure email. We believe that there could be a secure protocol and secure email protocols have been talked about in the network communications community and RFCs have been created. I think we need something similar for health care. It's going to be a protocol that needs to have directory look up. There needs to be a way to verify and validate that data was sent from the sender and to verify that it gets to the proper recipient. It's going to need to support cryptography for encryption in transit and perhaps encryption at rest. There needs to be a way for routing to occur across the network. So this concept of creating a protocol and a consortium that implements that protocol, not unlike the Visa and Mastercard, they each have their own consortiums, really, and they have their own message formats and protocol that each of the distributed ledger banks, as it were, implement. Yeah, actually, in this context, you should be aware that we have just incubated a protocol called ARIES, Hyperledger ARIES, which is attempting to solve this very problem and using DIDs. Oh, perfect. I'd love to know about it. Yeah, so if you look up the ARIES proposal and there's a lot of actual code, which people have contributed, so it's not just a white paper. It is more than that. It is actual running code. And the Indie project is supporting this. But my question, which was about the current identity schemas, which obviously need to exist somewhere, and obviously, the future is the future, and we have to get there. But in the meantime, we have to deal with what is there currently. So I mean, I understand I'm a technical person, so I understand. In fact, anyway, I don't want to talk about SMTP and all the PGP and blah, blah, blah. But we are very familiar with all these problems. But in the identity context, we want to figure out, what can we do now? I mean, yes, biometrics. We, in fact, in the identity working group, which I chair, we had a paper presented on, we incubated paper on biometrics. In fact, it's available as a link from that site. And I'm aware of the work done by ID2020, for example, for biometrics to give the unbanked refugees, people like that, who do not possess any papers, but only their bodies. I mean, there's a lot of work going on in there, but coming back to the question, is there an identity schema in, I'm not talking about a universal identity schema, just something very practical today, and can we attempt to bridge the gap between that identity schema and what we represent on the blockchain? So the short answer is that I'm not aware of, other than what's in the FHIR spec, in terms of supporting the passage of patient identifiers and custom naming conventions. It's somewhat identification agnostic, is what I'm trying to say. I will say that I, as part of the, in the CHIME competition, I submitted a proposal. It was a 20-page paper on what I saw as a potential way to move forward, where you need to have entities that are similar to banks today, where they perform the onboarding and enrollment of new individuals and gather their biometric data and check their government-issued IDs and so forth, just like a bank is required to do today and sets them up with their digital profile and acts as the custodian of that digital profile, not unlike a bank is the custodian of your digital bank account. And in exchange for providing that service, the banks would be able to charge transaction fees as data is moving across the network. So that would be the business model. I don't think that there's necessarily a magical solution to this problem. For example, Instamed, we onboard consumers, they can join our network, they will eventually get a username and password. We have capabilities for them to retrieve their account if they forget their password, et cetera, and verify that they are who they say they are. And we've onboarded a large number of consumers already and we're continuing to do so. So if there's companies like Instamed who can take on that responsibility and also be a member of this network, I think that that is one way to get there. Thank you. Thanks, Vipin, appreciate it. And I'll follow up and see if I can get a link over to the identity workgroup that biometrics reference, because I think that's something that we would see particularly useful in the health group SIG here. So thank you for that, Vipin. Any other questions? Yeah, this is Chad from Buying. I have just one comment on the SMTP kind of reference. It's interesting that if you're the new MTA STS initiative around making SMTP a little a lot better and Google and lots of players are in on that spec. But I like that concept for identity in healthcare. That's a great analogy. But my question was around kind of the business aspect on the provider side of the equation. And if you could speak to maybe what your thoughts are around adoption and incentives for adoption to this, I think I know some of them, but I'd be interested to get your take on that. Sure. So today Instamed is a full service clearinghouse. We have several competitors as well and providers utilize Instamed to outsource their consumer billing and payment acceptance. So they're already incentivized to use Instamed or one of our competitors to print and mail bills, also to support electronic statements. Many other solutions that we build on top of those data feeds, automated payment collection, for example, and many others. So we already know from our own experience that providers want to outsource billing and payment collection. They want to make sure that they're PCI compliant and that's what Instamed helps them do. They want to kill paper. I think everybody is incentivized to kill paper. It's slow and expensive. That's the common enemy. And I think there's a win-win situation. Now, Instamed would be a member of this consortium. And so to the extent that the providers want to participate and opt in, we would do all the work of translating to and from their systems if they don't want to join the network as a member and host their own node, we would take care of all the interactions with the blockchain. Now, other providers and large health systems, perhaps who are sophisticated, they could join the network directly. Once people have joined the network, the idea would be to have this sort of directory system so that if there's a provider, payer, or patient that we have in R that's directly connected to our node and somebody else, just like this at instamed.com concept, that they would know that, okay, I'm going to send something to Chad at his Instamed blockchain account and they would know that it needs to come to Instamed and there might be, as it travels, some sort of fee as the data moves around. So I think that the providers, to the extent that it will further reduce their paper costs, I think they would choose to opt into it. Yeah, and I'll just add on the payer element, there's, I think, a lot of incentive just for the, the kind of lead time, the round trip around repricing and payment from the payer could be accelerated significantly on a blockchain integration, I think. And yeah, you could even think about cases where the payment, the patient payment is complete, even beforehand. So, like you said, that three-statement chase of patient payments is in there too. Okay, yeah, it makes sense. Not to, the consortium, is there anything started? Is there anything in this space? So we've been talking to several folks, like for example, Hashed Health, they've started a consortium for provider credentialing that they're helping manage. There's other consortia that are in different stages of development and discussions. Many of them are focused on one specific use case or specialty. That is not the approach that I would like to focus on. As I had said, I would prefer to create a generic protocol like SMTP and a process, and it would cover the entire healthcare market. It's essentially, not unlike secure FTP, not secure FTP, secure email, secure SMTP. And maybe that vision is, some people might say it's a little too, perhaps too big to try to bite off. However, to me, I think that's where the most value will be to get to a fully connected ecosystem. I'm also, one thing I wanna notice, I'm thinking that this connectivity and blockchain aspect is not something that InstaMed sees as a competitive advantage. Open standards aren't typically that. They should be just the cost of doing business. Security, compliance, connectivity, those are just the cost of doing business. The way you need to differentiate yourself is all of the services and functionality that you build on top of it. What's your customer service like? What's security and compliance? What functionality do you have, et cetera? What's your user interface? Yeah, I agree. Yeah, and I think, yeah, without momentum, yeah, openness to the, yeah, it doesn't, I don't know, I don't see it working, yeah. So, yeah. So, I have a quick question, Brian, this is Stephen Elliott. Great presentation, like to see things actually working, and even though it's just a small slice, really, really great to see the blockchain in function. I was a little surprised that you use FIRE for a payment. That actually wasn't what would be the first implementation of FIRE on a blockchain that I had imagined. Coming much more from the clinical area. So, I would definitely like to work with you to see how we can combine what you've done with the clinical workflow and using FIRE for interoperable clinical data. Just one, the question I had is, how many entities on the consortium did you have on the channel, and did you have just one channel? So, currently we have just one channel in our prototype and there are three members. There's a payer member, there's a provider member, and then there's kind of like an instamed member that's representing a large number of patients. And you had one CA on the blockchain? The number of CA's, you know, I don't recall, maybe Walter can chime in because he helped set it up. Yeah, sure. In this case, each organization has its own CA. From a technical standpoint, it's actually two instances. It's a root certificate authority, but organization and also an intermediate, which is issuing all the certificates for this current structure. Yeah, I was talking about the chain CA, so. The observer, so to speak. So, I've looked at the source code, it looks great. Like I said, I'd like to take a conversation and work with you and talk about how we might be able to work into your existing prototype for what we hope to be the healthcare interoperability. I know that there is another interoperability work group at another level in hyperledger fabric. They're currently struggling with adding dynamically another healthcare organization. I believe in this case, they're working to add another payer into the blockchain. Did any of that, did you find that to be an impediment in growing the chain and growing the channel? That's a really great question. That is the area that we're talking about right now for the V2 is that the way hyperledger fabric handles channels, it works okay for a relatively small network where you know all the participants are members upfront. However, with something, with such a large healthcare industry, you'd need something that is more flexible and more dynamic and has a way of growing more organically over time. And so that's an area that we're currently talking about. Is there a way to either completely eliminate the concept of channels as being statically defined and make them dynamic and perhaps on each particular resource, store information about who should be able to access it. Back to the email analogy, you have the recipients and you also have BCC and CC and putting that on a per resource basis. And then the protocol would handle making sure that the people who should have access have access, et cetera. So that's one thought that we had. The other thought is using private data. Channels can have private data collections in fabric that supported, I think as soon as 1.2 and we wanna look at potentially using that as it already exists. So the question is, does hyperledger fabric have what we need today or does it not? And if it doesn't, we are interested and maybe Rich can help facilitate this but we'd love to have a conversation with some of the core engineers of fabric to talk about the scalability and manageability of the channels and enhancing fabric to support it. Ironically, it's also an issue that's been felt by other parties. We've had conversations with other folks and they said that the concept of channels has been very difficult for them. They've had situations where they were trying to copy data from one channel to another and that completely subverts the concept of a single source of truth, creates a whole lot of pain points and challenges. And so that's why I'm thinking and based on my experience with various technologies like CouchBase where each document you can specify who has read access, who has write access and there is a service that takes care of ensuring that only people who should have access can access the things that they have access to and otherwise that handles the replication. Yeah, Consent Management in short. What was that? Consent Management. Yes, Consent Management needs to be a core part of the protocol. And I'm perfectly, I would much rather improve hyper ledger fabric and make it better and address some of these challenges than throw the whole thing out and start a whole new platform from scratch. Completely agree until you understand the problems you can't really say they're gonna throw something out. I think that part of what we're looking at payments are relatively simple because they can, I don't mean to say that, I think you've done a very complex job and made it very simple. But they can be stored directly on the blockchain on the ledger itself. Medical, clinical data by and large will have to find a side chain to be stored on and the resource metadata resource, a fire resource put on the chain to preserve as assets the resource that it points to who has identity, who has consent to that resource, et cetera. So that makes it even more complex. Agreed. Now I definitely understand the complexity. The reason, part of the reason why we are, we are payment focused, but I didn't want to limit ourselves and our thinking to payment only because I do feel that solving the problem generically across use cases is ideal. And it would be much better if providers didn't have to have many different connections and ways of communicating. Well, I gotta jump off, but I would love to carry on this conversation unfortunately it looks like my time has opened up a little bit this month. So I'll reach out and get a conversation going and see what we can do to collaborate on building in a clinical workflows into the Instamat prototype. Perfect. All right. Thanks for joining. Alrighty, well we are coming up to the top of the hour. If, does anyone else have a sort of a quick sort of closing question or if not, Brian, maybe a closing comment. So last, last question, anybody? Bippin again, just reminding everyone that some of these things that you guys talked about right now is being looked at by HEPA ledger Aries. Just, just want to remind you to get involved in the project. Yes. Yeah, great idea. And Aries is very, very new, brand new. And so it's just now coming together to Bippin's point, there's already code in place. And so it's really kind of a spin out or I don't know like a brother to Indy in some respects. And so it's moving along at a pretty good clip. Now that's great. I think we definitely intend to get more plugged in. You know, we're getting more plugged into the fire community. We want to get more plugged into the hyper ledger community. Right now we're in the discovery phase for the V2 of the prototype. And, you know, we want to tackle the hardest aspects, which include the identity verification and the privacy and permissioning, if you will. Aspects at scale. So that's really the focus. And we don't want to reinvent the wheel. We want to work with, you know, as part of a team. The wheel has been reinvented many times. Yeah. So we do have a privacy and security architecture working group, which call is coming up, you know, in three minutes. The other one is the, there's a general interoperability working group as well. Working group meaning a sub working group of the architecture working group. So that is not specifically aimed at hyper ledger fabric, but at a general problem of interoperability. And those are the two that are cross DLTs hosted by the architecture working group. So you're welcome to join or look at the material that we post. No, thank you. I definitely will look at those groups and try to join some meetings and participate. Excellent. Well, thank you, Vipin. And thank you, Brian, outstanding presentation. And for everyone that has been listening, this is all this is open source. It's out on GitHub. And so obviously, you know, you certainly have the opportunity to sort of dig into the code a bit and play around. And then Brian, I suspect that you're available for questions or comments if people bring them up sort of post presentation. Definitely. Are these resources going to be available publicly? Meaning the links to the GitHub, all that stuff. Correct. Yeah, it's available through our agenda. So we've got links there. And of course, obviously, Brian will be available through Rocket Chat or through our listserv. So if anyone wants to contact them, there are certainly ways to do so. Alrighty, well, thanks everyone. We are at the top of the hour. Appreciate it. Again, thank you, Brian and everyone from Instamed for making this happen. Great presentation. And with that, I think we're all set. Have a great weekend and we'll see you in two weeks when Walter presents from Global at Cebu. So thanks everyone. Take care. Thank you.