There's a popular saying that's attributed to Phil Carlton. There are only two hard things in computer science, cash in validation and naming things. Don't worry, I don't have a clue what cash in validation is and we're not going to talk about it, but I can't tell you how right he is about naming things. Throughout the past 30 or so episodes, I've been working on a project that I've since realized I didn't name correctly. In today's episode, I'm going to refactor my code to reflect a better name and we'll talk about how our reproducible practices of using make and version control can help us out. But before we get going too far, I wanted to let you know that I'm Pat Schloss and this is Code Club, where we learn about reproducible practices to improve our data analysis skills. Please be sure to subscribe to the channel and hit that bell icon so you know when the next episode is released. Alrighty, let's get going. For the past 32 episodes or so, I've been investigating what I've been calling Amplicon sequence variants or ASVs. ASVs are the rage in microbial ecology right now. People want to use each 16S RNA gene sequence to represent a different bacterial group. As we've shown, there's a significant risk of splitting a single cell in the multiple groups because a genome can have multiple different ASVs. Furthermore, we've also shown that an ASV can appear in multiple species. Not good, eh? To do this analysis, I've been using data obtained from the RNDB, which provides the 16S RNA gene sequences for thousands of bacterial genomes. Because we trust those genome sequences, we've been treating each sequence as a distinct ASV. The problem, though, is that in actual application, like if I'm sequencing 16S genes from a soil sample, I don't have as much confidence in those data as I do from the genome sequences. So when people generate ASVs using popular tools like Data2, U-Noise, D-Blur, or Mother's Own Precluster, they allow it for a bit of slop to clump together sequences that are within a few bases of each other because they know there's some sequencing error. Who cares, right? Well, there's conflicting jargon in the field. Some call these things Amplicon sequence variants or ASVs, as we have been, and others use exact sequence variants or ESVs. I think most people use them interchangeably because they haven't thought too deeply about what the names imply, and they haven't really dug into the methods. Considering the methods allow for some slop because of residual sequencing error, I will start referring sequences from the clean genomic data that we've been working with as ESVs because they don't allow for any slop. The other data that has some slop will call ASVs. In the next few episodes, we'll go on to looking at how we can include some of that slop in those units, which again, I'll start calling ASVs. We'll talk about how we'll calculate the ASVs in the next episode or two, but to get ready for that, we need to replace ASV with ESV throughout the analysis. I'm sure people are closing the video in droves right now and running away from YouTube. Hold on! Although there's a lot of find all replace all to make this change, we'll also see how we can use make and get to help us refactor our code. We'll see how we can convince make to keep our intermediate and secondary files, how we can use patterns to tidy up our rules and make, and how we can use phony rules and make to build a bunch of targets all at once. We'll also use get to protect ourselves in case we get overzealous and changing or deleting anything. Please check out the blog post that accompanies this video where you'll find instructions on catching up, reference notes, and links to supplemental material. The link to the blog post for today's episode is below in the notes. As you see, I've already created an issue for today's work that we're going to refactor the project to indicate that we've been working with ESVs rather than ASVs, and then we want to use the refactored code to go ahead and rebuild everything, regenerate all the data and all the analysis. In future episodes, of course, we'll come back and we'll work with ASVs. Okay, so we're going to create a branch for our issue. The other benefit of having these issues is these issue branches is that if I royally screw everything up, I can burn the branch to the ground and I haven't lost anything. Of course, we can do that with anything and get even without those issue branches, but it's kind of compartmentalizes our changes a little bit more. I'll go ahead and use Adam to open up where we are for today. So within Adam, I'm going to do some kind of brute force across the project changes. And we'll do that with the find in project. So if you do shift command F, that will open up this tab. And so you'll know you're there because it says find in project. And so in the project, I'm going to do ASV, all caps, and I'm going to click on these letters over here to match the case. And I'm going to replace that with ESV. And I'm going to put in exclamation point dot start up MD. And so this should change everything except for the markdown documents. Those I don't really care about because I'm going to end up deleting them or regenerating them anyway. I can do find all. And we said there's 60 results and five files. So if I click on these little triangles or pointers, I see that those changes are in my exploratory files and may read me file. So I'll go ahead and change those. I guess. And then I'm going to do ASV, ESV in lowercase. Find all, replace all. Of course, doing this one by one would just be horribly painful. I think there's also some in my R script. So if I search then in my start out R files, maybe I'll remove the case sensitivity. Doesn't seem to have found anything in an R file. Maybe if I'll do code forward slash R. Nope, doesn't have it there. Okay. I don't quite believe that. But I guess maybe it already had done it. Oh yeah, because I said don't change things in a markdown file but change everything else. So we see here convert count table to tibble already changed ASV to ESV count unique seeks did it here as well. And one of the nice things about Adam is that if things are under version control, it's turning things that have changed to this kind of brownish mustard color, right? So that is good. So I want to double check my read me file because in here I had said how many ESVs and so I want to say ESVs or ASVs kind of getting ready for looking at ASVs. And I think this all looks pretty good. I've got some extra text here that I think I'll get rid of. I'm not sure what that was even about. I'll save that. This all looks pretty good. Oh, I changed the title to utility of ESVs and ASVs. Okay, so I'll save that close that. So one of the things that I'd also like to do is if I look at data v19, I see that I've got these R&DB count tibble files. So I'd like these to be rndb.esv.count tibble because down the road we'll also have ASVs. And so I'd like to be able to keep two separate files. Maybe we'll wind up joining them together. But for now I want to work with those as ESVs. So I think I set those in my make file. So we create the file in count table to tibble. And this takes an input file name and an output file name from our make file. And so if we look at, where was it? Convert here, then let's see. This could be ESV.count tibble, and that's in processed. And we'll do the same thing here. ESV, I'll do some copying and pasting. That's pooling. That's the pooled file. And here is the individual files for the individual regions. So I'll do ESV.count tibble and that all looks good. And so perhaps we need to modify countuniqueceaks.sh. Double check that. And so that takes in the target. So it's taking the name from the file. And I think that is good shape. And I think everything is good there. All right, so we'll save that and we'll save our make file. Now, one of the things that we need to do is there's a lot of stuff that we need to clean up. So again, if I do get status, I see I've modified all these files. And something I notice is that some of our exploratory files have ASV in them, rather than ESV. So I can change those by doing get MV. And so by using get with MV, then we're keeping track of the old version of the file. So get MV this to this, but I'm going to change this to the A to an E. And that was the coverage one. And so we also want to change tax overlap and return that second ASV to an ESV. And then there's one more here, this commonness and dominance one. And we'll change that to an E. And I think we're good. And we can see that it's now keeping track of the renaming. Very good. What I'm going to do is I'm going to go ahead and commit these changes. And we can always revise the commit. But what the commit allows us to do is to potentially roll back any changes to this point going forward if we just totally botch everything up. So I will go ahead and do get add exploratory everything an exploratory my make file my read me a RMD file and my code stuff my code. And so that's all staged. So I'll say get commit dash M rename files from ASV to ESV and maybe not files but rename ASVs to ESVs that I forgot to close and quote. So I'll put that in. And as we see from the my ability type as we see from this issue 33 tag it's green. So everything is good to go and we're in good shape. All right. So now what I want to do is start burning things down start deleting things and so let's go ahead and remove data that's in the variable regions and the things that start with R and DB. So I'll remove all that. And so if I look at data before say it's empty and if I look at data processed I want to get rid of that also. So we'll move data processed R and DB and I also want to get rid of all the exploratory stuff. So you might say well maybe we should keep that stuff under version control to kind of updating the changes but we effectively are because we're going to be regenerating a lot of that stuff. I guess those files that went from ASV to ESV will be gone but that's cool. So what we can then do is remove exploratory and then start at MD and so that's anything that ends with period MD the rendered files as well as I'm going to RM-RF and so that's recursive and force exploratory anything that ends in files. So that's all the images that were there. And so if we look at this we see a lot of stuff got tossed and so again this is why I really like using git status because I noticed that I'm accidentally removing my readme file so I can do git restore exploratory readme and my autocomplete tab isn't working because it's not there right.md and let's make sure that everything looks right. So all these things I've just deleted we should be able to regenerate using make and if I open up my make file you'll recall that whatever I made one of these new rules I got a little bit uneasy because I'm basically repeating the same chunk over and over again but changing the names of the files. At the top of this I have a little reminder of how you write a rule in a make file. So you have a target so like the file you want so say I want this data references silver seed reference alignment that's the target that's what we want the computer to build and then after the colon we have all the prerequisites. Then on the next line after a tab we basically have the instructions for going from the prerequisites to the target call that the recipe and as I scan through here you'll notice that in various places I have these percent signs and up here we'd use those percent signs to represent the different variable regions that we wanted and so that is kind of like a wild card and a special kind of wild card in make. So what I am going to think about doing is if I do the percent sign.md so basically match anything that ends in .md and I'm going to then as a dependency require that same pattern but ending in rmd and so that will take our markdown document and render it to the markdown document and I also then want these two files which I'm going to copy and paste up here. You may be notice that this first rule doesn't require the genome ID taxonomy file. If I over specify the prerequisites it's not a big deal. The other thing that you'll notice is that at the end of these lines where there's a lot of prerequisites or the names are quite long. If you put a backslash that allows you to continue the line. Then what we will do is I will copy this rline and we just want one tab and we're going to render not that file but we're going to use one of the automatic variables which is the less than sign the one with the small sign the small edge next to the dollar sign and what that does is that means take this value whatever it ends up being and shove it in there right so we'll go ahead and save that so what I'll then do is I'll go ahead and delete all this text and save it and you might be saying well we've also got this rule here for creating a readme.md file so what make will do is it'll look for the most specific target first and then use that rule and so for all of our exploratory files it'll come back and it will then use this so you might need to revise this again in the future but we'll see something else that stands out to me is that we don't want rndb we want rndb.esv.countTibble and so that matches this target here and of course then we're going to want to change all of our markdown documents to also have esv so I'll go ahead and open these up and I guess I could have done a find all replace all but shouldn't be too bad to go ahead and modify these so of course we're going to rerun everything using make and if we run into any errors it will definitely tell us that there are errors um in a way this refactoring is good because it's forcing us to make sure that our work is reproducible right we should be getting the same results that we had initially after we've refactored everything the refactoring should not change the results because we're not really changing any of the code we're changing what we're calling things okay good so we've seen how we can simplify that long list of like six different rules we had for generating those exploratory data files and so we are in good shape um let's go ahead and think about how we would go about regenerating uh saying one of these files so I'm going to copy this first exploratory file that I deleted and I'll do make dash n space and then the target and that dash n is going to tell us everything that make needs to run to regenerate all this stuff right um one of the things I notice at the end of generating that is that it then goes back and deletes all of the dependencies it had to create okay and so again remember make was used was created to compile source code to create a final executable and there's no reason when you're creating that final executable to keep track of all the prerequisites right or the intermediate targets or what they call secondary targets for our data analysis we'd like to keep that around so what we can do is at the very top of of our make file I can put dot secondary with a colon and so this is a special rule that's built into make and this will this one line just dot secondary colon will tell make to keep all of the secondary files so now if I redo that make dash n we now see that we no longer have that remove line right so we ran the same code all we change is that one line and that remove goes away so this would generate everything to then create generate all of the files we need to then generate this output file okay so one other thing that I want to show you about make before I do that is that it's possible to create what are called phony rules and these are rules that don't really have a target and don't necessarily or I guess yeah they don't really have a target right so what you'll sometimes see when you're compiling code is you'll say like make all or make install and that is not a real you're not creating something called install or all or sometimes you'll do make clean you're not creating something called clean you're following the rule called all or clean and I'm going to create one called exploratory exploratory and it's going to be the target is going to be called exploratory and then the colon is going to be all these md files I I deleted and so maybe what I'll do because I'm a little lazy I'm a lot lazy so I'll do get status and I'll pipe that to grep and I will then pull out all the things that md and okay so the backslash forces it to be a period rather than a meta character don't worry if that's over your head I'm going to copy this in here and get rid of all that deleted stuff and I'll go ahead and tab these all in a notch and I'll put the backslash at the end of each line too many there save that and now if I do make exploratory it says nothing to be done for exploratory the directory and oops it's running I didn't want it to run ah so if I do make dash and exploratory it will then run all these things one of the concerns though is that exploratory is also the name of a directory as we saw and so what I'd like to do is use another special rule called dot phony okay and so that tells tells make that exploratory is a phony target it's not a real target to be generated and and so now if I do make an exploratory it will then regenerate all these things I think I hit control c quick enough before all this stuff got very far that I didn't cause any problems I think it got into v19 so I'll look at LS data v19 and I see that I still have some stuff there so I'll go ahead and remove that rndv stuff and again if I do make an exploratory it says doesn't have a rule to make ah this asv species coverage needed by exploratory so let me um ah when I copy it and paste it I left in the asv so I'll save that look at this and now the error messages go away I think it'll work so I'll go ahead and do make exploratory and this is going to take a while to run so I'll run this and I if you're if you're doing this alongside of me that's awesome um I'm going to do some creative editing so that we don't just stare at a blank screen or watch the scroll here for a few minutes while it's running and you're looking for something to do instead of going um and reading the web or checking your insta your facebook or twitter accounts um go ahead and like and subscribe this video be sure you click on that bell icon so you know when the next video is released um and we'll be back in just a couple seconds through the wonders of editing so it appears that we ran into a bit of a problem um processing through the v19 data and if I do ls-lth data v19 um I see that there is count dot tibble but esv count dot tibble doesn't exist all right so let's double check um where we generated that uh so that's there rndb esv count dot tibble um and it was coming out of code count unique seeks dot sh so let's come up code count unique seeks so it springs in the target it generates the unique file and uh I think our stub might not be happy so let's practice let's try this out running the code through um each line and so I'm gonna so I think instead of now that I think about it a little bit more that I don't want it to I don't want the target to be dot esv dot unique a line um I want the tibble file to be dot unique dot esv so this where I run the convert count table to tibble dot r that should output esv count dot tibble I think this should work now I'm gonna go ahead and give it another run um and we'll go ahead and do make exploratory nope without that forward slash and we'll see how things go all right so it looks like we ran through and got to rendering the exploratory data analysis files there were no other errors uh further up that I can see but it hit this first one and it's complaining that this file doesn't exist uh the esv dot count tibble file doesn't exist in data processed so let me look and see what's in data processed and I see sure enough rndb dot count tibble um so let me go back to my code and this was generated in the combined count tibble files and let's see I see sure enough we had rndb dot count dot tibble that should be esv count tibble let me double check in our make file that we have that so that's right there so I'll go ahead and remove data processed rndb count tibble and then if I do make dot n exploratory again without that slash um we see that I'll go ahead and combine it and then I'll re-render it so again fits and starts but because we have make it allows us to figure out where our dependencies aren't quite where we need them to be and how we need to modify our code to get it all to work smoothly all right so we hit another snag here um in generating the first of the exploratory files so I'm going to go ahead and open up that r markdown document let's see that was 10 5 I guess it wasn't the first one um I'm kind of wondering what happened with these others that they they went through so okay well if there was a problem here so maybe there's a problem with my code so I'm going to start by um doing something a little bit different um I'm going to run r from the terminal here we could do it in our studio um for these types of things where I'm trying to debug things in my make file um I like to it's easier for me sometimes to do it in the terminal and it's just good to know how to do it so I'll go ahead and copy and paste those in let me look at metadata esv to make sure that all looks good um and one thing I notice sure enough is that this region column is supposed to be a region but it's actually um text it's it's the file path I think so if I look at metadata esv um select region I have the paths and so that tells me that um something didn't get parsed right when we pooled the data so let's look back here and we see sure enough um you know we we parse out the region here in this parentheses and so I need to have rndb.esv.counttable there uh let me quit out of r we see all the stuff we've changed if I do make make dash and exploratory that we see everything that needs to get rerun and so we'll go ahead and do that and hopefully this does the trick well wonderful it looks like everything finally went through without a hitch no errors and we're in good shape so that makes me very happy let's go ahead and do get status to see where we're at I'm mainly looking at these deleted lines to understand maybe what have we deleted or gotten rid of um that we didn't intend to right um and so those all look pretty good um one thing that occurred to me as I was running all this that I don't know that I did update is my readme file uh so if I do not get make readme.md uh that needed to be re-rendered okay so everything looks good and like everything's been updated um again the value of having version control is that uh we've accidentally deleted something like we saw before with one of those readme files it was easy enough to do get restore and to bring it back to life so to speak so I will go ahead and do um add all this stuff so all that stuff oh I guess I didn't add the code or the thought I didn't oh I guess because it didn't like one of the arguments it didn't like all the arguments so I'll do get add make file readme.md and code good everything's added um I'm gonna add this to the previous commit because I think everything looks great so I'll do get commit hyphen hyphen amend this brings us um into nano um and I'm gonna say rename asvs to esvs and regenerate all data okay and save that exit and work good um I need to amend that again because I want to say closes number 33 and then we will do get checkout master get merge issue 33 um because of the way that timestamps work on version control on get when you merge a branch like we just did um that actually screws up all of our dependencies so we wanted to be we want to double check that everything was right we wouldn't want to rerun now make exploratory I'm not going to subject you to watching that or sitting through that again um everything will work uh so I'll go ahead and do get push and uh life should be good from here on in so again uh not a big concept that we covered in today's episode I was changing the name from asv to esv throughout the project and that gave us a good opportunity to delete all the intermediate files and then to see how we can use make to regenerate those intermediate files make sure that they don't get deleted um and make sure that we've got all our dependencies set up correctly so that if we rerun it then everything would work well maybe in a future episode what I should do is accidentally delete my whole project directory and show you how I can do a get clone where I get a copy of the repository from get and then I can do make exploratory again and regenerate everything so again this combination of version control and make are really instrumental to me for my doing a reproducible data analysis and I hope you find the same thing so keep practicing these concepts don't be afraid to make large overhauls of your project again using tools with like make and get will make it a lot easier and a lot safer so please tell your friends about these code club episodes of this is your first one welcome feel free to go back and check out previous episodes we're going to keep going now talking about amplicon sequence variants for real um and how we might generate those using the genome data that we've gotten from the rndb so we'll see you next time for another episode of code club


Hello, everyone. I'm really excited to introduce our next speaker. Mr. Mu Chengcheng is Director General of the Digital Currency Institute at the People's Bank of China, where he was appointed in July 2019. Mr. Mu joined the People's Bank of China in 1995. From 1995 to 2004, he worked for the International Department, and his responsibilities covered multilateral and bilateral cooperation with international organizations and foreign central banks. From 2004 to 2006, he was Senior Advisor to the Executive Director of the Constituency Office. In 2006, he rejoined the International Department. From 2010 to 2017, he served in a number of positions, including Assistant to the Governor and then the Deputy Director General of the Executive Office. In 2017, he was appointed as Deputy Director General of Payments and Settlements Department. Mr. Mu is a member of CPMI, a member of the FSB Financial Innovation Network, and also a member of the IMF's High-Level Advisory Group on Finance and Technology. Mr. Mu graduated from Renmin University of China with a BA in Economics in 1995, and earned his Master's Degree in Applied Finance from Macarena University in Australia in 2000. Please join me in welcoming Mr. Mu. Mr. Mu, welcome. Thank you so much for being here today. It's just a real delight to get to speak with you. Thank you. My pleasure. I know the world is watching with great interest. China is development of a central bank digital currency, and the People's Bank of China started researching CBDC six years ago, way back in 2014, very early in the process of global countries looking at this. Can you say a little bit about what motivated the PBOC to begin this work and then what is pushing you now to really foster the development of a new currency? Okay, thank you. Well, personally, I would rather to use the digital fair currency instead of CBDC because I think, personally, I think digital fair currency is more suitable for our digital version of RMB. So now we call it eCNY, and the eCNY is the digital version of RMB that is the digital fair currency of China, which is value-based, quality account-based and account-based hybrid legal tender with legally, with loosely coupled account linkage issued by the PPC operated and exchanged by the authorized operators, including commercial banks, payment service providers and telecom operators. So that's the brief introduction of our digital fair currency. And as you mentioned that we started our project back to six years ago. That's the top value cases and drivers for this project is firstly is to safeguard the monetary sovereignty because back to six years ago we have so many competitors that private digital or crypto assets came out. And that is definitely a threat to the monetary sovereignty or independence of our monetary policy of China. So in order to safeguard the monetary sovereignty, we have to start our own version of digital RMB, the eCNY. Secondly, is to provide a backup or redundancy for the retail system, retail payment system. As you may know, we have two big giants in terms of retail payment system sector, which include Alipay and Tempe. And people now go out to shopping without any credit cards, debit cards or the wallets with paper notes, paperback notes or coins. So those two have already taken almost 97 or 98% of the whole mobile payment markets. So they have already become the significant important financial infrastructure in China. But for those, I don't think we cannot let the private sector to run financial infrastructure, but the problem is all the private sectors that have their own life cycle. Just in case, if they have any problems with their financial issues or there's other operational issues or technical issues, then maybe the operational outage in some cases that will bring negative impact to the financial stability. So for that reason, as the public goods provider, the central bank have to step up and provide a backup or redundancy for the retail payment system. So that's the second reason we have to build our own digital world and our RMB as a payment instruments. And thirdly, is to improve the efficiency of the central bank payment system with a wider access and a stronger capacity. As you may know, internationally we have a trend that the central bank are obliged to provide a wider access and a stronger capacity for the payment systems. Before the introduction of digital currency to the general public, we have the central bank have already built up the wholesale payment system like RGGS, the BEPS, or the other retail payment systems like the credit cards, payment systems, or other fast payment systems. But recently all the central banks are trying to widen the access and improve the capacity of the central bank's payment systems. And one of the efforts, one part of the efforts is to provide access to the general public. So digital currency is definitely part of that effort. So that's the third reason. The last but not least is to improve the financial inclusion. Because in China we still, as you know, we always underscore that we are still a developing country. We have a large part in our country. We have remote areas and poor areas. A lot of population actually is still below, they are still in the poor shape, not very good shape in terms of the financial or economic conditions. So in order to improve the financial inclusion, especially those people without traditional banking accounts, for those people we have provide basic financial services. So in order to improve the financial inclusion, we have to build or develop our own digital currency. So that's the top value cases and drivers for our project. Thank you. Thank you. That is incredibly helpful and informative as people think about the development of the digital RMB. I wonder one of the other factors that people cite about the desire to move forward is about China's, the role of China's currency in the global economy. And do you think that the development of the digital RMB will also help China use its own currency in more global transactions to have the digital RMB become more prominent globally. Well, I personally I have to say I have a different view on that because the internationalization of a currency like, you know, Hank Paulson ever said in his article, that is, the technologies never the, the most important key for internationalization of the currency. The roots and the architecture or the whole financial system actually is the key factors or key elements for internationalization of a currency. So I personally I don't think the technologies that the key driver or key elements could improve the internationalization of a currency. Only the rules and the system. I mean, all the governance issues governance, the issues could be could be the key of it to improve the internationalization of a currency. So before the improvement of the whole system. The technology is never the answer is not a tendency for internet, the RMB internationalization. So that's my personal view on this on this issue. Thank you I think that's very helpful as well. I wonder for viewers if you could give people an update on the development of the digital RMB. I know you've been involved in a number of pilots, and that these are expanding. Do you anticipate a national rollout soon what can you what can you tell us about the status of the work that has been going on in the field. Well, PPC, you know, got the digital RMB or the ECNY as the important financial infrastructure for the future. So we have already actively carried out research and development and the pilot project. And we actually adopted adopted a rules or primaries of two tier operation to tier model and zero substitution and controllable anonymity. And we have already finished the completed the architecture standard formulation research and development of the ECNY functionality. And also we have finished the completed the joint debugging and testing of ECNY system. The, as you may know, the internal close pilots have been run in Shenzhen, Suzhou, Xinhuan, Chengdu, and also this will be conducted in the forthcoming Winter Olympics in Beijing. And at present, the pilots have made positive progress. And we have already created a series of use cases and a variety of safe and convenient payment functions. As of late September to 2020, more than 12,000 pilot use cases have been implemented covering bill payments, catering services, transportation, shopping, government services and others. And aggregates of 172 and 400 personal or individual data toilets and 16,000 corporate data toilets have been opened. In addition, more than 4.7 million transactions were processed with a total amount of RMB 2.3 billion. So, and we have already developed multiple payment methods such as QR codes, facial recognition, tap and go, such kind of functionality, such kind of payment functions. In addition, in order to show gratitude and respect to the medical and healthcare workers who have made significant contribution to the fight against the COVID-19, we have recently launched the Yixing-wide red packets pilot project in cooperation with the Luohu district of Shenzhen and some 5000 medical and healthcare workers received allowance in the format of Yixing-wide red packets provided by the fiscal support by the municipal government of Shenzhen. It could be used at designated merchants in Luohu district. In October 2020, we also launched another round of Yixing-wide red packets pilot, also supported by the fiscal funds of Luohu district of Shenzhen, some 50,000 lucky residents, the one the lottery received Yixing-wide red packets worth 200 yuan, that is 29.9 US dollars each. So that's the recent update, our development of the Yixing-wide pilot project. Thank you. There's an enormous amount of work going on in so many different strategies that you're pursuing at the same time. Do you foresee in the near future this going nationwide or do you think that you will continue to explore pilots for a period of time? Yeah, we so far we don't have very clear agenda or timetable for the rollout in the whole country, nationwide. We are going to, next stage, based on the previous results of the pilots, we may extend the pilots to more cities and more banks. Thank you. Thank you. I know a number of countries around the world are also considering central bank digital currencies or digital fiat currencies, as you said. And they're looking with interest at the different approaches that you've taken and that other countries have taken. There are different design features in the Chinese system that I think are quite important. I wonder if you could explain the basic design feature and maybe provide advice about why you believed that that design structure was appropriate for China? Well, thank you for that. That's a very good question. Firstly, I think we adopted a very important model, which is we call it two tier model. And maybe some people will call it hybrid model, but we call it two tier model, which is quite different from the other countries hybrid model. What is PBC and commercial institutions? Well, the PBC will work as the first layer or first tier of that model. And the commercial institutions will work as the second tier of that model. And that is the suitable approach to the E-SNY operation in China because that is different from the decentralized issuance of crypto assets, definitely. So that is an intermediate solution to providing for direct claims on the central bank while real time payments are handled by the intermediaries. The general public could exchange the E-SNY from the authorized operators as the second tier who could exchange the same amount of E-SNY from the central bank. And the consumers have a direct claim on the central bank. And this will not change the current creditor data relationship in currency circulation. And the E-SNY will not change the existing currency circulation system and the two tier account structure or create competition with commercial banks in the savings market. In other words, a two tier E-SNY will not increase banks with reliance on the interbank borrowing or affect their lending capacities. So this intermediation could be avoided. And since it will not affect the existing monetary policy transformation mechanism or intensify the pro-cyclicality, in different stress scenarios, issuance E-SNY will not lead to any negative impact on the way of the real economy operates. To avoid the crowding of the effect on bank deposits, arbitrage, trading and the rise in pro-cyclicality, the use of E-SNY will not be limited to small retail transactions by setting maximum daily and yearly limits and introducing policies that E-SNY conversions exceeding a certain amount can only be processed by appointment. If necessary, multi-tier charges may be introduced, especially in the time of stress for small and small and low frequency transactions can be processed free of charge. The service fees can be charged on large or high frequency transactions, especially during the background to increase the exchange cost and system friction to avoid any background or crowding out effect in terms of the bank savings market. So that's our key design of the two-tier model. That's the first design architecture of our E-SNY system. Secondly, our E-SNY will be positioned as M0, mainly as M0. So in that case, as M0, that is the back-nose encirculation and corn encirculation, mainly the corn encirculation and back-nose encirculation, also the required reserve in the central bank. So since it's a position to M0, that means the E-SNY will be limited to small retail transactions domestically. So we are going to focus on the domestic retail markets instead of the wholesale market and also internationally use cases. So it's not for we are going to focus on the domestic retail sector, not internationally, as you haven't mentioned that whether that will be a key driver for the internationalization or RMB. So firstly, I will focus on the domestic market. If in the future there is a demand for cross-border payments because definitely digital fee occurrences is born to be used for cross-border payments. But if there is demand requirements for us to be used for cross-border payments, firstly we have to talk to the local monetary authority or the local central banks before we can extend to the cross-border use, use cases. Because we have to respect the local supervision and we have to respect the independence or sovereignty of their monetary policy. So that's why that's the reason we develop our own E-SNY is also we cannot do that to other countries without a prepared coordination or well-coordinated mechanism, especially for the exchange mechanism. So that's the first implication of the position as M0. Secondly, because it's a position as M0, we have to observe the same regulations as M0. So all the cash regulations, the rules, the laws will apply to the E-SNY. We have to comply with all the existing M0s and regulations. That also includes the ML and CFTE rules of the M0.  And thirdly, since it says it's positioned as M0, so there will be no interest to be paid to the holders of E-SNY. And since it's M0, so the exchange function will be carried out by the commercial banks. Because in the back-nose, in the era of paper back-nose and coins, it's the responsibility of the commercial banks who are going to exchange the back-nose and coins to the general public. So those PSPs, the payment service providers, the telecom operators, they are not the person, not the institution who are going to exchange the E-SNY to the general public. But the transactions, but the circulation services could be carried out by the commercial banks and the PSPs and the telecom operators and other financial institutions. So those are the implications of the M0 besides that the central bank will not charge any fees from the services providing to the general public that will not charge anything for exchange in the circulation of the E-SNY among the individuals of the general public. That's very helpful in understanding the path you're on. I wonder whether you could touch on an aspect of the design related to privacy. Some people prefer the anonymity of cash or maybe they want a private cryptocurrency like Bitcoin. How do you think about the privacy aspects of offering digital R&B? Well, definitely we have to respect the demands of the general public in terms of anonymity, in terms of payment services. And we adopted a policy that is we call it a controllable anonymity of the E-SNY. That's to, you know, the E-SNY transactions may jeopardize the personal, I mean the digital currency transactions may jeopardize the personal data and privacy. And so we have to have a better design to protect the personal privacy and data.  So the only way to strike a balance between the two is to keep the degree of anonymity within a controllable range. Namely, that is for the large sum transactions we have to do the QIC completely. That means the large sum transaction has to be done with their real name, real identity. But for small sum daily use transactions, people could choose to remain anonymous. So that's the key design of our principle. Of course, and also the authorized operators, we call it the second tier is authorized operators. They will perform QIC responsibilities and store their own data locally. And they will submit all the data to the central bank via un-synchronized knowledge, the synchronized knowledge transmission on a timely basis. They will allow the central bank to keep track of necessary data to implement prudent regulation and combat on money laundering and other criminal offenses and illicit transactions. But at the same time, we have to respect the demand to remain anonymous for legitimate transactions. So that's the rules or our views on the privacy issue. Thank you. You know, a major theme of the conference we're having over the next few days is financial inclusion and the ways that central banks might advance financial inclusion in their own economies. You mentioned at the outset that you think that the digital RMB may help with financial inclusion. Others are worried that moving to digital currencies will leave more people out who are not technologically connected or don't have access to the financial system in different ways. How are you thinking about working on the digital RMB in such a way that financial inclusion is a central goal that the design features can help advance financial inclusion rather than leaving people out? Of course, as I said, it's the main driver of all the top value cases for us to develop the ECMY. So due to our ECMY's property characterization and the loosely coupled account linkage, the general public could apply for digital wallets without opening a banking account. Therefore, the issues of ECMY and offline payment function will enable the underbanked population in poor and remote areas with poor coverage of telecom networks to enjoy basic financial services. The ECMY could provide functions that you wallet cannot such as offline payment function due to offline payment function and smart contracts which serve currency functions such as conditional payment and schedule payment. So for those people, you know, we have a lot of population in remote areas, they don't have any traditional banking accounts. So traditionally, they are underbanked because bank cannot provide services for those people without a banking account. But since we are loosely coupled, it's decoupled from the traditional banking account. People can open a digital wallet without a banking account. That means those subsidy subsidies or allowances for those poor people could be sent to their digital wallet without a banking account support. So that people could enjoy some basic financial services and also physical support from the government. So definitely that will improve the financial inclusion. Beyond that, because ECMY is a value based quasi and full account based hybrid payment instrument that could be also is loosely coupled from the banking accounts. So it doesn't rely on the banking accounts for fund transfer. Therefore, for the perspective of settlement finality, the settlement will be completed as a very moment of the payment is completed. So if the financial finality confirmation by the RTGS is no more required for those small merchants, especially the small and medium enterprises, the working capital turnover efficiency could be improved. So that case, that also will provide some support to the financial inclusion. That's a very comprehensive approach to financial inclusion. I think there are many important lessons there that others around the world want to look to and examine and explore and see whether it works in their own systems. Obviously each each system is unique. And people will have to develop their own path. But I do think there are many important lessons there. We are almost done with our time. I wonder whether you have any final words you want to leave us with to convey to the participants in the conference. Okay, I know people are especially those media is exaggerated on the internationalization effect of ECNY, you know, to the to the R&B. But as I said, we need a international coordination. We need, we call for international cooperation in terms of the development of digital currency or digital currency. And so in that case, if we can cooperate together, we can improve the interoperability among the digital fair currency or CBDCs among different countries, and we can improve the efficiency. And we can improve the transparency. We can reduce the cost of the, the cross border payments. So can we can make the whole world better, and we can stimulate or improve the international tree to make people's lives better. So we are looking forward to have a better coordination, a better cooperation among different central banks and international organizations. Thank you. Thank you very much. We really appreciate your participation in the conference. Your remarks are quite insightful and I think will help our listeners really around the world understand the work that it China is we're proceeding on. On the digital R&B. And I know that we'll have many such issues to discuss in the coming years. So thank you so much for participating in the conference today. Thank you.


So in this session, we will talk about how you can assess readiness for starting with DHS-2 and tools to assess the maturity of a DHS-2 implementation. In this session, we will identify tools for performing DHS-2 readiness and maturity assessments, learn about which factors are relevant for a country's readiness to start with DHS-2 aggregate systems, and understand the factors relevant for a country's readiness for DHS-2 tracker or individual data systems. We will start talking about the DHS-2 maturity framework. We have two different tools that can help you both assess whether you are ready to start with DHS-2 and to understand how mature your DHS-2 implementation is. So the DHS-2 readiness assessment and the DHS-2 maturity profile related tools. The readiness assessment is a tool to map the current situation in a country before starting with DHS-2 to ensure that the prerequisites are in place. While the maturity profile on the other hand is a tool that maps the maturity of both the foundation and programmatic topics related to an existing DHS-2 implementation in a given country. So again, a readiness assessment is something that you do before you start using DHS-2 in a country to understand whether you are ready. The maturity profile is something you can use to understand how you are doing in your already running DHS-2 implementation. You can see on the slide on the left is the topics that is addressed in the readiness assessments. These are areas such as leadership and governance, security, training of end users and infrastructure. To mention a few, we will go into detail about these areas later. On the right, you see a visualization of the DHS-2 maturity model. This will also be discussed more in detail later. But the point to show on this slide is that the topics that we address in the readiness assessments are corresponding quite closely to the foundational areas of a DHS-2 implementation. The foundational areas are topics that is important to have in place to have a solid functioning DHS-2 system in a country. And again, to summarize, the readiness assessment is the mapping of the current situation before you use DHS-2. The maturity profile is the mapping of the current situation with DHS-2. And we will now move into explaining more about both of the different tools. So readiness essentially means what needs to be in place to start a DHS-2 system. So before starting with DHS-2 in a country, it's really important to assess if the country is ready with a focus on a key specific areas, such as leadership and governance, strategy and investments, security and compliance, if there are available technical skills for a DHS-2 system to be set up, if there are people available with the right skills, if the country has a system to train end users, whether there is availability of a facility and population profile, what the situation is for infrastructure, and how the country currently collects aggregated data for the HMS. So in the next coming slides, I will go through each of these sections, the questions that is asked to understand the readiness for a DHS-2 system. It's quite a lot of text, but bear with me. So first, under leadership and governance, what we want to understand is, is there an existence of a health management information system unit within the government? Does the government have a national department or agency or coordinating body for digital health? Is there existence of leadership and political will to start with DHS-2? Does it have political support, for example? Are there existence of agreements between the Ministry of Health and other agencies for digital health implementation? So are there any kinds of agreements and coordination happening? Existence of structure for engaging key stakeholders, including other government agencies, system users, civil society, organization, funder, technical partners, implementers in the private sector? So are there any sort of formal forums or places where these conversations are taking place? For strategy and investment, we're interested in understanding whether there is a key health strategy in the country already, and if there is money set aside to work with DHS-2 over time. So again, here we assess whether there is existence of political interest and support in investing for IT for service improvements, existence of sufficient funding to support infrastructure strengthening. Often we can see that there is lack of devices, for example, in a country that will influence how a DHS-2 system can succeed over time. So is there sufficient funding to support infrastructure strengthening? We're also interested in understanding if there is a cost plan for maintaining physical and technical infrastructure in the country and human capacity of the system strengthening investments. So for example, is there a plan to replace broken devices, for example? Are there people available in the country that know how to do these replacements or repairs? And also whether there is sufficient funds to support a cost of maintenance plan. So for example, if a device breaks down, is there a plan on how to replace that device or upgraded, etc. Under security and compliance, we're interested in understanding whether the country has the policies, frameworks, laws, etc. that guides how the country, for example, addresses personal data. So we want to understand whether there are legal frameworks for data protection, if there are any laws or regulations for privacy, confidentiality and access to data information, and also if they're personal responsible for implementing e-health security policies at a senior level in the country. This is important as a lot of the DHS2 systems often contain personal and sensitive data. And you want to make sure that this is set up in a way that does not conflict with the country's regulations or laws. Or if there is none in the country, that needs to be addressed when starting up. You want to understand whether there are existence of specialized knowledge to support and maintain a system such as DHS2 in a country? Are there people available that have basic IT skills, that can do basic programming, understand databases, scripting, etc. For training the end users, it's important to understand whether there is a system in place to train both the HMIS team but also the end users that are going to use DHS2. So we want to understand the capacity and computer literacy of the HMIS team. We want to understand the mechanisms for workforce capacity developments and communication of training support. So for example, is there a plan for training people when they are newly hired? If there are new people coming in in the middle of the year, for example, if people quit? Is there a system for retraining staff? We also want to understand whether there is an existing process available for regular supervision of staff regarding data entry analysis and management. The key aspect of a DHS2 system is the facility and population profile. So an important thing to assess before starting with DHS2 in a country is whether there is a master facility list in the country. So does the country have an overview of all the facilities with associated data available to use as the basis for the DHS2 system? And you also want to understand whether the country has the ability to identify a person or a child unambiguously. So is there any kind of social security numbers or ID numbers, etc. That can make sure that you can identify a person. The key components of a DHS2 implementation is infrastructure. Before starting with DHS2 in a country, you would like to understand whether the country has stable electricity, how the internet or data access is at health facility and district level. You want to understand who has accessible computers or mobile devices to capture data. You want to understand how a country is supporting data storage and servers, how the national level capacity of maintaining hardware in the data storage center is, and whether the country has the ability to maintain and troubleshoot both hardware and software at district and health facility level. And finally, before starting with DHS2 in a country, you would like to understand how the country currently collects health data, so the availability of paper-based records. If there is enough workforce capacity to enter data or is the workforce completely overburdened, is there any existence of a regular data review process? So all of these topics that I've gone through now, we've developed in a tool called the DHS2 readiness assessments, and it scores these domains from non-existent to strong. So it's not required that all of these are in place before you start, but you should be aware of where the weaknesses are or where the gaps are before starting so that you can address them in parallel before starting and as you start a DHS2 implementation project. So once you have DHS2 already set up in a country, we have a tool called the DHS2 maturity framework. This both guides readiness for new programs. So if, for example, the country uses aggregate HIV, TB, and malaria in a country, and maybe you would like to add another program, EPI, for example, or you would like to go deeper into a tracker program, it's useful to understand what the situation is of the current DHS2 implementation. So the DHS2 maturity profile tool is a tool that assesses the maturity of DHS2, and it really supports countries to measure and understand if the country is progressing on their health information systems strengthening, but also if they're ready to go further and if there are any areas they should really address before moving to the next level. You can see here in the picture that there are some foundational areas at the bottom. This covers areas such as leadership and governance, how you train end users, security and compliance, etc. A lot of what I described in the readiness section and this is depending or it doesn't really matter which program you're building on top of it. This needs to be in place in any case and then each program is assessed by itself. Once the HIST group has done this assessment of the country, the results are compiled and aggregated and it can be displayed the way that it is here. So it gives a sort of a glance of what the situation is. And it's important that this tool can encourage investments in the core DHS2 capacities, so the foundational areas. This is really what contributes to a sustainable health information system supporting the health programs. So if all of the foundational boxes at the bottom are red, meaning that they're scoring very poorly, then the chance of succeeding with a health program at aggregate level and even more at tracker level, and I'll get back to that later, is very poor. So you're depending on a strong foundation in order to build something else on top. The results here can also help align across investments or donor interventions. So in an ideal world, you would have different partners pay for the same thing. So if everybody can chip in and contribute towards the DHS2 core team, for example, or to strengthen the security and compliance under DHS2, that's helpful for all programs. And it also helps in assisting planning DHS2 implementations and strengthening activities. It can also really identify areas in need of more in-depth evaluation and monitoring. So if an area is scoring very poorly, it also means that you would have to dig deeper and understand really what is the problem and go deeper to really understand the details of how you are to address that specific problem. Again, the tool measures maturity in three core areas. You have the foundational at the bottom, the aggregate in the middle, and the tracker on top. I've mentioned this already, but just for a quick repeat. You can see the symbols here at the bottom. You have the in-development symbol with a little tool that indicates that the program is being configured and developed, but it's not yet been implemented anywhere. Then you have the pilot sign, the wheels turning. That means that it's being tested out in a couple of facilities to see whether the configuration is sound and if then you need to do any changes. And then the arrow pointing upwards, it means that it's in the process of scaling or fully scaled. Next, I'll talk about what is important to be ready for DHS2 aggregate systems. Again, repeating to add new DHS2 aggregate programs. For example, if a country wants to add aggregate EPI, for example, to their DHS2 system, or they want to add an HIV or surveillance, we recommend that all the foundational topics that you see on the bottom, on the blue square, are at least in early progress. That would be the yellow marking in the maturity profile before starting a new program. If you have a country that is scoring reds, not yet achieved, these really needs to be addressed. You can start with a new aggregate program, but we highly recommend that you address these not yet achieved things already. And this is because if the country does not have any system for training end users, if there is no facility or population profile or the infrastructure situation is very poor, it's very hard to do even aggregate programs well. Next, I will assess the readiness for DHS2 tracker systems or individual data. So starting a tracker program is a little bit more complex than starting an aggregate system. So it's a potentially large and pretty complex endeavor with large investments in devices, personnel, etc. And hence it is very important to ensure that there is sufficient institutional buy-in and support from key stakeholders, that there is funding not only for developing the program and the start of the implementation, but you also need to have money for training of staff and continued support, being able to buy and replace devices, etc. You need to ensure that the legislation and policies for privacy, e-health and standards are up to up to dates. And if there are no policies, that's the topic that needs to be addressed carefully so that you're sure not to break any laws or do anything that is unethical in that country. We deal with sensitive data, so that's important to remember. It's important to assess the capacity and competence to plan, design, develop and long-term support tracker system. So do you have the proper DHS2 capacity in the country to start up? Is there capacity in the districts to support end users over time if they get stuck using the system, etc. And lastly, how is the infrastructure situation? Do you have enough devices? Do you have money set aside for connectivity? What is the service situation like? Do you have a system for user support? Who will pick up the phone if one of your 2000 users, tracker users have a problem? Do you have a system for that? And to match the implementation plan. So in general, the foundational domains, we recommend strongly that they are at an acceptable level before tracker programs are implementing. So this means they should score at least early progress, meaning the yellow box here, yellow color, preferably adequate when using the maturity profile tool. You should really not have any not yet achieved before starting a tracker program and security and compliance should always be at adequate level before starting a tracker program. And as with aggregate systems, when planning and budgeting implementations of new individual data domains, it's critically important that the plans also provide for strengthening the foundational areas that are in need of improvement. So when writing your budget for your system implementation, do not only write down the cost of configuring your TV tracker, for example, but also are there any activities related to these foundational issues that you should include in your budget to ensure that your system is successful over time? Lastly, I will talk about Android considerations. So readiness for implementing the tries to Android applications as a component of the aggregate and tracker systems is not something that we have explicitly covered in the maturity model tool, but it is part of assessing each aggregate and tracker system. But there are some special considerations for Android implementations, for example, if there are special implications for trainings, what kind of devices you should procure, etc. This is covered in more detail in the session on going mobile in this course. In summary, before embarking on a details to project, it is important to assess whether the country is ready or not to start and if there are things you need to fix before you start. This is especially important for projects using tracker to collect individual data, because these projects are close to clinical practice, they are in use every day and they require more elaborate planning and a higher degree of readiness and details to maturity than an aggregates project does. It's a larger investment, it's more complex and it affects more users. So here it's especially important to make sure that you are ready before start. So here's BIO, we provide various tools and frameworks that can help assess readiness and maturity for countries in details to implementations.