Hello!
I've been taking a look at the existing data standards established by WHO/PQS/E006/DS01.2, and was wondering if there is any work being done in the open to extend this standard. Section 5 of the current standard is amazing since it encourages an open data policy in the space! But without a shared understanding of how to *interpret* time series data that's being shared, it will be difficult for countries to take advantage of the coming AI transformation.
Off the top of my head, I'd love to see some of the topics addressed:
- Defining a standard for how facilities and administrative regions should be represented and associated with CCEs and data loggers.
- Defining a standard around how KPIs are grouped across multiple CCEs and data loggers. A single deployment may contain thousands of CCEs and data loggers, there need to be metrics and KPIs defined for groupings of those CCEs such as health facilities or administrative regions.
- Defining several approaches intelligently interpret data. It's fairly common to see CCEs decommissioned in the field, but the remote data logger assigned to the CCE still sending data. A naive way to interpret this data would be to report this CCE as being in a heat alarm for months. Different approaches are possible to make reports more interpretable for business users, keeping the focus on *real* problems rather than data input flubs.
And then of course, going beyond standards and documents and actually building software (preferably open source) that implements said standards.
If there's a discussion happening around these topics, I'd love to listen in and help where I can! I worry that the current standards are necessary but not sufficient, they may bring us to a world where data can be shared freely, but if the data we're sharing isn't interoperable between different software systems, the value of the data remains locked away and in the hands of the organizations that can afford to mine the data for insight.
Hello Chris -
Thank you for sharing these questions. I have some perspectives to contribute to this conversation.
As you indicate, Clause 5 of E006/DS01.2 requires suppliers to transmit all captured CCE data to the country, at the country’s request. It’s important to recognize, however, that the low-level details of CCE data transmissions are not fully defined in DS01.2. Recognizing this gap (and a opportunity to create more clarity), UNICEF Supply Division convened a consultative process with E003 and E006 suppliers in January 2025 to develop low-level requirements for transmitting CCE data to countries. This work will conclude in a matter of days, but you can find the current-state artifacts from this process at the following URL: Requirements for interoperable CCE data delivery. This work supports both next-gen EMS equipment and current-gen RTM systems. As I see it, the ecosystem is fast approaching a point where suppliers and countries can align on a common, scalable approach to CCE data exchange. This would unlock significant benefits in CCE data utilization and value.
Below are some more specific comments to your original post:
RE: Defining a standard for how facilities and administrative regions should be represented and associated with CCEs and data loggers.
The EMS data standard includes a Facility ID (FID) field, which is intended to capture the unique ID of the facility where the equipment is located. Ideally, this ID would be registered and queryable in the country’s geolocated Health Facility Master List (HFML). This ID might be a GLN (i.e., from the GS1 system) or some other national identifier. If we assume that the FID field can be reliably populated (a variety of approaches are possible) and if the country has reasonably mature HFML system(s), then the entire administrative hierarchy should be retrievable as part of a data ingestion pipeline. Admittedly, things get trickier if Facility master data is distributed across a bunch of different platforms or if you cannot reliably populate (or lookup) the Facility ID based on other attributes (e.g., LAT/LNG of the equipment). I’d be keen to talk more about this. It’s my sense that associating CCE with facility and/or administrative hierarchy data is less about data standards and more about three things: (1) the country’s HFML strategy, (2) the maturity of the country’s CCE commissioning process, and (3) the maturity of feedback loops to maintain these data associations over time.
RE: Defining a standard around how KPIs are grouped across multiple CCEs and data loggers. A single deployment may contain thousands of CCEs and data loggers, there need to be metrics and KPIs defined for groupings of those CCEs such as health facilities or administrative regions.
I’d love to ask you some more questions about this. It’s clear that a CCE analytics system must be able to compute mathematical aggregates, grouped by administrative hierarchy attributes. When you think about data standards for KPIs, do you envision that aggregate KPIs would be exchanged between different systems? My mental model includes data exchange for raw CCE data and aggregates for individual CCE (e.g., daily temperature summaries or alarm counts), but I haven't thought much about the possibility of exchanging population-level aggregates.
RE: Defining several approaches intelligently interpret data. It’s fairly common to see CCEs decommissioned in the field, but the remote data logger assigned to the CCE still sending data. A naive way to interpret this data would be to report this CCE as being in a heat alarm for months. Different approaches are possible to make reports more interpretable for business users, keeping the focus on real problems rather than data input flubs.
I like this question and I would be interested to discuss in more detail. This topic is especially interesting as we prepare for the introduction of EMS systems. These systems will capture an expanded set of diagnotic parameters, which can improve the quality of automated diagnostics. On the other hand, CCE data systems exist in a symbiotic relationship with people and we should be cautious that we don’t design software systems that undermine the critical responsibilities of people in the system. In your example, a continuously alarming data logger seem to me like a challenge that could be solved [primarily] with people and process, rather than technology.
Please send me a message if you'd like to discuss any of these topics.
- Page :
- 1