The ravine between data specifications and the reality of implementation
What Do Healthcare Information Models Have in Common?
FHIR, openEHR — what do they have in common?
Aren’t these healthcare information models ?
What do they describe?
- Healthcare Concepts: Domain entities (like Patients, Encounters, and Observations) representing real-world clinical realities.
- Data Structures: Logical arrangements (like tables, trees, or graphs) defining how health concepts are organized and stored.
- Relationships: Links and dependencies connecting distinct concepts (e.g., a Practitioner prescribing a Medication to a Patient).
- Constraints: Validation rules and limits (like required fields, cardinalities, or allowed date ranges) ensuring data integrity.
- Semantics: Standardized meanings (often using SNOMED CT or LOINC) ensuring data is interpreted identically across systems.
The Overlap with Data Modeling and Querying
RDF/OWL, SQL, SPARQL, GQL, GraphQL — what do all of these have in common ?
Do they all have data modeling and querying at their core ?
What do they describe ?
- Entities: Core objects, tables, or nodes (e.g., resources, rows, or vertices) representing distinct real-world or digital items.
- Properties / Attributes: Key-value fields, columns, or predicates describing the characteristics and state of an entity.
- Relationships: Directed or undirected connections (like foreign keys, edges, or RDF triples) linking entities together.
- Constraints: Structural rules and validation criteria (such as primary keys, type checks, cardinality, or SHACL/OWL axioms) governing data shape.
- Semantics: Shared domain definitions, ontologies, and query logic ensuring uniform, unambiguous data interpretation across queries.
Do you see the overlap ? And do you really think you can specify FHIR or openEHR in any meaningful depth without eventually confronting the same fundamental problems addressed by RDF/OWL, JSON-LD, SQL, SPARQL, and GQL?
Once you go beyond superficial schemas and start specifying entities, relationships, semantics, constraints, identity, cardinality, composition, and how information is represented and queried, you are inevitably entering the territory of data modeling.
Specifications vs. Integrated Systems
OK, my second point — and this is where I want to drive the discussion.
You cannot turn specifications like FHIR, openEHR, RDF, OWL, SQL, SPARQL, or GQL into a commercially deployable software product simply by declaring them “implemented on a DBMS.”
Why?
Because on the implementation side of the ravine, a DBMS is a fully integrated execution engine. To transform abstract models into a working system, it must provide storage, indexing, transactions, concurrency control, query processing, optimization, security, recovery, replication, durability, logging, caching, administration, monitoring, and APIs, all operating together seamlessly.
The standards, by contrast, sit safely on the specification side of the cliff. They describe specific aspects of the information problem at an abstract level. But they cannot—and should not—prescribe the complex internal engine required to run them.
The Implementation Ravine
Therefore there is a huge gap between the two.
A specification can tell you what something means, what its structure should look like, what constraints apply, and what behavior is expected. Specifications are valuable, but ultimately, they are specifications. They are words, models, rules, and contracts. But in a DBMS one has to determine how all of that is actually implemented, optimized, executed, persisted, secured, and operated. A real DBMS has to turn those abstractions into an actual working system. And this is where Linus Torvalds’ famous moto, “Show me the code,” becomes particularly relevant.
Show me the implemented system and its code.