 Creating new metadata in DJI-S2 is often a straightforward process that can be done quickly via the user interface. However, one of the challenges of setting up a functional DJI-S2 system is that many people can potentially contribute to it by adding or modifying these metadata. Without close coordination between those users, we can end up with a system that is difficult to navigate and where it is hard to find what you need. In this video, you will learn about one crucial aspect of maintaining a well-functioning DJI-S2 system, following clear standards for naming metadata. Let's take data elements as an example. When creating new data elements, a standardized method of naming them should be followed by all users of the system. This will mean some coordination both within and between different programs or services as necessary. Where no protocols are being followed, the users may find it difficult to locate the items they need. If they can't locate items, they may create duplicate copies of them out of a belief that they do not already exist in the system, leading to system clutter and confusion for other users over which of the duplicate items is the correct one to use. This issue will compound itself over time as more data elements are added to DJI-S2. To prevent this issue, you can apply some key principles to make it easier for end users to locate the data elements they need. The first principle is to avoid unnecessary information. For example, there is usually no need to include phrases such as number of in data elements. Remember that data elements typically have numerical values, so we can assume it refers to a number unless otherwise stated. The second principle is to put the key information early in the name. For example, we should say malaria cases positive instead of positive malaria cases. Why does this matter? Putting malaria first will help us sort all of the malaria program related elements instead of all the positive cases from different diseases. The third principle is to be explicit about the program that the data element belongs to if it could belong to more than one. Because DJI-S2 is an integrated system with information for many different types of data, it is necessary to be explicit about the area or program for each data element or indicator. For example, the indicator case incidence rate per 100,000 population is unclear, because it could refer to malaria, TB, cholera, or other programs. We should put the specific health program at the start of the indicator name to make it clear which one it refers to. Let's see what this looks like with an example. We would like to apply good practices to the naming of the data element, number of pregnant women who attended their first anti-natal care visit. First, we can exclude number of. We understand that we are referring to numbers in the realm of aggregate data collection unless specified otherwise. We also don't need to mention pregnant women in the name at all since anti-natal care visits only concern pregnant women. We can also cut out who attended there as it is assumed. By cutting any unnecessary words, we can keep it short and simple. If we decide that we want to retain more descriptive information about the data element, we can include it in the description field instead of the name. Second, identify the key information and put it at the beginning of the name. After cutting the words down, we are left with first ANC visit. Let's think about the particular order of the words first and ANC visit. Conventionally, first ANC visit would be the first of a series of visits. There would likely be additional related data elements. For example, first ANC visit, second ANC visit, third ANC visit, and fourth ANC visit. Although this makes sense in plain language, when applied to DHS2, this might not work as well because the data elements in DHS2 are alphabetically ordered. It means that in a list of data elements, they would appear in this order. First ANC visit, fourth ANC visit, second ANC visit, and third ANC visit. If there are many other elements in your system, your ANC elements might end up separated in a list and would be harder to find. We recommend keeping related data elements together where possible. We can change the name of these elements so they start with the essential part of the name. Let's put ANC first so we get ANC first visit, ANC second visit, ANC third visit, and ANC fourth visit. This will allow the items to appear together. However, they still won't be in the correct visit order. To ensure they are in the visit order, we can change the words first, second, third, and fourth to numerical abbreviations. So we have ANC first visit using the 1ST instead of the word first, ANC second visit spelled 2ND, and so on for the third and fourth. With this final change, the data elements will be correctly ordered from first to last and will be kept together as a group within an alphabetically ordered list. Lastly, we could add a prefix that indicates the program this data element belongs to. Since this element belongs to the reproductive maternal newborn child and adolescent health program, R-M-N-C-A-H in short, we can add the prefix R-M-N-C-A-H to the data element. We would then have R-M-N-C-A-H ANC first visit. In particular, this will assist system administrators as it will allow them to find and group data elements together for various maintenance operations. In summary, when programs, services, and individuals use different procedures for naming data elements and other metadata in the system, the result is often a system that is difficult to use. Using naming conventions when creating metadata can help mitigate these issues. These best practices include avoid unnecessary information, put the important information early in the name, use the same prefix for related data elements to keep them together, and include a program prefix before the name of each data element.