Public Health Data Can Talk to Each Other. But Do They Understand Each Other?

Public health has a data problem that is easy to describe and surprisingly difficult to solve.

Hospitals collect data. Laboratories collect data. State and local health departments collect data. Environmental sensors collect data. Emergency medical systems, wearable devices, wastewater monitoring programs, pharmacies, schools, and community organizations all generate information that could potentially help us understand population health.

But collecting data is not the same thing as being able to use it together.

That distinction sits at the heart of interoperability: the ability of different systems, devices, and applications to exchange data and use what they receive effectively. Recent work on Internet of Things (IoT) systems describes interoperability as the capacity for different technologies to collaborate, exchange data, and interpret that data despite differences in manufacturers, technologies, or protocols.

For public health professionals, however, one distinction within interoperability matters most: Syntactic interoperability determines whether systems can exchange data. Semantic interoperability determines whether they understand the data in the same way.

That may sound like a technical distinction. It is actually a public health issue.

What Is Interoperability?

Imagine two people trying to communicate. The first problem is establishing a connection. Can they hear one another? The second is agreeing on a communication structure. Are they speaking in a form the other person can process? The third is understanding what the words actually mean.

Information systems face essentially the same problems.

A recent framework developed by Azad and colleagues divides interoperability into four levels: network, syntactic, semantic, and organizational interoperability. Network interoperability concerns the technologies that connect devices. Syntactic interoperability concerns the formats used to communicate data. Semantic interoperability concerns the meaning of the information being transmitted. Organizational interoperability goes another level higher, addressing differences among platforms, domains, and organizations.

Those layers build on one another in a nested structure. Two systems cannot exchange information if they cannot connect. But establishing a connection does not guarantee that they can process each other’s data. And successfully processing a message does not guarantee that both systems interpret that message the same way.

That is where the distinction between syntactic and semantic interoperability becomes critical.

Syntactic Interoperability: Can the Systems Read the Same Data?

Syntactic interoperability is primarily about structure. Different information systems may organize the same information differently. One might call a field “PatientID,” another “patient_identifier,” and another simply “ID.” Dates might be represented as 09/16/2026, 2026-09-16, or 16-09-2026. One system may transmit XML while another expects JSON. Or dates might be encoded as characters, or numbers, or dates.

Humans can often recognize these differences immediately. Computers cannot unless rules tell them how to translate between the structures.

The problem predates modern public health informatics. Kim Veltman’s earlier work on syntactic and semantic interoperability describes interoperability as partly a problem of mapping equivalent fields between systems. One system might use “Author,” another “Name,” and another “Creator.” Similarly, one database might use “Subject” where another uses “Topic.”

Syntactic interoperability therefore requires identifying the elements used by different systems, establishing rules for structuring them, and creating mappings or “crosswalks” between equivalent elements and schemas. In public health, imagine two disease-surveillance systems. One sends:

disease = influenza
date = 2026-09-15
location = Berks County

Another expects:

condition
report_date
jurisdiction

The underlying information might be perfectly compatible. But unless the systems know that disease corresponds to condition, date corresponds to report_date, and location corresponds to jurisdiction, automated exchange can fail.

Syntactic interoperability solves that structural problem. But solving it doesn’t necessarily solve the harder problem.

Semantic Interoperability: Do the Systems Mean the Same Thing?

Suppose two public health databases can now exchange information perfectly. Both have a field called case_status.

Excellent. Except one system defines “confirmed case” using a positive laboratory test, while another includes people meeting a clinical case definition without laboratory confirmation.

The data have moved successfully. The structure matches. And the resulting dataset may still be wrong.

This is the problem of semantic interoperability. Veltman defines semantic interoperability as the ability of information systems to exchange information based on shared, pre-established, and negotiated meanings of terms and expressions.

The simplest way to remember the difference is:

Semantic failure can be especially dangerous because it is less visible. When a file fails to load, somebody notices.

When a file loads perfectly but one system interprets a variable differently from another, the resulting dataset can look completely normal.

Why Semantic Interoperability Is So Important for Public Health

Public health routinely combines information collected for different purposes by different institutions. That creates enormous potential for semantic mismatch.

Consider something as apparently straightforward as a “COVID-19 hospitalization,” “opioid overdose,” “maternal death,” “vaccinated person,” “rural resident,” or “uninsured patient.”

Each sounds like a single variable. Each actually depends on definitions. What time period counts? Which diagnosis codes qualify? Does an incidental positive laboratory test count? How are repeat events handled? What geographic classification defines rurality? Does “vaccinated” mean one dose, completion of a primary series, or being up to date according to recommendations at that time? Two databases can include a column with the same name but represent different underlying populations.

Conversely, two systems can use completely different terms for essentially the same concept. That means public health interoperability cannot end with successfully moving information from Database A to Database B.

We need to know what the information means when it arrives.

A Useful Example: The Ambulance

Imagine an ambulance containing a heart-rate monitor, oxygen sensor, and blood-pressure monitor. Those devices need to communicate with an onboard system in real time.

Syntactic interoperability allows those devices to transmit information in compatible formats.

Semantic interoperability allows the receiving system to correctly understand what those measurements represent, for example, recognizing a dangerous decline in oxygen levels and triggering the appropriate alert.

Now scale that idea from one ambulance to an entire public health system. A laboratory reports a result to a hospital. A hospital reports information to a local health department. The local health department transmits surveillance data to the state. The state aggregates information across jurisdictions. National systems combine information across states. Researchers eventually analyze those datasets to identify trends and disparities.

At every step, the information must move. But at every step, its meaning must survive the move. That is the difference between merely connecting public health systems and creating a genuinely interoperable public health information ecosystem.

The Problem Gets Harder as Public Health Data Become More Diverse

The distinction becomes even more important as public health moves beyond traditional clinical records.

Modern surveillance increasingly can incorporate environmental sensors, wastewater measurements, wearable technologies, connected medical devices, geospatial information, laboratory systems, and other IoT data. Readers of the blog know how much I LOVE qualitative data scraped from all different sources

Azad and colleagues note that IoT environments frequently involve devices from multiple manufacturers using different network technologies, protocols, message formats, and terminology. That produces several distinct interoperability challenges.

A sensor may need to connect to a network. Its data must be transmitted in a structure another system can process. The receiving system must know what the measurement means. And eventually that information may need to move between organizations operating under different technical and institutional environments.

These aren’t interchangeable problems. A system can succeed at one level while failing at another.

Interoperability Is Also About Where Computing Happens

The newer research adds another dimension that is particularly interesting for public health: edge computing. Many modern information systems depend heavily on cloud infrastructure. Data are transmitted somewhere else, processed on remote servers, and then returned.

That architecture can work extremely well when connectivity is reliable.

Public health does not always operate under those conditions, as any practitioner well knows. Disasters, rural environments, emergency responses, field investigations, infrastructure failures, and environmental monitoring can all occur where internet connectivity is limited or unstable. Azad and colleagues specifically identify mission-critical applications, environmental monitoring, and water-quality monitoring as situations in which reliance on cloud connectivity can become problematic.

Edge computing moves some of that processing closer to where the data are generated. Instead of every decision requiring a round trip to a distant cloud service, devices can communicate and process information locally. The researchers’ InterEdge approach was designed to keep communication within an edge network and, under wired configurations, potentially function without an internet connection. Its model explicitly separates network, syntactic, semantic, and organizational interoperability.

For public health, the concept raises an important design principle: Interoperability should not necessarily disappear when connectivity does.

Why Speed and Resource Requirements Matter

Interoperability standards can also carry computational costs. A theoretically elegant standard is less useful if the devices that need it cannot run it (I demoed an advanced version of PubTrawlr this morning that does a LOT, but has high latency of like 60 seconds)

The InterEdge researchers compared their implementation with three existing open-standard approaches: OGC Sensor Observation Service, OGC SensorThings API, and EdgeX Foundry. Their experiments found lower code size, lower memory requirements, and lower response latency for their implementation on the tested hardware.

This matters because very small devices have severe computational constraints. The researchers note that the alternative solutions they tested required more capable hardware for their experimental implementation, whereas InterEdge was designed to support highly resource-constrained Class-0 devices.

The authors report that common read, write, and controller-to-controller operations in their implementation took 10 milliseconds or less, while device memory requirements were measured in hundreds of bytes.

Those are engineering results, not direct evidence of improved population-health outcomes. But they illustrate a broader lesson for public health informatics:

Interoperability has to work under real-world constraints. The best data architecture on paper is not necessarily the best architecture during a hurricane, inside an ambulance, beside a river monitoring station, or in a rural community with intermittent broadband.

Public Health Needs More Than a Universal Dictionary

Semantic interoperability creates another challenge. It might seem that the solution is simply to establish one universal definition for everything. For some information, that is exactly what we want.

Veltman uses medicine as an example: anatomical terminology must mean essentially the same thing whether a physician is practicing in Berlin, Rio de Janeiro, Shanghai, Sydney, or Los Angeles.

Public health needs this kind of standardization too. A laboratory value cannot silently change meaning when it crosses a state line. But public health also deals extensively with concepts whose meaning depends on social, geographic, institutional, and historical context.

Veltman’s framework therefore makes a subtler argument: meanings may be negotiated at international, national, regional, or local levels, and interoperable knowledge systems need ways to recognize those different layers rather than simply erase them.

That idea has important implications for public health.

• Consider “community.”
• Or “food insecurity.”
• Or “homelessness.”
• Or “access to care.”
• Or even “neighborhood.”

Standard definitions can make comparison possible. But forcing every local concept into a single universal category can also strip away information that matters. The goal of semantic interoperability therefore isn’t simply to make everybody use identical words.

It is to make the relationships among meanings explicit enough that systems and the people using them know what is actually being compared.

The Hidden Danger: Data That Look More Comparable Than They Are

This may be one of the most consequential interoperability problems for public health analytics. Suppose we successfully aggregate data from 50 jurisdictions.

Every record arrives. Every variable maps neatly into the master database. The dashboard works. The visualization looks beautiful.

But several jurisdictions operationalized key variables differently. We have achieved syntactic interoperability without full semantic interoperability. The resulting national estimate may therefore create a false sense of comparability. And once those data enter automated pipelines, dashboards, predictive models, or AI systems, the problem can propagate at enormous scale.

More computing power does not fix ambiguous meaning. Neither does artificial intelligence (the garbage in / garbage out principle).

If anything, increasingly automated public health systems make semantic interoperability more important because fewer humans may inspect each transformation along the way.

From Data Exchange to Public Health Knowledge

For decades, interoperability has often been framed as a technical infrastructure problem. Can System A send information to System B?

That is necessary but not sufficient.

A mature public health information infrastructure needs to preserve several things simultaneously:

Connection → Structure → Meaning → Context.

The Azad framework describes a similar hierarchy through network, syntactic, semantic, and organizational interoperability. This way of thinking changes the question public health leaders should ask.

Instead of: “Can our systems share data?”

We should increasingly ask: “Can our systems share data without losing what those data mean?”

That is a much higher bar, and one that primarily matters. Because public health decisions aren’t made from packets, JSON objects, APIs, or database columns.

They are made from what we believe those data tell us about people, places, exposures, diseases, risks, and communities.

Interoperability succeeds only when that meaning makes the journey too.