Category: Extension Registry

Extension documentation is where teams pay the debt for the extensions they minted a year ago. The developer who introduced the extension is on a different team. The consumers who read it need to know what it means. The support engineer...

A validator that refuses every extension URL it does not recognize is a validator that will reject nine out of ten real-world payloads. A validator that accepts every extension without checking is a validator that lets modifier-extension...

US Core is the implementation guide most US-based FHIR integrations follow, and its extensions are the ones most producers have to carry and most consumers have to handle. Knowing which extensions US Core actually requires — not the full...

FHIR extension URLs look like they should resolve to a canonical StructureDefinition on the web. Sometimes they do. Often they do not. And the difference between "identifier" and "network location" is where a real class of interoperability...

Every custom extension in a public API is a promise to consumers, and the promise has costs the API author does not always see up front. Versioning, documentation, terminology drift, consumer inertia, and support burden all follow every...

FHIR gives two extension shapes that look identical on the wire and behave very differently at consumption time. A regular extension is informational — a receiver may safely ignore it. A modifier extension changes the meaning of the...

An implementation guide (IG) is where the extensions your integration needs are declared. Not by name, exactly — by the profile-plus-extension shape that the IG expects on every payload it accepts. Reading the IG the way a compiler reads a...

Every team that ships a FHIR integration eventually has data that does not fit the base spec. The instinct is to reach for extensions, and that instinct is right more often than it is wrong. But not every gap deserves an extension, and the...