Key points
- Two data sources can disagree without either being simply wrong, for example when one holds name-based line lists and the other holds facility totals.
- Relational database concepts such as keys, tables and one meaning per field are a useful way to think about this. Working in digital health means understanding some of that logic, not just the word interoperability.
In many digital health discussions, someone says it. “We have to make it interoperable.” The conversation then moves quickly towards APIs and exchange standards such as HL7 FHIR. These are important foundations. But the agreements underneath them, about what data means and who maintains it, deserve as much attention.
Interoperability is essential, but it is not a feature that can be added at the end, like a new button. It is closer to a discipline, a set of agreements about what things are called, how they are identified, what each number means and who keeps the lists up to date. When those agreements exist, connecting systems becomes easier to manage. When they are missing, technical connections can move data between systems without resolving differences in meaning, coverage or ownership.
My point in this piece is a simple one. People working in digital health, including those in programme and policy roles, benefit from understanding some of the technology underneath, especially how data is structured in a database. Without that, interoperability stays a word.
Data by hand
Anyone who downloads data from public health portals soon learns that much of the time goes into making sense of it. In many public datasets, the first challenge is making the data ready for analysis. That means interpreting headers that run over several rows, telling totals apart from individual rows, resolving different spellings of the same district and understanding how missing values are shown.
So the first job is not analysis. It is understanding. What does each field actually count? Is “registered” the first contact, or the first full check-up? Which rows are totals? Do blanks mean zero or missing? Only after that can cleaning begin.
Then came the moment that taught me the most. I had two sources that both reported pregnancies for the same district and the same months. The numbers did not match, and not by a little. For a while I assumed one of them was wrong.
One source was a line list of pregnant women registered for follow-up, one row per woman. The other held monthly facility totals. They differed in what each row represented, in how and when data was entered, and possibly in their definitions and time periods. The difference did not by itself show that either source was wrong. It showed that the two could not be compared meaningfully without first understanding how each was produced.
That is the gap that “make it interoperable” can skip over. The problem was not only that the two systems lacked a connection. It was that they did not share a definition, a unit or a moment of counting.
Three spellings, one facility. Linking starts with a shared identifier. Diagram: Hussain MS, illustrative facility.
What the sentence actually asks for
When someone asks for two health systems to be interoperable, they are usually asking for several things at once.
- Shared identifiers. The same facility needs the same code in every system. “PHC Rampur”, “Rampur PHC” and “Rampur P.H.C.” are three different strings to a computer. Without master lists of facilities, health workers and people, with stable identifiers, records do not join reliably.
- Shared definitions. If one programme counts a pregnancy as registered at first contact and another at the first full antenatal check-up, their totals will not agree, however good the connection.
- The right unit of data. Totals can be compared across sources, but on their own they cannot support linking or following an individual over time. Following a woman through pregnancy needs person-level records and a reliable way to connect them across visits and systems.
- Owners for the reference data. Facilities open, close, upgrade and change names. Without clear ownership and regular maintenance, master lists go out of date.
- Agreement between organisations. Who may see what, who pays to maintain the link, and what happens when one side changes its system.
HIMSS, the health information society, describes interoperability at four levels. These are foundational (systems can connect and exchange data), structural (the format of the data is agreed), semantic (its meaning is agreed, through shared terminologies) and organisational (the governance, policy and social considerations that make exchange work). In my experience, discussions often focus on the first two, while meaning and governance get less attention than they need. How hard each level is depends on the systems and the purpose.
The database ideas worth knowing
Many of these questions have long been worked through in how databases are designed. In 1970, Edgar F. Codd, a researcher at IBM, published a paper proposing the relational model of data. Its ideas sound obvious now, which shows how widely they were adopted. They are worth knowing for anyone who works with health data.
- Tables for things. Each kind of real thing, such as a facility, a woman or a visit, is stored in its own table, with defined columns.
- Primary keys. Every record has a key that identifies it uniquely, such as a facility ID. Names can change or be spelled differently. The key does not.
- Foreign keys and relationships. A visit record does not repeat the facility’s name. It holds the facility’s ID, which points to the facility table. That is how records link.
- One meaning per field. Each column means one thing, and the database can enforce rules about what values are allowed.
- Grain. Every table has a unit, such as one row per woman, per visit or per facility per month. Mixing different grains is exactly what made my two pregnancy sources disagree.
A small example shows how this works. Suppose a facility table holds one row per facility, with an ID such as F102, its name and its district. A visits table holds one row per antenatal visit, with the woman’s ID, the date and the facility ID F102. A monthly report can then be calculated from the visits, and it will always agree with them, because both rest on the same IDs and the same definition of a visit. If a second system also uses F102 for the same facility and the same definition of a visit, the two systems can exchange data and get the same answer.
IBM built a research prototype, System R, to test these ideas, and SQL, the language most databases use today, grew out of that research. A small company founded in 1977 by Larry Ellison, Bob Miner and Ed Oates released one of the first commercially available relational databases using SQL in 1979. The company was later renamed after its product, Oracle. Its success had many causes, but the episode shows how central these ideas became.
The analogy with interoperability is useful, with limits. Health systems also need agreed ways to identify things, interpret data and maintain reference lists. But interoperability goes beyond database design. It also involves exchange standards, consent, matching people’s identities, versions of systems changing over time, and agreements between institutions. It also does not require one central database. Separate systems can work together through agreed interfaces, as long as their meaning, identifiers and governance are aligned closely enough for the purpose.
Where standards fit
Standards such as HL7 FHIR are essential for structured exchange. A standard gives everyone a common shape for a patient, a facility or an observation, and a common way to request them.
But a standard defines the shape of the data, not its truth. A FHIR message can carry a facility record with the wrong identifier, or an indicator built on a local definition nobody else shares, just as faithfully as a correct one. Conforming to a standard is not the same as having good quality data or agreed meaning. Standards make agreement possible. People and institutions still have to reach it.
Shared registries help. India’s Ayushman Bharat Digital Mission includes a Health Facility Registry for identifying facilities, a Healthcare Professionals Registry for identifying professionals, and the Ayushman Bharat Health Account (ABHA), which ABDM describes as a way for individuals to access and share their health records digitally. These serve different purposes. They support interoperability when they are used within appropriate workflows, governance and technical standards.
The questions underneath
So the next time someone says “we have to make it interoperable”, it is worth asking what is underneath the sentence. Which identifier will both systems use for the same facility? Whose definition of the indicator will we use? What is the unit of each dataset? Are we linking records, or comparing totals? And who will maintain the master list next year?
If those questions have clear answers, the foundations for interoperability are stronger. If they do not, they need to be worked through alongside the technical implementation. That is why understanding the logic of data, and not only the vocabulary, matters for anyone working in digital health.
Views are my own.