A standard is a social artifact before it is a technical one

The most common mistake I see in standards work, and the one that ministries and agencies pay for most often, is treating a standard as a technical artefact that will succeed or fail on its technical merits.

That is not how standards work. The most consequential decisions in a standard are almost always social: who is in the room when the decision is made; who is not; whose implementation experience gets to be authoritative; whose objection is treated as a design constraint and whose is treated as an outlier.

The evidence from HL7

I have spent parts of four decades inside HL7. I chaired an affiliate, sat on the international board, watched several ballot cycles from close range. The most useful comparison in that experience is between HL7 v3 and FHIR.

HL7 v3 was technically extraordinary. It was based on a rigorous reference information model, it was type-safe, it was internally consistent, and it was, in many respects, the most carefully engineered health-data standard ever produced. It never achieved broad implementation. The people who understood it were a small priesthood, and the standard was written in their language.

FHIR was, at the time of its early ballots, technically compromised in ways that made the v3 community uncomfortable. Resources were pragmatic rather than principled. Extensibility mechanisms were casual. The information model was implicit rather than declared. And yet FHIR shipped: not in one country, not in one sector, but across the field.

The difference was not a schema decision. It was a decision about who was in the room when the resources were designed. FHIR made a deliberate choice to include implementers (working developers with production systems) in the drafting group at the same level of authority as modellers. Every resource had to satisfy an implementer that they could actually build against it before it was balloted. That was the social decision that made FHIR ship.

The three social decisions every standard makes

Every standards effort (inside HL7, inside ISO, inside the WHO SMART Guidelines process, inside every national profile group) makes three social decisions, usually implicitly:

1. Who is in the room. The composition of the working group defines what “obvious” looks like. If the working group is majority-vendor, the standard will make vendor implementation easy and payer analytics hard. If it is majority-payer, the reverse. If it is majority-clinical, the standard will drift toward clinical richness at the expense of implementer tractability. There is no neutral composition; the composition is the design.
2. Whose objection counts as a constraint. In any standards process there are more objections than the group can address. Which ones are treated as design constraints that must be resolved and which are treated as outlier concerns that will be documented and moved past is a social decision made mostly by the chair and the editor. It is rarely written down and it is almost always the most consequential decision in the cycle.
3. How the standard exits the room. A standard that leaves the working group with a strong editorial voice (a coherent narrative, a small number of examples, a set of prescribed implementation patterns) will be implementable. A standard that leaves the working group as a set of individually-defensible clauses with no editorial voice will not. This is a decision made in the last two weeks of a ballot cycle by whoever holds the pen.

The implication for programme leaders

If you are a national programme leader deciding which standards to adopt, the question is not “is this standard technically sound”. Every serious candidate standard will pass that bar. The question is:

• Who is in the room shaping this standard’s next version?
• Are they people whose implementation constraints look like mine?
• Who is not in the room, and how much will that matter?
• Whose objection has been treated as a constraint in the current version, and whose has been treated as an outlier?
• Is the editorial voice strong enough that I can actually implement it, or is this a set of clauses I will have to profile to make usable?

Those are the questions that predict whether a standard will be implementable in your programme five years from now. They are almost never the questions asked in a standards evaluation.

What to do about it

The practical implication is that a serious national programme cannot outsource its standards decisions to a technical evaluation of the standards themselves. It has to be in the room: through a delegation, through participation in the SDO, through funded staff time, where the standards are being made.

This is expensive in staff time and it is politically expensive because it means a country is accountable for the outcome. It is also the only way to end up with standards that actually fit. Every national programme I have worked with that skipped this step has, within a decade, ended up with a standards portfolio that failed on implementation and had to be redone.

The alternative is cheaper up front and much more expensive later.

---

This essay is one of a series drawn from four decades of standards leadership at HL7, ISO/TC 215, and national digital-health authorities.