 Okay, and a good morning to Chad, and a good morning to Zachy, Alam. Good morning to Zachy, 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. 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, 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, 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 started sort of walk through this a little bit as, as people were coming online, but it's always great to sort of meet people that are fairly new to the, to the group. And so if someone is new, it'd be great if they just introduced themselves briefly, talk 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? Oh, Ken from Central Health Systems in Virginia Beach, Virginia. Great. And is this the first time call for you? No, it's like my fourth. Oh, okay. Oh, there goes my mind. I'm losing my mind. All right. Well, thanks for that. Thanks. I'll go ahead. Monday. 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 Krapels. Yeah. Mark Rappels, chief operating officer, instruments based out of Philadelphia. Oh, excellent. Oh, great to have you, Mark. Thank you. Happy to be here. Excellent. Neil Morton. Sure. Good morning, new Morton. I'm a solution engineer for Instagram. Oh, excellent. Oh, you got a good contingent going, Brian. Excellent. Good to have you. And, 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 civil. And we be tools for their fabric and other systems. We be tools for their fabric and other block analogies. I'm not specifically from the healthcare area, but I'm a friend of in some ads. So I'm here. Yeah. And, and Walter will be like I had mentioned, Walter's will be speaking at our next general meeting. And for those, 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, 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 Instamed. And so just great, great to have the, 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. Good morning. Yeah. Good morning. Yeah. I'm just, I'm a from bind. It's a on-demand health insurance. I'm the dev sec ops lead. And yeah, I'm interested to learn more. This is my first user group session with. Oh, 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, the future of the future. In the, 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, 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. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. 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 we have a community announcement, which really came up through the, the listserv. So Cambridge University is doing some work in the field of academic research as it relates to blockchain technologies. They're, 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, 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, or 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 Michele and, and, and or Appalene 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. Cause it's always, it's always great to know that we have some, some representation of, of the Hyperledger team out there somewhere. And so this would be a great opportunity. Okay. Any other community announcements? Anyone else working on something that they'd like to share with, with the group here? Okay. Yeah. If you do feel free to use lift serve. And of course we also have an active rocket chat channel. Rocket chat is very similar to, and 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 HCCIG member directly or a team of folks, cause you can do that very easily through, through the rocket chat product. Works very well. Okay. Well, with, with just being very excited about this, Brian Bento, whose 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 Hyperledger fabric in, in the healthcare 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 healthcare 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% 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 their 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 employs 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, the CEO. We're focused on simplifying healthcare payments, and we have many solutions like photo bill pay using our mobile 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, hyperledger fabric with the Node.js SDK. We're using Convector from Walter's company, WorldSeaboo. We chose to use Fire version four and the financial management workflow as an open standard. 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 WorldSeaboo that allows us to deploy our network on any cloud, and we're currently deployed on Google Cloud. So why we chose hyperledger 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 is 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 hyperledger labs project. It has great documentation, including tutorials for migrating from 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 healthcare 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 World Subu 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 healthcare demos that anybody can play with. So it starts with, and this will write to the blockchain running on through Forma. This application demonstrates, you know, three separate applications and perspectives. So first as the provider, I would see a patient, I would perform, you know, 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 data 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, 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. We're 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 payments, their payment will get recorded onto the blockchain and their invoice will 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 a lot of this, some of the code is auto generated by convector. The main area of interest is this financial CC, which is the set of, this 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 fire resources and auto generates and translates them into convector models with validation attributes. And I included both. I included all of the fire resources, both the clinical financial resources as well. So it will make it very easy for others to expand upon it and implement clinical workflows. All right. And you can also see the different controller methods, which represents 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, you know, on every week to discuss, you know, what they see as the next steps, answer any questions and so on and so forth. All right. The lessons learned. So during this process, as we were using fire version before, 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 fire 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 fire in the future. We found that hyper ledger fabric and 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 there are anonymous. It's the members responsibility to handle authentication and identity verification. The possible next steps for the project, working with the fire 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 and voice disputes. We did this demo at our healthcare 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 healthcare, it would be much better if a broad consortium for healthcare 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. Rather than having to create separate blockchain consortia for each of those different use cases, if we could create one generalized approach and healthcare 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. Finally, we do have the clinical models. However, we don't have the clinical workflows implemented. 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. If anybody has any questions, they can send e-mails to this e-mail address and somebody from our team will answer them. Excellent. Outstanding, Brian. Thank you. Questions? Yeah, it's Vipin. Hi, Vipin. 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 FHIR 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. Okay. I think it was about two years ago, that CHIME put together a prize for a million dollars for a team to come up with an approach for a universal patient ID. And I competed in that challenge and followed it closely, you know, a national patient identifier, if you will. And the result of that process of analysis, what people realized was that HL7, including FHIR, 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 the... 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. Okay, 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 million dollars 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, you know, there's... It's a very challenging problem. You know, 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 want to... We will need to discuss and have conversations about. You know, how do you translate... Intimate is both a clearinghouse and a payment processor. We were the first integrated healthcare and payment transaction processor. So bringing those two industries together, you know, we're very familiar with the way that banks authorize their, you know, card holders, if you will. And we've been thinking about this problem for a while, but there, you know, 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 kind of a working session to talk about interoperability, because it is important. You know, 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, you know, at instrument.com. There's a DNS lookup. There are MX records that tell you which servers are hosting email for instrument, 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, you know, 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. We think we need something similar for healthcare. It's going to be a protocol that has, you know, it needs to have directory lookup. There needs to be a way to verify and validate that data was sent from the sender, and, you know, to verify that it gets to the proper recipient. It's going to need to support, you know, cryptography for encryption in transit. And perhaps encryption at rest. There needs to be a way for routing to occur, you know, across the network. So this concept of creating a protocol and a consortium that implements that protocol, you know, not unlike the Visa and Mastercard, you know, 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. Yeah, so if you look up the ARIES proposal and there's a lot of actual code, you know, which people have contributed. So it's not just a white paper. It is more than that. It is actual running code. And it's, the Indie project is supporting this. But, you know, my question, which was about the current identity schemas, which obviously need to exist somewhere. And obviously, you know, 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, you know, I'm a technical person, so I understand in fact. Anyway, I don't want to talk about SMTP or, you know, PGP and blah, blah, blah. But, you know, we are very familiar with all these problems. But in the identity context, we want to figure out what can we do now, right? 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 from as a link from that site. And I'm aware of the work done by ID 2020, 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, you know, 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 fire 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, you know, 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, you know, acts as their, 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, you know, 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, you know, 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 I, you know, 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, Wippin. 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, Wippin. 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 will, you know, 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, you know, 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 in large health systems, perhaps who are sophisticated, they could, you know, 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, you know, as it travels some sort of fee, you know, as the data moves around. So I think that the providers, you know, 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, is complete even beforehand. So, you know, 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, you know, not unlike secure FTP, not secure FTP, secure email, secure SMTP. And maybe, and maybe that vision is some people might say it's a little too, perhaps too big to try to bite off. However, you know, that's 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 want to notice. I'm thinking that this connectivity and blockchain aspect is not something that InstaMed sees as a competitive advantage. You know, 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. You know, what's your customer service like? What's, you know, 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, open 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. Right. 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. It's a little surprise that 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 a 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. And the question I had is how many, how many entities on the consortium did you have on the channel? And did you have just one channel? So currently we, 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 a, 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, 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 what we might be able to work into your existing prototype for what we hope to be the healthcare interoperability. I know that the inter, 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 was, did you find that to be an impediment in, in growing the chain and growing the channel? That's a, 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's, it works okay for a relatively small network where you know all the participants are members upfront. However, with something, you know, with such a large, you know, healthcare industry, you'd need something that is more flexible and more dynamic. And, you know, has, has a way of growing more organically over time. And so that, that's an area that we're currently talking about. You know, 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. You know, back to the email analogy, you have the recipients and you also have BCC and CC, you know, and putting that on a per resource basis. And then the protocol would handle making sure that the, the people who should have access have access, et cetera. So that's, that's one thought that we had. The other thought is using private data. You know, channels can have private data collections in fabric that supported, you know, I think as soon as 1.2 and we want to look at potentially using that as it already exists. So the question is, does hyper ledger fabric have what we need today or does it not? And if it doesn't, we are interested in, you know, 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, you know, the scalability and manageability of the channels and enhancing fabric to, to support it. Ironically, it's also an issue that's been felt by other parties. We've had conversations with, 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, you know, subverts the concept of a single source of truth creates a whole lot of pain points and challenges. And so I, that's why I'm thinking and based on my experience with various technologies like couch base, 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, 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, I'm perfectly, I would much rather improve hyper ledger fabric and make it better and address some of these challenges then 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 going to 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, to be stored on and the resource metadata resource of fire resource put on me 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 the, and our thinking to payment only. Because I do feel that solving the problem generically across use cases is, is ideal. And it would be much better if providers didn't have to have many different connections and ways of communicating. Well, I got to jump off, but I would love to carry on this conversation. Fortunately, it looks like my time has opened up a little bit this month. So I will reach out and get, get a conversation going and see what we can do to collaborate on building in a clinical workflows into, into the instrument 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. Just reminding everyone that some of these things that you guys talked about right now is being looked at by HEPA ledger areas. Just, just want to remind you to get involved in the project. Yes. Great. Yeah. Great. Yeah. Great idea. And Aries is very, very new, brand new. And so it's just now coming together to Vipin's point, there's already code in place. And so it's, it's really kind of a spin out or a, I don't know, like a, like a brother to, to Indy in some respects. And so it's, 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, 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, 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. 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 DLT's hosted by the architecture working group. So you're welcome to join or look at the material that we post. Thank you. I definitely will look at those groups and, and try to join some meetings. And participate. Excellent. Well, thank you. 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. Yeah. It's, it's available through our, through our agenda. So we've got links there. And of course, obviously Brian will be available through through rocket chat or through our listserv. So if anyone wants to contact him, 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, for making this happen. Great presentation. And with that, I think we're all set. I 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.