Global Healthsites Mapping Project
Project Overview
When a natural disaster or disease outbreak occurs there is a rush to establish accurate health care location data that can be used to support people on the ground. This has been demonstrated by events such as the Haiti earthquake and the Ebola epidemic in West Africa. As a result, valuable time is spent establishing accurate and accessible baseline health data. Healthsites establishes this data and the tools necessary to upload, manage and make this data easily and readily accessible.
Through collaborations with users, trusted partners and OpenStreetMap, the Global Healthsites Mapping Project aims to capture and validate the location and contact details of every health facility, and make this data freely available under the Open Data License(ODBL). The project outlined in this wiki focuses on the development of an OpenStreetMap data model that can be used in Healthsites.io to capture the data for both platforms. This wiki page also outlines some examples for best practices when tagging health facilities, as well as providing overall context to the Healthsites initiative and linking to other pages for creating and sharing this data.
Goals & Deliverables
The overall aim of Healthsites is to have a system that enables long term curation and validation of the location of all health facilities across the globe. The data will enable users to discover what health facilities exist at any location, along with the services and resources provided. Core to the above goal, is also ensuring that this global dataset of health facility data is easily accessible to everyone. Healthsites uses OpenStreetMap as the data store and makes the data available online through an API, as well as other formats such as GeoJSON, Shape files, KML, CSV.
The goals and deliverables of the project outlined in this wiki page, is to ensure that the alignment of data between Healthsites and OpenStreetMap is done appropriately, following the Organised Editing Guidelines from the OpenStreetMap Foundation.
Why Not Use OSM Directly?
Our approach with Healthsites is to provide a domain specific view of OSM data, focussing on the needs of people who wish to work with health facility data. The aim is to provide a directed experience where all interactions with the Healthsites.io website are health facility focused, where the user does not need to be aware and understand the full extent of the larger OSM project and all it has to offer. For example, dashboards are provided for visualisation of OSM health facilities, broken down by country or aggregated to the world for easier understanding and access to the data.
Healthsites provides a number of methods to make data easily accessible to users, through custom forms for capturing facility attributes, which are aligned with the recommendations for OSM tagging laid out in this wiki page. Health facility focused export tools so that the user does not, for example, need to learn how to use Overpass to extract health facility data from OSM. And API’s have been developed so that users can easily incorporate health facility data into their own applications. We believe in OSM and are passionate about seeing the healthsite data in OSM becoming the main point of reference, and we aim to leverage our work in Healthsites.io to help achieve this, while carefully catering to the specific needs of users of health facility data.
Mapping Timeline
In response to the Ebola outbreak of 2014, Healthsites was launched at the Global Partnership for Humanitarian Impact and Innovation (GPHI2) in 2016. GPHI2 promotes the development of innovative solutions to humanitarian challenges by harnessing the creative capacity of International Committee of the Red Cross partners to respond to the needs of conflict victims.
Following the launch of the site, presentations and advocacy for sharing health facility data were made to a number of organisations including WHO Health Data Forum in Geneva, WHO Expanded Programme on Immunization (EPI) and Department of Immunization, Senegalese Ministry of Health, Le Centre des Opérations d’Urgence Sanitaire (COUS Senegal), International Federation of the Red Cross, London School of Hygiene and Tropical Medicine, MSF Manson Unit, Group on Earth Observations and UNITAR. A highlight of this work was the inclusion of a recommendation to share health facility data by the United Nations Committee on the Peaceful Uses of Outer Space.
80. (c) Member States are strongly encouraged to promote open data-sharing policies and participatory approaches to developing and improving access to all geospatial information relevant to global health, whenever possible.
Healthsite.io data was then made available through the Humanitarian Data Exchange platform, with the Global Healthsites Mapping Project set up as an organisation. Healthsites has also supported the Ebola response in the DRC through the Health data collaborative established by CartONG.
In 2018 Healthsites was awarded funding through the Digital Square Global Goods program. Part of the work carried out through this funding, is focused on piloting an upgraded system in Saint Louis, Senegal. This will include the surveying of health facilities on the ground starting July 15, 2019 and will focus on the collection of key information as outlined in the data model below. Together with Geomatica, students from the Université Gaston Berger, SIG Santé community, CartONG and OpenStreetMap Senegal, a collaborative focused on health facility data is formed.
The collaborative will identify use cases, with the support of the Ministry of Health, that will drive the development of the data. During this period we will work with and encourage the Ministry of Health to share their health facility data with OpenStreetMap. To read more about the pilot in Saint Louis, Senegal, please jump to the Ground Survey section under Data Creation.
Area of Interest
The Healthsites.io initiative is global in scope. A pilot data collection effort on the ground in Senegal is taking place in July 2019, which will look at using a localised version of the OpenStreetMap data model put together for Healthsites.io. More information can be found on their dedicated OSM wiki page, please jump to the Ground Survey section under Data Creation to read more about the pilot in Saint Louis, Senegal.
Healthsites.io <> OpenStreetMap
The data flows both ways from Healthsites.io to OpenStreetMap, and from OpenStreetMap to Healthsites.io. On the sign up to the Healthsites.io page, users register using OAuth against the OSM authentication provider. Each data change (create/update/delete) to a health facility on the Healthsite.io platform is written directly to the OSM database using the OSM API, with the OSM credentials associated with the logged in user on Healthsites.io.
Changes to health facility data made outside of the Healthsites.io platform, and directly to OSM are replicated back in near-real time to a Healthsites.io mirror of all health facility data found in OSM. This is achieved using docker-osm, developed by Kartoza which takes the high frequency diffs produced on OSM and applies them to a PostgreSQL / PostGIS database hosted on Heathsites.io. Changes made locally on healthsites.io are first pushed to OSM via the OSM API and then replicated back to our docker-osm instance using the same mechanism described above.
Our aim with this architectural approach is to make OSM the main storage location of all the health facility data available on Healthsites.io and at the same time facilitate large queries, extracts and general innovation around the body of OSM health facility data, whilst having minimal impact and load on the services offered by OSM. The diagram below illustrates the high level architecture as pertains to interactions between OSM and Healthsites.io.
Data Model
The OSM data model put together for Healthsites was initially based off of several data models used in various HOT projects across South America, Africa and Southeast Asia. The initial list of tags was then compared to the data model that Healthsites.io was already using to ensure that the same attributes were still being captured, but also offered some suggestions for additional key information that should be captured for health facilities. This was based on the numerous collaborations with HOT project partners over the years and their data needs.
The overall idea is to use existing OSM tags where possible and only propose new tags where necessary. A lot of research went into the development of the Healthsites OSM data model, including the review of existing HOT data models and OSM data models available on the OSM wiki. Verification of the tags usage through the OSM wiki, Tag Info and Tag History, with further analysis on tags using OSMFilter for certain areas of interest, helped identify values generally applied in a local area.
The last step involved in the creation of the Healthsites OSM data model was discussing and assessing the health facility components and the associated tags to capture this data, with partners Médecins Sans Frontières (MSF) International and CartONG, who have both conducted many projects focused on the data collection of health facilities across the globe. There are two data models outlined below. The first is the ‘Simplified’ OSM model, which is the minimum mandatory attribute information required for a health facility. The second is the ‘Complete’ model, which outlines all the tags that should be used to capture a complete list of vital information for health facilities.
Simplified
| Mandatory Healthsite OSM Model | |||
|---|---|---|---|
| No | Key | Value | Description |
| 1 | amenity | clinic, doctors, hospital, dentist, pharmacy | For describing useful and important facilities for visitors and residents |
| 2 | healthcare | doctor, pharmacy, hospital, clinic, dentist, physiotherapist, alternative, laboratory, optometrist, rehabilitation, blood_donation, birthing_center | A key to tag all places that provide healthcare (are part of the healthcare sector) |
| 3 | healthcare:speciality | biology, blood_check, clinical_pathology, diagnostic_radiology, medical_physics, medical_engineering, radiology | A key to detail the special services provided by a healthcare facility. To be used in conjunction with the 'healthcare=*' tag. For example 'healthcare=laboratory', and 'healthcare:speciality=blood_check' |
| 4 | name | <name of health facility> | The primary tag used for naming an element |
| 5 | operator | <name of operator> | The operator tag is used to name a company, corporation, person or any other entity who is directly in charge of the current operation of a map object |
| 6 | source | <source of data> | Used to indicate the source of information (i.e. meta data) added to OpenStreetMap |
Complete
| Wish List Healthsite OSM Model | |||
|---|---|---|---|
| No | Key | Value | Description |
| 1 | amenity | clinic, doctors, hospital, dentist, pharmacy | For describing useful and important facilities for visitors and residents |
| 2 | healthcare | doctor, pharmacy, hospital, clinic, dentist, physiotherapist, alternative, laboratory, optometrist, rehabilitation, blood_donation, birthing_center | A key to tag all places that provide healthcare (are part of the healthcare sector) |
| 3 | healthcare:speciality | biology, blood_check, clinical_pathology, diagnostic_radiology, medical_physics, medical_engineering, radiology | A key to detail the special services provided by a healthcare facility. To be used in conjunction with the 'healthcare=*' tag. For example 'healthcare=laboratory', and 'healthcare:speciality=blood_check' |
| 4 | name | <name of health facility> | The primary tag used for naming an element |
| 5 | operator | <name of operator> | The operator tag is used to name a company, corporation, person or any other entity who is directly in charge of the current operation of a map object |
| 6 | operator:type | public, private, community, religious, government, ngo, combination | This tag is used to give more information about the type of operator for a feature |
| 7 | addr:full | <full address> | Used for a full-text, often multi-line, address for buildings and facilities |
| 8 | contact:phone | <phone number> | The contact tag is the prefix for several contact:* keys to describe contacts |
| 9 | operational_status | operational, non_operational, unknown | Used to document an observation of the current functional status of a mapped feature |
| 10 | opening_hours | <days/times of opening> | Describes when something is open or closed. There is a specific standard format for this data https://wiki.openstreetmap.org/wiki/Key:opening_hours/specification |
| 11 | beds | <number of beds> | Indicates the number of beds in a hotel or hospital |
| 12 | staff_count:doctors | <number of doctors> | Indicates the number of doctors in a health facility |
| 13 | staff_count:nurses | <number of nurses> | Indicates the number of nurses in a health facility |
| 14 | healthcare:equipment | ultrasound, mri, x_ray, dialysis, operating_theater, laboratory, imaging_equipment, intensive_care_unit, emergency_department | Indicates what type of speciality medical equipment is available at the health facility |
| 15 | dispensing | yes, no | Whether a pharmacy dispenses prescription drugs or not. Used to add information to something that is already tagged as amenity=pharmacy |
| 16 | wheelchair | yes, no | Used to mark places or ways that are suitable to be used with a wheelchair and a person with a disability who uses another mobility device (like a walker) |
| 17 | emergency | yes, no | This key describes various emergency services |
| 18 | insurance:health | none, public, private, unknown | This key describes the type of health insurance accepted at the healthsite |
| 19 | water_source | well, water_works, manual_pump, powered_pump, groundwater, rain | Used to indicate the source of the water for features that provide or use water |
| 20 | electricity | grid, generator, solar, other, none | Used to indicate the source of the power generated |
| 21 | url | <url of source data> | Specifying a url related to a feature, in this case the wiki page if it is linked to an organised mapping effort, both through surveying and importing |
| 22 | source | <source of data> | Used to indicate the source of information (i.e. meta data) added to OpenStreetMap |
Please note that the source tag is very important to help identify where the data came from, was it a data import? If so, than something along the lines of healthsites-import-<country>-<year> should be used and the link to the OSM wiki project page should be added as the URL value to help provide data users context and confidence when utilising the information. Similarly, please do the same if the data was collected through a ground survey, use healthsites-survey-<country>-<year> as the source value and the OSM wiki project page as the URL value, or if the data is crowdsourced use healthsites-crowdsourced-<country>-<year> as the source value and leave the URL blank.
Tag Proposal
The tags that are being proposed as part of the development of an OSM data model for Healthsites.io include ‘staff_count:doctors’, ‘staff_count:nurses’, ‘healthcare:equipment’ and ‘insurance:health’. The ability to be able to record how many staff members, particularly doctors and nurses were available at a health facility is extremely important in an emergency situation, where government officials, for example would want to identify a site that can handle the influx of a certain number of patients. Therefore the introduction of ‘staff_count:doctors’ and ‘staff_count:nurses’ was necessary for capturing this information.
| Propsed OSM Tags | ||||
|---|---|---|---|---|
| No | Key | Value | Description | Wiki Page |
| 1 | staff_count:doctors | <number of doctors> | Indicates the number of doctors in a health facility | https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:staff_count:doctors |
| 2 | staff_count:nurses | <number of nurses> | Indicates the number of nurses in a health facility | https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:staff_count:nurses |
| 3 | operational_status | operational, non_operational, unknown | Used to document an observation of the current functional status of a mapped feature | https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:operational_status |
| 4 | healthcare:equipment | ultrasound, mri, x_ray, dialysis, operating_theater, laboratory, imaging_equipment, intensive_care_unit, emergency_department | Indicates what type of speciality medical equipment is available at the health facility | https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:healthcare:equipment |
| 5 | insurance:health | no, public, private, unknown | This key describes the type of health insurance accepted at the health facility | https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:insurance:health |
The extensive wiki page Healthcare 2.0 put together by OSM user Fabi2 was reviewed and re-purposed where it made sense. We wanted to ensure that the work by Fabi2 was not overlooked and although very detailed, only extracted the parts that were required by the Healthsites.io model. The tags ‘staff_count:doctors’ and ‘staff_count:nurses’ was initially proposed by Fabi2, but unfortunately the whole page has been listed as abandoned. There are 882 features using both of these tags, based on the statistics from Tag Info, which is predominantly based in Africa. Looking at Tag History, it looks as though there was an initial bulk import but the use of both tags has steadily increased over time.
The use of ‘health_amenity:type’, which is also a tag that was proposed by Fabi2 as part of Healthcare 2.0, is a tag that is used to capture the type of speciality medical equipment available at a health facility. This information is also important for deciding where a patient will be sent based on their needs and whether or not a health facility has the proper equipment to support those needs. The ‘insurance:health tag’, was not proposed as part of Healthcare 2.0 but is an important piece of information for health facilities, as it is a way of indicating what type of health insurance is accepted and will help patients determine whether or not they are covered for care at the site. Utilising parts of Healthcare 2.0 bit by bit is an easier way to isolate and incorporate new tags for the addition of key information for health facilities in OSM. Please see the table below for the dedicated wiki pages for the full proposal of each tag.
Health Boundary Debate
During the development of the OSM data model for Healthsites.io, several discussions were held regarding the inclusion of a health boundary to help identify the boundaries of a health division within a country. This was initially proposed by Claire Halleux in 2016, which focuses on the use of a ‘boundary=health’ tag, along with ‘health_level’, ‘name’ and ‘ref’. It should be noted that health boundaries appear to be different from administrative boundaries in a significant number of countries.
| Health Boundary Tags | |||
|---|---|---|---|
| No | Key | Value | Description |
| 1 | boundary | health | A tag for health divisions limits and relations |
| 2 | health_level | <health level> | A tag to describe the level of the health division, working in a similar way as admin_level=* |
| 3 | name | <health division> | The name of the health division |
The use of health boundaries has been applied in the Democratic Republic of Congo, but has not been applied in other countries. The biggest hurdle is coming up with a level category for each country, as these will vary from place to place. From the countries surveyed so far, there seems to be 3 to 4 active levels of health divisions and the DRC decided to use even numbers for describing their different health levels. This strategy allows them to create additional intermediate levels in the future, with limited consequences as they can use the odd number in these cases. The use of tags that can be applied to objects such as villages, health facilities or smaller health divisions, in order to identify which health division they are part of was also proposed as part of the health boundary discussion.
| Health Level Tags | |||
|---|---|---|---|
| No | Key | Value | Description |
| 1 | is_in:health_level2 | <health division> | The name of the health division of level 2 including the object |
| 2 | is_in:health_level4 | <health division> | The name of the health division of level 4 including the object |
| 3 | is_in:health_level6 | <health division> | The name of the health division of level 6 including the object |
| 4 | is_in:health_level8 | <health division> | The name of the health division of level 8 including the object |
Tagging Examples
Some examples for using the OSM Healthsites.io data model for tagging health facilities has been added below as a guidance to anyone who is looking to contribute data, as well as use the data. Please note that how the tags are used are not restricted to this method, and we encourage individuals that have found special use cases to share them here so that we can all understand how to better capture health facility data.
Data Identifiers
Data in OpenStreetMap can be created through a number of methods. This includes, but is not limited to the importing of existing open datasets, the remote digitisation of building footprints and the collection of detailed attribute information on the ground through surveying. Populating the data needs to be traceable not only by the username, but also by the changeset comment, a source attribute tag and ideally a URL link to the data source and/or OSM wiki page detailing the organised editing efforts.
| Identifier | Value |
|---|---|
| OSM Username | <name of osm user> |
| Changeset Comment | #healthsites |
| Source Tag | healthsites-import-<country>-<year>
heathsites-survey-<country>-<year> healthsites-crowdsourced-<country>-<year> |
Please note that the source tag is very important to help identify where the data came from, was it a data import? If so, than something along the lines of healthsites-import-<country>-<year> should be used and the link to the OSM wiki project page should be added as the URL value to help provide data users context and confidence when utilising the information. Similarly, please do the same if the data was collected through a ground survey, use healthsites-survey-<country>-<year> as the source value and the OSM wiki project page as the URL value, or if the data is crowdsourced use healthsites-crowdsourced-<country>-<year> as the source value and leave the URL blank.
Data Creation
Data Imports
The section covers the importing of existing open datasets of health facilities. There are a number of things to consider when planning an imports, such as the suitability of a dataset, its completeness, data accuracy, is the data is up to date and most importantly if it has the correct license to match the OSM ODbL license. Imports should be carried out with more care and sensitivity than other edits in OSM, as it can have significant impacts on both existing data and the local mapping community.
A methodology must be developed and strictly followed, and there are various Import Guidelines created by the OSM community, which should be taken into account while developing the import process:
- Prerequisites
- Community Buy-in
- License Approval
- Documentation
- Import Review
- Uploading
The main tools used for importing existing datasets into OSM is the Tasking Manager and JOSM, but data can also be imported through a CSV file on Healthsites.io. The intention is that batch uploads will be carried out by medical data administrators around the globe as we work together to build a complete and current dataset of health facilities. If you are carrying out a data import please be sure to create an OSM wiki page following the Import Guidelines linked above, and add the page details to the table below so anyone wanting to use the data can gain context and confidence in doing so.
In general our strategy is to avoid bulk imports to OSM in favour of rather performing atomic transactions (i.e. single record transactions) to the OSM database via the OSM API. However there is one scenario where bulk imports will be used.
In some cases, institutions (e.g. a national health ministry) may make available to the healthsites.io platform a complete health facility dataset for their country or region. In such cases we will import these data into OSM in bulk using the user’s OSM credentials. We will have in place logic to try to eliminate any duplicate records (initially based on location and facility name) and report such duplication candidates to the user performing the import. Non-conflicting records will be imported directly into OSM.
Methodology for performing bulk uploads:
- Creation of an OSM account specifically for the bulk import - e.g. Rwandan-MoH-import.
- Signing of an authorisation letter from e.g. the ministry of health for the country providing bulk data.
- The bulk importer must review a guidance document on the implications of doing a bulk import.
- Creation of an OSM wiki page describing the bulk import project.
- Linking of the bulk import page to the bulk import table below.
- The authorisation letter will be attached to the bulk import page on OSM wiki.
| Year | Duration | Location | Dataset | Wiki Page |
|---|---|---|---|---|
| 2020 | In progress | Cameroon | RFUK health facility import cameroon | RFUK health facility import cameroon |
| 2020 | in progress | Democratic Republic of the Congo | RFUK Health Facility Import DRC | RFUK Health Facility Import DRC |
| 2021 | in progress.. | Brazil | Import of the Brazilian National Register of Health Facilities | Import of the Brazilian National Register of Health Facilities |
Ground Survey
This section covers the collection of health facility information on the ground through surveying the site directly, generally as part of an organised mapping effort. There are several ways to collect data in the field and it will vary by context, but it will generally include the following:
- Development of an OSM data model
- Recruiting a mapping team and providing training
- Preparing the relevant data collection tools
- Allocating appropriate transport for the area
- Authorisation from district officials to survey the area of interest
- Producing field maps to help guide the team on the ground
- Managing data being collected on the ground
- Data validation and spot checks, followed by a
- Final round of validation before uploading the data into OSM
Tools that can be used for the data collection include but are definitely not limited to OpenDataKit, OpenMapKit, Field Papers, GPS units and OMK Server. Customised survey forms, based on a project data model are created for OpenDataKit through a simple spreadsheet. The use of customised forms ensures that the data collected by the mappers during the survey is consistent, with a set of standardised tags for each map feature. This makes the data collection workflow much more streamlined and greatly helps reduce the potential for error.
If you would like to organise a ground survey focusing on the data collection of health facilities, please use the Senegal OSM project page linked below as a template and reach out to Mark Herringer or Tim Sutton who can help provide some guidance. Otherwise, if you feel confident to go ahead than please be sure to create an OSM wiki page for your surveying project, and add the page details to the table below so anyone wanting to use the data can gain context and confidence in doing so.
| Year | Duration | Location | Organisation | Wiki Page |
| 2019 | July - August | Senegal | Geomatica
Cartong Openstreetmap Senegal | |
| 2022 | in progress | Saint Louis - Senegal | Healthsites | COVIDaction Emergency health data validation |
Crowdsourcing
Adding details about a health facility through crowd-sourcing, is a surveying technique that focuses on local communities capturing information associated with key features in their environment. This generally involves going out in person to map a level of detail that cannot be seen from aerial imagery. This is necessary for creating a detailed and accurate map. By going in person, they are ‘ground truthing’ the data by directly observing it and ensuring its accuracy. This is not an organised editing effort, but generally an enthusiastic mapping individual who wants to add information about a health facility that they frequent, is in their vicinity or they have good knowledge about. As this is not an organised effort, an OSM wiki page does not have to be created but the detailed attribute information can simply be added to the health facility following the data model above!
Data Extracts
Healthsites.io
Data extracts per country are available on Healthsites.io, which can be found by going to the map page and browsing the country list on the left panel. Clicking on the name of any country listed will show a dashboard for that country which includes a link for downloading the associated data as a shapefile.
Humanitarian Data Exchange
Health facility data can be downloaded from the Humanitarian Data Exchange (HDX) platform. Healthsites is registered as the Global Healthsites Mapping Project and hosts country datasets for health facilities, which can be downloaded as a GeoJSON, CSV and/or Shapefile.
Export Tool
The Export Tool is another platform where health facility data can be easily downloaded. Developed by the Humanitarian OpenStreetMap Team, the Export Tool is an open service that creates customised extracts of up-to-date OpenStreetMap data in various file formats, including GeoPackage (.gpkg), Garmin (.img), Google Earth (.kml), OSM (.pbf), MAPS.ME (.mwm), OsmAnd (.obf) and MBTiles (.mbtiles).
Sustainability Plan
Healthsites is developing a social enterprise business model to fund health facility mapping and validation. We invite citizens, organisations and Ministries of Health to share baseline health facility data to OpenStreetMap and collaborate around the Ministries Health strategy and prioritised use cases.
Contact Information
If you would like to get in touch with the project lead, please contact Mark Herringer or Tim Sutton via their OpenStreetMap user accounts. Alternatively you can send a message through the contact form at the Healtsites.io website.
See Also
The OpenStreetMap Foundation Organised Editing Guidelines wiki page.
