New Table Proposal: Public Health Actions Table

While we’re in the business of adding new tables for the next release, we decided there may be one more table that would be worth potentially adding. This table’s development partially came from trying the address the mapping or capture of variant threat designations, as discussed in this topic: Additional fields? Or how best to capture diverse European data

The problematic is that information on threat designation is a challenging piece of metadata, structurally, because of how the ODM is organized; it is metadata about a measurement, or a part. It is time-bound and carrying, like a measure, but it’s not really a measure as we’ve built them, since it describes actions or labels assigned/taken by organizations around the surveillance activity that we are actually describing. The idea for adding this table feels more future-focused.

The table will be used to record information on public health actions or activities, serving as a kind of public health action registry. I think it will need to pull in foreign keys for:

  • organizationID: the organization doing the action (ie. ECDC, WHO, etc)
  • measureRepID & measureSetRepID: linking a measure of a virus to the public health action. CONVERSELY, it may be better to reference a kind of “action ID” in the measures or measureSets tables, as it might be more parsimonious.

Other use cases for this table might be in declaring outbreaks, or public health surveillance changes. Currently an outbreak can be reported as a measure, but that would be deprecated and moved here.

Below is an image of the suggested structure:

A summary of the proposed headers:

  • actionID: a provisional unique identifier for each for of the public health actions table.
  • measureRepID: a link to the measures table (maybe to removed)
  • measureSetRepID: a link to the measureSets table (maybe to removed)
  • organizationID: a link to the organizations table to link responsible organizations.
  • phAction: a categorical variable describing the nature of the action (see below and in image for examples)
  • value: a categorical value, dependant on the phAction value, describing the details of the action (see below and in image for examples)
  • actionDT: the date and time that the action was taken.
  • summary: a free text summary of the action (optional).
  • lastEdited: when the row/entry was last edited.
  • notes: any additional free text notes.

In the image you can see the central "public health actions table (phActions), receiving it’s foreign keys from the measures, measureSets, organizations, and partstables - though my mind may have changed now, and I thinkactionIDshould instead be referenced inmeasuresand/ormeasureSets`.

You can also see a table listing mine (and ChatGPT’s) suggested possible values for the phAction field. Those marked in red are ones which I think we may not actually need, but I included them for discussion.

For each phAction value, there is also a table with a list of suggested values for each action. Those with red headers are linked to the red actions which I think may be unnecessary.

I think value as a field works well here, but I may be being inconsistent with my attitude toward the calcType and standard field in the calculations table. But this does feel closer to a measure potentially here? But If we want to hold me accountable to more consistency, I’m happy to come up with a different name than “value”.

@jeandavidt and @dmanuel - looking forward to your thoughts and we’ll chat soon! If others have any thoughts or input, please let me know as well.

1 Like

I am supportive of incorporating public health actions into PHES-ODM.

The outlined approach looks good. There are a few areas that benefit from more discussion:

Integration with other public health action information approaches. I propose that we support linking to other information systems that may contain more details about public health action, in the same way we link to genomic information.

How much should public health actions be first-class data? The proposed solution is a strong approach. I suggest adding a new attribute to the measures table, a public health action flag akin to the data quality flag.

We need to be mindful of implementing and supporting this addition. PHES-ODM receives feedback that it is complex, and this addition will make PHES-ODM more complex.

Additional suggestions and notes:

  1. Leverage international standards: Use ICHI, SNOMED CT, and LOINC codes to represent public health actions consistently across systems.

    • Include key action values with mappings: Maintain a short, curated list of core actions, each mapped to relevant codes from ICHI, SNOMED CT, or other frameworks while allowing additional mappings as needed.
  2. Use a link-out model for details: As with genomic sequences, geographic polygons, and derived measures, store only minimal metadata in PHES-ODM and reference external documents or databases for comprehensive information. Public health actions potentially have more information than we will want to store, and we don’t want to duplicate what is recorded in other systems.

    • Additional information includes start and stop dates of actions, ICHI’s Target-Action-Means structure, etc.
    • If a municipality issues a boil-water advisory after detecting high viral RNA in wastewater, the advisory date and a reference link could be recorded in PHES-ODM, while the full text or legal notice remains in an external system.**
  3. Coordinate with stakeholders: Work with public health agencies, standards bodies, and users to align PHES-ODM’s public health action representations with evolving global norms. Environmental surveillance has properties that are different from other surveillance approaches. When they arise, we need to feedback public health action that is not addressed in other systems.

Background on existing classification systems for public health actions

International Classification of Health Interventions (ICHI)

ICHI aims to standardise the reporting of health interventions. ICHI was finalized in 2023, with improved consideration of population-level public health measures. I have not reviewed the final version in detail. It uses a flexible three-axis model—Target, Action, and Means—to capture the breadth of interventions ranging from surgery to environmental sanitation campaigns. ICHI is the international standard in this space, and it was designed for integration with ICD (diseases) and ICF (functioning/disability). That said, ICHI has not experienced widespread adoption (to my knowledge).

SNOMED CT and LOINC

These comprehensive clinical terminology systems that considerable expanded their public health support during Covid-19. They are incorporated in to public health surveillance systems worldwide.

SNOMED CT

SNOMED CT is a clinical terminology that includes millions of concepts for health conditions, procedures, and findings, increasingly used in public health surveillance for notifiable diseases and outbreak management. It is hierarchical, allowing detailed coding while maintaining the ability to roll up to more general categories. For new or evolving concepts, SNOMED International supports additions, which is helpful if we encounter public health actions not yet fully represented.

LOINC

LOINC standardises identifiers for measurements, observations, and documents, widely used in lab test coding and public health data exchange (e.g., case reporting). It includes codes for outbreak indicators and public health investigation fields, facilitating consistent data exchange across labs and health departments. Its coverage of surveillance-related panels can be extended to environmental measures by leveraging existing structures and linking to additional metadata.

Additional public health reporting systems

NORS and SORMAS

NORS and SORMAS illustrate how outbreak reporting systems capture public health actions, though often in unstructured or minimally coded ways. NORS (CDC’s National Outbreak Reporting System) records interventions like restaurant closures or boil-water advisories in outbreak investigations, while SORMAS (Surveillance Outbreak Response Management and Analysis System) integrates surveillance data with real-time outbreak response workflows. In both, interventions are critical data points, but formal coding systems are not consistently applied.

PHIN (Public Health Information Network)

PHIN provides standards and services for reporting notifiable conditions and other key health indicators in the US, sometimes referencing codes from SNOMED CT and LOINC for consistent messaging. However, it mainly focuses on case surveillance; capturing broader public health actions remains somewhat ad hoc.

PHEIC (Public Health Emergency of International Concern)

Declarations under the WHO’s International Health Regulations highlight international-scale interventions and coordination. While these are pivotal public health actions (e.g., travel advisories, global coordination efforts), they are often tracked in situational reports or event information systems, rather than in a standardized data format.

ETMS (Event and Threat Management System)

ETMS is under development by the ECDC to better track and communicate about emerging threats and the responses they trigger. While it has the potential to unify threat-level data across Europe, the integration of a structured classification for interventions remains an area of ongoing development.

@dmanuel and @jeandavidt had a good chat about this last week where we got into the weeds a little more on the topic.

First, to address some of the point made by Doug above:

→ For these items it was discussed that it might be useful to link the phActions table to the accessions table. The data for actions is rich and complicated, much like sequencing data, and is beyond scope. Linking out like this is via accessions would leverage some of the infrastructure we’ve added for the new version as well, taking accessions beyond its exclusive use for sequencing.

→ This can also be integrated into the accessions table and dictionary.

It is worth noting, though, that a cursory overview of these possible linkages and standards shows that they’re not terribly well designed for public health interventions specifically, and where public health activities have been added, they are broadly used and lack specificity.

→ This is typical ODM standard practice, so we will keep on with that. This addition would be an optional table, so that it wouldn’t need to complicate the “base model” of ODM.

Items that came up in discussion:

  • action groups: There may be multiple actions undertaken at the same time, so how do we link these actions together? It was suggested that adding an actionGrpID field might work, as an umbrella to capture related actions, with the actionGrpID getting its own blank row.
  • linkages and keys: In my initial suggestion, I said that measures would link into the phActions table. I have since shifted and think that actionIDs should link into the measures or measureSets tables. This would be done with the understanding that the linkages are not causal, but simply related. There may also be actions which are not referenced by outside tables.
  • Accessions table linkage: discussed above, but would allow the row(s) of the phActions table to act as a summary, with the linkage out to NORS or PHIN for example for more detailed information.
  • Structure of variant designation: We have something to say what the action type and the actual action are, but we aren’t linking it to specific part IDs. This might need to be revisited.

With all this in mind, I’m re-jigging the draft and will post an updated structure in my next reply on this thread.

Okay - below is an image of the rejigged/updated draft structure for the table:

The main updates to the suggested structure are:

  • actionID now links out to measures and accessions (previously measureRepID or measureSetRepID linked into the table and there was no accessions linkage)
  • Added a relevance start date and relevance end date (relavDTStart & relevDTEnd) to manage timelines on actions (not previously included in the table)
  • Removed the additional red phAction categories and category sets.
  • Added a target field to the phActions table. This will pull from the parts table, using parts of either partType = measurements or partType = groups. This will reduce ambiguity around what variant/AMR strain is having a designation put on it and by whom. This will be an optional field. The addition of target also borrows from the ICHI structure of “target, action, means”. I contemplated adding a corresponding “means” field, but that seemed to get into protocols territory and felt out of scope. This will be an optional field.

I’ll look to set up another meeting for next week, but in the meantime, @dmanuel and @jeandavidt please feel free to weigh in!

The proposal looks good, but there are a few specifics that still need more discussion. After further reflection, I want to restate a few higher-level suggestions. These points are largely addressed already, but I’m noting them here for clarity:

Avoid implying direct causality between actions and measures, while still maintaining linkage and association capabilities. A public health action may be triggered by information outside PHES-ODM (e.g., clinical surveillance or burden estimates). Nonetheless, we should provide a mechanism to link an action to a relevant pathogen or risk factor.

Recognize linkages and hierarchies in public health actions. Multiple interventions can be nested within an overarching strategy. Initial table specifications should be clear and straightforward yet designed to expand in the future if needed. A graph database structure might be most appropriate for this relationship complexity, similar to what we’ve implemented in protocols and samples. We already have several model structures within ODM (measures, samples, protocols, and sets) that can support future expansion.

Acknowledge that recording public health actions is complex and evolving. Despite efforts like ICHI, there is no single, well-established standard in this domain. We need to balance a pragmatic approach that addresses current practices (such as declaring variants of concern or defining levels of public health concern) with the flexibility to accommodate the nuances of more complex interventions.

I’ll provide more specific details about implementation recommendations in a follow-up post, and we can discuss these points further at our upcoming meetings.

phAction is my most challenging field to feel confident about, as there is a range of existing approaches and standards (ICHI, LOINC, etc.). For PHES-ODM, I propose we define “action” as “a discrete public health response or intervention undertaken in reaction to surveillance data or risk assessment.” I’m partial to using “action” as the term since it aligns with ICHI terminology.

I agree with the approach to have ‘phActionSets’. From a data modeling perspective, can we structure ‘phActions’ as reusable entities that can belong to multiple sets? Technically, this would mean making phActions a ‘partType’ entity and phActionSet a ‘partType: attributes’ that references these actions.

For initial implementation, I suggest we generate phActionSets from existing frameworks from WHO, CDC, EU, and PHAC. Priority should be given to sets related to what you’ve identified, as these are most commonly needed in wastewater surveillance contexts.

In subsequent iterations, we should incorporate mappings to the Public Health Intervention Wheel (which has demonstrated global applicability over 20+ years) and the Behaviour Change Wheel. I’ve searched for existing ontologies we could adopt but found none that fully meet our needs - has anyone else identified potential candidates?

If we approach this thoughtfully, we should find that many phActions are reused across different phActionSets, which would validate our approach and simplify implementation. Over time, this reuse may help harmonize terms across jurisdictions while allowing flexible local adaptations.

I think we need two links out. For the reusable phActions and phActionSets, we’ll want to a link out to references for those. For the phActionID entry, we’ll want to allow a link out to details, or where the source action is stored.