Blog
Follow the question from release risk to operating evidence.
Technical notes for FHIR product, platform, implementation, and interoperability teams — organized as reading paths rather than a publication feed.
Choose your path
Read in the order your responsibility demands.
Start with the release decision, the implementation control, or the market context you need to understand.
For release owners
3 articlesUnderstand continuous FHIR release quality
Start with the operational questions, identify what can drift, then see where a CI gate stops being enough.
For FHIR engineers
2 articlesImplement a deterministic validation control
Put validation in delivery first, then give AI-assisted work the same explicit runtime and data boundary.
For interoperability teams
3 articles
Navigate German FHIR in practice
Map the overlapping program landscape before going deeper into ISiK delivery and the national ePA context.
For release owners
Understand continuous FHIR release quality
Start with the operational questions, identify what can drift, then see where a CI gate stops being enough.
Three Questions Every FHIR Team Should Be Able to Answer
FHIR teams rarely fail because they lack a validator. They fail when they cannot answer whether production data is valid now, when errors first appeared, and what the conformance state was in the past.
Terminology Drift: The Silent Killer of FHIR Data Quality
Your FHIR data was valid when it was created. It may not be valid today. Terminology drift is a common — and often under-monitored — source of FHIR data quality failures.
Why CI Validation Is Not Enough for FHIR
CI validation is a necessary first gate for FHIR teams, but it only answers whether a controlled change broke known fixtures. It does not show whether live data is still conformant.
For FHIR engineers
Implement a deterministic validation control
Put validation in delivery first, then give AI-assisted work the same explicit runtime and data boundary.
How to Add a FHIR Validation Gate to GitHub Actions
A FHIR validation gate should be boring: run on every pull request, fail clearly, produce machine-readable output, and leave a path from local checks to reviewable Records evidence.
Claude Should Not Guess FHIR: Validation Guardrails for AI-Assisted Development
Claude can generate plausible FHIR JSON. Trust requires a validation loop that identifies the runtime, protects data boundaries, explains the evidence, and revalidates every change.
For interoperability teams
Navigate German FHIR in practice
Map the overlapping program landscape before going deeper into ISiK delivery and the national ePA context.
The German FHIR Landscape: ISiK, MII, gematik, and Why It's More Complex Than It Looks
Germany has one of the densest and most overlapping FHIR landscapes in Europe. ISiK, MII, DiGA, KHZG — they're not the same thing, they don't share the same profiles, and hospitals may need to work with several of them simultaneously.
§373 SGB V and ISiK: What German Hospitals Are Actually Required to Deliver
§373 SGB V makes ISiK conformance mandatory for German hospital information systems. What the Bestätigungsverfahren actually tests, why a one-time certification isn't enough, and what happens between stages.
ePA für alle: What Germany's National Health Record Means for Your FHIR Data
Since October 2025, Germany's ePA has entered mandatory everyday use for healthcare providers. It's the largest FHIR deployment the country has attempted — and it moves German healthcare from documents to structured data, at a scale where conformance stops being optional.
Product notes
Why Records exists and how the product is changing.
Founder context and product decisions that sit outside the operational reading paths.
Records
Turn FHIR validation into operational evidence.
Records validates FHIR continuously, compares pinned runs, and preserves the basis behind release, handover, and integration decisions.