We solved syntax and failed on semantics
For decades the effort went into making systems parse the same XML or JSON. They still do not agree on what the data means.
System A writes value: "5" meaning five items. System B reads it as five
metres. Both parsed correctly. That is the entire problem in one line.
- Semantic drift. Critical context is lost in translation between systems.
- Hallucination. Probabilistic models fail when fed ambiguous, context-poor data.
- Domain silos. A patient record is alien to a vessel-inspection system, and neither can read the other.
The original sin of data standards
Most standards conflate how data is encoded with what it means.
Structure, semantics and validation rules get bundled into a single artefact: an archetype, a resource, a profile. The result is complexity, ambiguity and a tooling ecosystem you cannot leave. It is impossible to process structure independently from semantics in a conflated model, which is why every integration becomes a bespoke mapping exercise.
SDC separates them. Structure is a container; meaning is an explicit, separate, machine-readable payload.
Four pillars
Explicit separation
A two-stage pipeline validates structure first, then enriches with meaning.
Architectural simplicity
A stateless, document-centric model in which the document is the self-contained message.
Semantic rigor
A type system that prevents ambiguity by design. Units are not codes, and the difference is enforced rather than documented.
Cross-domain utility
A domain-agnostic reference model rather than one locked to a single industry.
How it compares, on checkable properties
Architectural characteristics, not scores. Every row is something you can confirm by reading the specifications.
| Property | SDC | openEHR | FHIR | NIEM |
|---|---|---|---|---|
| Separates structure from semantics | Yes | No | No | No |
| Mandatory units for quantities | Yes | Yes | Optional | Text only |
| Distinguishes units from codes | Yes | Partial | No | No |
| Automatic RDF triple generation | Yes | Limited | Limited | No |
| Tooling requirement | Standard XML | ADL | Custom ecosystem | Custom ecosystem |
| Domain scope | Domain-agnostic | Health | Health | Justice and public safety, extended |
On comparison
These are design differences, not verdicts. openEHR, FHIR and NIEM each solve problems SDC does not, and SDC is meant to sit underneath them rather than replace them. Where a row says "no", it reflects a deliberate choice by that standard, made for reasons that were good in its context.
The difference in practice: why a number is not enough
Modeling a blood glucose value of 5.5 mmol/L, three ways.
NIEM — ambiguous
<nc:MeasureValue>5.5</nc:MeasureValue>
<nc:MeasureUnitText>mmol/L</nc:MeasureUnitText>Units are free text, prone to typos, with no semantic link.
FHIR — optional
{ "valueQuantity": {
"value": 5.5,
"unit": "mmol/L",
"system":"http://unitsofmeasure.org",
"code": "mmol/L"
} }
Richer, but unit is not mandatory, so a value can exist without one. The
ambiguity is permitted rather than prevented.
SDC — enforced
<BloodGlucose>
<value>5.5</value>
<units>mmol/L</units>
</BloodGlucose>
units is a mandatory reference into a controlled, semantically rich units
model. The ambiguity is architecturally impossible rather than discouraged.
Designing for decades, not for deployment
Software changes, and forced data migrations are where the cost lands. SDC answers that with two layers.
Layer 1 · permanent component identity
A component's structure is identified by a permanent CUID2 and locked at publication. You create new models without touching old data.
Layer 2 · namespace versioning
New reference-model versions get new namespaces. SDC4 and SDC5 data coexist and can be queried in parallel. There is nothing to rip out.
The consequence
Data written against SDC4 today is designed to still validate against its original components twenty years from now. Read the permanence argument →
Is SDC missing an API? No, that is the choice
The document-centric architecture prioritizes determinism and transport independence.
| FHIR, API-centric | SDC, document-centric | |
|---|---|---|
| Paradigm | Resource-centric | The document is the contract |
| State | Server-managed | Stateless |
| Validation | At the endpoint, at runtime | Deterministic, offline capable |
| Transport | Coupled to HTTP REST | Agnostic: HTTP, Kafka, AMQP, file |
The sensible strategy is the one openEHR practitioners already use: model in the system with the stronger semantics, and expose a FHIR API where the ecosystem requires one.
We did not reinvent the wheel
SDC is an assembly of existing open standards, not a new one competing with them.
- W3C XSD 1.1, OWL, SHACL and SPARQL
- ISO 21090 for exceptional values and healthcare data types
- ISO 8601 for date and time
- BFO, ISO/IEC 21838-2, for ontological alignment
- SDC4 Reference Model — open specification on GitHub.
- sdcvalidator — production Python library on PyPI.
- sdcvalidatorJS — TypeScript and Node.js library on npm.
The foundation of data trust should be open, accessible and community-driven.