 Okay, so program access levels is kind of another complementary method to what we've been discussing the past couple days. So we looked at users, particularly user roles and authorities and how they are linked together. We also looked at sharing and user groups and how we can apply different sharing settings to our different user groups in order to allow different levels of access. In addition to what we have discussed on these two concepts, we also have another one called program access levels that gives us an additional kind of mechanism to control who has access to our tracker data. And in particular how our system behaves in response to accessing our tracker data. So, in this session, we want to describe a couple new concepts. All right, and we'll see where we get to today. Once again, I don't want to rush you through all these concepts. Okay. But the first thing we want to do is describe the concept of what we call ownership inside of DHS to. Okay. We then want to describe what program access levels are. Okay, so you might as I say this term, you might not even know what it means and that's completely fine. All right, we're going to define it here together. We then want to describe how the concept of ownership, which is the first concept we will describe, and the concept of program access levels are linked together. Okay. When we do that, we're going to discuss the there's four different program access levels, and we will discuss all four we will see examples inside of the highest two. Okay. And then lastly, we want to show you how you apply these program access levels to your own tracker programs. Okay. All right, so let's start by describing the concept of ownership. Okay. And please ask questions if this is not clear, because admittedly, it's not always immediately clear. Okay. So when we speak about the concept of ownership. Okay, it is used to describe access privileges when reading and writing tracker data within a program. This is in addition to sharing settings. All right. When we do this, we'll get into in a moment. Okay, but really because tracker data, you know, we need several layers of security basically controls. You might not need it in every system. Right, but some systems need more than others. All right. Ownership always starts out as the organization unit that first enrolled attract entity into a given program. All right, so what do I mean by that? I'll just go to the next slide and kind of come back. Right. You'll see the current owner of attract entity in the enrollment widget under the person's program dashboard. Right. So when I go to first, let's just open up. Open up DHS to here. Okay, you'll see this owned by text in the enrollment widget. All right, and what this means is in particular with the first user side of register. Go back to this user. When I register a user or sorry, I register attract entity. I'm registering them into a particular organization unit to start. This is the owning organization unit. Okay, this can change. Okay, but to start, it's where I initially enrolled attract entity into my program. Okay. And you'll see that in that widget widget. Now, when you open a record, you'll see this owned by text. Okay. So ownership can be different for attract entity enrolled in more than one program. Right. So let's say in our example, we've been looking at many different programs. Okay. Mother attends anti natal care. And she attends at one of the facilities that are present. A mother has TV TV care is only offered at one of the hospitals. So they're registered in a hospital. And the owner of that particular tract entity in the TV program is the hospital, not that facility that they're enrolled in anti natal care for. Okay. Because you can have more than one enrollment ownership can be different for different programs across the same track entity. Okay. Hopefully you're with me so far. All right, and just ask away if you're not. Okay. Ownership can also be modified by using the referral, the referral function within DHS to. Okay. So I'm just going to go back here and just let me log into a login with this guy here. Okay, this is my user. Okay, so in DHS to you have this concept of referral. Okay. And if I move them permanently, it will alter the owner of this track entity within this program. And now it's owned by Cardinal Hospital. If I were to permanently move them to Hawk Primary Health Center. Okay, the owner gets updated. Okay. So keep that in mind that you can change the owner from the initial point of entry. All right, and we'll get into this, why this is important in a moment. Okay. This ownership ties to the organization unit assignment that we make when we create a user. Okay, so if you remember from a couple days back, when we were making users we assign them capture organization units analysis organization units and search organization units. And a user that has capture access to the organization unit that is the current owner of a tract entity will also have right access to all the enrollments for that combination. Okay, so if they're given sharing settings to capture data. They also need to be given capture access through their user role, through their user sorry. Okay, in order to enter data for that program. Right. If they do not have capture access for a particular organization unit, then they can't enter data within that organization. Even if they have capture access to the program. Okay. The user that has search access to the organization unit. Okay. That is the current owner of the entity. Okay, we'll be able to find that person. Okay, so they can view the data, but they cannot modify entered anything entered within another organization unit so what I mean is, let's say that a person is in hospital a okay and that's the owner of that person. Okay, and then the second person only has access to search data in hospital a but they don't have access to enter data in hospital a. They will be able to find the person in hospital a, but they will not be able to modify any of the data that's there in hospital a. Okay, so this is how the capture and search mechanisms tie to this concept of ownership. All right. So just remember this is where we can see that ownership and it just really means at the start in particular, where did I register this person. Okay. And if another person entering data can't capture does not have access to this organization unit in their capture settings, they won't be able to enter any data for any tract entities in that organization unit. If they have search access they can find them. Okay, but they won't be able to modify their settings if they don't have the capture access. Okay, if they don't have search access, and they don't have capture access, then they won't even be able to see this individual. Okay, regardless of what other permissions have been assigned. All right. Now this concept of ownership the reason why I described it is because it ties in very closely to the concept of program access levels. And just to kind of review and kind of make sure that it's hit it hits home. Okay, so if I go to a user. Okay, this is what I'm talking about with our organization units. Right. We assign them capture organization units output organization units and search organization units. If a person only has access to certain capture organization units. That's, they can only modify the tract entities or new track entities. Okay. In the organization units they have capture access to. Okay. If they can search for a particular location. Okay, then they can find the track entity. But if they let's say for example here. This person can enter data in these three places, but they can search all of training land. Okay. So in such a scenario, they will be able to, because of the ownership, modify or add any new track entities in these three locations. Okay. But if someone is registered in anywhere else in training land, let's say they're registered in woodpecker health center, for example, this person will be able to find them, because they have search access to them. But they won't be able to modify any of the events or any of the other data that was entered in woodpecker health center. Okay. The reasoning behind that is the owner of this could be one of these other organization units. They have access to search, but not to capture. Okay. So they can capture data within that program and those program stages let's say, but only within these three organization units. Okay. And that's how these, these, these levels link to the user when we create them. All right, I hope, I hope so far, so good. Okay. If not, you know, I see there's a couple of questions in the chat, for example, all right. We'll kind of try to tie this together practically. All right. So we, on top of this ownership, we have program access levels. And as I mentioned, we have this, these kind of additional layers of protection is because DHS to treats tracker data very differently. Okay. And that's why we sometimes, for example, recommend your tracker system is separate from your aggregate system. Okay, that's because there's so much we can do in terms of controlling access to the data. And that might need to be done based on, you know, national guidance or even legal kind of procedures in your country. Okay, to make sure we have proper access to the data itself. So in addition to the standard features of metadata and data protection through our sharing settings, which we've just covered now. Okay. Tracker data can be shielded with one more level of access protection via a concept we call program access levels. Okay. But as I've been kind of mentioning, the sharing settings are still respected. Okay, the user role is still respected. Okay. But then we have this concept of access control through program access levels that adds an additional layer of protection on top of those concepts with all of those settings still being respected. Okay. So there are four access levels that can be configured for a program, open, audited, protected and closed. Okay, and we're going to discuss each of these and the impact this has on the program itself. Now before we get into that I want to kind of, you know, touch on something, maybe a bit more concrete. Okay, so we can see it in action. Right. How do we have these program access levels? What does it actually do? Okay, so in healthcare in digital health records, we have this concept called breaking the glass. All right. And in DHIS2, this concept is associated with the protected access level, which we will get into in more detail. Okay. But as a general concept, this applies not just to DHIS2. Okay, this is kind of a universal kind of electronic health record concept. All right. So breaking the glass is an alert that occurs when, you know, when you access, when an end user access is a record that is considered restricted. Okay. And when this end user breaks the glass, they're required to document the reason why they are trying to access this potentially restricted record. Okay. What we typically mean by restricted and how we define it in DHIS2 is if a person is accessing a record that is outside of one of their organization unit scopes. Okay. So the scopes we set when we create that user. Okay, so if it's outside of the scope and they're trying to access this record, what do we do? Okay. So, well, we have this in place because we want to avoid disruptions in patient care. Okay. Let's say a person is registered in one facility. They go on vacation, they go on holiday, or they go back home, maybe, right. And they attend another facility to continue their care. Right. That that particular user who's accessing the record might not have access to the record through normal means. But there's no reason not to enter or update their record necessarily if they're, you know, following the proper protocols and everything like that. And you need to kind of go through this process of updating that record. Right. So for example, a person could attend your facility without a previous referral. Right. So by that, I mean, you know, they're attending facility B, they started their care in facility A. They did not know they were leaving wherever the location is going home, going on vacation, whatever it might be, and did not inform facility B. So facility B now has to access their record, even though they were not registered in facility B. Okay. Other situations might include other access issues, account problems, passwords, authentication, etc. Right in the field, this does happen a lot. Right. So you just can't log in correctly and then you can't access the record you need because you're the one who has access or maybe you and several other people are the one who has the right level of access, but you're denied because of, you know, some type of access issue. Right. And there are other circumstances that might also occur. For example, the provider is no longer able to provide that service in the in the original facility. Right. There are other kind of systemic problems that might occur that might be a reason for someone to access a record that they did not initially have or not should should not be initially access. All right. So to kind of remove the theoretical constraints around this let's just work through an example. All right. So, what I'm going to do is I'm just going to register somebody. Okay, I'm going to register somebody in one of the programs. I'm going to register them in the TV program. Let's say I'll do it here. Okay. So I'm going to register a new person and take note of where I'm registering them right in Robin primary health center. Okay, so I've registered this person Dan Smith, male 38 years old in Robin primary health center. And let's say, you know, he receives his care. Okay, we identify him as pretty mild TV let's say. So far Dan set he's received his care and Robin primary health center. All right. I'm going to log out of my user want to log in as a different user and I just clear my cash here. And you can see here to start. Okay this user that I've logged in. They only have access to capture data in insect district. And if you remember the person I added Dan Smith was registered in Robin primary health care center. All right. So this is a person who has a different level of access. Dan started his treatment in that health center but he showed up at mosquito district hospital and needs to receive his continuation phase of treatment. He needs to be reassessed assigned a new treatment type and given the appropriate treatment based on that. So I'm going to select the TV program. Oh, sorry. And I'm going to search for Dan. Okay. Now this person can search all of training land, but they can only capture within insect district. So let's just search for Dan here. Mail. Okay, just enter in some of the parameters that I remember from when I registered him. Let's just search for Dan. Now we can see Dan is registered in Robin primary health center, which is not a record that this person has captured access to. Okay, so I'm going to click on this record, and now I'm going to break the glass. Okay, a pop up has came up and said well why are you accessing this record. It's not in your capture scope. Okay. So what I'm going to do now is just, you know, I have to enter a reason then. Why am I accessing this record right and this reason can be accessed later on. Okay, so. So what this is going to do, it's going to give this user temporary access to a record that they didn't have access to, and we'll discuss the implications of that. So add in my message and then select, add audit message. Okay, and then it's going to open this up and I can see, here's the details and Robin primary health center. Now Dan doesn't have capture access to Robin primary health center. He cannot modify any of the details. Okay, in this health center. Right. What you can do though this is the continuation phase, a selective report date. And the second event. I've still elected the same date I apologize, but the second event is now in this users facility. It's now in mosquito district hospital. And this person has capture access in mosquito district hospital. So they can modify the event. Right, so let's just check in here. Dan was receiving community based thought. He's still going to be receiving the same type of treatment. Okay, just reassess his culture and his columns. Okay. This person broke the glass, entered a message to access the record. And then they can register it for a period of time. Okay, so in DHS to the default is three hours. All right. So after they perform this task, or they're accessing this record that's outside of their capture scope. They can access the record for three hours. Now note, this is not the behavior for for all configurations. Right. This is associated with this concept that we call the program access level. Okay. And breaking the glass is associated with the protected program access level. So there are other levels where if someone searches for a person and finds them. And it's outside of their capture scope. Something else will happen. Okay. And we'll go over those differences in a moment. But I just wanted to give you an opportunity to understand, you know, how this gets applied in practice. Right. And I will say, you know, not every implementation requires this for sure. Right. But this is the general health care concept that's been kind of implemented this way within within DHS to. So what I want to do now, I just want to give you the opportunity to interact with this just to kind of see it in action. Okay, so you're going to kind of work through the same steps I did just register somebody new log out log back in search for them. And then you should see the breaking the glass prompt in order to access the record. All right. So, in order to do this. Okay, let's talk about the other. Let's let's talk about each one actually we just kind of briefly describe protected but let's talk about the different program access levels that are available. Okay, then we'll also demonstrate them. All right. So the first level of access and the one you're probably most used to is what we refer to as open access. Okay, the open level of access. It allows anyone to search for an open records for tracked entities within a program within the search organization units that they have been assigned. All right. So as long as I have assigned the search organization unit, I can open the record. I don't have to enter any reason as to why I'm accessing that record. Okay. So this might be the behavior that you're used to in most scenarios. And that's completely fine right if that's what you need to do. Right. A lot of scenarios that's the really kind of accepted way for the program to behave. And that's completely fine you don't need to enter in an audit message or something like this. If you're accessing a record outside of your captured organization units. All right. The second access level is called audited. And this is very similar to open, meaning that I don't have to enter in a reason why I am accessing that record. Okay, when it is outside of my captor scope. But what will happen is when someone accesses the record outside of their captor scope, an automatic kind of recording of this will occur in the system. Okay, on the data that's being accessed by that user. All right, so a new entry will be made kind of in the database log files about somebody accessing a record outside of their captor scope. This user does not need to enter any additional information. Okay, the log entry is created automatically. And the log entry can be found within the database. It can also be found within the API but that gets really messy. Okay, the easiest way to kind of pull it out is within the database. This table I've identified here. Okay. And it's not super easy to admittedly access. Okay, but the idea is that you know when you have some kind of breach or some reason to review your security protocols, then you'd be accessing the audit log. Right. It's not something you do every day, just to check. Right, but when you have a specific problem. I would say that it can't be improved, of course, how you access that log, but just to kind of be aware is in terms of the initial conception of why it's currently implemented this way. All right. Okay, then we have the protected access level. And this is the access level we worked through a little bit. We showed an example of this, where we break the glass in order to access a record. Okay, so this access level. This access level, it is slightly more restrictive, of course, than the others. Right. If I go to access a record outside of my captor scope, I have to enter in a reason as to why I am accessing that record. Right. So data inside a protected program can only be accessed by users if the owner organization unit falls under the captor scope. Right. Unless I enter a reason as to why I'm accessing that record. Right. So I can temporarily gain ownership by breaking the glass. So I search for a record outside my captor scope. I find it, I enter a reason as to why I'm accessing it. And now I have three hours to access that record before I have to do it again. Okay. And then it has to provide a justification as to why they're accessing the data that they see. Right. And some of you might have seen this if you had an opportunity to work through the exercise. If not, you would have seen it during the demonstration. Okay. Now note that when you break the glass, the owner organization unit does not change. Okay. So the person in my case I've accessed Dan Smith's record from Mosquito District Hospital. Okay. He was registered in a different in Robin Primary Healthcare Center. Right. The ownership maintains itself. So the dance myth is still owned by that Robin Primary Healthcare Center. It's just that one event that I added that's in Mosquito, for example. Okay. So one important thing we have to consider also. Okay, depending on your implementation. This feature does not work in Android. Okay. So whether or not the captor scope is defined or the access level is defined. Okay. Basically, if I set it to protected and the person tries to access a record outside of their captor scope, rather than finding it and entering a prompt, you won't be able to open the record. Okay. So on an Android device. So just keep that in mind. Right. If you're implementing Android or thinking about that in your own setting. Okay. The final level of access is what we call closed access. And this is by far the most restricted access. Okay. So data recorded under a program with the access level closed will not be accessible if the owner organization unit. So either where the person was initially registered or where they've been referred to does not fall within the user's captor scope. Okay. It is also not possible to break the glass or gain temporary ownership in this configuration. So you can search for it and then open the record, enter a reason why you're accessing the record. Okay, that only works for protected access. Okay. It is still possible via closed access to transfer the ownership to another organization unit, however, right, but only a user who has access to the data initially. Okay. So they have to have capture access to the data in order to do this right they can move it via a referral for example, but only if they have capture access to the organization unit where this track entity is registered. Okay. But otherwise, people outside of this, they won't be able to open the record if it's if it's registered somewhere else or if it's, you know, in another organization unit essentially. Okay. So, let's see how this looks in practice. All right. So I'm just logging in that same restricted user. Okay, and what I'm going to do is I'm going to perform a search in a different program. Now this program is set up for open access, open access means that I can search for people outside of my captor scope. And when I go to open their record, the record will just open. Okay. So let's search for somebody already there. See here, Jaden here. He's registered in Cardinal Hospital. Okay. This person does not have Cardinal Hospital in their captor scope. Right. But when I go to open the record, it just opens. Right. Because there's no access level applied to this program. Right. I'm looking at a different program now the immunization program. The record just opens as it should. Okay. And depending on how you want this to work. That's certainly a valid configuration. All right. The same thing happens with audited. The only difference is a log entry is made in the database. Okay. But the behavior that the user sees is exactly the same between open and audited. The only differences in the background with audited we have a log entry that is added to the system to the database. Okay. I can go back one more time. And then I'm going to switch to the antenatal care program. Okay. Now this program is configured with closed access. This means any person outside of my captor scope. I won't be able to open their record. So if I go to search for somebody, I'm going to search for this individual. She's registered in Cardinal Hospital, which is once again outside of my captor scope. I'll click on this record. And I cannot open it because this is configured as closed access. So says no access to track entity instances outside of my assigned data capture organization units. Now I admit that message is not clear, especially if I'm an end user. Okay, probably something we can improve upon. But what it's saying is the person does not have access to the individual that you found, because it is not within their captor scope. They don't have data entry access to Cardinal Hospital Gateway. Okay. They don't, they can't enter data there. So they can access this record. Sorry. That's the way the programs configured. All right. So what I want you to do. Okay. Is just give this a review by looking at exercise too. Okay. And as part of this review, you're basically reviewing both open and close access. So you had a chance to review protected access by looking at the breaking the glass concept. All right. And now I'd like you to review the open and the close level of access. All right. So, okay, so let's just summarize what we've learned so far. Okay, putting together the concepts of ownership and program access those. All right. So ownership and program access levels decide what happens when a user accesses attract entity instances, attract entity instance sorry. That's been enrolled. Sorry, I need to clean up that text that's been enrolled in a given program. Right. Okay, a user can access attract entity attract entities program data. If the corresponding owner organization unit falls under their organization unit scope. Right. So what I mean by that is, if they have access to capture individuals in certain organization units, then they can automatically kind of open up the record and modify data, right, with the proper sharing settings applied. Okay. If they only have access to search for a person that's not within their capture scope, then ownership and the program access level will then determine what happens. Okay. For program access levels that are configured with an access level of open or audited. The owner organization unit has to be within the user's search scope. Right. So as long as a person can search. Or has the organization unit within their search scope and the program access level is set to open or audited. They will be able to open the record. Okay. For programs that are configured with the access level protected or closed. The owner organization unit. Okay, so where they were initially registered or where they've been referred to permanently. So it has to be in the user's capture scope. Right. So if it's closed program as you would have saw with the ANC program, and it's outside of your captor scope, you can't even open the record. If it's protected, you will be able to access the record, but you need to enter a reason as to why you are accessing that record. Okay. We can temporarily override this privilege through the protected level of access. Right. If they're outside my capture scope, but within my search scope, I can find them and I can perform this operation we refer to as breaking the glass. All right. And this access is granted for three hours. I saw there was a question about, you know, can we modify the time. All right. I think this has to kind of modified at the application level and not 100% sure how that would be modified to be honest. I'll try to get back to you on that. All right. Okay, but the default is three hours and then I'm not 100% certain how to modify that. Okay, I'll try to get an answer for that. Okay. So we have access to audits breaking the glass, along with the reason specified by the user, and this is accessible via the database. Okay. However, it's not possible to gain temporary access when the access level is set to closed. Okay. So we have these four levels, we're going to describe how to set them up now. Okay, but when the programs are configured in certain ways. We can see these different things happening. We can open the record pretty easily with open and audited access. Right with protected access we can open the record, but we need to say why. Okay, why are we accessing this record. If it's closed, we won't be able to open the record at all. If the organization unit is outside of our captor scope right the owner organization unit is outside of our captor scope. So hopefully, maybe the full thing isn't clear in your mind, right, but the ideas of ownership and program access levels are tied together, right. The ownership determines, you know, what's the owner, owner organization unit is, and then the protected, and then the access levels determine what happens when someone accesses someone who's owned in a particular organization unit based on their captor or search scope. Okay. So what we're going to do now, I'm going to switch gears a little and talk about how this is configured. Okay, so we've seen how it works. Right now let's talk about how to set it up. So for the moment, I'm still in the demo system. Okay, I'm still in my demo system here. I'm going to log out of this user and log into my admin user. And I'm going to go to my program list my program so we looked at three different programs anti natal care, the TV treatment card and immunization. Okay, now let's start from kind of easiest to most difficult. So the immunization program was open. And go to immunization. And there's a little tab that we skipped in our initial configuration. Okay, when we are working through creating our tracker program called access level. Okay. And this is where the access level is chosen for our program. So if I select this you'll see the four levels that I mentioned open, audited protected and closed. Okay, and hopefully this is starting to bring things from full circle. Okay. So I had this set to open. When I searched for a person in the immunization program, I could just access the record, as long as it's within my search scope. Okay. If I look at the other programs, like TV treatment card. This is where we had to break the glass. It is set to the protected level of access. This is this means if a user looks for somebody outside of their captor scope, they have to enter a reason as to why they are accessing that record. Okay. If we go to the anti natal care program will see the same thing at the access level. It's now defined as closed. All right. And this means that I cannot access any records that are outside of my captor scope. Right, even if I can find them through my search scope. So we use this program access level. This tab access level to define which program access level we want to give to the program. All right, so so far pretty straightforward right, we select an access level, and that has implications on what a user can do when they access the tract entities in my program, based on the ownership of the tract entity they're accessing. All right, we combine this with everything we've discussed about our users so far. So this includes sharing settings because those are still respected. This includes the user role they have access to this includes all the different organization units that that user has been assigned to. So if I go to users here, not just find the user that's been doing all this stuff for us. Okay. So I'm going to scroll down. And we review this a little bit. Right. Have a look at this user right there data capture organization unit is insect district. So they're able to capture data for any of the facilities within this insect district, but anything else will be outside of their scope. Okay. And based upon the program access level that we configure either open audited protected or closed. Okay, it's going to define what happens when a person looks for a record. Okay, the next closely related one is their search scope. Right. Here I've said this person has access to the entire country. That means they will be able to find anybody. They'll be within the programs, regardless of the access level. Okay, but they'll be only able to open ones based on the access level that's been defined. Right. If they had access to less search organization units. For example, if I said insect district, instead of training land. Then these access levels are really not as applicable. Right. Because they can only find people within the same organization units that they register somebody. So they have to have a larger search scope in order to find these individuals. Right. If I register somebody in hospital a, and then I look for somebody for a user who only has access to hospital be. They need to be able to search within hospital a right. If they don't have access to search within it, then they won't be able to find anybody in that hospital. So, if I want to give them a broader search scope like this, then they'll be able to find anybody within any within anyone who's owned by these organization units in this region. So any facilities in all of these districts, for example, or I could say the country. Okay, allowing someone to find anybody registered in the country. All right, then the access level will subsequently determine what happens when they access the record. So if they if they look for anybody inside of insect district. They'll just be able to open that record. Okay, no matter what the access level is. Okay, because they have full capture access to this to this hierarchy individuals in this hierarchy, and they have full search access across the entire country. All right. And then register somebody in another organization unit and that's the example we were going through any of these other organization units. Okay, then the program access level is going to come into play. Right. So this person can only capture data within this organization unit. But if they look for somebody in Panther Health Center for example, okay the access level will determine what happens. Will they be able to open the record. Will they have to enter a reason as to why they're accessing the record. Will they not be able to open the record at all if it's close level of access. Okay, so we start to kind of put all these components together in order to build up access to the data in our system and you know control what people can do basically. Right. Keep in mind that all these program access levels are dependent on them having sharing settings applied to their user. Right. They need the program shared with them. Otherwise they won't be able to see it. They need can capture and view access to different components of the program, or they won't be able to do anything. Right. So if this person doesn't have access to the track entity type, then you know none of this matters right you can set up the access levels but they won't be able to do anything. So all those other sharing all those other settings are still respected, they still have user roles that are respected, and they still have user groups that they're a part of that are respected where the sharing settings that are applied are respected. And on top of this, you have the program access level and the ownership organization unit, but as theoretically if you need it. Okay, another layer of protection. So we combine several different concepts in the end to allow us to determine, you know what level of access people have to track our data in the system right and we can be very specific using these different layers right be a user roles user groups and sharing, and then our ownership and program access levels. Okay, so it's quite a few concepts but when we link them all together. Okay, we can really be specific. And that's the whole thing right we have personal identifiable information in these tracker systems, and we have different protocols and procedures for accessing this information in different contexts. Okay, so depending on what you need to implement and do right sometimes you can just ignore these access levels right. So let's say 70% 80% of your programs, it's just open access right, and that's, you know, it can be the case in many places, right, then you don't need to think about it so much, right, but from time to time if you need more information, why people are accessing records. In certain situations, you know, then these access levels really, really come into play. All right. So, sorry, didn't want to go there. So just remember to think about that when you're creating your program. Okay, by default, if I don't click anything. So I created a new program. It's not going to have anything and it's not a mandatory field you can see right. It's just going to set it to open by default. So if I were to add in all my other details and save my program by default it sets it to open. Okay, so if I don't need to kind of consider it too much. And that's fine, right, only in situations where maybe I need specific levels of access controls. You know, then I would want to modify, right, because it's not a mandatory field so you don't need to kind of it'll just set to open by default. All right, but you can of course modify this, just keeping in mind, you know, to get the behavior you want, make sure your users are also configured correctly. And your sharing settings are applied correctly. Right, because without that it'll be quite difficult.