 sharing and user roles. And these two concepts will allow you to kind of enable some of what Marcus and Akuba had mentioned in their presentation that they gave you. There's another aspect here. They talked about how you access records and sometimes you can get a prompt, for example, to enter in a reason why you're accessing that record. I also have an extra resource on how that is configured. There's a video resource for you that you can review and we'll make sure that we put the link with the additional resources. Actually, for all of this, there's some videos on the configuration side. So if you are interested in that, we can link those as an additional resource. I mean, you can have a look at those as well. All right, so there are really kind of two levels involved in this kind of user access, at least for the ability to access or provide read and write access, in that process matrix, for example, or sorry, in that separate matrix that Akuba had presented towards the end there and where she had, who has write access, who has read access to various portions of the program itself and who can do what. It's really these two concepts that interact with one another in order to enable that access. And basically, these two concepts interact with one another in order to enable that type of access, okay? Inside DHIs too. So where you have this kind of management sheet where you're entering in who can do what in the matrix, which is going to be extremely helpful. Then this is the actual mechanics of how you would set that up in DHIs too. This is how these concepts relate to one another. So in DHIs too, you first have this, what's called sharing. And this sharing concept, it allows you to take any specific item or object in the system and it determined the level of access that users have with these objects. So for example, if you have a program like your COVID-19 vaccination program or your adverse events program, and you want to tell the system who has read and write access to that program, who can just view the data, who can actually enter records, who can upload records or who can actually modify the configuration itself, then you kind of use the sharing concept to kind of enable a portion of that, one level of that access. It is typically applied to what we call user groups or groups of users in the system. And in that matrix that was shown, you had kind of groups of users where you're kind of determining, okay, who has what level of access and how do we give that access to them? So basically you're following a very similar concept in the configuration part where you're going to take a group of users and actually enable this access for them. So you don't have to do it one by one, but I mean, you can do it one by one, but that will be very time consuming. It's just much easier if you have quite a few users with these different authorities that are accessing your program. So when the sharing concept is combined with user authorities or user roles, and we'll show some examples of this, it allows for the system to then be segmented by the various programs which are accessing the system. So for example, if you only want the TB program to have access to the TB program data, then you can do that. And even if you have an integrated system consisting of malaria, TB, HIV, and then maybe immunization or something else, right? You can segment your system. So it only has these different types of access for these different programs. Or of course you could have kind of more admin users or system wide users, perhaps in programs where there's cross-analysis occurring, like TB, HIV analysis occurring, where they have access to both programs data, but they may not be able to edit the other program, for example. So there's a lot you can do with this concept in order to segment your system off. We combine this concept of sharing in DHIS too, with this concept of user roles, okay? And user roles can be thought of as the top layer restriction on what a user can do in the system. So we can look at sharing as kind of the secondary layer. This more precisely restricts a user role functions to specific objects in the system. So for example, as part of the user role, you can say, okay, this person can, I don't know, create a new variable in the system. And that is as part of their user role, right? But then the sharing concept says, well, which program can they actually do that for? Which program can they actually add new variables to? So these two concepts together allow you to kind of manage very specifically, you're very granular at a very granular level, who has what type of access? So in the context of either event or tracker programs, I should say, this concept, it allows you to determine what level of access they will have to either the event or tracker program for data entry, for data analysis. And it's not mentioned here, but also for configuration. So let's look quickly at different types of ways that this can be used. So let's say we have three apps, right? The maps app, the capture app or tracker capture app. Here I can just add that in for posterity's sake, okay? And we have, let's say we're looking at malaria or this SARA survey is a survey availability and readiness assessment, it's just a survey program. Or we have an ICD-10 program of some kind, okay? And we're looking at three different apps and how we segment off access to those apps. So at the top level, we have this function called a user role. And the user role will basically say, okay, this person has access to the maps app, the tracker or the capture app, the tracker capture app, allowing you to enter tracker data and the maintenance app, okay? Then within those apps, we have the sharing concept and this will tell you what the user has access to within those applications itself. It is the second level of the restriction that is placed upon this information or metadata or programs that you're allowing people to kind of use within that system. So within the maps app, you're saying, okay, user A can access the ICD-10, malaria and the SARA program and they can analyze that data within the maps app, okay? User A can also enter data for the ICD-10, malaria and SARA program and they can also configure the data elements or the variables for these programs. Now you can be more granular of course and make that more specific and say, okay, there's a team working on mortality surveillance. So they have access to ICD-10, there's a team working on malaria, they have access to malaria only, there's a team working on the survey, they're the only ones who have access to that survey, right? You can even define this further where you can say, okay, person A only can enter data for this program, right? Person B can only view the data in analysis but they cannot enter the data and then person C can only edit or the configuration of these programs. So there's a lot that can be done in order to kind of configure or define, you know, the different levels of access or authority people have in relation to your program itself. The ones that you will mainly focus on are typically, you know, granting access to view and edit the data itself, right? There's only gonna be typically a small amount of people who will be managing that program or managing the configuration in the grand scheme of things, you know, there'll be a lot more people that you'll probably give access to view the data and edit or actually edit the records, right? And turn your people into the system. There'll probably be a lot more of those individuals actually performing those tasks. So we combine these two concepts in order to enable that type of restriction in the system itself, right? And when you're coming up with that matrix to kind of determine who has read and write access, how you're going to then apply this in GHIS too is to use the sharing concept in order to do that. Okay, so I'll just show you real quickly. Okay, actually here, we're gonna talk about it more. Okay. So in relation to this concept, that's why we kind of mentioned people can modify the configuration itself. They can also, you know, you can also grant different access to the data itself, right? So in GHIS too, we actually have these two models called metadata and data sharing. And actually that's just what I wanted to quickly show. So if I open up one of these programs here, let's take a look at the COVID-19 vaccination registry and I'm just going to, we have this tool called sharing settings that allows you to manage as part of the configuration. We're not gonna get into a whole discussion around it now, but just so you can quickly see, okay? And what we've done is we've given different groups access by default, right? So we've kind of thought ahead of who has, who's going to analyze this data, who's going to enter this data and who's going to administer this program, right? Who's gonna modify the various variables, et cetera within this program. And this is just at a high level, you do a bit more, but just thinking about who might actually have access to do these different things in the system itself, right? And if I just click on one of these icons, we'll see there's two levels of sharing within GHIS too. One is called metadata sharing. This is to actually manipulate and view the variables, the indicators, other parts of the configuration itself, and then we have data level sharing, which determines who has access to the actual data itself. So if you want to analyze certain components related to your programs, or you want to provide information to actually enter new cases into your programs, that is all controlled through this secondary level called data sharing, okay? So the metadata sharing itself, this focuses on the configuration the data actually focuses on the data itself. And then within those two levels, we have different layers of access that you can provide to different users, right? So we have this can edit and view and can view only for metadata. And actually there's one more level if you're looking overall is no access, right? So you can also say, they can't see anything related to this configuration at all if you wanna hide this from a certain group of people, right? I default when you add a group, then they have to have either edit or view access, which means if I can edit and view, that means I can actually modify components of the specific item that I'm sharing. In this case, it's the program itself. So if I said they can edit and view, they could actually go in and modify the parameters associated with the program, for example, they could add in new data elements to the program, right? If I put can view only, what that means is they can only view the program. And this is necessary for them. For example, if I'm entering data and I just want them to view the related configuration inside of track or capture, for example, I would give them this can view access, okay? The secondary level we have is data and there's also three levels associated with this on top of the no access. So we have data can capture and view and data can view only. If I give them can capture and view access, this allows them to enter new individuals into this program itself, right? So I'm looking at a vaccination registry, so I would be able to register new people into my vaccination program, right? And enter their associated details, at least their demographic details, et cetera, during registration. And then I have the secondary level can view only, right? And this determines who can see the related data that's associated with this program, right? So if you have highly sensitive data, this is one way you can kind of restrict who has access to that, right? Especially if there's a lot of sensitive demographic information in terms of identifiers and other information or criteria that you don't really want people to kind of be fishing around and looking for various information associated with that. This data can view only or no access, for example, will restrict people from doing that. So you can even have, for example, if you had some external support, you could have that external support, provide you with the ability to help you with the configuration, but they can't actually see any of the data that's in your system, right? Which might be useful in different scenarios, right? So these two levels allow us to kind of quite granularly separate who has access to what within the program that we're looking at, right? So this is just the summary of what I've presented there, and we can follow up with this presentation so you have this as reference. So in a tracker program, there's quite a bit of sharing that you can do. There's all of these different levels, right? So we're not going over the mechanics of doing all of this today, because you can see there's quite a bit, right? But there's different metadata that you can configure sharing for, right? And as a whole, you know, doing this within the different programs itself, it will grant you quite a bit of granular control over who can do what with the various objects in your system itself, right? So you have the data elements itself. You have what we call tracked entity attributes. Don't worry about this naming convention, but these are basically the demographic details. So items like the name, the sex of the person, their date of birth, any of those types of details that are associated with the program itself that are used to register an individual into your tracker program. We have these option sets, which are just lists, a dropdown list, basically. We have the program itself. Within the program, there's various processes. We call program stages and the indicators associated with the program. So all of this information here, we can put those levels of control on, okay? So not all of them have both levels of sharing, but some do. So for example, the program itself, the program stages, they have two levels of sharing, but the data elements, for example, only has one level of sharing, the metadata level, okay? And that's because you can control access to the actual data through the program itself. That's a bit more detailed than we'll probably go into right now, okay? But see here, these are the three items that we can kind of share the data with that have these two levels of sharing that you can enable. So we just went over one object now, which was the programs. You can also do this for the program stages and what we call attract entity type, okay? So actually, yeah, I'm gonna stop there and just... And while he's looking at this, I think if you guys wanna look into the program, I think the AFI or with adverse events, spying and immunization has some interesting user roles. So if you wanna play with and kind of look at that, I think those are something very interesting to look at because you're looking at one stage that has multiple access, user accesses within one stage. So it's having different rights based on different levels of people using the program. So I just wanted to highlight some examples of that as well. In this case, we have someone who can only register individuals into the system, but then they can't actually update any of the other information within the program itself. So for example, if I go to register somebody, you can enter some details for an individual. Looks like this isn't configured correctly. I'll have to check. Oh, sorry about that. I guess the example isn't configured correctly. Maybe I'll have a closer look at the AFI one and we can demonstrate that one in a bit. In any case, I just wanted to kind of convey what some of these allow you to do. We do, as I mentioned, there are some additional resources on how we configure this. So I will share those as well. There's a second presentation that I will upload, but I'm not going to discuss so much just so we can discuss the template as well, but it discusses the specific permissions that you can provide for each individual object in the program itself. So I will upload this as a resource and you can go through that as well, just so you can kind of see. So it goes through the three items within a tracker program that allow for both what we call the data sharing as well as the metadata sharing. And it talks about if you provide certain permissions to these individual items, what you can actually do with this. And there's a detailed video on this as well, about the different effects that this has. So we will make sure to link that as an additional resource. So if you are interested in kind of reviewing some aspects of this, as can mention that AFI is one example, but there is a lot of programs in there that have different sharing settings applied to them. So you will see, I think if we pull up, you can probably at least pull up the, yeah, okay. So here I think there has been sharing settings provided. There's a couple of different user groups that do different things, but you can see that the sharing is not equal across all of the stages basically. They provide different levels of access to different users to do different things. So if you wanna view more about how the sharing is configured when you open up a program, so here you go to this maintenance app followed by a program. And just view the list if I just go to any of these programs and go to this access tab. This is where the sharing is actually configured. And you can review some of, you know, how the different sharing is configured, what type of access different users have to different components of the system itself. And this combined in particular with that second resource on which talks a lot about, you know, the specifics of what each portion of the sharing does, should give you, you know, a better generalization of how you can apply this in certain contexts to really give people the right information, access to the right information in your system itself, or even just restrict people who you don't want seeing certain information, you know, within those different parameters that you've defined. So these two concepts, sharing and user rules are really quite helpful in order to understand that in a bit more detail. And we have a couple of resources that we will upload in order for you to see more fully. So just to recap, you know, real quick, then we'll move on to the roles and responsibilities in the template. So just real quickly, thinking about, you know, what these two levels are. So provides the top level access to apps and their key functionality within the system, that's user roles, okay? And then controls more specifically what items a user can interact with in the system that is shared, right? We talked about these two levels that interact with one another and allow you to provide, you know, various aspects of this control within the system itself. And then sharing the two levels of sharing, okay? This is, there's two levels of metadata and data sharing, okay, are the two levels of sharing. User authorities and user groups, those are related to the user configuration itself, right? And we didn't really touch on that too much, but that is another aspect that interacts with this in order to allow you to provide that information to people. Okay, and then what are the three items that interact with one another to fully realize the sharing model? We actually didn't cover this too much, but the user roles we talked about, we talked about sharing. The third one that's really quite important is user groups as well, because we talked about that you share this information with a group of users, right? Not just typically one or two users. You go through your, you would first start with what a CUBA had defined, which often takes a lot longer than configure the actual configuration, identifying who has what access to the individual components of your program. When all those groups are fully realized, you would configure those inside of VHS too, you would make sure they all have the proper user roles and access to the system, and then you would share components of your program based upon what you've defined previously. And then you would configure them in the same order, user roles, or user groups, user roles, and then sharing as well. So we'll upload some additional resources so you have some more information on these concepts. And then what is the difference between metadata and data level sharing? So just as a recap, right? Metadata sharing, it allows you to share variables or parts of the configuration with users to either view or edit. So if you want someone to enter data, for example, you need to allow them to view all the different variables or data elements associated with the program, they're going to enter data for. And then data level sharing allows you to control who can either edit the data or upload new data within a program, or view the data associated with the program, okay? So these two levels allow you for kind of a bit more granular access control, I mean, in order to control who can see what within the system itself, all right? So this model hopefully meets some of your needs, if not most of your needs, when you're going to kind of refer back to the model that you filled out, the matrix that you filled out in terms of who has access to what, once that's all kind of said and done and defined, then you can kind of configure this inside of DHIs to using these two levels of sharing as well as some other aspects to actually configure this inside the system itself. And you can have a look at some of the programs just to see how they're configured by going to their access settings here. And then if I just click on any of the components, for example, the program, I'll be able to pull up some information in terms of different authorities, different ways that the program is shared with different groups in order to allow them to access different components of the program itself. In a lot of DHIs to implementations, this is sometimes ignored. So that's why people have access to things they shouldn't. So just having you can make those considerations and be aware that this stuff is available, I think, is a big step in the right direction just so we can make sure that people are accessing the information they need. And of course, if you want to widen access, that's another area where there's, you can restrict access, but if you want to increase the scope of access for people, you can do that as well by allowing many different groups of users to access the data of your program without affecting them, their ability to modify the configuration of any kind. All right, so if there are any questions about that, let me know in either the Slack or the Zoom chat. As I mentioned, we'll upload some additional resources on the configuration of this. So if you're interested in seeing how this is configured, we can do that for you. You can view those resources there to get a better understanding of this, both on the sharing model as well as some other aspects related to this, this breaking the glass concept, the second concept that was mentioned in their presentation, where if I just pull it up here, they talked about some of this information here where you had to kind of allow people to enter a reason for accessing a certain record. We also have more information on that as well, which can be useful in certain scenarios. All right, so if there are any questions about that, let us know and we'll try and field those additionally if you're kind of after you filled in your matrix and are kind of trying to decide how you actually implement that. We're happy to help there as well. Can we open the floor to questions if you wanna raise your hand? Yeah, if there are any questions now, please feel free to ask. And this is being recorded so we can always look back on it, but these user access rules are very important. So thanks for sharing, giving some more insight on this, Sherry, it's very helpful and useful to see it actually work in the program. I'm not sure if there are too many immediate questions. It is a bit to think about, but if you come up with any questions later on after having reviewed everything, we'll post the additional resources as well so you can review those. And if there are any questions at that time, just feel free to ask us. There's the questions channel on Slack, that's a good place for you to post them after the fact or in the coming days, if you think of anything else. All right, so with the remaining time we have, I'm just going to touch on the rules and responsibilities portion of the template. I understand last time you presented a bit on the process matrix and I hope that was useful to you. On the remaining sections, privacy security, monitoring evaluation and budget, there are specific sessions on those. So until those are presented, we will hold off in terms of I'm going through the remainder of the template just so you have a better background. But as soon as those are presented, we will go through those different optional sessions just so you have a bit more background on those topics before getting into the planning component of those various topics as well. So Bob will present on privacy and security and Anna will present on monitoring, evaluation and budgeting in the coming days. And when those are presented, we will come back to this and then go through some of the components of the template and how you might consider those when you're actually going to deal with your own program. All right, so in the rules and responsibilities tab, so we had discussed this very briefly on Thursday. I think there was a question about it and then we kind of tried to address it that way. But here what we're really trying to do is define all the individual actors that are going to be working with you in this system itself. And when you're working with Tracker, there's actually can be a lot of different people that you're talking to. So on the access side, we talked a little bit about defining different things in different ways. We talked about the DHI's two side, but then you will also have legislation, et cetera, associated with that potentially. And if not, you might have to come up with some type of standard operating procedures and things like that in the interim, if nothing exists, which can happen in many places where there's not adequate legislation on these types of things. So there is a significant amount of coordination around that. But just thinking outside of this one topic of user access and control, you are thinking about the whole scope of your project. So there could be, for example, senior support that's involved in getting this up and running. And then you will obviously have the kind of lower level support as well at the lowest level that's involved in the day-to-day operations of the implementation, providing configuration support. Then you'll have people actually entering the data itself, people providing training on the programs, et cetera, et cetera. So you're really looking at this whole scale of individuals that will be helping you to implement this program successfully. And the role could be very small, but very vital. For example, if you have some senior level support that you require to get things up and running, especially if there is a lot of issues around sensitivity to access the information itself, that you might need some type of information that you typically wouldn't. For example, if you're dealing in an aggregate system, there might be less concern about the privacy of this information that you're collecting versus now where there might be a lot more emphasis on that itself. So we just put a couple of examples of people who could be involved in the projects itself. I would say when you get to the budgeting part later on, that you will probably be able to identify more people that are involved in these roles and responsibilities, only because there are often a lot of things that don't be considered until you have to kind of procure them later on after the fact. When you're implementing tracker, I may talk now twice about Android devices, for example, and that is a typical area where we see a lot of delay. If you need to purchase Android devices or if you're waiting on some type of partner to provide you with those devices, and this is delayed for a significant amount of time, then you're really having some difficulty. We've experienced that scenario now in some countries where even for COVID-19 vaccination, they don't have the devices they need, for example. So having these things kind of well thought out to the best of your ability can prove useful only so you can kind of just continue to follow up with these people and involve them in the decision-making process when you're kind of going to interact with various parts of your program. So when you kind of identify all these different actors, this is just kind of a listing to help you better understand who's involved in that, but you might wanna take this one step further, right, after you had listed them out, to really identify, you know, you might have working groups where there might be a scope of work, for example, or some type of type of terms of reference if you're meeting regularly, let's say you have an HMIS working group of some kind where they meet regularly to identify, you know, what will be their contribution to these various programs that you're configuring or working with or implementing in your own setting. You might have other types of processes, as I mentioned, you know, procurement is a big one that it can be overlooked. So there might be very specific processes that you may need to review in relation to follow their guidelines to get things up and running if there is a lot of bureaucracy associated with, you know, making sure you're able to get what you need in order to make this happen, right? Because this is also related to maybe travel as well, if you're going to do large-scale training, maybe a mix of online training and in-person training, for example, to kind of reach everybody, then you need to make sure that everything's in place in order to do that. So these are things you guys probably already have, you know, you guys are already aware of the processes in your country to make things move, but it's just useful to have all this kind of written down so you can, you know, have reference to this. And then, you know, this is really the first step in this, you know, it's just a listing of what you see here, but as I mentioned, it's very useful often to take components of these lists and spell them out in much greater detail. So, you know, you even have specific items that we'll be talking about later, researching, monitoring and evaluation. So one thing that this mentions here is the team responsible, for example, for indicators and things like that, but when we get into the monitoring and evaluation components of the program itself, you'll see that there are two aspects. They're like monitoring and evaluation within the program to look at the data, but you also have this secondary aspect that is overlooked and this is monitoring and evaluation of the implementation itself, right? To really see if what you're doing is successful, if it makes sense, where to put additional investments if you are falling short of your expectations. So that is an important part as well. And a secondary kind of component, you might have different people responsible for this. Now, looking at these things, you might be thinking, even just these listings here, in some cases, you don't have all of this, like for example, software engineers and test specialists. You know, these are just examples once again, right? If you have access to such resources, of course it is useful, but this doesn't necessarily mean you will have access to all these resources. And if you don't, just take those considerations into heart. Of course, you know, the whole idea is that you're able to perform some of these functions, you know, when you actually go to implement your program. So on this side, if you don't have something that you've seen here, once again, these are just examples, just think kind of locally in terms of the resources you do have. And if you see a function that, you know, you don't really have, you might have some way of addressing that capacity gap, or perhaps doing something in the interim that allows you to address that gap. So if you don't have test specialists, you know, that's not typical of many places, but you might just have people testing the configuration following guidelines that others have provided, perhaps or coming up with their own guidelines in order to test the configuration. Prosper provided some templates, for example, on the test he's done in the past and all the information he's ticked off in order to check if things are working in the way he expected to. So those types of things can help with a lot of this filling in these gaps. If you don't have the right person to kind of meet these needs, then in a lot of cases, you might wanna think about how you can develop SLPs, standard operating procedures, or various guidance and tools to allow people in order to perform those operations in the interim while you try and build that capacity in country, or you know, if you're even considering building that capacity in country, right? So, I'm just... I have a question. Sure, do you have a question? Go ahead. There are a lot of players in this. Do you have any recommendations or experiences of how to get all of these players on the same page? Do you have a meeting with all of these people at the same time? I mean, how do you initiate this kind of role and responsibility kind of at a practical level? Sure, sure. So, there are a couple of things that I can suggest in terms of the coordination. So, I think for me personally, at least, my experience has been that having large meetings, this can happen maybe towards the end of this process, but in terms of initiating this process, I find it's actually much more useful to kind of engage them individually. It requires a bit of running around, but, you know, if you have a big meeting and then let's say you have a document or something saying that this is how things are going to work and people sign off on that document, you know, the reality after the fact is that, you know, things don't really go the way you had planned and you will often find in any case, people really involved in the day-to-day portion of this. It's a really smaller group of people, right? You still need a lot of sign off and you still need to coordinate with a lot of different bodies and groups, but there will probably be a very small team, a small subset at least of these individuals that it's really going to be pushing this forward and make sure it's operationalized. And then of course, there's a huge amount of people that will be using whatever you've done, but, you know, all these different people here, as an example, would not be involved in a lot of the day-to-day operations. So, engaging them separately, I find, works a little bit better, just to try and, you know, people will also have individual concerns that either they might not feel comfortable raising in a shared environment or conversely, if they feel comfortable, it might, you know, might not necessarily sit well with somebody else who has a reservation about what someone else is proposing. So it's always good to kind of try and identify these things beforehand. In the case that you, you know, you as the implementation person or as a person managing that project, it's good to kind of understand, you know, what challenges you might face when you're bringing all these people together, because, you know, there is that component where, you know, some views on these things might differ significantly. It could be anything from, you know, how the data is collected to any types of concerns about the access or, you know, even, you know, just how quickly things need to be done, for example. You know, there could be a lot of tension there from any of these different aspects in terms of different things that are being proposed. So it might seem like a lot of work running around to all these different people and kind of engaging with them. But, you know, having these types of big meetings for me, it works at a kind of larger level to kind of, if you have agreement or if you want to provide updates, for example, that's also a good time to have these larger meetings I find. If you want to update a large group of people all at once, of course you don't want to engage them individually. But, you know, really understanding kind of some of these concerns and just, you know, making a note of them before you get to the point where you're going to bring everyone together, I think can be very helpful rather than kind of trying to kick this off in a large meeting. You know, that's just, you know, this might be a controversial statement, but that's really, doesn't provide you with the information. I mean, that's just to kind of facade in some cases where, you know, you have these large meetings, someone signs the document or something. But at the end of the day, right, then you run into all these challenges when you're actually doing things. And, you know, for me, at least a lot of these tracker implementations that I've been involved in personally, it's a lot of kind of frustration as a result of this, you know, people not being willing to come to the terms of the reality of the situation and kind of, you know, thinking everything will work very well and kind of maintaining that view throughout the entirety of the implementation and not being very flexible in terms of changing that view. So trying to get some of this kind of handle of the forehand is often quite useful. So, you know, I mentioned things like SOPs and things like that. If you have those things in place, you kind of know that, okay, you already have some gaps in the roles and responsibilities, but you already have some solutions to address them beforehand. So when you meet as a larger group, they might not have to be completely written or defined, but you know that you will have to do them. You know, having some of those available beforehand as potential avenues that would deal with some of these things, you know, that's always useful to kind of share with the group throughout the saying, oh, we don't have these things and we don't really know what we're going to do in order to address them. So just thinking through these various things beforehand can often be quite helpful. And I would say also as this process continues, you know, people's roles might change a bit. It's not really, you know, staying in one place at one time, especially if you're a smaller team, right? You might be working on the development. You might be working on the deployment. You might be working on the operations, for example, just as a smaller group. That might also be the management person given that, you know, this whole course is about managing the implementation. So you could have many roles, you yourself or people within your team as well. This is just to try and kind of segment that off, but with the understanding that, of course, some people will just be wearing many hats throughout the course of the implementation. It's not really identifying people so much as it is identifying different roles they might have to play as part of that. And it's good to also be upfront with that, I think. So people understand, you know, the scale of what they're, the scale and scope of what's trying to be achieved and, you know, some of the many different things that they might have to do in order to make this thing happen. If you are a smaller team, but where you might not have, you know, someone individual and individual person working on each of these things. So when you're looking at this and filling this out, you can think of the different roles you might need, okay? I don't think of the roles that you have. Think of the different roles that you might need because then when you're seeing gaps, this allows you to kind of think of what solutions you might need to come up with in the meantime to meet those individual needs. So if you don't have a business analyst or something like that, you know, kind of think about who's going to work with you on the translation of all of your data collection tools, all of your indicators, who's going to work with any type of subject matter expert or if you're the subject matter expert, you know, and things of that nature, right? So even though you might not have that person, someone will have to perform that function, right? And as I mentioned, in some cases, might be just someone who's kind of steps in and does it or it might just be, you know, you might obtain some SOPs or guidance from somewhere else in order to allow you to perform those functions as well, okay? So once again, don't think about what you actually have because that list might not be long enough, but think about what you need and then you can find ways to kind of fill in the gaps and especially when we get into some of the other sessions, especially like the budget and things like that, you know, we can talk a bit more about, you know, how you might actually meet some of these gaps that you're seeing when you identify the different people that you think will be needed to go through this, all right? So I would ask that maybe you have a look at this rules and responsibilities if you haven't yet and try to fill this one out and, you know, if we get some of these shared, we can go through them. If we don't, that's okay, but we can talk a bit more about it, especially when we get to some of the other sections where we can come back to this and discuss how you might meet some of those gaps. But if you are able to just have a look at this and identify, you know, what might be missing from this or what you might want to add or what you might want to modify, that will be useful, I think. And if you do want to share those with us, please feel free to share those within the Slack and we can have a look at them and provide a bit of individualized feedback. And if you're not comfortable sharing, that's okay. We can come back and discuss how we might meet some of these gaps later on when we talk about some of the other sessions on the coming days. All right. So if there are any questions, you know, we can wait around a couple of minutes now and see if you can also ask on Slack at any time or, you know, if this is a bit to think about and you haven't really gotten this far, that's also okay. Just try and have a look, try and fill it out, try and fill in any gaps you might have. And then we can have a look at it together in the coming days.