Open Standards Are Not Enough: Why the Ecosystem Decides
A JMIR viewpoint reframes the FHIR-versus-OMOP-versus-openEHR debate. The technical specification matters less than the open-source community around it. The argument is sound; it is opinion, not evidence, and the authors have skin in the game.
Dr. Sven Jungmann
CEO
Counting public repositories on GitHub on 28 January 2025, the OMOP project showed 221 active in the previous three months but only 113 over its entire lifetime — more recently than ever. That apparent impossibility is a measurement artefact, and the authors of a viewpoint in the Journal of Medical Internet Research flag it themselves. It is also the tell that this paper is not really about repositories, or even about specifications. It is about the people who keep a health-data standard alive, and whether a hospital is measuring the right thing when it chooses one.
The usual way to choose is to compare the specifications: which data model is richer, which query language is faster, which covers more of the clinic. Three standards dominate the conversation, and they do not even solve the same problem. FHIR (Fast Healthcare Interoperability Resources) is built to move data between systems. OMOP (Observational Medical Outcomes Partnership, maintained by the OHDSI community) is a common data model for analysing observational data across sites. openEHR is an architecture for the longitudinal clinical record. The viewpoint argues that ranking them on cleanliness of design is the wrong exercise: what decides whether an implementation survives a decade is the living open-source community around it.
The evidence on offer, and what kind it is
Before crediting the argument, name the genre. This is a viewpoint — a structured opinion, not a study. No protocol, no comparator, no measured outcome. So its empirical core is a proxy: open-source activity on GitHub, which a software engineer trusts more than a vendor's brochure. And the proxy is lopsided. Over each project's lifetime the headcount of contributors runs to roughly 8,500 for FHIR, about 1,000 for OMOP/OHDSI, and around 430 for openEHR. Narrow the window to the preceding three months and the ranking survives intact: some 1,650 active contributors for FHIR against roughly 450 for OMOP and 80 for openEHR.
The authors are scrupulous about what this can mean. FHIR spans far more application areas, so heavier activity is partly mechanical rather than a verdict on quality. GitHub vitality measures whether a community is busy; it says nothing about whether a standard fits a particular clinical purpose. A smaller, more focused community can produce a more disciplined standard for a narrow task. So the figures answer one question well — which ecosystem is busiest — and leave the question a hospital actually has, which standard serves its data best, untouched. The piece does not pretend otherwise, which is to its credit.
Two further moves, and a tilt to notice
Around the data sit two conceptual claims. The first is that an open specification is necessary but not sufficient — software and maintainers have to grow around it, and that growth needs an external pull, usually regulation. FHIR is the only one of the three written into health regulation across several jurisdictions, which gives its ecosystem a standing reason to expand. The second borrows the "spanning layer" from internet architecture: the narrow waist of the hourglass through which everything passes. FHIR, the authors propose, can occupy that position between data capture, exchange and analysis, even though it was not designed for analytics.
It is worth saying plainly that the argument is built to land on FHIR, and that three of the six authors disclose commercial interests — in companies working on federated data, clinical algorithms and health-information exchange. The disclosures are printed in full, and a conflict of interest refutes nothing. But a conclusion convenient to its authors earns its weight only when the reasoning, not the affiliation, is what persuades. Here the reasoning mostly does the work — which is the right reason to be persuaded, and a reminder that it is still reasoning, not data.
“An open specification is necessary but not sufficient. What keeps an implementation alive for a decade is the community around it.”
What it means for a European hospital
The practical reading is concrete. FHIR already underpins the national infrastructure mandated by the gematik specifications, so for German institutions the exchange layer is in large part a settled question. More interesting is a German example the authors cite against their own framing: the KETOS platform runs a FHIR/OMOP hybrid, and a collaboration of ten German university hospitals reported roughly 99 percent conformance when transforming FHIR data into the OMOP model. If the two standards combine that cleanly, the choice is not FHIR or OMOP or openEHR. It is which to use for exchange, which for analysis, and whether the conversion between them is mature enough to depend on.
Read the paper for that, not for a winner. Its durable contribution is to put one item on the evaluation checklist that procurement habitually omits: the size and staying power of the community maintaining the standard, sitting beside the specification rather than behind it. A standard, in the end, is only as good as the software and the people who keep it running.
Source: Kapitan D, Heddema F, Dekker A, Sieswerda M, Verhoeff BJ, Berg M. Data Interoperability in Context: The Importance of Open-Source Implementations When Choosing Open Standards. J Med Internet Res 2025;27:e66616. A viewpoint — a structured argument with no primary data — in which several authors disclose commercial interests in interoperability infrastructure; read it as informed opinion, not evidence.
