5.1.3. Data elements and classification tables

GeoPrism Registry focuses on all the information that allows to contextualize any piece of information in both space and time. It therefore only handles data elements meant to:

  1. Uniquely identify,

  2. Classify,

  3. Locate, and

  4. When applicable, contact

each geographic object it contains (the set of data elements referred to as the signature domain; see Health Facility Technical Working Group (2007)). Such a list will be specific to each type of geographic object hosted in the platform.

Other types of data elements, including programmatic ones (e.g., statistics), are not meant to be managed in GeoPrism Registry but in program-, or even sector-, specific information systems. Some of the reasons behind this are the sensitivities often linked to programmatic data, the difference in data flow between this type of data and the geographic objects they are attached to, as well as the difference in the management of the time dimension (e.g., the temporal validity of a statistic might be different from the temporal validity of the geographic object it is attached to). In addition, managing these data elements in these other systems allows the programs to benefit from functionalities that are not available within a registry, including, but not limited to, data collection, statistical analysis, or visualization (graphs, thematic maps).

The identification of the data elements to be associated with each geographic object and stored in GeoPrism Registry should take place as part of a process involving all concerned stakeholders. The result is a data dictionary containing at least the following information for each of the selected data elements (an example for a health facility master list is presented in Annex 2 of Ebener (2022)):

  • The data element code as implemented in GeoPrism Registry

  • A short description of the data element

  • The data element type

  • The size of the data element (number of storage units)

  • Whether the data element is considered as mandatory when adding a new record in the master list

Examples, notes, and, when applicable, the source (reference) of each data element can be added to the above information if it can help those in charge of managing GeoPrism Registry content and its users to have a clear understanding of each of these data elements. A classification table also needs to be defined for each of the data elements where the values are limited to a few options to ensure consistency across records, for example, type, ownership, etc. Such tables should at least contain the following for each option: a unique code, a label (English and local language) and/or acronym, a description (English and local language), and, when applicable, the source of the definition. The following table provides an example of a classification table for health facility types in Cambodia following this structure:

Last updated