Animating geodemographic data with D3

What’s here

  • Some thoughts on the cost of establishing provincial bodies to design, deliver, and monitor public services whose geographic boundaries are misaligned with the national census
  • An extensive collection of geodemographic files
  • Some cool (at least I think so!) data visualizations involving sliders and animation

An aside

Since last time, I have been familiarizing myself with some of the more technical details of the Canadian government’s census and the administrative bodies that the Ontario government has established to plan, deliver, and monitor health and human services. In many instances, the geographic boundaries of these administrative bodies are difficult – if not impossible – to align with Canada’s census divisions, census subdivisions, dissemination areas, dissemination blocks, and other geographic units. This misalignment seriously challenges the use of expensive census data to address the social determinants of health and well-being in our public services. 1 The cost of this misalignment needs to figure more prominently and explicitly in any future decisions to establish new or modify existing administrative bodies. In this regard, the decision of the Ministry of Children and Youth to align the geographic boundaries of its five Integrated Service Regions (ISRs) and its thirty-three children and youth mental health Service Areas (CYMHSAs) with Ontario’s census divisions is commendable.

New geodemographic datasets

I have to admit that earlier posts have run the risk of presenting a somewhat disjointed view of the population projections and the geographic boundaries of administrative bodies that the Ontario government has established to plan, deliver, and monitor health and human services. So I want to consolidate some of my thinking and share a number of geodemographic datasets that will form the basis of future data analyses and visualizations. I have structured these datasets using three main categories – geographic unit, classification of age, and demographic variable – each with a number of sub-types:

  • Geographic Unit (4)
    • Statistics Canada
      • Census Division (CD)
    • Ontario Ministry of Children and Youth Services
      • Child and Youth Mental Health Service Area (CYMHSA)
      • Integrated Service Region (ISR)
    • Ontario Ministry of Health and Long Term Care
      • Local Health Integration Network (LHIN)
  • Classification of Age (5)
    • Life Cycle Grouping (LCG)
      • Child (0 – 14)
      • Youth (15 – 24)
    • Young Person
      • LCG-Child and LCG-combined (0 – 24)
      • CFSA-Child (0 – 17)
    • Transitional-Age Person
      • Emerging Adult (16 – 20)
  • Demographic Variable (7)
    • Population
    • Population Density
    • Population Share
    • Population Growth
      • Annual Growth
        • Change in number of persons
        • Rate of growth (%)
      • 5 Year Growth
        • Change in number of persons
        • Rate of growth (%)

We have met with most of these categories and sub-types before, or they carry their usual meanings here. One exception is the CFSA-Child (0 – 17) classification of age, which refers to the definition of “child” under the Child and Family Services Act in Ontario. CFSA-Child is central to any data analyses and visualizations relating to the CYMHSAs and ISRs defined by the province’s Ministry of Children and Youth.

We have compiled twenty-eight datasets in *.csv format that profile the different classifications of age for the years 2016 to 2041:2

Table 1. Datafiles for five classifications of age (above), 2016 to 2041 within a Geographic Unit x Demographic Variable tuple.
Geographic Unit
Demographic Variable CD CYMHSA ISR LHIN
Population data data data data
Population density data data data data
Population share data data data data
Growth
   Annual growth
       Change in number of persons data data data data
       Rate of growth (%) data data data data
   5-year growth
       Change in number of persons data data data data
       Rate of growth (%) data data data data

Sliders and animations

Of course, compiling all of these geodemographic datasets is only worthwhile if we can use them to make better decisions. In earlier posts, we have illustrated how to generate static maps of the geographic boundaries of administrative bodies like the MCYS’s CYMHSAs and ISRs, the MOHLTC’s LHINs, and we have introduced some limited capabilities for the user to interact (zoom, pan) with more dynamic maps.

Before leaving off here, I wanted to illustrate the use of sliders and animation to enhance the user’s abilities – not only to interact with maps – but to discern spatial-temporal patterns in the demographic data.

First, let’s introduce a slider that allows the user to move forward and backwards in time as we use a choropleth map to illustrate the rate of growth in the Child (0 – 14) population in Ontario’s fourty-nine Census Divisions, 2016 to 2041 [interactive version]:

Screen CDS GrowthPC Child slider
Figure 1. Choropleth with slider, illustrating annual rate of growth in Child (0 – 14) population by Census Division in Ontario, 2016 to 2041.

Second, let’s use animation to display the same data [interactive version]:

Screen CDS GrowthPC Child animation
Figure 2. Choropleth with animation, illustrating annual rate of growth in Child (0 – 14) population by Census Division in Ontario, 2016 to 2041.

Next time: I will provide a (fairly) friendly interface that will allow users to select among the 140 possible combinations of Classification of Age x Demographic Variable x Geographic Unit.

 

  1. For example, consider the challenge that Ontario’s Ministry of Finance confronts when it provides population projections for Ontario’s Local Health Integration Networks (LHINs). Except for a few cases, the boundaries of the LHINs do not conform to those of Census Divisions (CDs) or Census Subdivisions (CSDs). Thus, to take advantage of Statistics Canada’s annual updates of population projections to revise the basic demographic profiles of the LHINs, the Ministry of Finance must resort to a number of fiddles, depending on how a particular LHIN splits one or more CDs and/or CSDs. Case 1: If the LHIN consists of intact CDs (the Erie St. Clair LHIN), the Ministry of Finance’s CD-level projections for each CD are aggregated. Case 2: If the LHIN does not include any part of Toronto, York, and Peel AND its boundary splits CDs but not CSDs (the Champlain, South East, North-East, and North-West LHINs), the share-of-growth method is used. Case 3:  If the LHIN boundary splits CSDs (as well as CDs) in Toronto, York, and Peel (the Central West, Mississauga Halton, Toronto Central, and Central East LHINs), the share-of-growth method is used based on the growth of Dissemination Areas. Case 4: If the LHIN boundary splits CSDs (as well as CDs) in CDs other than Toronto, York, and Peel (the South West, Waterloo-Wellington, Hamiltion Niagara Haldimand Brant, Central, and North Simcoe Muskoka LHINs), the constant-share method is used. Additional iterative prorating procedure is required to deal with the age-sex structure of CSDs and split CSDs. All of this merely to update basic population projections! Imagine the impracticality, if not impossibility, of taking advantage of Statistics Canada’s periodic updates of subtler, and potentially more valuable, census-based socioeconomic data.
  2. For a given year within these twenty-eight datasets, the data corresponding to the Child, Youth, LCG-Combined, CFSA-Child, and Emerging Adult classifications of age are identified with the prefix Child_, Youth_, Young_, CFSAC_, and Mixed_, respectively, plus a suffix for the year. For data relating to annual growth of population, the suffix refers to the later year in the comparison.

Overlaying the boundaries of the Local Health Integration Networks and Children and Youth Mental Health Service Areas in Ontario

Preamble

This article was originally posted on May 14, 2016 and revised on July 28, 2016 to take account of changes in the geospatial representation of Children and Youth Mental Health Service Areas in Ontario. For more details, see … and then there were 33.

In a series of previous posts, we have visualized the boundaries of the MCYS Integrated Service Regions (ISRs) and the MCYS Children and Youth Mental Health (CYMH) Service Areas.

Now we want to merge the digital boundaries of the CYMH Service Areas with the MOHLTC’s Local Health Integration Networks (LHINs) in Ontario.

The boundaries of the LHINs in 2015 are provided in the ESRI ® shapefile format (HRL035b11a_e.zip) by Statistics Canada. The .zip file contains four familiar files:

  • HRL03b11a_e.dbf
  • HRL03b11a_e.prj
  • HRL03b11a_e.shp
  • HRL03b11a_e.shx

The projection information in the HRL03b11a_e.prj file indicates that the geospatial data for the LHINs uses the EPSG 3347 PCS Lambert Conformal Conic projection. 1 So we convert the original shapefile for the LHINs to the same projection (EPSG 4269) used for the CYMH Service Areas:

ogr2ogr -f 'ESRI Shapefile' -t_srs EPSG:4269 lhins.shp HRL035a11a_e_Sept2015.shp

Next we convert the new shapefile lhins.shp to a GeoJSON file and then to a TopoJSON file (see Visualizing the MCYS Integrated Service Regions Using d3.geo for the details of this process):

ogr2ogr -t_srs EPSG:4269 -f GeoJSON lhins_geo.json lhins.shp
topojson -o lhins_topo.json --properties -- lhins_geo.json

Finally, to merge the TopoJSON file for the CYMH Service Areas and the TopoJSON file for the LHINs into a single TopoJSON file, we need to install the utility geojson-merge:

npm install -g geojson-merge

and then run:

geojson-merge cymhsas_geo.json lhins_geo.json > cymhsas_lhins_geo.json

The properties of cymhsas_lhins_topo.json include:

HR_UID -> idHealth Region ID

Property Value
area_index Identifier of CYMH Service Area
area_name Name of CYMH Service Area
ENG_LABEL -> lhin_name Name of LHIN (English)
FRE_LABEL Name of LHIN (French)

We use Notepad++ to rename ENG_LABEL to lhin_name. We then promote HR_UID to the id property of the TopoJSON file.

topojson -o cymhsas_lhins_topo.json --id-property HR_UID --properties -- cymhsas_lhins_geo.json

And finally, we use Notepad++ to add the isr and color properties to the CYMH Service Areas.

Notes:

Our visualization of the MCYS and MOHLTC geospatial data includes the following features:

  • the five Integrated Service Regions and their respective CYMH Service Areas are distinguished with different hues
  • the boundary and name of a Local Health Integrated Network are displayed when the user hovers the mouse over one of the thirteen LHINs
  • the user may pan and zoom in on the visualization

Our visualization requires only these few modifications of the Javascript we developed to display the names of the CYMH Service Areas:

/* CSS */
...
.lhin_area:hover{
  stroke: #000;
  stroke-width: 1.5 px;
}

/* Javascript */
...

function draw(topo) {

var service_area = g.selectAll(".area_name").data(topo);

/* Visualize the CYMH Service Areas in colour, use id index to assign transparent colour to LHINs */
service_area.enter().insert("path")
.attr("class", "lhin_area")
.attr("d", path)
.attr("id", function(d,i) { return d.id; })
.style("fill", function(d,i) { return i <= 32 ? d.properties.color : 'transparent' });

/* define offsets for displaying the tooltips */
var offsetL = document.getElementById('map').offsetLeft+20;
var offsetT = document.getElementById('map').offsetTop+10;

/* toggle display of tooltips in response to user mouse behaviours*/
service_area

.on("mousemove", function(d,i) {
var mouse = d3.mouse(svg.node()).map( function(d) { return parseInt(d); } );
tooltip.classed("hidden", false)
.attr("style", "left:"+(mouse[0]+offsetL)+"px;top:"+(mouse[1]+offsetT)+"px")
.html(d.properties.lhin_name);
})

.on("mouseout", function(d,i) {
tooltip.classed("hidden", true);
});

}

… yielding the following visualization (interactive version):

Overlay LHINs on CYMH Service Areas
Figure 1. Screenshot of LHIN superimposed on CYMH Service Areas.

Next time: We’ll begin to merge the geospatial data in our TopoJSON files with demographic data in the public domain.

 

  1. Using Prj2EPSG.

MCYS Service Areas and Integrated Service Regions in GeoJSON and TopoJSON Formats

Preamble

This article was originally posted on May 14, 2016 and revised on July 28, 2016 to take account of changes in the geospatial representation of Children and Youth Mental Health Service Areas in Ontario. For more details, see … and then there were 33.

Here we provide geospatial data for the MCYS Integrated Service Regions and their constituent Children and Youth Mental Health Service Areas in GeoJSON and TopoJSON file formats:

Central Region GeoJSON TopoJSON
Dufferin/Wellington GeoJSON TopoJSON
Halton GeoJSON TopoJSON
Peel GeoJSON TopoJSON
Simcoe GeoJSON TopoJSON
Waterloo GeoJSON TopoJSON
York GeoJSON TopoJSON
East Region GeoJSON TopoJSON
Durham GeoJSON TopoJSON
Frontenac/Lennox and Addington GeoJSON TopoJSON
Haliburton/Kawartha Lakes/Peterborough GeoJSON TopoJSON
Hastings/Prince Edward/Northumberland GeoJSON TopoJSON
Lanark/Leeds and Grenville GeoJSON TopoJSON
Ottawa GeoJSON TopoJSON
Prescott and Russell GeoJSON TopoJSON
Renfrew GeoJSON TopoJSON
Stormont, Dundas and Glengarry GeoJSON TopoJSON
North Region – 7 Service Areas

North Region – 6 Service Areas

GeoJSON

GeoJSON

TopoJSON

TopoJSON

Algoma GeoJSON TopoJSON
Greater Sudbury/Manitoulin/Sudbury GeoJSON TopoJSON
James Bay Coast GeoJSON TopoJSON
Kenora/Rainy River GeoJSON TopoJSON
Nipissing/Parry Sound/Muskoka GeoJSON TopoJSON
Thunder Bay GeoJSON TopoJSON
Timiskaming/Cochrane

Cochrane/Timiskaming (including James Bay Coast)

GeoJSON

GeoJSON

TopoJSON

TopoJSON

Toronto Region GeoJSON TopoJSON
West Region GeoJSON TopoJSON
Brant GeoJSON TopoJSON
Bruce/Grey GeoJSON TopoJSON
Chatham-Kent GeoJSON TopoJSON
Elgin/Oxford GeoJSON TopoJSON
Essex GeoJSON TopoJSON
Haldimand-Norfolk GeoJSON TopoJSON
Hamilton GeoJSON TopoJSON
Huron/Perth GeoJSON TopoJSON
Lambton GeoJSON TopoJSON
Middlesex GeoJSON TopoJSON
Niagara GeoJSON TopoJSON

Visualizing the MCYS Integrated Service Regions Using d3.geo

Preamble

This article was originally posted on May 14, 2016 and revised on July 28, 2016 to take account of changes in the geospatial representation of Children and Youth Mental Health Service Areas in Ontario. For more details, see … and then there were 33.

Introduction

In the past few years, a wide variety of free and open source software (FOSS) tools for visualizing geospatial data have become available.  For many people like me who work in human services, coming to know how to use these tools even in rudimentary ways represents a steep learning-curve. Here, I illustrate the use of one of these tools, d3.geo, to visualize a geospatial view of children and youth services in Ontario. 1

In 2014-15 the Ministry of Children and Youth Services (MCYS) defined two administrative views of Ontario:

The five Integrated Service Regions (ISRs) combined nine previous Service Delivery Division regions and four Youth Justice Services Division regions. The ISRs are integrated with the five regional boundaries of the Ministry of Community and Social Services (MCSS).

The thirty-four thirty-three Children and Youth Mental Health Service Areas (CYMHSAs) were defined after a thorough review, including an assessment of Statistics Canada’s census divisions and projected population and children and youth.

The Ontario government has published two Shapefile archives – mcys_integrated_regions.zip and cymh_shapefile.zip and cymh_service_areas_after_march_9_2015.zip – that define the geospatial boundaries of the ISRs and the CYMHSAs, respectively. For now, we’re going to work only with the Shapefile archive for the ISRs.

Before we can visualize the ISRs using d3.geo, we need to convert the Shapefile format archive – mcys_integrated_regions.zip - to a TopoJSON format file – isrs_topo.json. (For more details of converting geospatial data from one file format to another, see Geospatial Features of the MCYS Integrated Service Regions).

A Simple Map

So, let’s use d3.geo to visualize the MCYS Integrated Service Regions in Ontario.

HTML template

In the same directory as the isrs_topo.json file, we create a file – isrs01.html – using the following template:


<!DOCTYPE html>
<meta charset="utf-8">
<style>

/* CSS goes here */

</style>
<body>
<script src="//d3js.org/d3.v3.min.js" charset="utf-8"></script>
<script src= "//d3js.org/topojson.v1.min.js"></script>

/*                                                           */
<script>
/* JavaScript for reading and rendering data goes here */
</script>

d3 supports the two main standards for rendering two-dimensional geometry in a browser: SVG and Canvas. We prefer SVG because you can style SVG using CSS, and declarative styling is easier.

There are several steps involved in reading and rendering our data in SVG:

  1. Define the width and height (in pixels) of the canvas
  2. Create an (empty) root SVG element
  3. Define the projection, beginning with a “unit projection” with .scale(1) and .translate([0,0])
  4. Define the path generator
  5. Open the d3.json callback
    1. Load the TopoJSON data file
    2. Convert the TopoJSON data back to GeoJSON format
    3. Calculate new values for .scale() and .translate() to resize and centre the projection
    4. Bind the GeoJSON data to the path element and use selection.attr to set the “d” attribute to the path data
  6. Maybe do some other stuff
  7. Close the d3.json callback

If we modify our template – isrs01.html – by adding the Javascript to load and render isrs_topo.json in SVG, we obtain:


<!DOCTYPE html>
<meta charset="utf-8">
<style>

/* CSS goes here */

</style>
<body>
<script src="//d3js.org/d3.v3.min.js" charset="utf-8"></script>
<script src= "//d3js.org/topojson.v1.min.js"></script>

<script>

/* 1. Set the width and height (in pixels) of the canvas */
var width = 960,
    height = 1160;
 
/* 2. Create an empty root SVG element */

var svg = d3.select("body").append("svg") .attr("width", width) .attr("height", height);

/* 3. Define the Unit projection to project 3D spherical coordinates onto the 2D Cartesian plane - HERE we use the Albers equal-area conic projection. */
var projection = d3.geo.albers()
    .scale(1)
    .translate([0, 0]);

/* 4. Define the path generator - to format the projected 2D geometry for SVG */
var path = d3.geo.path()
    .projection(projection);

/* 5.0 Open the d3.json callback, and
/* 5.1 Load the TopoJSON data file. */

d3.json("isrs_topo.json", function(error, isrs_topo) {
if (error) return console.error(error);

/* 5.2 Convert the TopoJSON data back to GeoJSON format */

  var regions_var = topojson.feature(isrs_topo, isrs_topo.objects.isrs_geo);
/* 5.2.1 Calculate new values for scale and translate using bounding box of the service areas */
 
var b = path.bounds(regions_var);
var s = .95 / Math.max((b[1][0] - b[0][0]) / width, (b[1][1] - b[0][1]) / height);
var t = [(width - s * (b[1][0] + b[0][0])) / 2, (height - s * (b[1][1] + b[0][1])) / 2];

/* 5.2.2 New projection, using new values for scale and translate */
projection
   .scale(s)
   .translate(t);

/* 5.3 Bind the GeoJSON data to the path element and use selection.attr to set the "d" attribute to the path data */

svg.append("path")
.datum(regions_var)
.attr("d", path);

/* 6 - 8 Some other stuff TBD later */

/* 9. Close the d3.json callback */

});

</script>

… which gives us this sort of basic rendering of the MCYS Integrated Service Regions [actual rendering]:

Figure 1. Basic rendering of the MCYS Integrated Service Regions.
Figure 1. Basic rendering of the MCYS Integrated Service Regions.

There are a few obvious improvements we can make. First, let’s draw the boundaries of the MCYS ISRs:


/* CSS goes here */

/* Define the boundary of an ISR as a 1.5 px wide white line, with a round line-join */
.isr_boundary {
  fill: none;
  stroke: #fff;
  stroke-width: 1.5px;
  stroke-linejoin: round;
}

...

/* Javascript for reading and rendering data in SVG */

...

/* 6. Draw the boundaries of the ISRs */
  svg.append("path")
      .datum(topojson.mesh(isrs_topo, isrs_topo.objects.isrs_geo, function(a, b) { return a !== b; }))
      .attr("class", "isr_boundary")
      .attr("d", path);

… giving us this sort of map [actual rendering]:

MCYS Integrated Service Regions with boundaries
Figure 2. Rendering of the MCYS Integrated Service Regions with boundaries.

… and then let’s label and colour the MCYS ISRs using the colour-scheme adopted by the MCYS:


/* CSS goes here */

/* fill the ISRs using the MCYS colour scheme */
.isrs_geo.Toronto { fill: #bd3f23; }
.isrs_geo.Central { fill: #fcb241; }
.isrs_geo.East { fill: #a083a7; }
.isrs_geo.West { fill: #e3839e; }
.isrs_geo.North { fill: #8dc73d; }

/* switch the colour of the ISR boundaries to black */
.isr_boundary {
  fill: none;
  stroke: #000;
  stroke-width: 1.5px;
  stroke-linejoin: round;
}

/* style the Region label */

.region-label {
 fill: #000;
 fill-opacity: .9;
 font-size: 12px;
 text-anchor: middle;
}

...

/* Javascript for reading and rendering data in SVG */

...

/* 7 Colour the ISRs */

  svg.selectAll(".isrs_geo")
      .data(topojson.feature(isrs_topo, isrs_topo.objects.isrs_geo).features)
      .enter().append("path")
      .attr("class", function(d) { return "isrs_geo " + d.id; })
      .attr("d", path);

/* 8 Label the Integrated Service Regions */

 svg.selectAll(".region-label")
 .data(topojson.feature(isrs_topo, isrs_topo.objects.isrs_geo).features)
 .enter().append("text")
 .attr("class", function(d) { return "region-label " + d.id; })
 .attr("transform", function(d) { return "translate(" + path.centroid(d) + ")"; })
 .attr("dy", ".35em")
 .text(function(d) { return d.properties.region_name; });

giving us this sort of map [actual rendering]:

Figure 3. Labelling and rendering of the MCYS Integrated Service Regions in colour.
Figure 3. Labeling and rendering of the MCYS Integrated Service Regions in colour.

Wrap-Up

In this post, we use d3.geo – a free and open source software tool – to visualize a publicly-available geospatial dataset related to children and youth services in five regions across Ontario. Next time, we will use another dataset to visualize children and youth services at the level of thirty-four service areas in the province.

  1. Accessing d3.geo is easy – you simply include a single call to d3 in the body of an .html web page. Installing and using some of the tools for converting geospatial data from one format to another (in order to use d3.geo) is more complicated. For some more technical details, see  Installing tools for d3.geo – 20160306.

Zaino, Jennifer – Ontology Plays a Part in United Nations Sustainable Development Goals Project – 20160303

Zaino, Jennifer – Ontology Plays a Part in United Nations Sustainable Development Goals Project – 20160303

How do you define “basic services”? What’s the difference between them and “essential services”? What is meant by terms like “natural capital”, “raw material” or “essential medicines”? How do these all fit into an ontology?

The truth is that there often aren’t universally accepted or precise definitions for terms like these – or even more simple ones, like “forest” – as they relate to their use in the United Nations Environment Program’s (UNEP) Sustainable Development Goals Project. The Sustainable Development Goals (SDG) – successors to the UN’s Millennial Development Goals, which expired last year – are a set of 17 goals and 169 targets to be achieved by 2030 to promote human prosperity worldwide while protecting the environment and addressing climate change.

For example, within the goal of ending poverty in all its forms everywhere, targets include reducing at least by half the proportion of men, women, and children who live in poverty in all its dimensions (according to national definitions); to implement nationally appropriate social protection systems and measures for all; and, to reduce poor people’s exposure and vulnerability to climate-related extreme events and other economic, social, and environmental shocks and disasters. Each goal’s targets will have one or more indicators, which are linked to specific data points that UN statisticians and the general public can monitor to assess progress on that issue.

For the project to come together in a way that ensures data quality and transparency and sets the stage to enable more accurate analysis and measurement of progress, the Sustainable Development Goals Interface Ontology (SDGIO) is being developed to represent the various facets of the SDGs.

An ontology is a structured set of terms and logical relations that represents not only the data, but what the data is about, says Mark Jensen, who is working on the UNEP ontology effort as a consultant. Jensen is pursuing his Ph.D. in the Department of Biomedical Informatics in the Jacobs School of Medicine and Biomedical Sciences at the University at Buffalo.

“An important distinction that well-made ontologies maintain is one between the information stored in databases and the entities out in the world that are described, measured or designated by that information,” he says.

The SDGIO project employs an approach in creating ontologies based in ontological realism, developed in large part by Barry Smith. Smith, who brought the UN effort to Jensen’s attention, is SUNY Distinguished Professor in the Department of Philosophy and Director of the National Center for Ontological Research at the university.

One use of ontologies in the UN project is to make it possible to intelligently tag incoming data to ensure that users are able to discover and better understand the information they are seeking, even when target and indicator data points intersect across domains and when there are inconsistencies in how member states define data points like “basic services” or “safe access” or, yes, even “forest.” For example, some definitions of “forest” will include palm tree plantations, while others do not, which can potentially impact data that relates to forest acreage, and subsequently, any analysis that occurs when data is aggregated across countries and regions with varying conceptions of what qualifies as a forest.

“As ontologists, we create semantic models that represent knowledge in particular domains of inquiry,” says Jensen. A UNEP ontology will provide a model to represent knowledge that’s relevant to the SDGs with more precision and better consistency, and that will provide a better way of integrating information used in monitoring the status of how various targets and goals are being addressed around the world, he explains.

Steps to the Ontology

Jensen is working closely on the SDGIO project with Pier Luigi Buttigieg, a post-doctoral researcher at the Alfred Wegener Institute for Polar and Marine Research. The lead of the Environment Ontology project (ENVO), Buttigieg was invited to participate in an UNEP-led meeting on integrated measures for global monitoring of the SDG process in 2014, Jensen relates. The value of the ontology in promoting integration and interoperability was recognized at that time by UNEP Chief Scientist Jacqueline McGlade – who is directing the SDG project with Ludgarde Coppens, UNEP head of the SDG Information and Knowledge Management Unit – and other representatives. This, Jensen says, resulted in the formation of a team of ontologists to create the SDGIO. “Pier continues to play a leading role in SDGIO’s evolution and is enhancing ENVO to help meet its aims,” says Jensen.

The aim of creating a better, more uniform approach to representing the data doesn’t mean changing the way member states conceptualize their own understandings of certain terms. But it does mean creating a way to represent the diversity of definitions and make that diversity of usage more transparent to people looking for data that is relevant to indicators. In addition to that, there needs to be a way to show how disparate data is linked together through a variety of common themes that cuts across multiple goals and targets.

An ontology enters the picture because of the advantages it affords of being a precise way to go about defining terms In hierarchical fashion and establishing relationships and formalized links between the lower-level terms in that hierarchy, he says. A top-level general definition for the term “forest,” then, can encapsulate all its different conceptualizations, with the variations between definitions represented as different lower-tier species or versions of what qualifies as a forest. There’s a great deal of unpacking of the semantics, or meaning, behind each indicator that’s required to facilitate the consistency users need to measure progress toward targets by making clear the links between various data and indicators, too. For instance, an indicator that is about the proportion of a population living in households with access to basic services has to account for all kinds of data that could relate to it, including what qualifies as a household and how that differentiates from living in a slum or informal settlement.

Jensen says the team will be finalizing the first phase of the ontology this spring, which will be implemented on the portal UNEPLive:

“An important aspect of the workflow is to elicit the feedback of relevant domain experts to guide their efforts in refining the semantics to better reflect the various domains surrounding the SDGs, such as legal entities, social policies, economic systems, equity and human rights, ecosystems and biodiversity, infrastructure, public health and education,” Jensen says.

This first phase includes the discovery and creation of all the needed terms and definitions and their formal implementation in OWL as an ontology. The team will reuse existing efforts by other groups developing ontologies, including those developed by ENVO (for the environment), CHEBI (for chemicals), OBI (for biomedical investigation), and PCO (for population and communities), and the complete semantics will grow over time as new ontologies are formed to address many of the domains that work on SDGIO has revealed a need for. For example, no ontology yet exists for human rights or financial measures, Jensen explains:

“SDGIO is truly an ‘interface.’ Not only is there a need to interface the data with the goals, targets and indicators, but also to interface the growing community of domain-specific ontologies that are and will be relevant to the SDGs.”

UN statisticians will tag the data using a few terms from the ontology (in addition to metadata such as provenance, geographic location, and so on). The ontology’s value for helping to enhance the discoverability of data should become clear in a few months as users go into the portal and type something like “access to basic services” or simply “basic services.” “We want to provide the ability for them to find data related to basic services in all contexts, not just for one particular indicator,” Jensen says.

Alternately, users might go in looking for data related to “essential services” but be served up data tagged as “basic services” because the two categories overlap very closely and often the distinction is hard to maintain. “We make the links between these terms and formalize that in the ontology so that if you search for one you can also find information tagged with the other,” he says. Researchers can drill down to determine whether information aligned with the other data tag fits their assessment requirements and use it or not, as they see fit.

Users also will be able to leverage the ontology for visualizing terms and the relationships between them. Along with those definitions they’ll find editor notes and comments about variations in usage. Says Jensen, “Hopefully they’ll utilize not just the discovery/search feature the ontology facilitates but also pay attention to the mapping and semantics it affords and the extra annotations we can add.”

Optimizing Ontario’s investments in a “basket” of core mental health services for children and youth – background

Some background

The Ministry of Children and Youth Services (MCYS) in Ontario funds service providers to deliver community-based child and youth mental health (CYMH) services under the authority of the Child and Family Services Act, R.S.O. 1990, c.C.11 (CFSA). The paramount purpose of the CFSA is to promote the best interests, protection and well-being of children.

Some terms

Client

The MCYS defines a client  as “the intended recipient of the child and youth mental health core service.” The client is a child or youth under 18 years of age who is experiencing mental health problems. In addition to mental health needs, clients may also be experiencing additional challenges related to their development or have specific impairments and/or diagnoses, including a developmental disability, autism spectrum disorder or substance use disorder. Other conditions or diagnoses do not preclude clients from receiving mental health services, but may add to the complexity of their needs, and the services they require. Similarly, where children and youth are involved in other sectors (e.g. youth justice and child welfare) these circumstances do not preclude them from receiving core services. Where children and youth have additional needs and are receiving a range of services, the focus must be on how the services connect. A coordinated approach to service delivery must be supported. Families (including parents, caregivers, guardians, siblings and other family members) may also receive services from a core service provider, in order to address the identified needs of the child or youth client. This may occur when the participation in treatment is recommended to support the child or youth’s service plan.

Continuum of needs-based mental health services

Children, youth and their families can benefit from access to a flexible continuum of timely and appropriate mental health services and supports, within their own cultural, environmental and community context. Mental health promotion, prevention, and the provision of services to address mental health problems represent different points along the continuum. Children, youth and their families may enter the continuum of needs-based services and supports at any point. The actual services a child/youth needs will vary. For example, some children/youth may benefit from targeted prevention services, while others will require more specialized mental health services. In addition, a child or youth’s mental health service needs may change over the course of their treatment.

The following schematic outlines the full continuum of needs-based mental health services and supports, and shows how core services fit within this continuum. It also represents the relative demand for services – level one reflects all children and youth, while level four focuses on a smaller subset of the child/youth population with the most severe, complex needs. This schematic is for service planning only – it is not used for diagnosis or for determining the appropriateness of specific mental health interventions.

MCYS - Continuum of core mental health services
Continuum of CYMH Needs-Based Services and Supports. *Includes members of a group that share a significant risk factor for a mental health problem(s).

Service areas

After a thorough review – including an assessment of Statistics Canada’s census divisions – the MCYS has identified 34 service areas in Ontario for the purpose of:

  • ensuring that all clients across the province will be able to access the same core services
  • facilitating planning, and
  • creating pathways to care.

The defined service areas are not barriers to service. Clients will be able to access service from any service area.

Core services

The MCYS has defined a set of core children and youth mental health services (“core services”) to be available within every service area and has established minimum expectations for how core services are planned, delivered and evaluated. Core services may not be available in every service area immediately – the expectation is that they will be made available over time as lead agencies assume their roles and responsibilities.

Core services represent the range of MCYS-funded CYMH services that lead agencies are responsible for planning and delivering across the continuum of mental health needs within each service area. It is recognized that children and youth in receipt of core mental health services may also require other services and supports. For example, children and youth may receive more than one core service as part of a service plan, as well as other services funded by MCYS or other partners.

Seven core services are to be available across all service areas:

  • Targeted Prevention
  • Brief Services
  • Counselling and Therapy
  • Family Capacity Building and Support
  • Specialized Consultation and Assessments
  • Crisis Support Services, and
  • Intensive Treatment Services.

The MCYS funds providers of core services through the following detail codes:

  • A348 – Brief Services
  • A349 – Counselling and Therapy
  • A350 – Crisis Support Services
  • A351 – Family/Caregiver Capacity Building and Support
  • A352 – Coordinated Access and Intake
  • A353 – Intensive Treatment Services
  • A354 – Case Management and Service Coordination
  • A355 – Specialized Consultation and Assessment
  • A356 – Targeted Prevention Term

The MCYS has identified a target population for each core service. This is the population for whom the service is designed, and for whom the service is intended to provide better mental health outcomes. The act of defining a target population is not meant to be exclusionary. Rather, it is a means to support planning and delivery in a way that benefits the children and youth who are in greatest need of the mental health service. In general, the target population for core services includes those children and youth under 18 years of age and their families who are experiencing mental health problems along levels two, three and four of the CYMH continuum. Additional target populations may also be identified within specific core services.

Lead agency

In every service area, the MCYS has identified a lead agency that will be responsible for the planning and delivery of high-quality core services across the continuum of mental health services in the service area.

A lead agency may either directly deliver core services or work with other providers of core services to deliver the full range of core services within the service area. Lead agencies are responsible for engaging cross-sectoral partners in the health and education sectors, including the relevant Local Health Integration Network (LHIN) and school boards. Lead agencies will connect with other providers to plan and enhance mental health service pathways for children and youth and improve transparency, so that everyone will know what to expect.

Providers of core services are required to comply with the Program Guidelines and Requirements #01 (PGR #01): Core Services and Key Processes.

The core services, key processes and functioning of the CYMH service sector will require refinement from time to time as other provincial initiatives and activities are developed and implemented. Within the broader context of these new initiatives, it is important that the roles and responsibilities of all core service providers are made clear and that the linkages between these services are transparent.

Planning to transform child and youth mental health services in Ontario

A key driver of Moving on Mental Health is the need to build a system in which children, youth and their families:

  • Have access to a clearly defined set of core child and youth mental health services
  • Know what services are available in their communities and how they are connected to one another, and
  • Have confidence in the quality of care and treatment. In a mature system, one of the ways in which this vision will be realized is through identification of lead agencies with planning and funding accountability for core child and youth mental health services within defined service areas.

Within each defined service area, the lead agency will be responsible for:

  • Delivering and/or contracting for the range of defined core CYMH services
  • Making them accessible to parents, youth, and children, and

Establishing inter-agency and inter-sectoral partnerships, protocols and transparent pathways to care. These responsibilities fall into two broad categories:

  • Core Service responsibilities – which relate to the defined core services delivered by the community-based child and youth mental health sector, as well as the key processes that enable high-quality service, and
  • Local System responsibilities – which relate to the collaboration of the community-based sector with other parts of the service continuum such as those supports and services delivered by health care providers, schools and others.

The Core Services Delivery Plan and the Community Mental Health Plan for children and youth will set out how the lead agency carries out these responsibilities. The lead agency will be responsible for developing these plans, and is expected to work collaboratively with other mental health service providers and with all sectors that support children and youth and respond to their mental health needs.

The Core Services Delivery Plan will, together with the Community Mental Health Plan, provide critical insight into each service area and guide activities as we move forward with transforming the experience of children, youth and families. The intent is that over time, both of these plans will have a three-year horizon and will be updated annually, since they inform one another. They will also provide content for the Accountability Agreement entered into between the lead agency and MCYS.

Core Services Delivery Plan

The development of a Core Services Delivery Plan (CSDP) is a key planning and communication tool that will document expectations, obligations and commitments for the provision of core services and associated key processes in each defined service area. This reflects the need to establish a consistent approach that will support critical insights into local and provincial child and youth mental health service issues, while recognizing the unique circumstances of lead agencies and service areas. The Core Services Delivery Plan documents how core services will be delivered in the defined service area. It consists of three areas of content:

  • Service Commitments
  • Continuous Improvement Priorities, and
  • Budget.

In developing the plan, the lead agency and child and youth mental health service providers should ask themselves some key questions:

  • Can we demonstrate that the full range of core services is available in our service area, and that minimum expectations set out in the Service Framework are being met?
  • Can we show how our services are getting better at meeting the mental health needs of children and youth in our communities?
  • Are we making the best possible use of limited resources to deliver high-quality services?
A. Service Commitments

This section of the plan will:

  • Identify, with specific activities and time frames:
    • How the lead agency and other child and youth mental health service providers in the service area will address the expectations set out in the Service Framework, including who will deliver what services over the projected three-year time horizon
    • Where changes to services or service providers are proposed, the plan will document how the changes will result in improvement to child and youth mental health outcomes, service quality and efficiencies
  • Indicate how, if a change in service providers or in contracted relationships is proposed, it will be handled in a transparent manner with due regard to minimizing disruption to service
  • Set out how services will be designed and delivered in a culturally responsive manner to address diverse populations including francophone and Aboriginal populations
  • Document how a clear, stable point of contact for children and youth with mental health needs and their families, as well as those seeking services on their behalf, will be established and/or maintained
  • Report on the reach and efficacy of programs and services, including how input from parents and youth has been incorporated to ensure that what has been developed works for them, and
  • Describe the process by which the lead agency has engaged and will continue to engage respectfully with all core child and youth mental health service providers in the service area.
B. Continuous Improvement Priorities

This section of the plan will:

  • Monitor and report on the impact of current programs and services
  • Identify improvement priorities, taking into account priorities established by MCYS and the expectations set out in the Service Framework, in areas such as service quality and outcomes, a purposeful approach to wait list and wait time management, and others over the three-year horizon of the plan
  • Set out specific activities and time frames that will support continuous improvement goals and priorities, and
  • Address matters such as data sharing protocols between the lead agency and other child and youth mental health agencies in the service area, that will support monitoring and reporting on performance indicators in order to enable tracking of trends, challenges and opportunities for continuous improvement.
C. Budget

This section of the plan will:

  • Forecast activities, resource allocations and budget over the three-year horizon, including financial implications of planned changes to service delivery.

Community Mental Health Plan for children and youth

System responsibilities are built on key partnerships and collaborations developed at the local level to support young people and their families across the full continuum of needs. Although service areas may differ in terms of their service profile, service patterns, as well as the degree of pre-existing cooperation and collaboration across systems and sectors, the lead agency will be responsible for bringing partners together to create coherence for children, youth and their families. MCYS is working, together with the Ministry of Health and Long-Term Care and the Ministry of Education, to put in place conditions that will support this important work.

The Community Mental Health Plan for children and youth will be a public document that is developed by the lead agency and describes the processes by which:

The lead agency has engaged and will continue to engage respectfully with sector partners such as organizations funded by Local Health Integration Networks, District School Boards, public health units, hospitals, primary health care providers, and those delivering MCYS-funded services (e.g., child welfare, autism services) and others, and

Input from parents and youth has been incorporated to ensure that what has been developed works for them. It will cover the following topic areas:

  • Understanding current needs and services
  • Collaborative planning, and
  • Pathways to, through and out of care.

In developing the plan, the lead agency, child and youth mental health service providers and partners from all sectors involved with child and youth mental health should ask themselves some key questions:

  • Are all those who serve children and youth working together systematically to address mental health needs in the service area?
  • Are the roles and responsibilities of everyone across the continuum of needs and services clear to parents, youth and those seeking services on their behalf, including how services are accessed?
  • Are there shared commitments to address service gaps and expand on opportunities to better meet identified needs?
A. Understanding current needs and services
  • Report on a needs assessment of the current state of child and youth mental health services across the service area, identifying gaps and opportunities for meeting needs across the continuum, and
  • Identify and maintain an inventory of who is providing which services to meet the needs identified.
B. Collaborative planning
  • Establish mechanisms to explore, on an ongoing basis, opportunities to leverage resources, reduce duplication, enhance outcomes, and create added value for children and youth with mental health needs through collaboration and joint planning, and
  • Identify and document commitments and actions to be taken to address shared and agreed upon priorities, together with associated timelines and measures to assess results.
C. Pathways to, through and out of care

Develop and document protocols, processes and partnerships that exist, or will be developed, that will streamline and strengthen clear pathways to, through and from care across sectors.

Next: Applying Multi-Criteria Decision Analysis to the “basket” of core mental health services for children and youth in Ontario

All things service

My day job as clinical leader of a large children’s mental health centre in Ontario, Canada presents me with the constant challenge of working with other professionals to devise and resource treatment plans for children and youth with complex emotional, behavioral, and learning needs.

I have been trained formally in the philosophy of language, cognitive psychology, and experimental design and statistics, though at this stage of my life I would describe myself as self-taught. Most recently, I have been studying two domains connected to my professional work – the concepts of “service” and “network”  – with the  idea of specifying more clearly a popular but particularly slippery concept – the “service network”.

In one case study, I intend to examine a database of human services in Ontario that is maintained online at http://211ontario.ca – and explore the “meaning” embedded in this sort of database using semantic web technologies, e.g.  the evolving Core Public Service Vocabulary of the European Commission and an ontology of government services included in a recent release of schema.org.

This is a work in progress.

Originally I had thought about working away under these broad headings:

While these headings still represent reasonable divisions of labour for me, there are three distinct but just-close-enough-to-be-confusing senses in which the term “service” is used in the literature:

  • a software service, like the SSL/HTTPS service, that secures the transfer of data packets over the Internet
  • a “real” world service, like a banking service, that allows someone to pay a monthly utility bill at a local branch
  • a “real” world service that is mediated by a software service, like an online banking service, that uses the SSL/HTTPS service to allow someone to pay a monthly utility bill securely over the Internet

Early on, the metaphor “software as a service” inspired pioneers in computer science to explore and elaborate one concept (software) that was novel and abstract in terms of another concept (service) that was familiar and grounded in human experience.

In the past two decades, our understanding of the concept of software, the concept of service, and the metaphor “software as a service” have advanced tremendously. Indeed, an entire industry has emerged around “Software as a Service” (SaaS) in “cloud computing.”

Finally, in much the same way that humans have moved from using the metaphor “computer as a brain” to using as readily the metaphor “brain as a computer” – the metaphor “service as a software” is used as readily as the metaphor “software as a service” in our thinking.

Today the prime driver for clarifying the semantics of “real world” service comes from software engineering – and seeks to improve the design and deployment of Web services that are (somehow) meant to facilitate the delivery of “real world” services.

My original thought was to enlist the technologies of software services – e.g. service-oriented computing, service-oriented architecture, service-oriented semantics – to describe and model more clearly and formally the defining features of “real” world services – especially human services, like social assistance, mental health counselling, and so on.

I still believe there is great potential in this exercise – and in the closely related exercise of elaborating how software services can support “real” human services – though we are liable to miss the mark if we take the metaphor “service as a software” too literally.