Healthsites data model

Mark Herringer edited this page Jun 4, 2018 · 45 revisions

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.

Humanitarian Data Model

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

https://github.com/healthsites/form-templates

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

http://wiki.openstreetmap.org/wiki/Tagging_in_Support_of_Women_and_Girls

User stories

https://github.com/healthsites/healthsites/labels/women%20and%20girls

People with Disabilities

User stories

https://github.com/healthsites/healthsites/labels/disabilities

Water, sanitation and hygiene (WASH) in health care facilities

"water_source": "tubewell"

https://www.washinhcf.org/home/ http://wiki.openstreetmap.org/wiki/Humanitarian_OSM_Tags/WASH

User stories

https://github.com/healthsites/healthsites/labels/WASH

Veterinary Health

http://www.onehealthinitiative.com/

User stories

Other links

Kathmandu Living Labs/exposuresurvey

http://wiki.openstreetmap.org/wiki/Kathmandu_Living_Labs/exposuresurvey#Health_Facility

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.

Healthsites attributes

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

Data model

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’.

Planned features:

  • 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
Clone this wiki locally
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.