Fantastic. Alrighty, welcome everybody to today's edition, June 6th of the Cardio Working Group under Hyperledger Labs. We're excited today to have a presenter and we'll get into that in just a minute before we have a couple of housekeeping items that includes our antitrust policy. So we are not talking about specific business opportunities here, you know, financial gain and things like that. We're talking about that at a more general level. If anybody has concerns, please let us know. You can email me or there are some ways to report that through Hyperledger directly. Similarly, our Code of Conduct, which is linked in our meeting notes, I'll chat this to you guys. These are community notes, so feel free to participate or correct. Also, you can tell me to correct as we go if that's helpful. But our Code of Conduct is really that we're an inclusive community. We encourage everybody to have a voice. If anybody feels like they're not getting the voice that they would like to have here, please again, you can reach out to me as a co-chair or again through Hyperledger to escalate an issue. Ken, who is our other co-chair, unfortunately, had a death in the family, so he's not able to join us today. We hope that he'll be able to take care of those things with his family and return soon. And so that takes care of our housekeeping items. Does anybody want to introduce themselves today? Maybe been a while. I can go first, because I know we're talking about some very specific health things. As co-chair, my name is Keela Schatzkin. I'm based in New York. I work in health data and operations, sort of the intersection of healthcare data and operations, primarily in the health information exchange space. And I've been doing so for a very long time at this point. I do that both in New York and in other states across the US. And so this obviously is very close to my heart as a data exchange method for healthcare data. Right, did I miss something and you wanted to chime in? No, I was just raising my hand. To introduce yourself. For introduction. Fantastic. So that's what I usually ask people to do is if you have a comment to make, please raise your hand. So I'm Ray Jones. I'm a community architect here at the Linux Foundation. I've been working on Hyperledger since before it was Hyperledger. And I was working with Cardia when they were over in LFPH, which went through some turbulence. So I'm really glad to see that Cardia has moved to a Hyperledger lab and is working on becoming what it promised to be. So I'm really glad if you need any support, I'm on Discord. Please reach out. And we're forever grateful for your support. Rai, we really feel it here. So thank you. Would anybody else like to introduce themselves? I will just because it's been a while. Hi everybody. My name is Helen Garno. I do the marketing work here at Cardia in conjunction with some of my colleagues, Tim Spring and Trevor Butterworth, and the community. I also do marketing for NDCO and was there when Cardia was born, I guess, last year. No, two years ago now. Three years ago. 2019, 2020, 2020, 20, 20. Anyways, so again, happy to see it grow. Happy to see us move forward and be part of the Hyperledger Foundation community. I'm also the Hyperledger membership marketing chair. So that's a role that I was elected in by the kind of doothpane members of Hyperledger, all the all the groups that are part of the community. And so if there's anything I can do to help support, yeah, just the visibility of Cardia, I have many, many hats that I wear that would support that effort. So if anybody has any ideas, please don't hesitate to reach out. I think Trevor might have an update on white paper potentially. So we might want to add just grab some time at the end for that at some point. Sure. Okay, so then just for an update, we've migrated all of our housekeeping, we've migrated all of our things to the Hyperledger platforms so that we're more integrated. It's been super helpful. Like as I mentioned, we're eternally grateful for the support that we're getting here. And so I've left the minutes about some of those transition things. If you're, you know, if you come to late to the party, there's some cheat sheets about sort of what's changed and how we're operating and where to find things. You can see those here. So I'll leave those we'll probably take them out moving forward. But just as a reminder, that's there for you. And we're taking notes in the Hyperledger labs space now, which I've linked in our chat. So today we are very excited to have a speaker participate and join and talk about some of the healthcare vital stats space. I'm not going to do it justice in terms of the breadth and scope of what we're going to learn about today and how it intersects with the work we're doing here at Cardia. So I'm very pleased to introduce Sarah and to encourage participation from our community. If you have questions as we go through today's discussion, feel free to throw your hand up and we'll get that asked or you can put it in the chat box and I'll be monitoring that through the course of today. So without further ado, Sarah, do you want to introduce yourself and Ivan? Sure. Hi, I'm Sarah Samus. I work at GCOM. We're a primarily state and local government product, software product and IT services company. And we work with many states across the country. And one of our product areas that we focus on is vital records, issuance and management. And then we also have been working on digital identity solutions using verifiable credentials. So we after talking with Ken and Helen and Kayla previously and Heather, we were invited to come speak to you guys and go through a little bit more of our design process on the vital records use cases for verifiable credentials. The vital records national association has sort of made a goal for its membership that all of the vital records, your restrictions across the country will figure out how to do at least some kind of pilot level digital certificate issuance by 2026. And we feel really strongly along with the community that decentralized identity should be a component of that solution and process because it is more secure and better user experience for constituents. So let me share my screen. Yeah. And is it loading? It's thinking about it. Let me try. Did it work? Let me try again. It's not a presentation without some technical glitches. I'm sorry guys. Can people see it now? We are with you. We're in the power point view. Great. Okay. How do I use the keyboard to do the screen slide view? Does anyone remember? If you... Yeah, there's a little icon that looks like a screen being pulled down at the bottom right. Here we go. Oh, or there. Okay. Okay. Cool. We're with you. So first I was going to talk a little bit about what vital records are and how they are somewhat unique in the United States compared to a lot of other nations and international countries. So vital records are a form of identity credentials. That is true both in the U.S. and abroad. They're used for a range of identity verification when you go to get other types of identity documents including your social security card and your passport and your driver's license. So they are one of the foundational identity credentials in the United States. However, they are not issued at the federal level. In the U.S. they're issued at the local jurisdiction level and there are 57 state and territorial vital records offices across the country. There are 57 because some states have delegated some of this authority to counties and cities and then we have our U.S. territories including Guam, American Samoa, Virgin Islands, that kind of thing. The states share all of their vital records data with the federal government through the CDC and the National Center for Health Statistics Cooperative Program. So the federal government's help supports and makes investments in state vital records IT systems so that they can do this data sharing and that kind of stuff. Any questions about that? This is very unique to the United States. Most other countries have vital records issued at the national level. And this sort of federated nature makes it a little harder to do sort of standardization and interoperability quickly across the jurisdiction. So I think, Kayla, you're super familiar with these types of challenges from working with healthcare providers on HIEs and some of those similar challenges occur at the vital records jurisdiction level. NAPSIS does have a bunch of tools that help with that in a way that your HIEs also do that sort of matching and consolidation. So there are investments in the vital records technology space that have helped to massage and address these challenges. And I happen to live in one of the wonderful states that has two because there is a city, New York City Department of Health and there is a New York State Department of Health and they have disparate systems that do not talk to each other. In fact, occasionally there's some bad blood there and so they don't collaborate as much as you would hope that they do. So there's all sorts of nuances and I think there's also, and correct me if I'm wrong, there is specific state law that also unlevels the playing field across these agencies. Each state has its own state law that dictates how vital records should be collected and can specify even down to the data field level what should be collected and included in a birth and death certificate. State laws also often govern how much it costs to get a birth or death certificate, but again this is all somewhat varied by states and the National Association does have a model law that it propagates for states to use in sort of drafting and updating their state legislation. But they can choose to go go rogue. Yes it is really up to their own individual jurisdictional authority though. So in addition to this federated system which as we just discussed has some data sharing and integration challenges, you also have a lot of different end users across all levels of government that use vital records. If we think back to the first slide where we talked about how this is an identity credential uses identity verification to get other identity credentials you can understand how all of the lines in this high level user flow and data flow chart have been drawn because there's just so much interaction across different both federal and state and local jurisdictions as well as the private sector. So we've bucketed and this is pretty industry standard. There's three primary end users of vital records IT systems and the systems that store your information that's put into your birth and death certificate. So you have your state and local jurisdiction staff, you have your external data providers, sorry the state and local jurisdictions after in the dark bill, your external data providers that enter data about birth and death including people's names, their cause of death, their time of birth, time of death, all that stuff and relationship to relatives. Those are all in the yellow on this diagram and then you have the general public when you want to request a birth or death certificate they're in the light blue here. So each of these 57 jurisdictions has to serve all of these stakeholder groups. And this means there's a lot of friction and interaction because you have multiple end users of one system and you're trying to make that system seamless and a good user experience and also be able to produce the certificates in a timely fashion. The CDC has set a goal that they want all births ideally registered within 72 hours of birth and I am blanking on the death cutoff but during COVID it was really important to have timely death reporting because that was really helping with the disease surveillance and understanding the flow of the epidemic. So I think COVID really highlighted the need for timely death reporting and again you can see that all of these people involved doing all of these different data entry pieces into the different portions of the vital record system really complicates all of those processes happening quickly. We have a question from Simon. Simon do you want to ask your question or do you want me to relay it?  So there's a question about why are these things not free to citizens of the US? Is that because it's state by state? I don't know if you have any insight to that Sarah. That is a really good question. It is definitely the fee scale is set state by state. I would say that and I can go back and check more with the association on this but the fees do help cover the operating costs of producing the birth and death certificate so that money generally goes into the operating budget for the vital records division. Normally those are within state health departments and so there's all the staff here right the IT systems. When you're talking about paper certificates there's very specific security paper with a lot of broad protection built in and the same way your driver's licenses are continually being updated with new broad protection methodologies. They have the similar type of broad protection approaches built into vital records paper certificates as well so there's all of this investment and operating costs around keeping the system safe and secure and able to handle the again as you can see from this diagram the volume of users entering data into the system. Including that there's an office there's like people that are having to be interacted with because it's not a seamless system and again it varies widely but because it's not seamless there's like an office that you have to go talk to. There are almost always walk-in offices where you can order a birth and death certificate because you can't do it all online. A lot of times you can't do it online for some of those exceptional relationship cases like adoption or custodial relationships where you're not a blood relative you have to do a lot more identity verification to even be able to request the birth certificate so they check that you're a valid requester so there's a lot of IV upfront when requesting a birth certificate if you have a more complicated relationship or death certificate to the child or the deceased so there's again a lot of resource-intensive processes around that identity verification and fraud protection because it is in one of the foundational identity documents you don't just want to give it out to anyone. Was there a follow-up? Sorry I apologize I was in the mute and I don't know if you know the vital check this is the company that issues vital credentials here in Idaho State. Do you know if it's the government owned organization or is it a private organization? Vital check is a software product provided by Lexis and Access and most jurisdictions use it for at a minimum their order processing so when you want to order an online birth or death certificate or over the phone or have a kiosk that is generally the software system that's used to help with that process. So it's a private technical solution but contracted by the public? Yes and that is common most states either have purchased a private technical solution or they've built their own homegrown solution so I would say the more jurisdictions have moved to the private hosted solutions or private maintained even if it's not hosted by the vendor and there are fewer homegrown systems anymore because again all of the maintenance required and the complexity and the business rules configuration it becomes very laborious and expensive so more places have moved to a private vendor provided solution. And I have another following question if you don't mind so if all of the vital checks on the territory of the United States should have the same architecture and basically meaning that the birth certificate issued in Hawaii should not be any difference from the one issued in Arkansas or Alaska doesn't it doesn't make sense to unify the whole process and make one software solution that would issue the mandate that those processes and the content be exactly the same but again that's all set by individual state law and if it's not already conforming to the sort of model all minimum requirements it does require the state to pass legislation amending and moving it closer their own law closer to that direction. Okay thanks. Yeah so it's really not a unified system there's a minimum sort of floor base that the association has set and most states try to reach that but there's still nuance and variation on top of it. These are great questions. I think one other thought I have is there and maybe it's more of just highlighting this that blue which is the public there are also it's not just like me personally it may be right if I'm getting social security benefits if I'm getting if I have life insurance right there's there's private companies that also need to know right and they become end users as well. I think if we go back to this this one is the birth one but there's one of these this is the generic sort of use case mapping that I think the CDC did and I can put the link in the chat or send it as a follow-up email if people are interested this is a great overview and this use case document goes through who all of those stakeholders are and talks a little bit more about some of the clearinghouse integration systems that are similar to HIE so this like Steve and Sam's thing in the middle here that helps to do some of that intermediary data sharing work but yes there are like on the it's more obvious on the on the death one in terms of the private users but here all all of the the pink is private entities not government I mean I guess it could be a hospital or a birthing center that's a public benefit corporation like when I worked at health and hospitals but all of these people in the pink are the private slash public users of vital records for birth certificates and then just to underscore these are typical modules in a vital records IT system each of these blue boxes in the middle with the white lettering so when you asked about vital check the order processing one is the one that they're most prevalent in but they also have full stack system so that provide all of these modules as well and just in full disclosure GCOM has a COTS vital records management system so we have a software product that does all of these functionalities so now the focus I think for you guys was really like what does this industry mean for decentralized identity technology and distributed letter technology so we've mapped out a couple use cases to discuss with you guys and and we have some trust triangles to illustrate the different use cases so the first one is the medical certifier so if we go back to this diagram we're talking primarily about the yellow external data providers here are the ones who certify records and say like this person was born at this time and it was you know a regular vaginal delivery versus cesarean delivery or this person died at this time and it was a natural cause of death versus something else so there's a way to use decentralized identity to make the certification process quicker and easier for the medical certifiers and this one is pretty interesting because it can be done it's not so clear from the the first glance who the the admin is who's issuing the credentials here so if you're if you're a doctor or funeral home director generally you're licensed at the state level but that agency that's licensing you may or may not be um the health department so you might you might need a different agency than the health department to be your admin here um and then your vital records are generally going to be in your health department so your your verifier is still going to be within the health department most likely but the admin could potentially be a different agency if that makes sense I don't know if I'm being clear here so this this type are you suggesting that it could be like the hospital for example that becomes the initiating admin because no it's usually like for example in New York state the medical licensure right the the agency that oversees your medical license is the state department of education so in in New York state's example the admin would most likely be the state department of education here and then your verifier in this case is the vital records system owned by the state health department which says okay I realize that you have a verifiable credentials saying that you're this licensed medical doctor okay so this is this is highlighting the trust triangle of saying who's qualified correct to formally submit a birth or death by that record that is a perfect way to phrase it um thank you for being so succinct and I think again the interesting thing is that this use case may or may not be totally controlled by one agency and might require some more interagency coordination to implement but we like this use case because it is more secure right now there's a lot of biometric data stored often for mobile apps that certifiers use and we don't think that ideally long term that's a great way to go because you're then centralizing storage of biometric data and it's such a high security risk I'm sure Ivan can go into way more um elaboration on this point so we think we're we think that trying to get the industry more interested in moving to a verifiable credential for medical certifiers would really accelerate security and lower costs if you want to hear a funny story the New York City Department of Health rolled out an app to people who were allowed to submit data to their vital stats and it had facial recognition and they had to roll it all back out because it didn't work and they were not able to meet those timeline requirements they couldn't mark anybody as deceased it was a major flop very painful Ivan you came off uh you came on camera do you want to add no yeah I was just going to add that you know you have a system with medical certifiers where you have a lot of different like systems that the state can't necessarily manage you have a lot of different doctors providers and whatnot so kind of a decentralized identity solution for that makes a lot of sense because the state doesn't necessarily have to manage that where if you have a centralized system it becomes a fairly significant cost and an overhead burden on the state itself I think one of the other interesting nuances to this use case in addition to like the multiple agency coordination and the um the comments Ivan was talking about is that the you might need some changes to state law because of what we're talking about earlier where state law governs like everything about vital records collection essentially if state law says you need certain types of um identity verification for the medical certifier you might have to amend state law or get some kind of creative legal opinion talking about how this technology which shouldn't exist um when those laws were written satisfies that existing state requirement so when we think about implementation challenges like that one also comes to my mind any more questions on this but we we again see real value in this because um and Kayla you worked with hospital systems so you know that anything that saves a doctor's time or clerk's time is like bottom line and freeze up time for patient care right so if we can arm providers with the ability to use their verifiable credentials in a quick and easy fashion on their mobile device then they've freed up so much more time to do the things that really matter to their profession absolutely so how does this fit into the next step so you've verified the certifier of the so this is the person who's now been rubber stamped basically to submit the death record to the vital status system what are those submission protocols do they also does this then piggyback into another trust triangle for the submission process um or is this do you see this as them using a credential to sort of like log in both it could be logging into the the data entry portal okay for the vital record system and it can also be about the submission so you could have two potential ways to apply um decentralized identity for certifiers excellent yeah so i think this one you get not only is it more secure potentially better workflows for the um external data providers which helps timeliness of reporting um but you can also potentially get two sort of use cases out of one application okay and anything else these are all great comments they're really helping us like flesh out the the use case um value prop as well okay so then we're going to switch to what the trust triangle looks like for the public customers the people who are ordering the birth and death certificates so um here's one where it's a parent and they're getting a birth certificate copy for their child because often a birth certificate is required to do um school enrollment for your child at the local um school district level so in this instance the issuer is the health department um office of vital records and then the verifier is the local school district um and there there are already some jurisdictions some local school districts that do online enrollment but think about the sort of security and um vulnerability associated with like uploading a picture of your birth certificate to a local school district website that's no bueno so this switching to verifiable credentials would probably be easier from a resident parent perspective and it's definitely a whole lot more secure um so in this workflow you've got your digital verifiable birth certificate credential on the parent's phone and then the local school district can have some kind of like qr scanner that scans it and then the child's birth certificate information can get automatically ingested into their online registration system this is also a really great use case to highlight the selective disclosure elements of or zero knowledge proof whichever your school district wants to move towards um aspect of verifiable credentials because if the school district just wants to know okay this child is of age for this grade then that could be zero knowledge proof and if the school district just wants to know their birth date to automatically determine the grade or and their parents address to automatically determine their um um residency um that could also be zero knowledge proof or selective disclosure so there the there's generally two forms of the birth certificate there's the long form which has a whole lot of information like it has both parents names it has information about the mom's health status and the type of delivery they had um whether there were some newborn screening health um characteristics collected at the time of birth and the school doesn't need all of that nor would you want to share all of it with the school um so the short form is generally what people use for the school and the again the selective disclosure functionality with a verifiable credential allows the resident to really easily make sure they're only giving the short form level information or even less than the short form level information to the school district so we really like this use case because we feel it really highlights all of the capabilities around verifiable credentials Ivan did you have stuff to add uh not exactly I think on the verifier side it it definitely presents a lot of value for these schools I mean a lot of times when you're applying for different school you know programs or even just the initial application into the whatever primary school it is um there is a lot of friction there in terms of ordering physical birth certificates um and the presentation process of those physical birth certificates um so you know we've seen a lot of positive feedback in terms of in that application process you know if there is a process where you can get your birth certificate you know instantaneously at the same time you're applying for something um it just amox a lot of possibilities for the the local school districts and the parents I see Mike has his hand up yeah so uh this may be one of the most important credentials to be issued as verifiable credential bar none anywhere in the entire world for any use case period um so for example I've been doing work with passport credentials that's a use case that actually spawned the you know originally started with uh vaccine records but morphed into the trials in aruba for DTC passport stuff and to get a passport I've recently gone through the the process with my with my daughter we had to mail her birth certificate into a federal agency and then pray that it came back you know and so besides having the friction of receiving the birth certificate there's the fact that you know do I really want to put this and trust this to the mail system and um and like you were mentioning with all of the data that they may not need to know um so you know where birth certificates are not only required to go to school you need them for driver's license and a passport which are you know the the later on universal identities that people use um I'd be really excited about this becoming reality um this on the horizon or is this just a really awesome presentation about um the possibilities and the use case we we think it's on the horizon again there was a lot of um interest and um we did some really great um implementation um brainstorming at the napsis conference in april where this was heavily investigated so I do think that there are a lot of there is a lot of momentum on the vital records side right now in addition some states um and Ivan can go into more detail are really moving towards um their own policies and regulations around digital identity to begin with so Ivan I don't know if you want to talk about Utah's law that was just passed but there there's this sort of this confluence like vital records themselves is really interested in this and then some states are um approaching digital identity you know from a a whole statewide policy perspective I think there's there's a couple different things to to talk about there um you know you mentioned that birth certificates are kind of a foundation for both passports and driver's license and in reality is in the United States that um birth certificates have lagged behind driver's licenses and passports um due to simply their portability um in terms of how you can use the actual credential itself and what we recognize is that you know if we can take birth certificates and digitize them in any way even if you didn't use the centralize identity in any way um it makes the the birth certificate um and a lot of those other processes after the birth certificate like driver's license and passports much more efficient and much simpler and it reduces a lot of overhead and burden on both the state the resident as well as anybody that wants to use it so there is a very significant use case for this and like Sarah was saying you know at NAFSA this was the biggest topic of discussion here was how do we bring birth certificates and all vital records into a modern age and yes there are a lot of different states we've seen in Utah and Michigan and Rhode Island a lot of different states are really trying to push decentralize identity and recognizing that birth certificates are a kind of a genesis credential for just about everything so if you can solve birth certificates you can then use this to apply for you know your SNAP benefits or unemployment or you can use this actually as um the credentials intended to be that kind of driver's license and passports have taken the place up I would also add that um the input impetus in the field right now is even though we're behind on the vital record side compared to the DMV sometimes it's easier to do that leapfrogging to the more advanced technology when you haven't tried to go the intermediate route first so I feel like personally as somebody who's worked in innovation for a while now this might be the more ready use case because there haven't been intermediate digital identity solutions already piloted or rolled out and so it might be more ripe for decentralized identity adoption from the beginning for a confluence of reasons right like the cost to ledger stuff is coming down now I kind of feel like this is we're at this moment where um decentralized identity is very similar to the credit card chip technology where it was clearly the superior and more secure technology from the get-go but the cost to production was so high that you haven't seen mainstream adoption until like 20 years after it was technically physically manufacturable right so I feel like again if if there's this sense of urgency and momentum on the state registrar side and the state registrars have so many operational pressures on them especially post-covid they're short on staff they want to like offer their staff more flexibility and remote work options to keep the staff that they have they want to simplify their workflow and processes to be able to provide better customer experience and do more order processing because again that gets them more revenue the faster they can issue more certificates and then you have the cost to use decentralized identity technology coming down and they're not tied down by an intermediate solution that they've already invested in right there's no sunk costs in some of the dmv type approaches that have already happened so we might be able to do that leapfrog in this market and for this use case in particular I think it's it's very appealing and the timing might really work out fantastic I have one question on this flow and then we'll get to Mike's technical question one second so it this is very interesting that you brought this one up because we've been sitting at this space where we're talking about the intersection of healthcare verifiable credentials which isn't dissimilar from the vital stats data but also for example the school based health requirements and those could be credentials so if you start to pair these things together you really start to see the ecosystem coming to fruition with you know the birth certificate sharing but also the immunization record sharing and etc that we've been working on in terms of conceptualizing that for cardiac as our extension use case I totally agree with you and I think this school enrollment example is the perfect confluence of that where you can use the immunization credential with the birth certificate credential together to almost fully automate and digitize the process so the parent literally doesn't have to produce any paper for the school to get their kid enrolled like that really excites me and I feel like there's high potential here for this use case for it to be almost fully digitized going forward right Mike you have a question about the technical structure and I I heard you say selective disclosure which would lend itself to an on creds but where do you see this from a technical perspective going in terms of credential formats do you have any read on that yes well I guess no would be the answer so I guess in our discussions that we've had both at NAFSA and kind of around the country the focus right now is less on the the technical aspect of it like there really is a desire just period from a business use case to just digitize credential digitize vital records and we've kind of pushed this decentralized method of doing that but I don't think there is the conversation is ready yet for which standard should prevail kind of across the United States and the reality is you will see stratification in different states and what they choose it's not a it's not you know it's not one central location of course there will be the recommendations from the association so I would say we're probably not probably at least two years away from you know one standard emerging as what's going to be the standard going forward but until then you know I think for the next few years you're probably just going to continue to see pilots happen around the space to where that question will get answered eventually but I don't think is answered now and Ivan do you anticipate or maybe have nightmares about a state where that doesn't get a consolidated single answer and the states go in deviating directions around their specific technical standard in reality I think it will happen you will have deviation I mean you take even just driver's license today around the MDL standards you see what Louisiana is doing with their kind of homegrown solution which is super effective and works really well from what I've heard in Louisiana but isn't interoperable with other standards and I think the reality is the United States you will see that that's unfortunate we can just hope to come together I guess as a community and try to push one of them over time which everyone kind of gains the most popular interaction is you know the most secure and best for the use case but I think reality is you will see stratification that's unfortunate but with 57 different jurisdictions it's very difficult to come to one I will say that there's a potential role for the federal funding aspect of vital records jurisdictions to help steer people towards the preferred standards so the national cooperative data sharing program does provide funding for the states and so they can attach some guidelines or requirements around the systems that share the data with the federal government for that program and then the CDC also provides data modernization funding for vital records jurisdictions usually on a more discretionary basis but should they you know really want to dictate more in this space I think a grant opportunity would help move the industry in one direction if if there was consensus I'm sure Napsis and the CDC folks are talking about this but which is the carrot that provides an opportunity I don't know whether there's a corollary and the DMV side and whether that was even a lever on the DMV side but that is certainly a carrot lever that the federal government could help with right and it's interesting I heard you mentioned CDC right so that means that there because CDC is heavily involved in federal standards in in health care and other you know tangential health care spaces and so there is an opportunity for some mandates potentially in that flow down Ivan I'm so sorry did I cut you off you were going to try no no you're absolutely correct and it's not just to see I think the Department of Homeland Security is doing some work around this space as well in terms of trying to I guess find federal standards I mean we hope that that kind of work works between you know the CDC and them as well but I guess to Mike what Mike just put in the chat is going to be key I mean you're going to need to have software that's just going to work I mean the states care about the use case and the state cares about the outcomes and you know there if they want to interoperate with another state that has a different credential we kind of have to make it work and I think that's I guess early on now that we can kind of predict that that's going to happen based on what's happening with driver's licenses I think we just have to be prepared to support whatever whatever direction the state in the legislature goes down great I just want to do a quick time check we have about 10 minutes left I don't know how much more are you more how many more use cases you have here that you should delve into before we move on to the death use case which is the one we have the least fleshed out so far one more aspect of the birth use case is that the revocable credential functionality could be really applicable for birth certificates for example like you would you might want to revoke the parent being able to have access to the child's birth certificate once they come of legal age so that is another functionality that we feel like really highlights the birth use case are there also complicating factors around parental accessibility like if somebody's removed would that be a similar application of that use case I think so we have less investigation into that aspect but I do think that yes some of these complicated guardianship cases could be made easier for all involved with a verifiable credential solution yeah and I brought up guardianship in the comments I think that's a that's one of those it's been kind of interesting and discussing like how that should or shouldn't work from what my understanding of my feeling now is that it may not be like a technical level of guardianship I think what you said with the revocation and reissuance is significant the reality is today in a birth certificate is the parent gets the birth certificate and they hold on to it regardless of what happens so anything we do around guardianship is an improvement over the existing process so this may not be an area where you need to you know engineer you know a more robust guardianship I think just the ability to revoke and reissue is already a massive improvement over today's systems and just to add on to what Ivan was saying that would apply not just to guardianship but to amendments and corrections so often especially with different languages being spoken and some legacy credential or legacy vital records there could be a lot of manual errors that require manual correction to people's names and spellings and all that stuff and so again the verifiable credential where you can easily revoke and reissue could make that back and forth like a lot of back and forth happens between the supervising clerks and the issuing day to day data entry clerks because of these types of things and the public customer has to bring in you know proof of changes all the time and that's like a huge burden on them one of the really interesting edge cases that was presented at the NAFSA's conferences in April is there are people who are born in the U.S. to non-citizen parents and then go back to their home their parents home country without a birth certificate because the parents have never fulfilled the process or been able to get the birth certificate because they're not a citizen in the same way so then you have an undocumented U.S. citizen in a foreign country and the steps they have to go through to actually get the U.S. birth certificate is incredible very state by state often involves tons of lawyers and representation and so again figuring out a verifiable credential solution would make it a lot easier for them they're stateless people they're they're actually like not often eligible to even enroll in school in the foreign country that they went home to with their parents because they don't have an identity document so there's a lot of benefits to the birth certificate use case excellent okay so really quickly on the death use case um the issuer here is again the vital records office generally at the health department um your you know so your relative or or legal representative would be the the holder after the disease is gone and then some of the um verifier use cases um are include not just government but as we were talking about before a bunch of private sector functions so title search companies life insurance that kind of stuff and then government often hires um third party services to do program integrity for benefit programs so think about Kayla Medicaid or um social security pension benefits for any local pensions for for government ex-government workers and their beneficiaries so there there's a whole industry out there that uses the death certificates to figure out when to terminate benefits so there that those would be some of the um verifiers for the death digital verifiable credential for death certificates i think um from my own experience the the selective disclosure is super valuable here too because so many people don't need any detail they just need a fact of death which i know naftis has worked on for many years i've been engaged with that but it's been really tricky just to say is this person alive or not uh so that they can take their appropriate follow-up action they don't need the details of related to their death or even the date they just need to know like yes or no what happened here um so that plays another role into that selective disclosure on the death scenario as well and that people find death data to be very sensitive that makes a lot of sense um especially like causes we think about the opioid crisis for example right highlighting that they had a substance use issue is super sensitive data on the why they died yep or like thinking back to the AIDS um crisis in the 80s and 90s right that was that was a sensitive cause of death back then um as well um i think some of the exciting implementation nuances for this one is when you think about the verifiers in in the death certificate use case there's a lot of heavy IT investment already in like IV for these um entities and so figuring out like what makes sense to do as like standard integrations across industry fields would be i think some of the interesting um sort of scoping and implementation next steps excellent and so and there's that play in the middle again in terms of generating the death certificate where a medically verified person had to submit the reason for death yeah the certifier use case that we talked about applies to either birth or death certificates excellent does anyone have any questions as we come to the end of our session here Ivan do you have anything else to add on the death use case no i think it's i think it's pretty straightforward i i think the one thing about death certificates is that we're what we've seen is longer like times to delivery in terms of the death certificates as well like you know in certain states taking weeks or months to process those um so i think just from an operational standpoint um there is a pretty intense emphasis on making those processes more efficient um which is significant and the certifier use case would play heavily into that um timeliness for the death certificate as well right right absolutely okay excellent i think this has been really wonderful very very critical to the conversations we've been having here in this community and so we hope that we'll be able to connect with you guys again in the near term future um because i think there's a huge overlap in in sort of what cardio is focused on and from the health-based credential and how it intersects with these vital stats credentials so i found this very interesting that this is this is quite possibly one of the best meetings we've had most informative yes that we recorded it it was spot on so very very very relevant for what we've been working on and i really appreciate what you've done um i took a couple of screenshots from the of the interesting deck pictures i don't know if that's okay to put in the meeting notes and maybe there we can just put the whole deck in our review of the whole deck a pdf of the whole deck too um and then um we'll put a link to that use case document that i was talking about as well um and i don't know i've been anything else you can think of we should add based on this conversation you there's something uh was it the cdc uh use is every time with use case yeah the use case document yeah just just bear in mind that is supposed to be a generalizable one across all 57 jurisdictions and they all have nuances to that all of them levels in the details with these kind of things yeah yes it always is i think this has been really excellent and gives us a lot to think about and how we see the future and interacting in some of these spaces so again huge thank you to both of you really appreciate your time i hope we'll have you back soon definitely and hopefully everybody has a wonderful day i took a lot of notes people are welcome to go read them if you have any corrections feel free and um we will talk to you all soon in two weeks is our next meeting june 22nd we'll be sending out some notes on what to expect in that meeting excellent great thanks sir thanks everybody


Kusunbara m왔u wakama, habi ki chilu kajalijne kama ni hwiai kufunbara wako ya umao uko ya wako ya umao waka jajene wako jajene kufunbara katilufunbara fain our payments process our process payment function and we know that we're going to apply to the payments processing here so whenever our value is actually greater than zero then we run this function but from this api i've realized that you actually need to have a value that is above 1000 shilling but for now we'll leave it at zero then allow this to actually run so i'm going to paste everything here and then from that point on we shall be able to make it dynamic based on the information that is coming from our wukamas order so let's save this here and then we are going to start off to make this all dynamic so i'll just click to reduce all these functions so that it's a very short distance going back and forth here so we realize that there are a couple of things that we're going to need to add in our payment settings for example we don't always change our api key and our widget key so we're going to have to make some forms for them here i'm going to duplicate this let me just duplicate the description which is going to be easy so description i'll call this a api key so we'll have that and then i'll duplicate also the api key so that we can have our widget id as paste this out to make it even so we have that working we don't have a problem with that so i'm also going to set these same pieces down here i'll copy these paste them down here and then for our api key i'm just going to add a message let's say this is our api key so i'll copy this add it here and say add api key and then i'll do the same thing here and then i'll say add widget key add widget id so we have this incorporated the next thing that we need to do is actually add them here so i'll duplicate this twice and then we'll have this as api key and then this will be widget id so we need to backspace this so that we keep everything nice and neat when we need to see it and then in here of course we will change this and say add widget id so we'll call this widget id that's the title we'll call this api key then we just need to change all this information add your widget key of course here we'll just say api key then we'll take out the defaults because we don't have any default keys that will be applied at that point so i'll save this and then come back to our payment gateway of course we now need to go to the settings and see how that looks like and if we go to payments you don't have any errors that's the good thing here it shows that we've done everything properly and then we now have the new field for the api key if we click we see it tells us what to do and then we have also the widget id already here so what i'm going to do instead of having this uh looking at me at the bottom let me close this off uh i'll just save this so instead of having this uh just thrown here i'm just going to copy this and then save them in our database so that we can always just pick them from there copy this also as well and test them here and save changes when i save that you can see that they are stored i can change them and save settings again so that's covered so what we're going to do is actually just come and take this away this so instead of having this generated here i'm going to do this dash greater than symbol and then put api key that will automatically fetch it i'm going to get that and then also paste here instead of api key this time it will be a widget key so we have this information that will be dynamically needed to be added here um the next thing that we need to do is get our phone number we've been we had the phone number already sorted for us inside our payment when you look at the payment checkout we already have this post payment number as this so i just need to get the same thing here copy it and then come back here and change it to that so that we'll have dynamic information always coming in from our form so the only thing that i need to do is because i'm sending this to our api we need to cleanse it we need to sanitize it so i'll use a escape attribute a ttr i usually read as attribute but it escapes this and makes it clean for our api to receive but we can do more sanitization and validation to make sure that this is as it's supposed to be and then for this particular part we're going to need the order amount so i'm going to check our function here which we have here we already have the order id here uh we just need to get this order total and when we get this order total i'm going to pass it inside this argument here and then after passing this here we need to also receive it here so i'll just call it total when we receive it here we shall just call it total so i'll copy this and then i'll say amount is equal to total so instead of saving it as a variable here i'll just quickly go in this piece that we set up here and i'll just change it to total there so we no longer need that amount and again there so for now we can also change the api key and do the writing so api key change it here and then our widget key will copy it and also paste it here so that we don't need these pieces we are reducing our code and making it a little cleaner so the phone number we can also just get it from here but since we are sanitizing it and running it let's just leave it here so what we are going to do at this point is let's just try to run our function see what it says and then at the end of this we are going to actually just kill whatever it is or just print out whatever response that we do get we'll also be looking out to see what comes on our mobile so i'm going to go back to our order our order is just 300 shillings it won't work for us so i'll go back to our shop i'll add a couple of items and then after that i'll go to view we'll come in we'll fill in our form you can even use this phone number if you want to since we have our tutu here i'm going to choose a paleo mobile payments i'll put in my number then we'll take this out and just validate this number to make sure everything is working out well and when i click place order our order says it has been carried out but we seem to be having an error at this particular point so i'm going to just place die here so that after we've ordered everything actually just sticks and then we don't go any further than that point first things first let's first comment this out and then let's first vadamp what we have here which is our url so get this url to make sure that everything is actually working out well uh so we'll vadamp it let's just go and try to make our order so we'll place a couple of things here go to our view cut then we have our order one six to put in our number five six blah blah blah and make sure that it's all right so i'll just open my audit of this and i'm ready place the order we have called our Ajax here we are seeing what we have and i know it breaks because we have a vadamp in there but if we look at our url we have this coming out well we have of course our api key working out well we don't have our widget so we know that's not going to work but we have our phone number coming out well we have our amount is missing we don't have a the company mobile is okay the reason is actually okay so we need to get two things we need to get the widget id to work we also need to get our amount to show up here so first things first is a widget key does not exist because what we have here is actually widget id so i need to come back down here and make that correct and then the other thing that we didn't have was the amount the amount we're going to get the order here so for my reason i am just going to get the order id and say payment for order id so we'll just change this here and say our reason is order id we're going to just chain on one thing in brackets chain that on so payment for order that and then we'll chain on our id that will be our reason so we need to also get the payment uh total so in here we shall pass in the order that we get and then we shall filter to get the order total from this point order here let's see if we get the order total so total will equal to the order and then we shall get our total on that gauge total do that so we can also decide to add up this see what happens copy this that let's see what happens so we'll go back to our order reload this come back down feeding our value because it will break everything look at our console place our order look at our hctp request we now have our api key we have our widget key we have our form we have our amount which is really good however it has two dots on it uh i probably don't want the two dots on it so i could sanitize it to be different but we can also see here that we have verdant it as zero zero here so for my case i am going to actually make this an integer so it will have to remove all the other pieces uh on it so make this int val and then i'll have this as int val but since it's working out well i'm just going to allow it to actually go to our api for the first time and let's see what we actually get so i'm going to go back reload this we have our order which is our order which is over 1600 it's better than what we required the api place the order look at our ajax going we have our request on our phone to pay and our sms has come to pay and then the api is just waiting to get a signal from our site to see if we have made a payment so if i make my payment and it is approved i have a payment of 160 on my phone you can see that and then of course we have an error showing up on this side but we now know that we in our api if you look at this this payment has been successful we'll see that we get back a response a message which is saying thank you this was successful we have all this in our our contents i'm going to copy this and then we'll filter it to make it possible to say if this response that we get was successful then this is what we should do maybe we should change our order status to payments have been made if it fails then we say the order status should be payments are pending so i'm just going to dump all of this here the reason why it failed to complete to have this is because we left die inside our function so i'm going to take this out and then i'm going to add our code that we get here it's not the best thing to do probably we just want to get the message that we get here we also need to know the response which is a 200 the code is 200 and then that will be all we need to have so i'll just undo this and just have this inside a notepad to make it easy for us to follow along so i'll just press all this information here and then we're going to get a couple of things so first and foremost we have to get the response code and see if it's 200 then we go if it's not 200 then we fail the whole process we just say you know what the payment has actually failed so we're going to use a couple of things that come by default one press and that is things like the response we're going to use the the wp remote get remote retrieve body that is one then we're also going to get the remote retrieve code and we shall get it from here so everything else will work out if it's an error we do that and then we return if that's the error otherwise let's go the step below and what we are going to say if 200 which means that it is okay we'll first start off if it's not 200 if our remote response code is not 200 then that means we have a problem so we need to return and say we have an error so we return and that will automatically show our payment gateway that there is actually an issue so we can even decide to echo what the problem is and then just throw it off so I'll just copy this and then serve this because we need to close this properly that's why we're having that error so that's the first fail if everything works out actually if it's not 200 this is how it should be not like this if it's not 200 then we should fail please note that this is just an exclamation mark and two equal signs but because I'm using font link it adds them all together to actually give us that piece so I'll take this out so if it's not 200 then we have an issue let's return we can even return this message right here and save some space not much it's negligible but that is it so we'll copy this and just do the something save here then if it is successful I'll just make it really typed to show that it is the issue but we don't to have that so I'll copy this if it's 200 and it is right so we just need to add three equal signs that if that is the case for us then what we are going to do is we are going to get the remote retrieve to also make sure that everything worked out well so we can also come in here and say if the remote retrieve body is saying blah blah blah then that it was okay so the body is going to have the message it can also return the metadata if you look at the metadata here it can return it because our API told us if you want to have any other information coming back you should write metadata so we can always pass that along if we want it but for my case probably not so if this field of body if our body has this message so we are going to chain on this message here so if we remote retrieve body and we are going to get we're going to chain on the message that's what we need to get if the message this message that we're getting here is actually equal to it's a string so we can even equate it to that and say if it is equal to thank you blah blah blah successful uh we'll do this yoda style to make it work out so if it is that then that means three equal signs if that is that so let's first escape let's first get this and say this is our response body so response body equal to this part and then we're going to say we're going to look for one part there we're getting body if this is what we are looking for so if if this is what we are looking for then what we are going to do is actually come here and say it was cleared so the order is complete so order payment is complete uh if it's like all the other cases up there then we are going to instead of just returning we shall just say pending payment so we shall use what we had here so we just say the order is actually pending payment it's invoice pending payment and then we shall also do the same thing here is an error so we can sort of record if we want we can record the order or we can just decide to fail it complete so in this case I will uh just say it's pending payment and then here I will pass it and then we'll clean out all these parts so for this point I'll save this and then we're just going to try one more order pay it first of all we shall fail it we shall refuse to pay see whether it goes in pending payment and then after all we shall also order to see if it actually passes so let's just do that and see what happens so we're going to go back come back let's make some new orders uh I'll just vardamp this I am not so sure of what we're going to be having here I'll just vardamp it so that we can see what goes on in there and then we can work according to it accordingly so I'll vardamp that uh let's see what happens so go back to our shop or go to our shop uh make some orders to pieces this is 1000 go to the view cart everything is working out where we fill out our order this is 26 means so much items let me just I need to go to the cart edit my cart uh remove a few things that take out that uh make these two update cart and then proceed to pay out our order details are filled in we have that I'll put 26 fill that in place our order let's see what Ajax gives us what our response is we have that showing up we are failing it for the first time let's see the response that we get we have failed it just waiting for it to time out come back tell us just waiting for a few seconds 45 to be exact so we got a response back uh clear the order that is a problem in our code here we need to check uh why it clears the order is received let's go to the back end and see how that appears so it goes to paying payments which is really good and clears the order it's paying payment but now we need to check uh when we actually pay for the commodities so let's go back and then see uh what happens when you actually pay for the commodities so shop let's go to the shop uh get our 500 another go to pay go to review that our mobile payments 25 blah blah blah this time around we are actually going to pay the order so let's go wait what comes we'll wait to see our response so waiting for api comes we get the message we are now paying and then replying fill payments are done we've approved the payments and then we get our order back we see our response gives us it's cleaned out this is doing so well let's go in the back end look at the orders and it's paying payment so we just need to see if we have an error in terms of what the way we receive this object it's supposed to we're not supposed to chain it but rather we're supposed to get the message like this so we'll paste our message like that same thing for this so i'll just copy this then paste it here to see what kind of message we get save this uh let's try it again um don't get ahead of losing some money that's why we have sandboxes to help us fix all of this so i'll pay this to the shop go pay for a few items i'll go to the cuts preview it and then i'll make my payments 256 blah blah blah come to place the order and now we are waiting for the order see what comes back in our response we're going to pay put in our code messages come reply positively the key is working out well our order is received let's go let's come back to our orders in the back end so when we come back to our orders we actually see that this is processing so our payments actually going through and this is working out well so try it out on your api see how you handle your data let me know if your processing is working out well try it out don't fail when you get some errors keep trying over and over again depending on the response that you get on your api so our api is actually processing it is in good shape and we are having what needs to be done so thank you for watching the video if you enjoyed it please give it a thumbs up share it with your friends and of course don't forget to subscribe because we have more interesting things coming up for you


I'm often accused of reinventing the wheel when I'm doing things like building another boat. And I think it's a little bit of a ridiculous thing to say because I'm not big on catchphrases. But okay, I understand the sentiment and I'd like to address it because I think it's an important thing. So the question is, why am I always reinventing the wheel? Well first let's take out the garbage-y catchphrase part, not reinventing the wheel. What I'm doing is building something, taking it apart, rebuilding it, testing it, taking it apart again, rebuilding it, building another thing that does the same thing but better. Testing that, breaking things down, getting a broken thing, putting things together, figuring out better ways to make things happen. Trying things out, trying to figure out how to make, just how to make everything like ideas, objects, machines, just everything in my life work better. Now the common response to that is, oh no, you're not supposed to do that. There are factories and big companies and they do that for us. So you just need to go to the store and buy the stuff. Well if you look at the world today, you can see all that stuff these companies and factories are building because it's like floating around in the ocean and filling up garbage dumps. We have a disposable culture because of this. See this mass produced culture we have gives us convenience at the cost of innovation and improvement and real quality of life. And the worst part is, it's always short term convenience. It ends up being much less convenient when you're just surrounded by mountains of garbage. You don't know what to do. It's an inconvenient thing.  So we've got these companies, you know, producing all this garbage and pumping it out into the world and people buying it. Meanwhile, there are like a billion people who could be innovating and creating and inventing, coming up with new ideas to make the world better, your lives better, anything better and instead of doing that, they're watching TV.


time for some change. I've got some pretty substantial changes coming up with my photography.  What I am going to do is change my gear a little bit and I just shipped off my medium format, my Pintak 645 in. Kind of broke my heart to do it, but with a lot of time to think over these last five six months it's more important to me to have a bigger negative and a little more versatility on the other side. So Nori and I are out exploring a new area. Not sure if I'm gonna find a photograph here today. I won't have a couple hours. We're in an old growth forest and I just wanted to kind of take a look see if there's anything out here I want to photograph. Of course Nori is my little companion today. I feel kind of like a flake. I watched my last video on this subject when I had convinced myself that all I just needed is a couple more lenses for my Pintaks and I could just settle on that system and and it would be like a middle ground something to use for everything. But it's become clear to me that I just can't use one system for everything. And I found that the Pintaks although a joy to use and I just really it was just a really great camera to use. It really wasn't it wasn't the best at both things I'm looking for. It wasn't most versatile. It wasn't as compact as the 35 millimeter setup. And the negative was not big enough for some of the enlargements that I'd like to do. So this week I just decided it was time to pack it up and I send it off to KEH with the plan of getting a large format body to start with. I have a lens right now and some film holders. I'll need to get a development tank so I can process my own film and then fill out a large format kit with which will just basically be two or three lenses. I don't see myself need more than that. And then on the other end I'll be using my 35 millimeter either film or digital. It just depends on the shoot. I'm going back to using a system or approach that I kind of started out with years ago. I would take my 4x5 camera out and I would find something I like to shoot. I'd photograph it but I'd also have a long SLR and I used its meter, its spot meter and I would take backup shots on 35 millimeter just in case something happened to my 4x5 and because 4x5 film is pretty expensive and it hasn't got any cheaper. Come on Dory. So I'll have the 35 millimeter either digital a digital file or a film file to back up my 4x5 and starting out I'm not gonna have a lot of lenses so if I need a certain focal length for a shot I will most likely have that in 35 millimeter if it's telephoto or a little wider angle. Then eventually I'll have probably the wide angle covered and maybe a short telephoto. When I can afford it I'll shoot the 4x5 when the conditions are right when it's not too windy but then when it's I don't have to stop shooting if I've got my 35 millimeter so if the conditions aren't right I'll pull out 35 millimeter and use that. I've come to the conclusion that 35 millimeters is good enough. It is smaller than the 645 negative-wise but for the sizes that I use most of the stuff for zines and book size photos it's quite capable and I did prove that to myself with the gear I have. So really for me to shoot 35 millimeter is really is it kind of freezing me up to do things that I really just couldn't do in medium format. When I look at the photos I've made for the last couple years in medium format. A lot of those high percentage of them could have been shot on 4x5 and I have a much bigger negative to work with. So I don't think giving up the medium format is going to be that detrimental to my photography. I think it's going to be a major change from the way I was working. It will be you know carrying two different systems but I've done that before so it shouldn't be that shouldn't be that big a deal. Now this decision has no bearing on how I feel about the Pentax 645 system. I find that very capable camera just a joy to use. In a lot of ways it was like using an SLR 35 millimeter. It's just a little bit more bulky and it it's not something I could use with 4x5 where I know I can put together a pretty compact 35 millimeter setup to use with 4x5 and I really want 4x5. I want that big negative. So something had to go and that's that's the Pentax just has to go. I will probably regret it but I I'm looking forward to working different. It's probably going to take me a while to get set up with the 4x5. I'm leaning towards the Intrapid just because it's really light. It's not as stable as I would like but I know that going in I'm not new to large format it's just been a long time since I've used one. And down the road there's nothing that says I can't go with something else but to start out to get it back into it I need to go pretty affordable. The only thing that I've got to work out still with the 35 millimeter is how I'm going to scan the negatives. I'm not real happy with the flatbed scans so I'm gonna have to figure out how to do an SLR scan. I don't have I don't use Lightroom so I'm going to figure out a way to invert the files with the software I have or get an app for it that if I can find an app that allow me to do it. So that's the stuff I've still got to work out. So when I do shoot 35 millimeter film I still need a way to get some good quality scans. The transition into the 4x5 should go pretty well. It's just gonna take a while even if especially if I order a camera from Intrapid it's gonna take six to eight weeks you know just to get just to get one. This location hasn't been very fruitful as far as compositions go. I haven't found anything really nothing that I really wanted to make a photo of. Oh look at that. Now what are you gonna do? No stay. I think we're too high for the autumn color which I'm not really interested in the color but the light foliage would be nice contrast against the dark woods. So I'm hoping for some of that in the next couple days while there's still a little autumn left. I think I'm gonna have to drop down elevation just a little bit. So we're just trying to set something up so we don't leave empty handed today. These are beautiful trees it's just a finding angle and a clear enough view to actually take advantage of them. On this shot I'm using a 20 millimeter. It's probably just a little bit wide for this location that I'm in. Well I checked another frame. This time I moved up the hill just a few feet and put a 50 millimeter on. Kind of focusing more on this just tree right here on the left. It's just brighter than the rest of the tree so it'll probably texture on the bark should stand a little bit better. The woods kind of get darker as they go back in there. Well I think I'm going to in this video here. I didn't find a lot to photograph but I just I did cover some ground as far as what the plans are in the future. And I just wanted to let you know of my gear change. I'm not that really matters anybody but there will be some changes in the channel in the not too distance future. And I think tomorrow we'll go out and find something to photograph. We'll do a little vlogging tomorrow. But it is pretty neat to walk amongst these old growth forest.  It's pretty cool. I've never been here before. It's only about 40 miles from home. I didn't find a lot to photograph but that's probably on me. Oh wait a minute. What is this? Is this a shot? I love this way this vine comes over this log. Check this out. I don't know. Maybe a detail shot. I think maybe I'll photograph it before I leave. I'll stick at the end of this video. So until next time, thanks for coming along for the ride.


All right, so fish comes up and hits it. You pick up the rod, the fish isn't there. Go ahead and just dump him. You'll be able to feel the fish start hitting it if he comes back at it.   Just slowly pull it forward, not a hook to fish. If he's still, that missed it again, you can do it again or you can just stop. It's probably time to do it back out. Yeah. Oh yeah, here he comes, ready? Here he is on the long rigger. Where is he? Right there, he just came in, he came in hot, jumping. Here, Alex, wrap it, I'll be right back. Woo!  Yeah, a little bit. A little bit of a run with it? No, try to just give him a minute. Don't put too much pressure on it, just give him a minute. There you go.  Oh yeah, he's surfing. All right, slow it down just a little bit, Shane. First all, finish it. Yeah. Good. Just keep that one tight. That's a nice little workout. That's a good workout. Yeah. He's right there.  He's tired, look at him. You don't ward him all out. He wants to headache a nap. Now he's gonna come in here and mad at himself. Look how pretty that fish is. He's good at calling. There you go. Nice, nice and easy, good job. He just fit up a whole gallon of water. He came into the boat. First mahi. He's gonna let him out a little bit. He looks more better when you hold him out. This is awesome. Geez, the power on this thing. Yeah.