Skip to content

JSON Schemas

About this page

This page was written by the New Horizons engineering team, which operated until December 2025. First-person references ("we", "our") are the original authors'. A number of those authors are now working with Phoenix GH, which maintains this material and stands behind it. Questions and comments are welcome — please get in touch.

Overview

This page provides JSON schemas to support the proposed requirements for CCE data transmission to countries.

The JSON schema on this page is closely derived from the PQS EMS Data Standard (DS01.x). While DS01.x defines how data should be stored on EMS-compliant fridges and freezers, this schema specifies how CCE data should be structured when transmitted from monitoring suppliers to third parties, particularly countries. The development of this schema began as an independent initiative without formal endorsement by, or association with, the WHO PQS process. Later, many of the core aspects of this schema were reviewed and incorporated into the output of the UNICEF industry consultation on CCE data delivery (Q1 2025). WHO PQS is actively working to integrate data delivery requirements and a schema into the EMS data specification (E006/DS01.x).

By developing these schemas in public view, with input from multiple CCE monitoring partners, Phoenix GH hopes that stakeholders across the cold-chain ecosystem can pursue their CCE interoperability objectives more efficiently.

Latest versions

Draft JSON Schema Versions

WHO PQS has not yet published the final data delivery JSON schema. The version that emerged from the Q1 2025 UNICEF industry consultation is 0.7.2. New Horizons and Phoenix GH had previously published draft schemas to this page that contained proposed revisions beyond 0.7.2. These proposed revisions have been shared with PQS and we have taken the draft schemas offline while the PQS processes proceeds. However, we would be pleased to discuss our proposed revisions with any interested party. Please contact us.

Output from UNICEF industry consultation:

Changelog

0.7.2 (February 12, 2025)

This is the version from the UNICEF consultation in Q1 2025.

  • Added logic in ems-record to prevent null TVC if LERR is also null.

Schema file: cce-interop-0.7.2.json

0.7.0 (September 19, 2024)

  • Added AMID property to RTMD report, to capture a stable identifier for an appliance in the absence of other appliance identifiers (e.g., serial numbers, national asset IDs, etc.).

Schema file: cce-interop-0.7.0.json

0.6.0 (September 6, 2024)

  • Fixed subschema for RTMD records to require BEMD and EERR instead of BLOG and LERR. This change makes the RTMD record fields consistent with the changes made in version 0.4.0 (i.e., to represent an RTMD as an EMD rather than an EMS logger). EMS-related subschemas have not been modified in this changeset.

Schema file: cce-interop-0.6.0.json

0.5.0 (June 13, 2024)

This update applies only to RTM transmissions. EMS transmissions are unchanged.

  • Added the DLST object to the RTMD data report, which provides a structured way to communicate mappings between RTM devices, attached sensors, and fridge performance attributes (e.g., TVC, TAMB, TFRZ). This property is required.
  • The TVC property in individual records objects is no longer required. Instead, at least one of TVC, TAMB, or TFRZ is required in each record, which ensures support for some RTM devices that sample ambient temperatures on different intervals from vaccine chamber temperatures. With this change, such systems can send TVC in one record and TAMB (or TFRZ) in other records. See examples below for more detail.

Schema file: cce-interop-0.5.0.json

0.4.0 (January 30, 2024)

  • Changed the required fields for an RTMD transmission to represent the RTMD device as an EMD, with corresponding metadata fields (e.g., EDOP, EMFR, EMOD, EPQS, ...), rather than as a Logger (e.g., LDOP, LMFR, LMOD, ...)

Schema file: cce-interop-0.4.0.json

0.3.0 (January 16, 2024)

  • Removed HAMB, HOLD, and SVA from list of required fields in the ems-record sub-schema. Added logic to ensure that either SVA or (DCSV + DCCD) is required in an ems-record, depending on whether an appliance is mains- or solar-powered.

Schema file: cce-interop-0.3.0.json

0.2.0 (January 12, 2024)

  • Added conditional handling for LSV and EMSV fields, which can appear either at the top-level of a report object or in each individual record.

Schema file: cce-interop-0.2.0.json

0.1.1 (January 8, 2024)

  • Added support for EMS and RTM data in a single schema

Schema file: cce-interop-0.1.1.json

Considerations

This schema supports transmissions for both RTM and EMS devices. Although reports for multiple devices can be included in a single transmission, all reports that are submitted in a single transmission must be of the same type. The type of report is indicated by the meta.transferType field, which supports a value of either rtm or ems.

The difference between RTM and EMS transmissions is the list of fields that are required in each report. RTM devices were developed independently of the EMS specifications and therefore do not support all data fields required by the EMS specification. In contrast, EMS devices are verified to the requirements of the EMS specification, so they are held to that standard. The examples below illustrate the differences between RTM and EMS reports.

Note that neither this schema nor DS01 constrains the ordering of the records array. Receivers must not assume records arrive in chronological order, and should sort by ABST before any duration or streak analysis.

Example Transmissions

Example 1: EMS report

The following example shows a report from a single EMS device. Reports for additional devices can be included as distinct objects in the top-level data array. Consistent with the PQS EMS standards, each report should include metadata about the appliance, the EMD, and the logger, plus a set of measurement and error/alarm objects in .data[].records. Note that the records array includes all required fields for a mains-powered fridge, plus optional HAMB and HOLD fields.

{
  "meta": {
    "transferSrc": "org.temp-monitoring-ltd",
    "transferId": "ba302d2b-a60d-423b-a34e-22bca05b6c24",
    "transferredAt": "2023-12-28T19:57:33.386615Z",
    "transferType": "ems",
    "schemaVersion": "0.7.2"
  },
  "data": [
    {
      "CID": "ATA",
      "LAT": -75.024306,
      "LNG": 70.497348,
      "ADOP": "2020-12-01",
      "AMFR": "Alpha Fridge, Inc",
      "AMOD": "FRIDGE-100",
      "APQS": "E003/998",
      "ASER": "1234asdf98jxzy",
      "EDOP": "2020-12-01",
      "EMFR": "Temperature Monitoring, Ltd.",
      "EMOD": "EMD-1000",
      "EPQS": "E006/999",
      "ESER": "b9c250d412234e5d80fd3f057903c36b",
      "EMSV": "0.2.9",
      "LDOP": "2019-12-08",
      "LMFR": "Temperature Monitoring, Ltd.",
      "LMOD": "EMD-1000",
      "LPQS": "E006/999",
      "LSER": "d2aa4105c32147e5b37bf7dcf8d56777",
      "LSV": "0.1.1",
      "records": [
        {"ABST":"20240103T163228Z","ALRM":null,"BEMD":13.0,"BLOG":13,"CMPR":0,"DORV":0,"HAMB":58.0,"HOLD":4.6,"LERR":null,"EERR":null,"SVA":900,"TAMB":23.1,"TVC":4.7},
        {"ABST":"20240103T164228Z","ALRM":null,"BEMD":13.0,"BLOG":13,"CMPR":0,"DORV":0,"HAMB":58.1,"HOLD":4.5,"LERR":null,"EERR":null,"SVA":900,"TAMB":23.1,"TVC":4.7},
        {"ABST":"20240103T165228Z","ALRM":null,"BEMD":13.0,"BLOG":13,"CMPR":0,"DORV":0,"HAMB":58.2,"HOLD":4.5,"LERR":null,"EERR":null,"SVA":900,"TAMB":23.0,"TVC":4.7},
        {"ABST":"20240103T170228Z","ALRM":null,"BEMD":13.0,"BLOG":13,"CMPR":0,"DORV":0,"HAMB":58.3,"HOLD":4.5,"LERR":null,"EERR":null,"SVA":900,"TAMB":23.0,"TVC":4.7},
        {"ABST":"20240103T171228Z","ALRM":null,"BEMD":13.0,"BLOG":13,"CMPR":0,"DORV":0,"HAMB":58.5,"HOLD":4.5,"LERR":null,"EERR":null,"SVA":900,"TAMB":23.0,"TVC":4.7},
        {"ABST":"20240103T172228Z","ALRM":null,"BEMD":13.0,"BLOG":13,"CMPR":0,"DORV":0,"HAMB":58.7,"HOLD":4.5,"LERR":null,"EERR":null,"SVA":900,"TAMB":22.9,"TVC":4.7}
      ]
    },
    ... optional additional EMS reports can be added
  ]
}

Example 2: RTM report

The example below illustrates a hypothetical JSON payload from a (non-EMS) RTMD device. It is similar to the EMS example above, but it doesn’t include any metadata about the CCE appliance (fridge or freezer). Similarly, RTMDs are not expected to have the same sensor equipment as EMDs, so RTMD data samples have fewer required fields than those of an EMS-compliant system.

Note how TAMB and TVC fields can be included in their own individual records. This is a change from EMS systems, which require TVC in every record. As noted previously, this change was made to ensure compatibility with RTM devices that sample ambient temperatures on different intervals from vaccine chamber temperatures.

The transmission treats the RTMD as an EMD and captures RTMD metadata in EMD-related fields (e.g., EMFR, EMOD, ESER, etc.). If the CCE supplier has data about the appliance (which might be captured during commissioning, for example), this data should be included in the JSON object (i.e., in the AMFR, AMOD, ASER, ADOP, APQS, and ACAT fields). These fields are omitted in this example because non-EMS systems might not have this information available.

{
  "meta": {
    "transferSrc": "org.temp-monitoring-ltd",
    "transferId": "6d5edade-8ad0-11f1-a5f7-cc96e5dfb60b",
    "transferredAt": "2023-12-28T19:57:33.386615Z",
    "transferType": "rtm",
    "schemaVersion": "0.7.2"
  },
  "data": [
    {
      "CID": "ATA",
      "AMID": "tenant:4efd513e/facility:544ed8a/appliance:456f8688", // supplier's internal ID for a CCE
      "EDOP": "2019-12-08",
      "EMFR": "Acme Monitoring, Ltd.",
      "EMOD": "Acme Monitor 1000",
      "EPQS": "E006/999",
      "ESER": "d2aa4105c32147e5b37bf7dcf8d56777",
      "EMSV": "0.1.1",
      "LAT": -75.024306,
      "LNG": 70.497348,
      "records": [
        {"ABST":"20231230T190733Z","ALRM":null,"BEMD":14.7,"EERR":null,"TAMB":28.5},
        {"ABST":"20231230T191733Z","ALRM":null,"BEMD":14.7,"EERR":null,"TVC":6.5},
        {"ABST":"20231230T192733Z","ALRM":null,"BEMD":14.7,"EERR":null,"TAMB":28.2},
        {"ABST":"20231230T193733Z","ALRM":null,"BEMD":14.7,"EERR":null,"TVC":6.4},
        {"ABST":"20231230T194733Z","ALRM":null,"BEMD":14.7,"EERR":null,"TAMB":27.9},
        {"ABST":"20231230T195733Z","ALRM":null,"BEMD":14.7,"EERR":null,"TVC":6.3}
      ],
      "DLST": {
        "TVC": {
          "SID": "abc-123",
          "SMFR": "Acme Monitoring, Ltd.",
          "SMOD": "Acme Sensor 1000"
        },
        "TAMB": {
          "SID": "def-456",
          "SMFR": "Acme Monitoring, Ltd.",
          "SMOD": "Acme Sensor 1000"
        }
      }
    },
    ... optional additional RTM reports can be added
  ]
}

A note about Software Version and Location

The examples above include software version information (i.e., LSV and EMSV) and location information (i.e., LAT and LNG) at the top level of the report (i.e., not in each record in the records array). It is important to note, however, that these fields might change over time and might be better included in each individual record (at the expense of repetition). It is up to the implementer to decide which approach is best for their use case. Both options are supported by the schema.

The following considerations might be helpful in making this decision:

  • How often does the software version change?
  • When the software version changes, will the interpretation of records need to change?
  • How often does the location change?

References