Director of Client Success, Evidentli
The management of terminologies represents one of the most critical yet complex challenges in healthcare data interoperability. In our 2024 JMIR editorial "Converge or Collide? Making Sense of a Plethora of Open Data Standards in Health Care," my colleagues and I proposed a framework where three major standards (openEHR for clinical persistence, HL7 FHIR for real-time exchange, and OMOP for longitudinal analytics) could work synergistically rather than competitively [1]. Central to realizing this vision is the question of how these standards handle terminologies, as each has evolved distinct approaches optimized for their primary use cases. As healthcare systems increasingly rely on multiple data standards to support different operational needs—from clinical care to research analytics—understanding these terminology management philosophies becomes paramount. Through my participation in HL7 Vulcan's FHIR to OMOP working group, contributions to the National COVID Cohort Collaborative (N3C) data enclave, and technical analyses conducted during my tenure at Johns Hopkins, UC Davis and Duke Universities, I've observed both a shared vision for open terminology services and fundamentally divergent philosophical approaches that must be reconciled for our convergence framework to succeed.
During our recent webinar revisiting the themes in our "Converge or Collide?" I articulated a vision created by one of our co-panelists, Grahame Grieve, which I consider the most transformative potential advancement in healthcare interoperability: the establishment of open APIs for terminologies. As emphasized during that discussion, terminologies represent "a common thread in all the standards" across healthcare data exchange. The vision is compelling in its simplicity—now that healthcare data is "almost universally electronic," the terminologies used in standards and electronic exchange environments "should be offered up and be available via open endpoints."
Grahame's vision of an API ecosystem builds on progress I've observed across more than two decades of work in this space—from multi-site research networks like PCORNet's pSCANNER, the Uniformed Services University Surgical Critical Care Initiative (SC2i), the NCATS Trial Innovation Network (TIN), and N3C, to standards governance roles including leadership in the HL7 Terminology Authority, co-chair of the HL7 Terminology Services Management Group, lead of the OHDSI OMOP + FHIR Working Group, and lead author of the HL7 Vulcan FHIR to OMOP Implementation Guide. These experiences have reinforced my conviction that open terminology infrastructure is not merely desirable but essential.
Certain terminology systems developers have already demonstrated the feasibility of this approach. The publishers of LOINC, SNOMED and RxNorm have established their prescience by providing open access to their FHIR terminology services, showing that major terminology providers can successfully offer their content through accessible, open APIs. The benefits of such an approach, as I outlined in the webinar panel discussion, would be substantial: semantic alignment would become "more fluid," data exchange would be significantly eased, and the field would advance "a great deal."
My call to action for the standards community is clear—terminology publishers should "think about publication or dissemination of the standards universally" and provide their terminologies via "APIs, as open endpoints" as Grahame and like-minded folk suggest. This would represent a fundamental shift from the current fragmented landscape where each standard and implementation must manage its own terminology infrastructure, often with significant duplication of effort and inconsistent results. I believe this is not just a nice-to-have feature but a critical infrastructure component that would be "hugely transformational" in the short term.
While the vision of unified terminology services resonates across communities, the technical reality I've encountered reveals that each of the three open healthcare standards has evolved a fundamentally different approach to managing external terminologies, each optimized for its primary use case [1]. These differences are not merely technical choices but reflect deeper philosophical commitments about how clinical meaning should be represented and managed.
OpenEHR employs what can be characterized as a reductionist approach, constraining external terminologies to fit within archetype models to ensure clinical concepts remain computationally tractable within its two-level modeling paradigm [2][3]. The Archetype Object Model specification explicitly states that "constraints on external resources such as terminologies are expressed in the constraint binding part of the archetype ontology," demonstrating how openEHR systematically reduces external terminologies to fit within predefined archetype structures.
This approach uses Archetype Constraint (AC) codes where "an internal code is defined, in this case an 'ac' code, and this is bound to queries to one or more external terminologies, whose result would be a (possibly structured) value set from that terminology." This architecture fundamentally constrains external terminologies rather than extending them. The strategy prioritizes semantic consistency over terminological diversity, making it ideal for longitudinal clinical records where meaning must remain stable across decades.
Kohler and colleagues demonstrated in their work on the OMOCL transformation language that when openEHR's richly expressive data structures are transformed into the OMOP Common Data Model, there is an inevitable loss of semantic precision [4]. This finding confirms the above: openEHR's sophisticated semantic constraints and two-level modeling approach create a level of clinical expressiveness that cannot be fully preserved when data is transformed to formats designed for different purposes. This is an intentional reflection of openEHR's optimization for clinical documentation and longitudinal patient records rather than population-level analytics.
In contrast, FHIR adopts an extensionist philosophy, augmenting external terminologies through profiles and extensions when existing codes prove insufficient [5][6]. This reflects FHIR's origins in rapid healthcare innovation where new use cases constantly emerge. The FHIR Extensibility Specification makes this philosophy explicit: "extensibility is a fundamental part of the design of this specification. Every element in a resource can have extension child elements to represent additional information that is not part of the basic definition of the resource."
FHIR's "no stigma" extension policy further demonstrates this commitment: "there can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions." This represents a philosophical commitment to extending rather than constraining external terminologies. When consensus exists about coded values but it's "impossible to create a bounded list of codes that are known to cover all use cases, including ones that are yet to arise," FHIR allows alternate concepts with any level of specificity to be used.
While this flexibility enables FHIR to accommodate novel data exchange scenarios, it can complicate semantic interoperability when extensions proliferate without coordination. Recent research validates this observation: a comprehensive analysis of nearly 3,000 FHIR profiles from 125 implementation guides found that these guides contained 3,306 distinct extensions—more than one per profile on average—with growing concern that this "profiliferation" (profile proliferation) will result in non-interoperability between different FHIR implementations [7].
Importantly, FHIR implements a rigorous technical framework for referencing external code systems that ensures consistency across published FHIR standards. The specification requires explicit versioning of terminology systems, with CodeSystem and ValueSet resources maintaining version-specific references to external terminologies. This framework mandates that terminology bindings specify not only the code system but also the specific version being referenced, ensuring reproducibility and consistency across implementations. FHIR's terminology service specification provides standardized operations that work uniformly across all external terminology systems, creating a consistent interface regardless of the underlying terminology's native structure or distribution format. This combination of flexibility through extensions and rigor in terminology management, coupled with its mature REST-based architecture and widespread adoption, makes FHIR hands-down the most suitable standard for implementing the distributed terminology services API ecosystem infrastructure.
While specifying adoption of OMOP for SC2i, building the data ingestion pipeline for N3C and leading development of the Vulcan FHIR to OMOP Implementation Guide, I've come to appreciate yet another approach—a normalization strategy that maps all external terminologies to its standardized vocabulary, creating a unified semantic layer optimized for population-level analytics [8][9]. The Book of OHDSI explicitly describes this philosophy, designating "one concept representing the meaning of each clinical event as the Standard" while mapping all other representations. For example, "MESH code D001281, SNOMED code 49436004, ICD9CM code 427.31 and Read code G573000 all define 'Atrial fibrillation'... but only the SNOMED concept is Standard."
This vocabulary harmonization process demonstrates systematic normalization, with the OHDSI vocabularies allowing "organization and standardization of medical terms to be used across the various clinical domains... [enabling] standardized analytics that leverage the knowledge base." All external terminologies are transformed into a unified vocabulary system rather than being preserved in their original forms. This approach sacrifices some clinical nuance for analytical comparability, enabling researchers to conduct studies across disparate data sources without reconciling multiple coding systems [8].
We recognize that data persistence, transactional data exchange, and integrated data utilization represent fundamentally distinct meta-interoperability processes, each demanding tailored solutions [1]. Simple data transfer focuses on moving information between systems with minimal transformation, prioritizing fidelity over immediate utility. Transactional data exchange requires real-time, bidirectional communication with guaranteed state consistency, demanding lightweight schemas and rapid validation [10]. Integrated data utilization involves harmonizing heterogeneous sources into analysis-ready datasets, necessitating semantic normalization and temporal alignment [11]. These meta-interoperability patterns impose different requirements not only on the underlying data standards but also on the level and location of semantic resolution—whether encoded in terminology models, information models, or hybrid approaches [12].
Given these divergent approaches to terminology management—reduction, extension, and normalization, the path forward requires not a single unified terminology server, but rather an ecosystem of validated APIs capable of hosting terminological artifacts native to all three open standards. This ecosystem must support the distinct operational requirements of each standard: providing constrained value sets for openEHR archetypes, enabling dynamic code system expansion for FHIR extensions, and maintaining comprehensive mapping tables for OMOP's vocabulary normalization.
Beyond merely hosting terminologies, this distributed infrastructure must function as an active translation layer, with APIs capable of resolving semantic equivalences across the different philosophical approaches while preserving the integrity of each standard's methodology. The ecosystem as envisioned would need to maintain authoritative versions of external terminologies (SNOMED CT, LOINC, ICD, RxNorm) while simultaneously supporting standard-specific transformations through specialized APIs: openEHR's terminology binding queries that return filtered subsets, FHIR's $validate-code and $expand operations that accommodate extensible bindings, and OMOP's concept relationship mappings that enable systematic normalization.
The convergence of vision and technical reality around terminology management represents both a significant challenge and an unprecedented opportunity for healthcare interoperability. The community consensus I've witnessed, particularly in our webinar discussions [13], clearly points toward open, accessible terminology services as a transformative advancement that would make semantic alignment more fluid and significantly ease data exchange. At the same time, it stands to reason that each standard's approach to terminology management—whether reductionist, extensionist, or normalization-based—reflects legitimate and necessary perspectives on how clinical meaning should be represented for different purposes. The solution lies not in forcing convergence to a single approach, but in building infrastructure that respects and bridges these philosophical differences. By coordinating terminology management across validated API endpoints while respecting each standard's
distinct requirements, such an ecosystem would enable organizations to leverage the complementary strengths of all three standards without duplicating terminology maintenance efforts or creating semantic inconsistencies across their data infrastructure. This represents the practical realization of the vision I've articulated—where investment in open APIs for terminologies becomes the foundation for true semantic interoperability across the healthcare ecosystem.
As the standards communities continue to mature and recognize, as my colleague Rachel Dunscombe noted in our webinar [13], that they must "look out to the bigger landscape and interact with other people's standards," the management of terminologies emerges as perhaps the most critical shared infrastructure component. The technical groundwork exists, the community will be present, and the benefits are clear. What remains is the coordinated effort to build and deploy these open terminology services that can bridge the philosophical divides while maintaining the integrity and purpose of each standard's approach. This is the work I'm committed to advancing through my role at Evidentli and leadership in the Vulcan FHIR to OMOP project, and I invite the community to join me in making this vision a reality.
[1] Tsafnat G, Dunscombe R, Gabriel D, Grieve G, Reich C. Converge or collide? Making sense of a plethora of open data standards in health care. J Med Internet Res. 2024;26: e55779. doi:10.2196/55779. Available: https://www.jmir.org/2024/1/e55779/
[2] Archetype Object Model 1.4 (AOM1.4). [cited 4 Sep 2025]. Available: https://specifications.openehr.org/releases/AM/latest/AOM1.4.html
[3] 12 Terminology in openEHR. [cited 4 Sep 2025]. Available: https://specifications.openehr.org/releases/1.0.1/html/architecture/overview/Output/terminology.html
[4] Kohler S, et al. Eos and OMOCL: Towards a seamless integration of openEHR records into the OMOP Common Data Model. Journal of Biomedical Informatics. 2023;144:104437. doi:10.1016/j.jbi.2023.104437
[5] Terminologies - FHIR v5.0.0. [cited 4 Sep 2025]. Available: http://hl7.org/fhir/terminologies.html
[6] Extensibility - FHIR v5.0.0. [cited 4 Sep 2025]. Available: https://www.hl7.org/fhir/extensibility.html
[7] Reducing FHIR "Profiliferation": A Data-Driven Approach. PMC. 2023. Available: https://pmc.ncbi.nlm.nih.gov/articles/PMC10148270/
[8] Observational Health Data Sciences, Informatics. Chapter 5 Standardized Vocabularies. 11 Jan 2021 [cited 4 Sep 2025]. Available: https://ohdsi.github.io/TheBookOfOhdsi/StandardizedVocabularies.html
[9] OMOP Common Data Model. [cited 4 Sep 2025]. Available: https://ohdsi.github.io/CommonDataModel/
[10] Kapitan D, Heddema F, Dekker A, Sieswerda M, Verhoeff B-J, Berg M. Data interoperability in context: The importance of open-source implementations when choosing open standards. J Med Internet Res. 2025;27: e66616. doi:10.2196/66616
[11] Essaid S, Andre J, Brooks IM, Hohman KH, Hull M, Jackson SL, et al. MENDS-on-FHIR: leveraging the OMOP common data model and FHIR standards for national chronic disease surveillance. JAMIA Open. 2024;7. doi:10.1093/jamiaopen/ooae045
[12] Introduction - FHIR to OMOP FHIR IG v1.0.0-ballot. [cited 24 Aug 2025]. Available: https://build.fhir.org/ig/HL7/fhir-omop-ig
[13] Converge or Collide Panel Webinar. Health Futures Collective Series. 2025. Available: https://drive.google.com/file/d/19xMRTbvqsH7A25O9e2DfVuFjdUay1pVk/view