Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Healthsites data model
Healthsites attribute list
Healthsites is working to establish a global commons of health facility data with OpenStreetMap. The International Hospital Federation have specified our current attribute list. We are currently re-visiting this list and looking at how it integrates with OpenStreetMap. In addition we are interested in understanding the OSM tagging structures that support Health outcomes for Women and Girls and people with Disabilities.
Healthsites is part of a consortium mapping the Risk of disease outbreaks. In the context of understanding the capacity of Health facilities we are interested in WASH scores of Health facilities and Onehealth.
healthsites.io upload CSV
.CSV template of healthsite.io attributes
healthsites.io survey form
Health facility tagging within OpenStreetMap
This is where we are working to update the Healthsite attributes to align with OpenStreetMap https://github.com/hotosm/health/wiki/Health-facility-tagging-within-OSM-(proposal)
OpenStreetMap attributes in support of women and girls
People with Disabilities
Water, sanitation and hygiene (WASH) in health care facilities
Kathmandu Living Labs/exposuresurvey
Healthsites data model concepts
- Every attribute can have one or more associated validators,
- validator functionality can range from a simple:
- email address should look like an email address
- to more complex which even rely on external services like: check if the Locality address is similar to results returned by external geocoding services
- or check if the telephone number is correct by manually calling the number and verifying
Due to the nature of validations, most will be executed as asynchronous tasks, which will as a result create more validation tasks that require user feedback, for example: a Locality similarity validator might detect two similar Localities so a user needs to manually mark one of the similar Localities as duplicate LVI calculation will be based on all collected history of changes, validator results, user reputations, ...
Flexible data model and import process
A Locality is defined by its Domain.
Domain defines a common theme for the data, for example: Health, Sanitation and Education, might be considered as unique domains.
Every Domain is associated with a set of Attributes through a Specification. For example, an Attribute 'name' can be associated with 'Health and Education Domains', but for the Health Domain, a 'name' attribute might have a different set of validators to those used in the Education Domain. Values are stored for each Specification for a particular Locality.
Definition of the healthsites attributes
The data model was inspired by the OpenStreetMap data model that enables users to store information about anything. It’s also based on Entity–Attribute–Value model ideas. FullTextSearch index has already been implemented, and it enables searching for textual data.
The importing process is based on a similar approach, a user needs to define an attribute mapping file for Attributes that are going to be imported. These attributes are defined as either mandatory, core or other. We work with organisations to prioritise these and only import mandatory and core attributes.
Clustered location rendering
As we expect a lot of data, we opted for server based clustering approach. First of all we have full control of what actually gets clustered, as some search queries might return a lot of data, or some data is only visible for certain users. Clustered rendering minifies amount of data transfer between client and the server, which is nice for areas with limited connectivity or slow ‘mobile data plans’.
- Track user activity and validate contributions, use accumulated ‘points’ as a social currency to start building a network of reputations.
- Network of reputation will serve as a basis for calculating Locality Validity Index (LVI) - key indicator of a Locality information quality.
- Enable user to define “areas of local knowledge” - contributions in those areas will contribute more to the LVI.
- Location Validation Framework
- Each change in state should be accompanied by a uniquely referenceable version state for that record. e.g. https://healthsites.io/map#!/locality/8c86327b0ef84dda89c310cb739d0604 / 1 would give the status as at version 1 of the record identified by UUID 8c86327b0ef84dda89c310cb739d0604