Using GIS for Decision Support in Emergency Medical Services

From CUOSGwiki
Jump to navigationJump to search

Introduction

Starting in October of 2012, the Ontario Ministry of Health and Long-term Care (MOHLTC) will be implementing new standards for ambulance response times. This change has the potential to significantly alter approaches to ambulance station allocation and deployment planning for many ambulance services. This tutorial shows how an open source GIS software package can be used for decision support in response to this change. This may be particularly beneficial for smaller (mostly rural) ambulance services who do not have access to a municipal GIS department (or a GIS department with the suitable proprietary software) and who are most likely to find the new standards particularly challenging.

Objective

There are three factors which are commonly evaluated when determining the allocation of ambulance resources; population, historical call data, and hospital demand ( Schuurman, N., Bell, N. J., L'Heureux, R., & Hameed, S. M. 2009)[1]. The objective of this tutorial is to develop decision support information based on ambulance service area population. The resulting information may then be used by decision makers to determine optimal ambulance allocation based on operational constraints.

Programs and data

To conduct an analysis of ambulance service areas, Geographic Resources Analysis Support System (GRASS) was used within Quantum GIS (QGIS). GRASS is included with the QGIS download. One of the benefits of GRASS is that the .dbf files which contain the attribute data are stored in their own file folder. This is helpful when accessing the statistical data. Open source options available to do this are OpenOffice or R.

The following data are required to conduct an analysis.

  • Roads
  • Ambulance stations/locations
  • Census population data

If a shapefile of the required roads is not readily available, one is available as a free download from Statistics Canada . Ambulance stations or locations may need to be created. This can be done in QGIS through the New Shapefile Layer item of the Layer|New menu. Create a new point file, add location attributes, and then edit to add geographic locations according to the road network. For the census data, some information may be free, depending on the size of the municipality. Otherwise, the census data may need to be purchased from Statistics Canada or acquired from some other source.

Methods

The following sections outline the process of meeting the objective step by step. To provide an example in this process the case of Leeds Grenville EMS (LGEMS) is used.

Programs and Data

First, download and install the software, following directions from the developers.

  • QGIS
  • OpenOffice
  • R

Then acquire the data. In the case of LGEMS, this included the following:

  • Road network
  • Ambulance locations (see #Assumptions and Customizations)
    • Ambulance stations
    • Standby locations
    • Potential standby locations
  • Census data for UCLG census dissemination areas (DA), shapefiles and population by DA
  • Census data for bordering municipalities, shapefiles and population by census tract (CT) or census subdivision (CSD) (see #Assumptions and Customizations)
    • Ottawa (census tracts)
    • Kingston (census tracts)
    • Frontenac (census subdvisions)
      • Central Frontenac
    • Stormont, Dundas &Glengarry (census subdvisions)
      • North Dundas
      • South Dundas
    • Lanark (census subdvisions)
      • Montague
      • Drummond/North Elmsley
      • Tay Valley
      • Perth
      • Smith Falls

Setting up map project

With the programs installed and data acquired it is now possible to identify service areas and their populations.

  1. Load shapefiles into Quantum GIS. This can be done through the Layer menu by selecting “Add Vector Layer” or by choosing the “Add Vector Layer” icon in the toolbar. (If using the icon in the toolbar, be sure not to confuse “Add Vector Layer” with “Add GRASS Vector Layer”)
  2. Create a new GRASS Mapset. This will be in order to use the GRASS tools in QGIS. Go to the Plugins menu, then Grass|New Mapset. When the dialog box appears follow these steps.
    1. Set working directory.
    2. Enter location. This creates a directory where the GRASS files will be stored. For this case study, the location was UCLG. After entering a location, press next.
    3. Select co-ordinate system (CRS). This should be selected automatically based on the shapefiles already loaded in QGIS. If it is not, select the appropriate CRS from the list. For this case study, the CRS was NAD 83, MTM zone 9 projection. Press next.
    4. Set the extent. Select “set current QGIS extent.”
    5. Create a name for the mapset. For the example it was LGEMS.
    6. On the final dialogue box a summary will appear. Click finish to create the mapset.
  3. The next step is to convert the shapefiles into GRASS files. To do this, click on the GRASS Tools icon in the toolbar. When the dialog box opens, select the Modules List to find v.in.ogr.qgis by typing it into the text bar at the bottom. When the tool is select, a new tab will open within the dialog box. Select one of the shapefiles from the drop-down list and enter a new name in for the output. Click on “Run” and then “View output.”
  4. Once this has been completed for all of the shapefiles, they can be remove from the map table of contents.

Creating service areas

With the GRASS mapset created and the files loaded, it is possible to determine service areas for each ambulance location.

  1. A road network vector is different than a road vector in that it contains additional information about the roads which enables network analysis. It contains information about lengths and intersections. It is also possible to add in constraints such as where U-turns may be possible, speed limits, or one way streets. Adding extensive additional information could be the subject of a separate tutorial. Here, the road network is created by using the v.net tool from the GRASS Tools dialog box. There are 8 choices to be made when using the tool.
    1. Name of input vector map. For this case study, “Roads” was selected.
    2. Name of input point vector map is left empty.
    3. Select operation to be performed: choose “New point is placed on each node (line end) if doesn't exist”
    4. Arc layer is 1
    5. Node layer is 2
    6. Threshold is blank
    7. Assign unique categories to new points is blank (not checked)
    8. Name for output map: For this case study “RoadNetwork” was created.
  2. The next thing to do is to connect points of ambulance locations to the road network. This is done by using v.net again.
    1. Name of input vector map is “RoadNetwork.”
    2. Name of input point vector map. For this case study, “EMS_Stations” was selected.
    3. Select operation to be performed: choose “Connect still unconnected points to vector network by inserting new line(s)”
    4. Arc layer is 1
    5. Node layer is 2
    6. Under Threshold enter 200. This indicates distance a station may be from a road in meters. If a higher threshold is required, adjust as needed.
    7. Assign unique categories to new points is checked
    8. Name for output maps: For this case study “RoadNetworkStations” was created.
  3. Before continuing, it is important to identify “cats” of locations as they will be needed in the next steps. It may be that they are sequential. However, in the case study, the stations were imported with other locations and were not.
  4. To determine the service area for a particular station, GRASS has a tool called v.net.iso. Due to the repetitive nature of this step, scripts were used instead of using the tool in the GRASS Tools dialog box. Here is an example:
    v.net.iso input=RoadNetworkStations output=Stn1 ccats=8 costs=11000,24000
    v.net.iso refers to the tool
    input refers to the vector network
    output refers to the name of the vector network created
    ccats refers to the identification of the point on the input network
    costs refers to the distances from the point to be identified. (See Assumptions and Customization).
    This script is repeated, altering the output and ccat parameters for each location.
  5. The v.net.iso tool copies the entire network for each location. However, because much of this is above the cost of interest, another tool v.edit is used to delete the unwanted portion of the network. Here is an example script:
    v.edit tool=delete map=Stn1 cat=3
    v.edit refers to the tool
    tool refers to the editing tool being used
    map refers to the vector being edited
    cat refers to the element being edited
    So, what this script is saying is delete cat=3 in the Stn1 vector. Cat=3 refers to parts of the road network that are greater than 24km from the location.
  6. Before Step 5 is repeated to delete parts of the network greater than 11km from the location, copies of the service areas need to be made. To do this, here is an example script:
    g.copy vect=Stn1,Stn1_8
    g.copy refers to the tool
    vect refers to the vector being copied, and the name of the copy.
  7. Now, Step 5 can be repeated. Here is an example script:
    v.edit tool=delete map=Stn1 cat=2

Determining populations

Now that service areas have been created, it is possible to determine the populations of those service areas.

  1. This process involves selecting one vector layer based on overlap with another vector layer. Specifically, census areas are selected based on overlap by the service areas. To do this, the GRASS tool is v.select. Here is an example script:
    v.select ainput=UCLG_DA atype=area alayer=1 binput=Stn1 btype=line blayer=1 output=Stn1_90pop
    v.select refers to the tool
    ainput refers to the vector map of which information is being selected
    atype indicates the type of vector map
    alayer indicates the layer of the vector map being selected
    binput refers to the vector map which is used to make the selection
    btype indicates the type of vector map
    blayer indicates the layer of the vector map being selected
    output refers to the name of the vector map being created
  2. Repeat step one for the various distances used to produce service area populations above.

Compile populations

The last step before embarking on the decision making process is to compile the population data for each service area into one file. This can be done by using R or OpenOffice. The requirement is the sum of populations for each census area in each service area.

Begin decision process

The approach taken here is to build an ambulance deployment plan from the bottom up. Under Assumptions and Customization there is further explanation regarding the cost thresholds that were used in creating service areas. In the case study, service area populations were determined at 11km and 24km from ambulance locations. These signified response areas within approximately 8:00 and 17:45 minutes. In the introduction to this tutorial, reference was made to new MOHLTC standards. The 8:00 minute threshold relates to the new standard. The 17:45 threshold refers to the current standard. The overall goal of this decision making process was to maximize the population covered by service areas while minimizing the overlap of the service areas to less than 10%. Here is the sequence that was followed to begin the decision making process.

  1. Sort the service areas by population.
  2. Starting with an empty map, add the service area with the highest population.
  3. Add the next highest population that has less than 10% overlap with the existing service area(s).
  4. Repeat step 3 until it is not possible to add any more service areas without a greater than 10% overlap.
  5. Repeat from step 2, taking the subsequent area with highest population. This is necessary because it may be possible to maximize the population covered where two service areas better cover a geographic population distribution than one.

In the case study of LGEMS, these steps were repeated at both thresholds and with and without consideration of bordering populations. As a result, the minimum number of ambulance locations were determined in order to adequately provide ambulance service to the entire area. These results were needed in order to finalize the decision making process.

  • With only one ambulance available, it is not possible for LGEMS to adequately cover its population (at either the current or new standard). Therefore, if only one ambulance is available, it should be place where it provides service to the highest population within an 8 minute response time within Leeds & Grenville exclusively.
  • With only two ambulances it is possible to adequately provide service to the population (excluding bordering municipalities) at the current standard.
  • With only three ambulances it is possible to adequately provide service to the population (including bordering municipalities) at the current standard.
  • With less than six ambulances, the three ambulances required to provide service to the population at the current standard should be supplemented with the best locations at the new standard (excluding bordering municipalities).
  • With six or more ambulances, the ambulances should be allocated to provide service to the highest population (including bordering municipalities) according to the new standard.

Finalizing decisions

Operational considerations need to be considered in finalizing decisions. In the case of LGEMS, the locations considered were current stations, current standby locations, and potential standby locations (see Assumptions and Customizations). Therefore, final decisions considered current stations ahead of other potential locations if there was greater than 80% overlap between the two. The table below outlines the final decisions as determined through these steps for LGEMS.


[[Image:]]

Assumptions and Customization

Assumptions

  • Ambulance locations. In the LGEMS case study ambulance locations were defined as current stations and standby locations as well as potential standby locations. A standby location has been traditionally defined as a midway point between two stations which enables the ambulance located there to provide service to two service areas. These locations are most often associated with major intersections. In the case of LGEMS, they often also correspond to volunteer fire department stations. Therefore, potential standby locations were defined as other major intersections and other volunteer fire department stations. Other research has considered non-discrete points.
  • Census areas. The assumption used in this case study is that the municipality would have access to its own population data by dissemination area. The population data used for bordering areas was at the census tract or subdivision level, assuming that these would be available free of charge. To conduct adequate interpretation of service area populations, census areas should average a size smaller than the lowest cost threshold.
  • Service areas. For this case study, two different service areas were considered based on the current and new MOHLTC standard for LGEMS. The current standard for LGEMS is a response time of 17:45min or better to 90 percent of emergency calls. This is referred to as the 90th percentile. The 90th percentile varies for different ambulance services. The new standard will be 8 minutes, and it will not vary between services. In this case study, an average travel speed of 80km/h was used to determine the actual distance thresholds. It may be possible to use a more accurate distance based on analysis of historical average speeds.

Customization

  • Historical call data, hospital demands. Ambulance services may be able to incorporate other components into the decision making process. Other research has looked at call data by census area ( Comber, A. J., Sasaki, S., Suzuki, H., & Brunsdon C. 2010). Importing this information into QGIS is limited to a services' ability to maintain such data. Similarly, data regarding hospital demands in relation to emergency transfers would need to be compiled by the ambulance service. If these other factors were to be included into the decision making process, it may be worthwhile to incorporate a weighting system into the process.
  • The role of borders. When Ontario ambulance services were restructured in 2001, the MOHLTC maintained that residents calling for an ambulance would receive “seamless” service. In other words, borders between municipalities would not be a barrier to receiving service. However, municipal boundaries exist and it is difficult for policy makers to ignore this. Leeds & Grenville are bordered by Kingston/Frontenac, Lanark, Ottawa, and Stormont, Dundas, & Glengary. Two of the LGEMS stations (4 and 6) are in close proximity to these borders. Furthermore, Lanark County Ambulance has a station in Smiths Falls which provides service to the northern portion of Leeds county. Therefore, how these borders are considered and what level of co-operation and co-ordination exists between neighbouring services can have a significant impact on the decision making process.
  • Scripts and batch files. It should be noted that, with a certain degree of understanding of computer programing, a great deal of the repetitive steps taken could be put into a batch file. The implementation of batch files in GRASS could be the subject of another tutorial.

About this project

This tutorial was developed by Matthew Leyenaar as part of a project for a fourth year geomatics course at Carleton University.

References

Comber, A. J., Sasaki, S., Suzuki, H., & Brunsdon C. (2010). "A modified grouping genetic algorithm to select ambulance site locations" International Journal of Geographical Information Science, i.

Schuurman, N., Bell, N. J., L'Heureux, R., & Hameed, S. M. (2009). "Modelling optimal location for pre-hospital helicopter emergency medical services" BMC Emergency Medicine, 9, 6.

External Links

http://www12.statcan.gc.ca/census-recensement/2006/geo/index-eng.cfm

Retrieved from "https://dges.carleton.ca/CUOSGwiki/index.php?title=Using_GIS_for_Decision_Support_in_Emergency_Medical_Services&oldid=85"