Most interoperability programmes I have worked with reach a particular kind of meeting. It usually happens a year or two in. Someone puts the progress report on the screen, and the report is good. Every member has adopted the standard, the deadlines were met, the audit came back clean. People in the room have earned that moment, and for a few minutes it feels as if the hard part is behind them.
A few weeks later, a project that needs two of those members to exchange real data asks for budget, and the budget is for a mapping. Both members comply with the standard. Their systems still describe the same thing in different ways, because what they need to exchange lies just outside what the standard covers. Nobody in the earlier meeting was wrong. The report measured exactly what it was asked to measure, and it had no way to see where the remaining work was piling up.
I have come to think this meeting tells us something uncomfortable about one of the most trusted tools in our field. A mandate is very good at producing adoption. Semantic interoperability asks for something else, and a mandate, on its own, has no way to deliver it.
The cobra bounty
There is an old story that explains the mechanism better than any diagram. Under British rule, the story goes, Delhi had too many cobras, so the government paid a bounty for every dead one. The numbers handed in rose, and the policy looked like a success. Then it turned out that people had started breeding cobras to collect the money. When the bounty was cancelled, the breeders released their snakes, and the city ended up with more cobras than before.
Everybody in that story behaved reasonably. The government wanted fewer cobras and chose something it could count; the breeders responded to the reward on offer. The harm came from the distance between the count and the purpose. Goodhart’s law, in the phrasing the anthropologist Marilyn Strathern gave it, says it in one line: “When a measure becomes a target, it ceases to be a good measure.” In our research on semantic convergence we found this pattern in four of the ways our field pursues interoperability. This series looks at each of them, and it begins with the mandate.
A mandate reaches only as far as it names
A mandate works by naming something precise: this standard, these fields, this date. That precision is its strength, because it can be checked. It is also its boundary. Participants implement what is named, at a reasonable cost, and they stop there, which is exactly what a sensible organisation should do with a compliance requirement.
Meaning, though, lives mostly below that line. European medicines show it clearly. Since February 2019, under the Falsified Medicines Directive, every prescription medicine pack in the EU has carried a unique identifier in a small 2D barcode, and pharmacies verify it before they dispense the pack. It is a successful mandate, and it does what it was designed to do: it makes counterfeit packs far harder to slip into the supply chain. It was also, deliberately, scoped to the identifier. How a manufacturer or a wholesaler records storage conditions, a temperature excursion in the cold chain or the information behind a recall is left to each company. Those are precisely the things that have to travel between companies when something goes wrong. The barcode will tell everyone which packs are affected. What happened to them, and in which words, each company describes in its own way.
That is the first reason a mandate falls short of interoperability. It secures agreement on the layer it names, and the exchanges people care about usually depend on the layers underneath.
A mandate speaks to everyone, and interoperability happens between someone
Interoperability always has a referent. Two parties are interoperable with each other, for a purpose: a pension office and its counterpart abroad, a wholesaler and the manufacturer whose batch is being recalled. A mandate addresses everyone in the same voice and asks the same thing of all of them. So it can tell you how many participants have adopted the standard. It cannot tell you whether the particular parties who need to exchange data are converging on the particular things they need to exchange, and that is the only question that matters on the day the exchange has to work.
Authority is granted, authoritativeness is earned
A standard published under a mandate arrives with authority on the day it is signed. Its authoritativeness is a different quality, and it grows slowly, from the parties who build on it, map their own terms to it and run it in production. Most programme reports measure the first and quietly assume the second. Where the two coincide, the mandate has worked. Where they drift apart, the report stays green while the standard becomes a formality that everyone honours and few rely on.
The decisive moment happens after the audit
Divergence rarely happens on the day of adoption, when everyone is paying attention. It happens months later, in the hundreds of small modelling decisions that follow: a new attribute, a new code list, a concept the standard never anticipated. Each of those decisions is taken by a modeller working alone, with a deadline and an empty model, who has nothing in front of them that shows what the peers have already chosen. The modeller makes a reasonable choice. The cost of that choice surfaces years later, on somebody else’s desk, as a mapping project. A mandate has no presence at that moment. Its influence was spent at the audit.
Put these together and the picture becomes clear. A mandate produces compliance with what it names, among everyone it addresses, on the date it is checked. Semantic interoperability is made of something more continuous: many independent decisions, taken over years, gradually moving towards one another. One can support the other, and a mandate can give that movement a direction and legitimacy. On its own, it cannot make the movement happen.
Five questions to ask of your own mandate
If you run or fund a programme built around a mandated standard, these questions will show you how much of the picture your adoption figures cover. Most of them can be answered from what your participants have already published.
- With whom do we need to be interoperable, and for what? Name the parties and the exchanges that matter, and write them down.
- What sits just below the mandate? List the concepts those exchanges depend on that the standard leaves open.
- For each of those concepts, who has settled on a shared model, who maps to one, and who runs one in production?
- Where is the split? Look for concepts where participants have chosen two or three different designs, and note which one your priority partners use.
- What does a modeller see before deciding? If the honest answer is “nothing”, that is where the next divergence will come from.
Keeping the mandate, changing what we watch
Mandates keep an important place, and the medicine barcode shows how much good a well-scoped one can do. What has to change is what a programme watches once the mandate is in force. When the evidence of convergence sits next to the adoption checklist, a programme owner can see where the standard has taken root and where it has only been ticked, and a modeller can see where the peers already stand before choosing. Making that evidence visible, at the moment decisions are taken, is the problem we built EVIDENT around at METALEVELS.
Next in this series: what organisations do when a mandate leaves them misaligned, and why mapping everything to everything else turns into the second cobra.
If you would like to look at your own programme through these five questions, start a conversation with us.