Data Cube Technical Manual

Table of contents

Introduction

The NOCC (National Outcomes Casemix Collection) Data Cube contains aggregated data extracted from the NOCC Data Warehouse, which, in turn, contains the results of mental health measures collected by all of the public mental health organisations in all Australian States and Territories. The earliest results in the NOCC Data Warehouse were collected in July 2000. In order to preserve the privacy of individual clients, information in the Data Warehouse is not made publicly available. However, aggregate data extracted from the Data Warehouse is deposited into the NOCC Data Cube, which ‘‘is’’ made available via a number of interfaces as described in this document. Additional information about the NOCC data can be found at https://www.amhocn.org/ via the Internet.

NOCC Data Cube Structure

The NOCC Data Cube contains three types of information:

General information about the site. Specifically: a version number for the NOCC Data Cube; the start date of the earliest financial year of data included in the data cube; the end date of the latest financial year of data included in the data cube.
Information about the structure of the data that is available (referred to as “meta data”). This includes things like: the list of NOCC measures available; the list of partitions and stratifications available; the lists of scales, subscales, and items available for each available measure.
Aggregate data derived from the responses to NOCC measures collected in the NOCC Data Warehouse. This is all numeric data – counts, averages, standard deviations, means, and percentiles – cross-referenced against various “stratification” factors and divided into various “partitions”.

Corresponding to these three types of information, there are three types of queries that are understood by the data cube: Information Queries, Meta Data Queries and Data Queries. Additionally there is a Statistics Query which uses a Data Query but returns the results pre-formatted. These are described in detail within the following sections.

Partitions, Stratifications and Text Items

Partitions are sets of data that would not be meaningful if they were aggregated together. For example, different measures relate to different issues concerning the client and so have different sets of questions. It would not be meaningful to get a client’s average score across the different types of measures collected for them.

Also, some partitions are hierarchical. For example, the measures collected for children and adolescents are different to those collected for adults, and different again for those collected for older persons. Both ‘age group’ and ‘measure’ are partitions, but the measure partitions are different for each age group partition.

Stratifications are attributes that can be used to make a sub selection within a partition. The sub selections of stratifications can be aggregated, since all of the observations being retrieved are part of the same partition and are, therefore, part of the same data set. For example, “sex” is a commonly used stratification. It is possible to retrieve the number of observations in a partition for just males, or just females, or for a combination of both.

The “age range” stratification is hierarchical. It allows sub selections within an “age group” partition, but each age group has a different selection of age ranges.

There is one class of data that is an answer to a question posed by the user, rather than a set of data kept in the data cube. As such, it is neither partition nor stratification, and is termed a “text” item to differentiate it from other results that may be returned. The user can specify a score of interest (usually the score achieved by a client whose results are being compared with normative data from the data cube), and the data cube will calculate the percentile that the score of interest would have had, if it had been an observation in the selected partition. Hence, a clinician can use this feature to get a precise comparison of a client’s score on a given measure with the aggregate scores for the same measure in the data cube.

Information Queries

There is only one information query and it returns three items of data:

The version of the data cube
The start date of the first financial year of data included in the data cube
The end date of the last financial year of data included in the data cube

Meta Data Queries

Meta data queries are used to determine what partitions, stratifications and text items exist in the data cube. This information will not change for a given version of the data cube, even though the range of financial years of data may increase over time.

The meta data is particularly useful for populating drop-lists and groups of check boxes in third-party user interfaces.

Data Queries

Data queries return the full details of a selected partition with (optional) stratifications applied, and, optionally, with a comparison percentile calculated for a given client score. The data items that are returned are:

The number of observations (N)
The mean
The standard deviation
A table of percentiles (10%, 25%, 50%, 75%, and 90%)
A table of observations per possible score (i.e. the cumulative distribution frequency) which can be used to generate a histogram
The client score (if supplied in the query)
The calculated test percentile (if a client score was supplied in the query)

Note that if the combination of the partition selected, and the stratifications applied, returns less than 30 observations, then the value for N will be the ‘‘only’’ data element returned. This is because any figures generated for a sample of less than 30 observations are not considered to be statistically significant and are suppressed to avoid them being used as a basis for clinical decisions.

NOCC Data Cube API

REST Overview

The NOCC Data Cube implements a Representational State Transfer (https://en.wikipedia.org/wiki/RESTful) interface across HTTP to allow the data to be queried. This implies that each item of data has its own URL and agents that wish to access a given item of data need only construct the appropriate URL and use standard HTTP to download the result. As the data cube contains only reference data, there is no need to implement two-way data transfers – it is a read-only data source.

The general format of a data cube query URL is:

<base URL><path><format specifier>

There are three base URLs:

https://data.amhocn.org/api/cube/info/ – for version, start date, end date and the date the data was generated (generation date).
https://data.amhocn.org/api/cube/meta/ – for information about the data structure and availability.
https://data.amhocn.org/api/cube/query/ – for statistical data.

The base URLs may have the path to the required item of data appended to create a full URL to the data item. This additional part is, appropriately, referred to as the path. The structure of the path is different for each of the base URLs and will be described in the following sections.

The format of the response is selected by appending an optional format specifier: none for HTML, .xml for XML, and .yaml (or .yml) for YAML, .csv for CSV and .json for JSON.

API Documentation

Information Queries

https://data.amhocn.org/api/cube/info/”

The info base URL does not require any path – the base URL alone is sufficient to return the version / start date / end date / generation date information response.

Response Attributes

Attribute	Description	Format
end_date	The end date of the last financial year of data included the NOCC Data Cube.	yyyymmdd
start_date	The start date of the first financial year of data included the NOCC Data Cube.	yyyymmdd
generation_date	The date the data in the NOCC Data Cube was generated.	yyyymmdd
version	The version of the NOCC Data Cube.	<major version>.<minor version>

Examples

https://data.amhocn.org/api/cube/info/.xml

<response end_date="20160630" generation_date="20170616" path="" start_date="20000701" updated_date="20170615" uribase="https://data.amhocn.org/api/cube/info" version="1.9"/>

https://data.amhocn.org/api/cube/info/.yaml

---
end_date: '20160630'
generation_date: '20170616'
path: ''
start_date: '20000701'
updated_date: '20170615'
uribase: https://data.amhocn.org/api/cube/info
version: '1.9'

Meta Data Queries

https://data.amhocn.org/api/cube/meta/

The meta base URL is hierarchical in nature. The base URL alone returns the valid options for the first part of the path. Appending one of these valid options to the base URL to form a new query will return the list of valid options for the next part of the path, and so on. Path items are separated with a forward-slash (/) character. Hence, the base URL used as a query ( https://data.amhocn.org/api/cube/meta/ ) will tell you that the valid options for the first part of the path are: jurisdiction, age-group, level-of-analysis, service-setting, sex, and diagnosis. Appending “age-group” ( https://data.amhocn.org/api/cube/meta/age-group/ ) will tell you that the valid options for the next part of the path are: child-and-adolescent, adult, and older-person. Appending “adult” to the URL ( https://data.amhocn.org/api/cube/meta/age-group/adult/ ) will tell you that the valid options for the next part of the path are: age-range, and measure. And so on. Eventually, a response will be received that contains no further options – that response indicates the end of that branch of the hierarchy.

The general format of a response to a meta query is as follows:

XML:

<response…>
    <options… />
    <path>…</path>
</response>

YAML:

---
options: []
path: []

Each “options” element represents a sub node of the subject of the meta data query. If there are no “options” elements, the subject of the meta query was a “leaf” node of a meta data branch.

Each “path” element represents an ancestor node of the subject of the meta data query. If there are no “path” elements, the subject of the meta query is the root node of the meta data tree.

Response Attributes

Attribute	Description
level-no	This element indicates what level in the meta data hierarchy the “options” elements of the meta query response are at. A value of “1” indicates the first level below the root, a value of “2” indicates the next level below the root, etc. If the subject of the meta data query was a leaf node, that is, there are no “options” elements in the response, then the level number will be that of the meta query subject – i.e. the level number will not increment beyond the level of the leaf node.
nodetype	This element indicates the type of node (“partition” or “stratification”) of the subject of the meta data query. This element is missing for a root level meta data query, since the root contains a mixture of both partitions and stratifications.
uribase	This element documents the base URL of the meta data query, specifically, “https://data.amhocn.org/api/cube/meta/” for the current NOCC Data Cube.
uripath	This element documents the extension to the base URL (excluding the format specifier) that was used to form the meta data query. For example, a meta data query of “https://data.amhocn.org/api/cube/meta/age-group/child-adolescent/.xml” would have a uripath setting of “/age-group/child-adolescent/”.

Options Element

The “options” element is a self-closing tag, that is, it contains attributes, but no text value or sub elements. There will be an “options” element in the meta data query response for each child node of the query subject. For example, if “/jurisdiction/” is the query subject, then there will be an “options” element for each Jurisdiction represented in the data cube (“national”, “nsw”, “vic”, etc.). Similarly, a meta query with a subject of “/age-group/” will contain three “options” elements – “child-adolescent”, “adult”, and “older-person”.

If the subject of the meta data query is a leaf node (e.g. “/jurisdiction/national/”), then the response will contain no “options” elements.

Attribute	Description
enabled	This attribute has the value “true” if the option is accessible to the user, and has the value “false” if not. The attribute will be missing from options that are always available to the user, regardless of the user’s login credentials. In the current NOCC Data Cube, only the “jurisdiction” options carry this attribute.
label	This attribute contains a human-friendly short version of the “literal” attribute in cases where the “literal” attribute is likely to be too long to be used in a drop list within a third-party user interface. This attribute will be set to an empty string if the “literal” attribute is not considered to be long.
literal	This attribute contains the human-friendly name of the option. It is always set to a non-blank value.
nodetype	This attribute is set to one of “partition”, “stratification”, or “text” depending on the node type of the option. It will be missing from leaf nodes, unless the node type of the leaf node is “text”.
urlid	This attribute is the computer-friendly name of the option. It is the value that must be used to construct a RESTful query. For example, if the subject of the query is “/age-group/”, and the “options” element of interest in the response has its “urlid” attribute set to “older-person”, then to query the next level of the tree along the “older-person” branch, the query subject would become “/age-group/older-person/”. This would create a complete meta data query URL of: [https://data.amhocn.org/api/cube/meta/age-group/older-person/.xml](https://data.amhocn.org/api/cube/meta/age-group/older-person/.xml)" or [https://data.amhocn.org/api/cube/meta/age-group/older-person/.yml](https://data.amhocn.org/api/cube/meta/age-group/older-person/.yml)

Path Element

The “path” elements in a response document the ancestor nodes from the level below the root down to, and including, the subject of the meta data query. There will be no “path” elements in a root query.

For example, the query:

https://data.amhocn.org/api/cube/meta/age-group/adult/age-range/.xml or https://data.amhocn.org/api/cube/meta/age-group/adult/age-range/.yml

Will contain the following “path” elements in the response:

<path>age-group</path>
<path>adult</path>
<path>age-range</path>

path:

age-group
adult
age-range

The “path” elements are always presented in hierarchical order within the response.

Errors Element

If a meta data query has the correct base URL, but contains an error in one or more of the “uripath” options, then the response will contain an “error” element, but not “options” elements. The “errors” element has no attributes, but it will contain one or more “error” elements that describe the errors detected in the meta data query URL.

The general form of an “errors” element is:

<errors>
<error…>…</error>
<error…>…</error>
   …
</errors>

errors: []

Error Element

The error element has an attribute that indicates the type of error in a computer-friendly form, plus one “message” sub element that describes the error in a human-friendly text.

The general form of an “error” element is:

<error name="...">
<message>…</message>
</error>

error:
   - name:
      message:
        - ...

For example:

<error name=”err-path-not-found”>
<message>/age-group not found.</message>
</error>

error:
   - err-path-not-found:
       message:
         - /age-group not found.

Attribute	Description
name	At present, the name attribute can only be “err-path-not-found”.

Message Element

The meta data “message” element is intended to provide a human-friendly description of an error in a meta data query URL. At present, it has no attributes, but future versions of the NOCC Data Cube may add an attribute to specify the language of the message text, should the data cube need to become multilingual. If this happens, then multiple “message” elements may be included in each “error” element – one for each supported language.

The only meta data error detected at present is an invalid meta data node name. The message will always consist of the unrecognised node followed by the text “not found.” For example:

<message>/age-group not found.</message>

message:
    - /age-group not found.

Example

https://data.amhocn.org/api/cube/meta/level-of-analysis/collection-occasion/occasion/.xml

Response:

<response>
    level-no="3"
    nodetype="partition"
    uribase="https://data.amhocn.org/api/cube/meta/"
    uripath="/level-of-analysis/collection-occasion/occasion/">
  <options label="" literal="Admission" urlid="admission" />
  <options label="" literal="Review" urlid="review" />
  <options label="" literal="Discharge" urlid="discharge" />
  <path>level-of-analysis</path>
  <path>collection-occasion</path>
  <path>occasion</path>
</response>

https://data.amhocn.org/api/cube/meta/level-of-analysis/collection-occasion/occasion/.yml

Response:

 ---
 level-no: 3
 nodetype: partition
 options:
   - label: ~
     literal: Admission
     urlid: admission
   - label: ~
     literal: Review
     urlid: review
   - label: ~
     literal: Discharge
     urlid: discharge
 path:
   - level-of-analysis
   - collection-occasion
   - occasion
 uribase: https://data.amhocn.org/api/cube/meta/
 uripath: /level-of-analysis/collection-occasion/occasion/

Data Queries

https://data.amhocn.org/api/cube/query/

The query base URL requires a path made up of sufficient = pairs to specify a unique partition of the data. Additional = pairs may optionally be added to identify a particular stratification of the data within the selected partition. Options that identify partitions have the attribute nodetype=“partition” set in the meta data, and options that identify stratifications have the attribute nodetype=“stratification” set in the meta data. A minimal valid path will define all partition values, such as: / jurisdiction=national / age-group=adult / measure=honos / view=htot12 / level-of-analysis=collection-occasion / occasion=admission / service-setting=ambulatory / (with no spaces around the “/” characters).

The above URL in full would be:

https://data.amhocn.org/api/cube/query/jurisdiction=national/age-group=adult/measure=honos/view=htot12/level-of-analysis=collection-occasion/occasion=admission/service-setting=ambulatory/

The general format of a data query is as follows:

{base URL}{option1}={value1}/[{option2}={value2}/][…].format

The base URL is currently “https://data.amhocn.org/api/cube/query/” and the allowable “option=value” pairs can be determined by using meta data queries.

The general format of a response to an XML data query is as follows:

<response>
   <literal-options… />
   <results…>
      <cdfs>
         <cdf… />
      </cdfs>
      <ptiles>
         <ptile… />
      </ptiles>
   </results>
   <path>…</path>
</response>

The general format of a response to a yaml data query is as follows:

---
literal-options: []
results:
cdfs: []
ptiles: []
path:
uribase:

Each “literal-options” element documents an option=value pair from the data query that produced the response.

The “results” attributes specify the overall values of the result (number of observations, mean, standard deviation, etc.). The “results” element contains two sub elements, “cdfs” and “ptiles”, which contain record sets of the Cumulative Distribution Frequency values and the Percentile values respectively.

Each “path” element represents an ancestor node of the subject of the data query. If there are no “path” elements, the subject of the data query is the root node of the data tree.

Response Attributes

Attribute: uribase

This element documents the base URL of the data query, specifically, “https://data.amhocn.org/api/cube/query/” for the current NOCC Data Cube.

Attribute: path

This element documents the extension to the base URL (excluding the format specifier) that was used to form the data query. For example, a data query of “https://data.amhocn.org/api/cube/query/jurisdiction=national/age-group=adult/.xml” would have a path setting of “/jurisdiction=national/age-group=adult /”.

Literal Options Element

The “literal-options” element is a self-closing tag, that is, it contains attributes, but no text value or sub elements. There will be a “literal-options” element in the data query response for each “option=value” pair in the query. For example, if “/jurisdiction=national/” is in the query, then there will be a “literal-options” element for it.

Attribute: literal

This attribute contains the human-friendly name of the “option” side of the “option=value” pair.

Attribute: urlid

This attribute contains the computer-friendly name of the “option” side of the “option=value” pair.

Attribute: value

This attribute contains the human-friendly name of the “value” side of the “option=value” pair.

Example:

The query “https://data.amhocn.org/api/cube/query/jurisdiction=national/…/.xml” would contain a literal-options element that looks like this:

<literal-options
     literal="Jurisdiction"
     urlid="jurisdiction"
     value="National" />

The query “https://data.amhocn.org/api/cube/query/jurisdiction=national/…/.yml” would contain a literal-options element that looks like this:

literal-options:
    - literal: Jurisdiction
      urlid: jurisdiction
      value: National

Result Element

The “result” element has both attributes and sub elements. The attributes return single value items, and the sub elements return record set items.

There are two general forms of the “result” element. The first, a self-closing form, is returned when there is insufficient data to provide meaningful results, that is, where the number of observations (the attribute “N”) is less than 30. The second is returned if N is greater than or equal to 30.

The first general layout of a result element is as follows:

<results N="…" />

results:
    N: ...

The second general layout of a result element is as follows (with no test score requested):

<results N="…" m="…" sd="…">
<cdfs... />
<ptiles... />
</results>

 results:
    N: ...
    m: ...
    sd: ...
    cdfs: []
    ptiles: []

The general layout of a result element for a query that requests a Status Score is the same, except that the “results” element has two additional attributes – status-score and comparison_percentile:

<results N="…" m="…" sd="…" status-score="…" comparison_percentile="…">

results:
    N: ...
    m: ...
    sd: ...
    status-score: ...
    comparison_percentile: ...

Similarly, the general layout of a result element for a query that requests a Change Score is the same, except that the “results” element has two additional attributes – change-score and comparison_percentile:

<results N="…" m="…" sd="…" change-score="…" comparison_percentile="…">

results:
    N: ...
    m: ...
    sd: ...
    change-score: ...
    comparison_percentile: ...

Attribute: N

This attribute supplies the number of observations that matched the criteria of the data query. If this value is less than 30, the self-closing form of the “result” element will be returned, otherwise, the full version of the “result” element will be returned.

Attribute: m

The “m” attribute supplies the mean of the observations returned by the criteria of the data query. The mean is returned to one decimal place. This attribute is only returned if the number of observations is 30 or greater.

Attribute: sd

The “sd” attribute supplies the standard deviation of the observations returned by the criteria of the data query. The standard deviation is returned to one decimal place. This attribute is only returned if the number of observations is 30 or greater.

Attribute: status-score

The “status-score” attribute documents the test score specified in the data query – it is relevant to “collection-occasion” queries only. The test score is returned to zero or one decimal places, depending on the measure and view selected in the data query. This attribute is only returned if the number of observations is 30 or greater.

Attribute: change-score

The “change-score” attribute documents the test score specified in the data query – it is relevant to “episode-transition” queries only. The test score is returned to zero or one decimal places, depending on the measure and view selected in the data query. This attribute is only returned if the number of observations is 30 or greater.

Attribute: comparison_percentile

The “comparison_percentile” attribute supplies the percentile of the test score supplied in the data query. The comparison percentile is returned to one decimal place. This attribute is only returned if the number of observations is 30 or greater.

CDFs Element

The “cdfs” element specifies the details of one record in the cumulative distribution frequency of a set of observations selected by a data query.

The general layout is as follows:

<cdfs N="…" percentage="…" score="…" />

cdfs:
  - N: ...
    percentage: ...
    score: ...

Attribute: N

This is the count of observations with the score specified in the “score” attribute.

Attribute: percentage

This is the cumulative percentage of the observations from the first “cdf” element in the set to the current one. It is returned to one decimal place.

Attribute: score

This is a possible score for the selected measure and view in the data query. There will be a “cdf” element in “cdfs” for each possible score that can be obtained for the selected measure and view, and they will be ordered from lowest to highest within the “cdfs” element.

Ptiles Element

The “ptiles” element specifies the details of one record in the list of percentiles of a set of observations selected by a data query.

The general layout is as follows:

<ptiles percentile="…" result="…" />

ptiles:
  - percentile: ...
    result: ...

Attribute: percentile

This a five possible percentiles for the selected measure and view in the data query. The percentiles returned are “10”, “25”, “50”, “75”, and “90” representing 10%, 25%, 50%, 75%, and 90% respectively. There will be a “ptile” element in “ptiles” for each of the five percentile values, and they will be ordered from lowest to highest within the “ptiles” element.

Attribute: result

This is the lowest score that is included within the percentile defined in the “percentile” attribute – that is, it is the score that defines the lower bound of the percentile. It is returned to zero or one decimal places depending on the measure/view selected in the data query.

Errors Element

The errors element has two attributes one that indicates the type of error in a computer-friendly form, the other indicating the option part of an “option=value” pair, plus one “message” sub element that describes the error in a human-friendly text.

The general form of an “errors” element is:

<errors name="…" urlid="…">
  <message>…</message>
</errors>

errors:
    - name:
      message: []

Attribute: name

The name attribute can be set to any of the error codes listed in the table below.

Error codes:

Name	Message
err-unknown	[option] is not a valid option.
err-missing	[option] is a partition and is therefore required.
err-access-denied	You are not authorised to access jurisdiction [jurisdiction].
err-no-child-nodes	No values defined for [option].
err-one-selection-per-partition	[option] is a partition so only one value can be defined.
err-invalid-value	[value] is not a valid value for [option].
err-one-value-per-text-field	[option] can only take a single value.
err-not-numerical	[option] must be numerical. [option] must be numerical to one decimal place.
err-out-of-range	[option] must be between [minscore] and [maxscore].
err-not-integer	[option] must be an integer.
err-normalizing-path	[normalization failure specific message]
err-no-view-transition-found	No view transition could be found – this error requires attention from the system administrators.
err-internal-error	Meaning similar to a HTTP 500 Internal Server Error (the error is not necessarily directly related to the user input). This error requires attention from the system administrators.

Message Element

The data query “message” element is intended to provide a human-friendly description of an error in a data query URL. At present, it has no attributes, but future versions of the NOCC Data Cube may add an attribute to specify the language of the message text, should the data cube need to become multilingual. If this happens, then multiple “message” elements may be included in each “error” element – one for each supported language. The data errors detected at present are those listed in the Error Codes table, above. Where a message contains an item enclosed in square brackets, this will be replaced by the appropriate value at the time the error occurs. For example, if the Level of Analysis partition was missing from a data query the message “[option] is a partition and is therefore required” would be used to create the following “message” element:

<message>Level of Analysis is a partition and is therefore required.</message>

message:
    - Level of Analysis is a partition and is therefore required.

Example

https://data.amhocn.org/api/cube/query/jurisdiction=national/age-group=adult/measure=honos/view=htot12/level-of-analysis=collection-occasion/occasion=admission/service-setting=ambulatory/.xml

Response:

<response path="/jurisdiction=national/age-group=adult/measure=honos /view=htot12/level-of-analysis=collection-occasion /occasion=admission/service-setting=ambulatory/" uribase="https://data.amhocn.org/api/cube/query">
<literal-options literal="Jurisdiction" urlid="jurisdiction" value="National" />
<literal-options literal="Age Group" urlid="age-group" value="Adult" />
<literal-options literal="Measure" urlid="measure" value="HoNOS" />
<literal-options literal="View" urlid="view" value="Total Score" />
<literal-options literal="Level of Analysis" urlid="level-of-analysis" value="Collection Occasion" />
<literal-options literal="Occasion" urlid="occasion" value="Admission" />
<literal-options literal="Service Setting" urlid="service-setting" value="Ambulatory" />
<results N="116008" m="11.5" sd="6.2">
<cdfs N="1517" percentage="1.3" score="0" />

...

<cdfs N="0" percentage="100.0" score="48" />
<ptiles percentile="10" result="4.0" />
<ptiles percentile="25" result="7.0" />
<ptiles percentile="50" result="11.0" />
<ptiles percentile="75" result="15.0" />
<ptiles percentile="90" result="20.0" />
</results>
</response>

https://data.amhocn.org/api/cube/query/jurisdiction=national/age-group=adult/measure=honos/view=htot12/level-of-analysis=collection-occasion/occasion=admission/service-setting=ambulatory/.yml

Response:

---
literal-options:
- literal: Jurisdiction
  urlid: jurisdiction
  value: National
- literal: Age Group
  urlid: age-group
  value: Adult
- literal: Measure
  urlid: measure
  value: HoNOS
- literal: View
  urlid: view
  value: Total Score
- literal: Level of Analysis
  urlid: level-of-analysis
  value: Collection Occasion
- literal: Occasion
  urlid: occasion
  value: Admission
- literal: Service Setting
  urlid: service-setting
  value: Ambulatory
normalized_path: /jurisdiction=national/age-group=adult/measure=honos/view=htot12/level-of-analysis=collection-occasion/occasion=admission/service-setting=ambulatory/
path: /jurisdiction=national/age-group=adult/measure=honos/view=htot12/level-of-analysis=collection-occasion/occasion=admission/service-setting=ambulatory/
results:
  N: 484508
  cdfs:
  - N: 5886
    percentage: '1.2'
    score: '0'
  - N: 5685
    percentage: '2.4'
    score: '1'
  - N: 10274
    percentage: '4.5'
    score: '2'
  - N: 13837
    percentage: '7.4'
    score: '3'
  - N: 18705
    percentage: '11.2'
    score: '4'
  - N: 22254
    percentage: '15.8'
    score: '5'
  - N: 26669
    percentage: '21.3'
    score: '6'
  - N: 28756
    percentage: '27.3'
    score: '7'
  - N: 31528
    percentage: '33.8'
    score: '8'
  - N: 32258
    percentage: '40.4'
    score: '9'
  - N: 32007
    percentage: '47.0'
    score: '10'
  - N: 30958
    percentage: '53.4'
    score: '11'
  - N: 30470
    percentage: '59.7'
    score: '12'
  - N: 27680
    percentage: '65.4'
    score: '13'
  - N: 25380
    percentage: '70.7'
    score: '14'
  - N: 22595
    percentage: '75.3'
    score: '15'
  - N: 20378
    percentage: '79.5'
    score: '16'
  - N: 17522
    percentage: '83.1'
    score: '17'
  - N: 15112
    percentage: '86.3'
    score: '18'
  - N: 12809
    percentage: '88.9'
    score: '19'
  - N: 11087
    percentage: '91.2'
    score: '20'
  - N: 8892
    percentage: '93.0'
    score: '21'
  - N: 7354
    percentage: '94.5'
    score: '22'
  - N: 5861
    percentage: '95.8'
    score: '23'
  - N: 4763
    percentage: '96.7'
    score: '24'
  - N: 3589
    percentage: '97.5'
    score: '25'
  - N: 2838
    percentage: '98.1'
    score: '26'
  - N: 2325
    percentage: '98.5'
    score: '27'
  - N: 1822
    percentage: '98.9'
    score: '28'
  - N: 1331
    percentage: '99.2'
    score: '29'
  - N: 1071
    percentage: '99.4'
    score: '30'
  - N: 762
    percentage: '99.6'
    score: '31'
  - N: 580
    percentage: '99.7'
    score: '32'
  - N: 418
    percentage: '99.8'
    score: '33'
  - N: 323
    percentage: '99.8'
    score: '34'
  - N: 225
    percentage: '99.9'
    score: '35'
  - N: 170
    percentage: '99.9'
    score: '36'
  - N: 105
    percentage: '100.0'
    score: '37'
  - N: 83
    percentage: '100.0'
    score: '38'
  - N: 47
    percentage: '100.0'
    score: '39'
  - N: 34
    percentage: '100.0'
    score: '40'
  - N: 29
    percentage: '100.0'
    score: '41'
  - N: 12
    percentage: '100.0'
    score: '42'
  - N: 15
    percentage: '100.0'
    score: '43'
  - N: 5
    percentage: '100.0'
    score: '44'
  - N: 0
    percentage: '100.0'
    score: '45'
  - N: 3
    percentage: '100.0'
    score: '46'
  - N: 1
    percentage: '100.0'
    score: '47'
  - N: 0
    percentage: '100.0'
    score: '48'
  m: '11.6'
  ptiles:
  - percentile: 10
    result: '4.0'
  - percentile: 25
    result: '7.0'
  - percentile: 50
    result: '11.0'
  - percentile: 75
    result: '15.0'
  - percentile: 90
    result: '20.0'
  sd: '6.2'
uribase: https://data.amhocn.org/api/cube/query

Appendix

HTTP Considerations

Redirection

Data query URLs contain a number of “option=value” pairs which select the partition and stratifications to be used. It is possible to shuffle these “option=value” pairs into any order and get the same response from the data cube. To simplify processing these requests, the data cube first sorts the “option=value” pairs into its preferred (the “canonical”) order, if this operation changes the order of the pairs, then the query is redirected to the new “canonical” URL. This may cause issues with a software application if the HTTP component used does not handle redirection automatically. If this is the case, the software will need to detect an HTTP response with a status code of 301 (redirection), and reissue the query with the URL returned in the HTTP response. See Hypertext Transfer Protocol – HTTP/1.1 and search for “redirection” for more details.