The Intelligent Wellbeing Engine exports every organisation-level result as a JSON report modelled on the aggregate report of the Open Workplace Health Standard (OWHS), an open data standard for workplace health published at openworkplacehealth.org.
An employer, or anyone the employer chooses, can read the file without your software or ours. Each row carries its own group size, completion rate and confidence interval, and a withheld result stays in the file with its reason. This page lists what the file contains, field by field.
OWHS is a draft open standard for workplace health data. It covers sickness absence, return to work, occupational health, wellbeing measurement and benefit provision. The specification text is published under the CC BY 4.0 licence and the schemas, code lists and tools under Apache 2.0, so anyone can implement it without asking permission. The current version is a v0.2 draft.
In OWHS, results leave an organisation as an aggregate report: a group size, a completion rate, a value with its interval, and details of any suppression. The standard sets a floor of five people for any result an employer can see, and ten for severe-distress measures.
OWHS is an open standard, currently stewarded by Alltoogether. This export is built on its aggregate report, and nothing on this page means OWHS endorses the IWE. The IWE's export states the OWHS version it was written against, 0.1, and has not yet been updated to the v0.2 draft. Its field names are the IWE's own, such as org_unit_ref and ci, and a withheld row carries null values where OWHS leaves those fields out, so the file does not validate against the published OWHS schemas.
curl -s "https://sandbox.wellbeingengine.io/aggregates/export?cycle_id=<round id>" \
-H "Authorization: Bearer $ACCESS_TOKEN"
# 200, Content-Type: application/vnd.owhs.aggregate-report+jsonThe call needs the aggregates:read scope, which sandbox keys carry. Round IDs come from GET /cycles. Leave out cycle_id and the file holds every round in the deployment, ordered by round, organisation and metric.
The file is one JSON object. The top level names the format and the system that produced it, and states the code-list versions that every row uses.
{ "owhs_version": "0.1",
"media_type": "application/vnd.owhs.aggregate-report+json",
"producer": { "producing_system": "IWE reference engine",
"system_version": "...", "region": "..." },
"codelists": { "suppression-reason": "0.1.0",
"sampling-design": "0.1.0",
"construct-domain": "0.1.0",
"construct-domain.x-iwe": "0.1.0-provisional" },
"reports": [ ... one row per result ... ] }region is where the deployment is hosted. Construct codes that start with x-iwe: come from a provisional IWE extension to the OWHS construct-domain list. The prefix stays in the file, so a reader can tell them apart from core OWHS codes.
Each entry in reports is one result: one organisation, one round, one metric, and for a single question, that question.
| Field | What it holds |
|---|---|
org_unit_ref | Your own reference for the employer, the same one you use when you sync the roster. |
period | The round's start and end, and its round number, cycle_number. |
sampling_design | How questions were given out, as a code from the OWHS sampling-design list. IWE rounds default to rotating-subset, meaning two fixed questions for everyone and one that rotates. |
metric | WELLBEING_INDEX for the headline index, or DOMAIN_MEAN for one question. Other metric names are defined but not computed today. |
construct_domain | What the question measures, as an OWHS construct-domain code or an x-iwe: extension code. Null on index rows. |
instrument_citation | A citation for the instrument the question comes from. The question's wording is never exported. Null on index rows. |
n | How many people the result rests on. |
headcount | How many people were on the roster for the round. |
completion_rate | The share of the roster who answered. |
method | design for ten or more people, indicative for five to nine. Show indicative results as provisional. |
index_version | Which version of the index calculation produced the result, for example v1-equal. |
suppressed, suppression_reason | Whether the result is withheld, and if so, why, as a code from the OWHS suppression-reason list. |
value, ci | The result and its 95% confidence interval, as low and high. Both are null when the result is withheld. |
measurement_context_ref | The ID of the engine's measurement context in force when the export ran. That record describes the scoring method and its known limits. |
computed_at | When the result was computed. |
A result for fewer than five people is never stored, so there is no value to export. The row still appears, with suppressed: true, a reason code, and no value or interval:
{ "org_unit_ref": "acme-ltd",
"period": { "start": "...", "end": "...", "cycle_number": 7 },
"metric": "DOMAIN_MEAN",
"n": 4, "headcount": 12,
"suppressed": true, "suppression_reason": "below-floor",
"value": null, "ci": null,
... }The reason is a code from the OWHS suppression-reason list, which defines three: below-floor, low-completion and safeguarding. Today the engine writes only below-floor, for a result that would rest on fewer than five people; the other two codes are defined in the list. Show the row as withheld, with its reason, and never as zero or a blank.
The rule lives in the database. The aggregates_firewall constraint rejects any stored result for fewer than five people, and the export reads the same table, so no setting can put a value for fewer than five into the file. Why the floor is five.
An employer that uses your product gets its results in a form it can check. The file names its code-list versions, those code lists are public at openworkplacehealth.org, and this page lists every field, so the employer's analysts, its auditors or a later provider can read it without your documentation.
The honesty rules travel with the numbers. Group size, completion rate, interval and any reason for withholding sit in every row, so a chart built from the file later has what it needs to show them.
A customer's data protection review can see exactly what leaves your product: organisation-level results, codes and citations, and nothing about any one person. And the history stays readable if a customer leaves your product, or if you stop using the IWE.