FHIR, HL7, openEHR and OpenSAFELY’s ehrQL

Glossary

FHIR (Fast Healthcare Interoperability Resources) HL7’s modern standard for exchanging healthcare data over web APIs. Breaks clinical data into discrete “resources” (Patient, Observation, MedicationRequest) with a fixed but very general structure, designed so two systems that have never met can exchange a single patient’s data with a testable contract behind it.

HL7 (Health Level Seven) The international standards body behind FHIR, and the family of standards it produces, including older formats. The name refers to the application layer (layer 7) of the OSI networking model.

HL7 v2 The older, pipe-delimited messaging format still used for the bulk of hospital admissions, lab results and orders. Ugly but extremely entrenched, still underpinning the majority of US hospital messaging even where FHIR has been layered on top.

HL7 v3 / RIM (Reference Information Model) An earlier, more ambitious HL7 attempt to model all of clinical reality in one abstract schema. Largely abandoned as too complex to implement in practice, and FHIR was built partly in reaction against it.

CQL (Clinical Quality Language) HL7’s purpose-built language for writing clinical logic, such as quality measures and phenotype definitions, against FHIR data. More readable than raw FHIR queries, but still requires explicit typed constructs, for example writing out a blood pressure threshold as a quantity with value and unit, to express simple comparisons.

openEHR A separate standards body and specification, distinct from HL7, built around “two-level modelling”: a small, stable reference information model plus a separate layer of archetypes that capture clinical detail without changing the underlying schema.

Archetype An openEHR artefact that defines the detailed structure and constraints for a specific clinical concept, for example what fields a blood pressure observation has and what units are valid. Sits on top of openEHR’s reference model rather than being baked into it, which is meant to let clinical content evolve without touching the core software.

AQL (Archetype Query Language) openEHR’s query language for retrieving data structured by archetypes. Resembles SQL syntactically but requires navigating archetype paths (codes like at0001, items[at0004]) to reach any clinical value, which pushes much of the query’s length into data model navigation rather than analytic logic.

Profile / Implementation Guide A narrowed, locally agreed version of a general standard, used to make it concretely testable for a specific country or use case. Examples are US Core and UK Core, which constrain the very general base FHIR specification down to something two systems can reliably agree on.

ehrQL OpenSAFELY’s own query language, built directly on top of the specific EHR systems used in English general practice, EMIS and TPP. Designed around the unit researchers actually need, patient-level tables built from codelists and events, rather than around a general-purpose clinical information model.

OpenSAFELY The Bennett Institute’s secure analytics platform for running research directly against NHS GP record systems without extracting patient data, of which ehrQL is the dataset definition language.

Summary

The regulatory picture is clear. FHIR has effectively won as the cross-organisational exchange layer, with NHS England mandating it for new GP systems and US law requiring certified EHRs to expose FHIR APIs. A 2025 survey found that 78 per cent of countries now have rules for electronic health data exchange, and 73 per cent of those mandate or recommend FHIR [source]. None of that, however, settles whether FHIR, or its query cousins, are the right tool for population-scale research, which is the question that matters for ehrQL.

FHIR earns its complexity for a specific problem, namely letting two organisations that have never met exchange a single patient’s data over a REST API with a testable contract behind it. That generality is precisely what makes it a poor fit for research. It is a wire format for transactional exchange, one patient and one encounter at a time, not an analytic model, so using it directly for cohort-level querying means constantly reconstructing tabular, longitudinal structure out of nested resource graphs that were never designed to be queried that way.

openEHR’s two-level modelling, archetypes plus templates, is a more deliberate attempt at semantic rigour, separating “domain semantics” from “information models” so that clinical content can evolve without the underlying schema growing without bound. The architecture takes the problem seriously. But the cost shows up directly in its query language, and in its own explanation of itself. The AQL example for something as simple as “blood pressure readings above 140 systolic or 90 diastolic” is dominated by archetype path navigation, at0001, items[at0004], rather than by the clinical logic itself. CQL is more readable but carries a comparable structural burden, with explicit encounter joins and typed quantity construction needed just to express a threshold comparison. A study that converted thirty-three real-world phenotype definitions into CQL found relatively low use of arithmetic and aggregate expressions, suggesting most of the syntactic weight in these languages goes on navigating the data model rather than on the logic researchers actually care about [source].

On AQL as an alternative

AQL looks like the obvious thing to check: it is also a query language for structured clinical data, so the question is whether it already does what ehrQL does, more simply. It does not. The example query for a simple clinical threshold is dominated by archetype path syntax rather than clinical logic — the same kind of complexity you get when a language is solving a harder, more general problem. The same pattern shows up in CQL: a study of real-world phenotype definitions found that most of the complexity in these languages comes from data model navigation rather than the underlying clinical logic, exactly the pattern AQL also shows.

A separate concern is worth naming: not that the problem has already been solved elsewhere, but that ehrQL might eventually hit a ceiling on what it can express and need to grow into SQL-like complexity to get past it, at which point much of its present simplicity would be lost. This is a real engineering risk, worth tracking separately from comparisons to AQL or CQL.

openEHR’s own architectural documentation is hard to understand even with sustained attention: the explanation of why archetypes exist is dense with terms like “domain semantics,” “information models” and “infrastructure types” before any concrete example appears. On an earlier look roughly a decade ago, openEHR had accumulated considerably more design and documentation than working systems in active deployment, and that had not shifted substantially since, outside some northern European countries and isolated NHS programmes. None of this is a direct argument against openEHR’s architecture — documentation quality and architectural soundness are different things — but a specification that cannot explain its own purpose in plain language is evidence of the practical cost of adopting it.

openEHR vs ehrQL

The core difference is what each is trying to work across. openEHR is built to represent any clinical concept in any care setting, anywhere in the world, without ever needing to change its underlying schema. ehrQL starts from the opposite end: rather than modelling all of clinical reality in the abstract, it starts from two specific, well-understood source systems and builds a language around the concrete unit of analysis researchers actually need, patient-level tables built from codelists, events and measurements. It does not attempt to be a general clinical information model or a universal exchange format, and is closer in spirit to a domain-specific analytic language than to an interoperability standard.

That difference in scope explains the difference in usability. openEHR and AQL, like FHIR and CQL, are more complex because they are designed to work with any clinical concept across any system. ehrQL is not trying to do that, and the narrower scope is what lets the code read closer to the research question.

Bottom line

ehrQL solves a specific problem that AQL and CQL are not designed to address: giving researchers a direct way to query English GP records without first navigating a clinical information model built for arbitrary systems worldwide. AQL and CQL are general-purpose clinical query languages designed to sit on top of data models that can represent any clinical concept across any system. The complexity in AQL and CQL is not incidental; it is what you get when a language has to handle that. ehrQL is not trying to do that. A separate concern — that ehrQL might eventually hit a ceiling on what it can express and need to grow into SQL-like complexity — remains a real risk worth tracking, but it is distinct from whether the problem has already been solved elsewhere. AQL, CQL, and the data models they sit on top of are solving a harder, more general problem, and that shows in how complex they are. A narrower, purpose-built language is a reasonable trade-off, so long as it can cover what researchers actually need to express.