Home

The Open Health and Demographic System (OpenHDS)

The OpenHDS maintains a consistent record of significant demographic events that occur to a population in a fixed geographic region, generate up to date registration books, and compute basic demographic rates (births/age, deaths, etc). OpenHDS also provides a mobile component where data entry can be performed while in the field. It provides an intuitive and easy way to record populations and their changes over time. The OpenHDS logically breaks down the geography of an area of study and captures the major demographic events within it.

The Hierarchy

The first thing to understand is the way the OpenHDS represents the area of study for a project. For every geographical location there exists some way to represent that location hierarchically. The regions, districts, prefectures, cities, etc that comprise the area of study are each represented in the OpenHDS by an entity called LocationHierarchy. There is one Root LocationHierarchy that represents the largest geographical denomination for the area of study. Underneath the Root is a LocationHierarchy for every other geographical denomination, each of which points to their 'parent' which forms a tree-like structure that represents the entire area of study. The benefit of organizing a study area into a hierarchy of locations is easier to understand once the concept of the Fieldworker is understood. The OpenHDS is a system that relies on data being collected in an area of study. To help keep track of who collected what and when, the FieldWorker entity is needed. Almost all of the entities in the OpenHDS are collected either directly or indirectly by a FieldWorker and thus all are dependent on the FieldWorker. The LocationHierarchy provides a logical and efficient means of navigating through the tremendous amount of data that can be collected during a project's lifetime. A FieldWorker is generally representative of the interviewer who is physically traveling from location to location within the hierarchy and collecting the demographic information. Now that the study area is broken down logically into a hierarchy within the OpenHDS the demographic data has a geographical context as well as 'collector' as represented by the FieldWorker. Every piece of information within the OpenHDS is tied in some way to the hierarchy, just as a population and its changes over time are tied to their geographical location.

The information in the OpenHDS comes in 3 main flavours.

1. Census data: people, the places they live and the groups they belong to.
2. Relation data: information about how people are related to one another, members of groups, or resident at a location.
3. Update data: records of events that change the census data over time.

The Census Entities are Location, Individual, and SocialGroup.

• Locations are particular points of interest within the study area. Locations are the leaf nodes on the hierarchy described above; there is nothing below them because they are most atomic geographical denomination. Examples of Locations could be buildings and houses.
• Individuals are the people within the area of study, i.e. the population. Since the OpenHDS is primarily focused on demographic information, many of the other entities and events within the system are dependent on individuals.
• SocialGroups are the societal or cultural organizations that the people in the area of study are a part of. Examples of SocialGroups are church groups, families, book clubs, etc.

The Relation Entities are Membership, Relationship, and Residency.

• Memberships are what tie an Individual and a SocialGroup together; a Membership is made for every SocialGroup a person a part of. An example of a Membership is being a member of a particular family.
• Relationships are what tie two Individuals together; a Relationship can be made for each way an individual is related to anyone else. An example of a Relationship is being the son of someone, being the pastor of someone, or being someone’s lawyer.
• Residencies are what tie Locations and Individuals together; a Residency is made for each Location an Individual is a resident at. An example of a Residency is being a resident at your house (a Location) and perhaps your parent's house (A different Location). The act of visiting the population is modeled explicitly within the OpenHDS with an entity called a Visit. All of the Update event entities are dependent on a Visit. However, a FieldWorker can resurvey a group within the study area and create a visit, but find that nothing has changed thus leaving the visit empty.

The Update Events.

Collecting information about the who and what within an area of study is powerful, but no population is static, things change over time. The OpenHDS provides functionality to capture these changes via a well-defined set of what it calls Update Evententities. Specifically, the OpenHDS is concerned with the coming and going of Individuals to and from the area of study. In general this is only possible by one of the three ways shown in Figure 1: an Individual migrates in or out of the area of study, an Individual is born into the area of study, or an Individual dies while in the area of study. The OpenHDS models these three events in more detail than what is shown in the diagrams and is explained below.

• An InMigration is the migration of an Individual into the area of study. This can come in two flavours: Internal or External.

  • An Internal InMigration is when an Individual migrates from one place within the study area to another place still in the study area.
  • An External InMigration is when an Individual comes from outside of the area of study and migrates to a location within it.

• An OutMigration is the migration of an Individual to outside of the area of study. Examples of migrations in general would be an individual who accepts a new job outside of the area of study and moves to be closer to it, an individual marries another individual and moves from one place to another within the study area, etc.

• Pregnancies are complex multi-stage events in the real world and so in the OpenHDS are modeled differently than the other Update Events. A pregnancy has three discrete event entities: PregnancyObservation, PregnancyOutcome, PregnancyResult.

• A PregnancyObservation is the initial record of the pregnancy by a FieldWorker.

• The PregnancyOutcome is a record of what the outcome of the pregnancy was, this includes information about actual delivery date and the number and type of births the pregnancy yielded.

• Finally, the PregnancyResult (Outcome) is a record for each birth from a particular PregnancyOutcome.

• Lastly, a Death is the death of an individual and the last way an individual can leave an area of study.

Once again, all of these things are dependent on the Visit as well as the FieldWorker who collected the data. The rest of the Update Events operate on this same basic principle of visiting a Location within the hierarchy and recording the events that have occurred at that Location since the last visit.