Using GIS for Decision Support in Emergency Medical Services

From CUOSGwiki
Jump to navigationJump to search

Introduction

Starting in October 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.

For those unfamiliar with ambulance service in Ontario, here is some background information. Presently, standards for ambulance response time are based on a 90th percentile. In basic terms this means that each ambulance service is required to respond to emergency calls within a designated amount of time for 90% of cases. As such, the 90th percentile varies for different ambulance services. The new standard will be 8 minutes, and it will not vary between services. Rather, the difference between services will be seen in the percentage of call that are responded to within this time frame. Historically, ambulance stations have been located based on two loosely defined criteria. First, population and second, minimizing distances between stations. Therefore, to maintain service to the respective populations, many ambulance services also follow a deployment plan that uses 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 this tutorial, Leeds Grenville EMS (LGEMS) is used as an example. The current standard for LGEMS is a 90th percentile of 17:45min. LGEMS operates out of seven stations. Stations 1 & 2 are located in Brockville. Station 3 is in Prescott. Station 4 is in Kemptville. Station 5 is in Elgin. Station 6 is in Gananoque. Station 9 is in Spencerville. The LGEMS deployment includes an additional 6 standby locations. In the case of LGEMS, standby locations also correspond to volunteer fire department stations. This case study also considers potential standby locations. Potential standby locations were defined as other major intersections and other volunteer fire department stations.

Map of LGEMS station locations (labeled), standby locations, and possible standby locations. Neighbouring stations appear outside the boundaries of Leeds Grenville.

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. Most research regarding station location takes into account a certain number of ambulances that can be allocated to a certain area. In some cases non-discrete points are considered ( Comber, A. J., Sasaki, S., Suzuki, H., & Brunsdon C. 2010). This tutorial considers that there may be circumstances where ambulance resources are marginalized due to operational demand. Therefore, the decision making process begins with optimal location for one ambulance, then builds to a minimum number of ambulances required to meet the new MOHLTC standard. It should also be noted that this decision support does not take into account the temporal nature of ambulance demand.

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. The assumption used in this case study is that the municipality would have access to its own population data by dissemination area (DA). The population data used for bordering areas was at the census tract (CT) or subdivision (CSD) level. This was based on the assumption 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.

Methods

The following sections outline the process of meeting the objective step by step.

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
    • 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)
    • 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; all further analysis will use the version of the data that is now stored in the GRASS database.

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, we use the common simplifying assumption that all turns and travel directions are possible, and that uniform speed is possible on the whole network. 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.
    This script is repeated, altering the output and ccat parameters for each location. In this case study, an average travel speed of 80km/h was used to determine the actual distance thresholds or "costs". It may be possible to use a more accurate distance based on analysis of historical average speeds.
  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_8 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. 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%. Ten percent overlap was defined as 10% of the mean population for a service are divided by the mean population size for a DA, resulting in the number of DAs that could overlap. 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 provide service to its population (at either the current or new standard). Therefore, if only one ambulance is available, it should be placed 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. 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.

Final decisions for LGEMS.

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., et al. 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 more data that can be incorporated into the decision making process, the greater the validity of the decision. The challenge is to maintain consistency between variables. A percent rank can do this and is also useful as a weighting mechanism.
  • 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

Other external links of note.

http://www.twprideaulakes.on.ca/ambulance-faq.html

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