Skip to content

CCE Data Interoperability

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.

The cold-chain ecosystem is quickly evolving to require CCE monitoring suppliers to transmit CCE monitoring data to the countries that own it. The PQS EMS specifications include an explicit requirement to this effect in Clause 5 of WHO/PQS/E006/DS01, but low-level details of these transmissions are not specified in the standards. This page links to a set of proposed requirements that are intended to supplement Clause 5 of DS01, promoting a common, interoperable approach for transmitting CCE data from suppliers to countries.

The documents linked on this page were originally developed by New Horizons in 2024 and refined through substantial industry feedback during a UNICEF-led industry consultation in Q1 2025. Beginning in 2026, Phoenix GH is maintaining these documents and contributing to WHO PQS efforts to incorporate CCE data delivery guidance into the EMS specifications.

Key documents

Three key documents are published here:

  1. This page provides a contextual overview to aid understanding;
  2. The Proposed Requirements page links to written requirements to supplement Clause 5 of E006/DS01.x;
  3. The JSON Schemas page links to the versioned JSON Schema document that provides data definitions and structure for interoperable CCE data transmissions. This schema supports EMS and non-EMS (i.e., RTMD) platforms with minimal variation.

Scope

The scope of Proposed Requirements is CCE data transmission from monitoring suppliers’ cloud platforms to country data systems. It covers aspects of transmission that were either omitted from the EMS specification or treated "lightly" by the specification, including:

  • Authentication
  • Encryption
  • Size limitations and support for compression
  • Data schema and definitions for transmission payload
  • Transmission timing
  • Error handling
  • . . . and other important considerations

The interoperable CCE data delivery schema, linked on the JSON Schemas page, is derived from WHO/PQS/E006/DS01, Annex 2: JSON Schema, adding support for RTMD data, plus metadata to capture details of the data transmission itself. As previously noted, these proposed requirements and schema are intended to apply to both EMS and non-EMS (i.e., RTMD) systems.

Intended audience

The primary audience for this document is Software and Data Engineers, especially:

  • Engineers who are responsible for managing CCE data in a CCE monitoring supplier’s cloud platform
  • Engineers who are responsible for country-side ingestion and management of CCE data

Data delivery conceptual architecture

To understand how interoperable CCE data delivery might work between suppliers and a country, first consider a country with hundreds (or thousands) of CCE monitoring devices deployed in the field. For simplicity, we'll refer to these devices as "RTMD" to avoid the need to distinguish between RTMD and newer EMS devices. These RTMD devices regularly transmit data to their respective supplier’s cloud-based platforms.

Now consider that the country wants to connect this RTMD data to its other IT systems (e.g., eLMIS, HMIS, etc.), to enable important use cases. To achieve this, the country has configured a software system – referred to here as an "interoperability layer" – to receive CCE data from all of its suppliers. Although the internal mechanics of the interoperability layer are beyond the scope of this document, it should be broadly understood as middleware designed to enable integration across diverse IT systems. It exposes an HTTPS endpoint to receive RTMD data from suppliers.

The country shares this endpoint1 with all its suppliers, who then configure their platforms to forward RTMD data to this address in accordance with the guidelines described here. Ideally, suppliers transmit RTMD data to the country shortly after receiving it, which helps avoid congestion and delays that could result from sending large batches only once per day (e.g., at midnight).

When valid data arrives, the interoperability layer responds with a 200 OK and processes the data according to a set of country-defined rules2. Occasionally, data processing might fail due to issues in the transmitted data. In these cases, the interoperability layer can notify the supplier about the failure via email, SMS, or a webhook, depending on the country's chosen approach.

The diagram below provides a high-level illustration of how countries could implement an interoperability layer to receive and process CCE monitoring data.

CCE Data Interoperability Layer - high level overview

Existing PQS requirements

This is a simplified summary of the key technical requirements for CCE data delivery from suppliers to countries, found in Clause 5 of WHO/PQS/E006/DS01.2. You are encouraged to refer to the original document for the complete text of the data delivery requirements.

  • At the country’s request, suppliers will transmit CCE data to the country.
  • Suppliers will transmit CCE data via HTTPS POST to a URL endpoint provided by the country.
  • Suppliers will authenticate to the URL endpoint using credentials provided by the country, if any.
  • Suppliers will transmit data in JSON format.
  • The transmitted JSON payload will include, at minimum, the following data:
    • Country ID
    • ID of the monitoring device
    • CCE monitoring supplier ID (“legal manufacturer” or “reseller”)
    • All monitored data objects, alarms, and error codes
  • Suppliers will transmit data within 24 hours of receiving it from a remote EMD.3
  • Suppliers will provide definitions for any custom objects used in their data transmissions.

The Proposed Requirements provide additional guidance and supplemental requirements to help suppliers and countries implement CCE data delivery to external systems in a common way.

Comparison to EMS JSON schema

The proposed data delivery JSON schema is derived from the JSON schema in the EMS data standard (WHO/PQS/E006/DS01, Annex 2). It is important to recognise, however, that the JSON schema in Annex 2 describes the data format for data recorded by an EMS logger or EMD on a refrigerator or freezer. The proposed schema linked here does not replace the existing Annex 2 schema — it is a separate schema that describes how EMS data should be formatted for delivery from monitoring suppliers to third-party systems. Some notable changes are listed below:

Adoption of JSON:API structure

The schema adopts the top-level JSON structure from JSON:API, section 7.1. This change adds a root-level meta property to the JSON object, containing metadata related to the transmission itself (i.e., not CCE data). The CCE data is moved under the root-level data property. The root-level structure of the resulting JSON payload is shown below:

{
  "meta": { },
  "data": [ ]
}

Multiple reports in a single transmission

The root-level data property is typed as an array. This allows suppliers to transmit reports for multiple CCE in a single HTTP transmission, as shown below.

{
  "meta": { },
  "data": [ 
     { <report from CCE #1> },
     { <report from CCE #2> },
  ]
}

Alternatively, suppliers could transmit multiple reports for a single CCE, as shown below.

{
  "meta": { },
  "data": [ 
     { <report 1 for CCE #1> },
     { <report 2 for CCE #1> },
  ]
}

Unchanging properties grouped at the root of a report

The EMS JSON schema in DS01 is very flexible with respect to where data properties are located within the JSON object. The only property that is required at the root of an EMS JSON object is records. The only properties required in a records item are RELT and RTCW. Nevertheless, there are many other required data properties that must be in an EMS-compliant JSON object. For each of these properties, suppliers can choose whether to place the property at the root of the JSON object or inside each of the records items.

The JSON schema for data delivery is more opinionated about where data properties should be located within the JSON object. Specifically:

  • Properties that never change – or change infrequently – are placed at the root of a JSON object. Most of the “administrative” properties (e.g., ACAT, ASER, LMFR, LMOD, etc.) are included in this group.
  • Properties that change frequently (e.g., TVC, TFRZ, ABST, LEMD, etc.) are located within items in the records array.

This eliminates repetition of unchanging data properties in the JSON object, which ensures that items in the records array reflect fridge performance metrics and other volatile CCE properties.

Requiring absolute timestamps

The proposed JSON schema for data delivery requires absolute timestamps (ABST) for all records. Although the EMS verification schema only requires relative timestamps (RTCW plus RELT) in the JSON object, countries and other downstream consumers of CCE performance data will depend on reliable absolute timestamps.

Support for RTMD data

Adding support for RTMD data required the most substantial modifications to the original EMS JSON schema. In comparison to RTMDs, EMS devices monitor an extended set of administrative data and performance metrics. As such, EMS devices are expected to transmit more data than RTMDs.

To support both EMS and RTMD data, the JSON schema structure expresses conditional logic based on the transmission metadata. Specifically: the value of meta.transferType controls whether a transmission will be interpreted as EMS or RTMD data. If the value of the meta.transferType property is "ems", the schema will enforce expectations that are appropriate to EMS. Otherwise, the schema will enforce expectations that are appropriate to RTMD.

To understand how this works, start by reviewing the $defs section of the schema, which is where common definitions are provided for named JSON subschemas. The conditional logic for interpreting data as either EMS or RTMD is responsible for selecting the appropriate subschemas based on the contents of the transferType property, as noted above. The transferType property is defined in the transmission-metadata named subschema. The table below clarifies the purpose of each subschema defined in the $defs section.

Subschema name Description and example
transmission-metadata Metadata related to the transmission itself (not the CCE).
ems-report Defines expectations for data and structure of an EMS report. A “report” is a JSON object that contains administrative and performance data for a single CCE, including one or more temperature records.
ems-record Defines expectations for items in the records array of an ems-report.
rtmd-report Defines expectations for data and structure of an RTMD data report. Similar to an ems-report, but tailored to RTMD datasets.
rtmd-record Defines expectations for items in the records array of an rtmd-report.
rtmd-sensor-schema Defines data and structure describing an RTMD sensor, which allows suppliers to clarify mappings between sensors and EMS-defined temperature properties (i.e., TVC, TFRZ, TAMB).

The image below illustrates how the JSON schema enforces different expectations on a JSON object by conditionally applying different subschemas, based on the value of the meta.transferType property.

Schema interpretation based on transferType property

References

Endnotes

1 A country could also, at its discretion, expose more than one endpoint to manage data intake. The inclusion of the sender information in the proposed payload (i.e., meta.transferSrc property) enables countries to segregate data by supplier, even if the country configures only a single data ingestion endpoint.

2 Different systems have different expectations regarding the structure and granularity of data. An interoperability layer enables the country to enrich, transform, and deliver data in a variety of ways to satisfy the requirements of downstream systems. For example, a country might develop one set of rules (i.e., software functions) to derive CCE Functional Status based on the full-fidelity data and then send this indicator to their eLMIS platform. Different systems might benefit from daily summaries of alarms (counts, times, etc.) or temperature (min, max, avg), which could be computed and delivered to those other systems by the interoperability layer. Ultimately, an interoperability layer allows countries to autonomously create new data processing rules to satisfy new use cases.

3 The EMS specifications acknowledge that “disruptions to communications networks may result in variable latency, so the minimum specified frequency should be considered a ‘best effort’ specification”.

Contact

Contact: Benson Miller

For more information, contact us about CCE data interoperability.