Konvence pojmenování¶

This document describes overall naming conventions and recommendations when creating DHIS2 metadata as part of an integrated HIS (tracker or aggregate). To the extent possible, these conventions are applied across UiO-developed configuration packages.

General guidance for naming DHIS2 objects¶

Obecným principem je navrhnout datové prvky a indikátory, které lze efektivně použít pro analýzu. Obecně platí, že množství koncových uživatelů interagujících s těmito položkami bude mnohem vyšší než u správců systému. Výsledkem je, že snazší rozpoznávání a hledání položek je obecnou páteří navrhovaných principů. * Shorten and simplify names/short names where possible, for example, there is in general no need to include “Number of...” and similar phrases, in particular for aggregate data elements where practically everything is numbers. * Provide a meaningful & concise name: put the key information early in the name, as long as this can be done without making it hard to understand the meaning of the name * Consider which users will see names/short names of various objects, and which apps they interact with. Remember: users can configure their user accounts to view long or short names in apps. * Names (long names) should include prefix & suffix as applicable, to facilitate ordering of metadata and filtering for analytics and admin users * Short names are limited to 52 characters; make these as meaningful as possible with consideration for the end user who accesses these objects through the analytics apps * Form names: form names for data elements should be optimized for the data entry user. These names appear in the data capture apps and should provide a sufficient level of meaning and clarify for the person entering the data guidance. The length of these names should also be considered. For Android implementations, implementers should consider how these names render on a mobile device * Most analytics users primarily interact with dashboard items, data elements, indicators, CategoryCombinations configured as a data dimension, legend sets.

Programme specific vs generic/shared metadata¶

DHIS2 is broadly used as an integrated HMIS, combining data and metadata from multiple health areas and programs into a single system. It is therefore important to be explicit of what disease/programme certain metadata refer to. For example, a name like “Case incidence rate per 100 000 population” could refer to malaria, TB, cholera etc. However, it is also important to ensure that some metadata can be shared across diseases/health areas.

To facilitate harmonization of metadata, we recommend the following prefixes to be applied to long names of metadata objects such as data elements and indicators (but not to ‘short names’ or ‘form names’’) depending on whether the metadata is specific to a certain program or shared across programs. * Metadata that is specific to a health program/disease should be prefixed with a consistent prefix code to represent the health programme/disease or other logical grouping of the metadata: * e.g. TB, MAL, HIV, EPI, RMNCAH, CRVS, etc * Metadata that is shared across health areas/programs should have a more generic pre-fix to signify metadata that is generally considered to be re-usable or shared metadata * e.g. UiO HIS metadata packages use the prefix ‘GEN’

Examples of naming¶

Example of good naming practice for a data element: Ensure the most important part of the name is what is determining the order of the data elements in an ordered list:

• ANC 1. návštěva
• ANC 2. návštěva
• ANC 3. návštěva
• Návštěva ANC 4.+

To umožní, aby se položky objevily společně v rámci tematické oblasti; jsou také v pořadí od prvního do posledního, jak je zamýšleno.

• Pokud se rozhodne použít známou nomenklaturu pro krátké formy běžné v programu (obvykle pro datové prvky nebo indikátory), vyberte jednotnou metodu pro všechna metadata dat (např. P., Pl. nebo Plasmodium).

Example of poor naming practice for a data element: Number of pregnant women who make first ANC visit.

• Počet obecně není nutný. Rozumí se, že se jedná o číslo uváděné v měsíční zprávě, a tím se prodlužuje délka názvu.
• Těhotné ženy jsou redundantní. ANC navštěvují pouze těhotné ženy.
• První návštěva ANC je klíčovou informací a neměla by být na konci názvu.
• V ideálním případě by vám první část názvu měla umožnit seskupit podobné datové prvky do seřazeného seznamu.

Pokud zkontrolujeme návštěvy ANC 1 - 4, můžeme použít:

• První návštěva ANC
• Druhá návštěva ANC
• Třetí návštěva ANC
• Čtvrtá návštěva ANC

V běžném jazyce to dává smysl, ale pokud se zkombinují v uspořádaném seznamu (například v aplikacích pro analýzu DHIS2) s jinými datovými prvky, nebudou v seřazeny ani seskupeny.

Numbers as part of names¶

• Méně než (nebo rovno): použijte 0–4, ne 0 - 4, < 5, <= 4, ≤ 5
• Více než (nebo rovno): použijte 15+, ne >14, >= 15, ≥ 15
• Intervaly: použijte 5–14, ne 5 - 14

Datové prvky¶

• Datový prvek názvu by měl mít předponu se zkratkou / kódem zdravotního programu / oblasti, např. TB, MAL, HIV, EPI atd.
• Datové prvky obvykle představují hrubý počet hodnot, proto se předpokládá, že pokud datový prvek nemá žádný postfix označující, o jaký typ hodnoty jde, jedná se o surové číslo (tj. První návštěva ANC - není k dispozici žádný postfix, takže můžeme předpokládat, že hlásíte počet návštěv ANC).
• Pokud sbíráte nějaký typ míry, podílu atd. Přímo jako nevypočítanou hodnotu dat (tj. Jako nezpracovanou hodnotu prostřednictvím procesu sběru dat), mělo by to být označeno přidáním krátké postfixu v závorkách na konec dat název prvku.
• Pokud je to možné, můžeme z datového prvku vyloučit prostý text, pokud to není zjevně smysluplné, když je zkontrolováno jako výstup ke zkrácení názvu (tj. „Počet případů malárie pozitivní s RDT“ lze změnit na „Případy malárie pozitivní (RDT)“) aby byl v analýze čitelnější výstup.

Indikátory¶

• Datový prvek názvu by měl mít předponu se zkratkou / kódem oblasti zdraví / programu, např. TB, MAL, HIV, EPI atd.
• Indikátory jsou výpočty, které používají kombinaci datových prvků k vytvoření výstupu pro analýzu.
• Pojmenování se od datových prvků často liší názvem samotného indikátoru (tj. Pokrytí ANC 1. návštěva vs. pokrytí ANC 1. návštěva (%))
• Mohou být o něco delší než názvy datových prvků kvůli přidání postfixu označujícího typ indikátoru, o který jde.
• Indikátory by neměly začínat znakem % na začátku svého jména. V seznamu budou neuspořádané.

• (assets/indicator_perc_prefix.png)

• V popisech lze použít dlouhé názvy, jako je poměr nebo procento, ale neměly by být zahrnuty do názvu indikátoru. Vidíme, že to přidá další text na začátek názvu. Také to seskupuje položky podle „podílu / procenta“ spíše než podle identifikační charakteristiky (tj. Ohniska, případy malárie, typ malárie).

• Pokud přidáme %, protože postfixové položky jsou uspořádány smysluplnějším způsobem, název se zkrátí a zbytečné mezery na začátku názvu se odstraní

Oblíbené¶

• Oblíbené názvy: Opatřete předponou oblíbené názvy názvem oblasti / programu a hyphen, e.g. TB - Case notifications..., MAL - Incidence rate...
• Oblíbené tituly: Tituly nepotřebují předpony, protože se nepoužívají k vyhledávání.

Sady možností¶

Obecné / opakovaně použitelné sady možností by měly mít pokud možno obecné názvy. Například pokud je pro výsledky testu HIV potřeba sada s možnostmi „Pozitivní“ a „Negativní“, měla by být pojmenována „Pozitivní / negativní“ místo „Výsledek testu na HIV“, aby mohla být znovu použita. V případech, kdy existuje možnost, že by mohlo být zaměněno několik předmětů nebo jsou podobné, ale ne stejné, mělo by to být výslovně uvedeno, například „výsledek léčby TBC“, „výsledek léčby malárie“.

Kódy¶

• Před všemi kódy by měla být uvedena zkratka / kód programu nemoci / oblasti a podtržítko, např. TB_, MAL_, HIV_, EPI_ atd.
• Kódy by měly být psány velkými písmeny.
• Pokud existují kódy pro konkrétní oblast programu / choroby, měly by se použít. Vždy by však měli mít předponu se zkratkou / kódem pro danou oblast a uvést velká písmena).
• Pokud jsou vytvořeny nové kódy, měly by se řídit těmito pokyny:
  • Měly by být použity pouze alfanumerické znaky a podtržítka.
  • Pokud je to možné, kódy by měly mít smysl (např. „HIV_TEST_POS“ spíše než „HIV_T01_“).