Stream: IG creation
Topic: Method and benefit of Standard Extensions
Scott Gordon (Apr 07 2022 at 14:29):
Question re: Standard Extensions
1) If an extension is created that ultimately gets passed (balloted?) as a Standard Extension, does that make it so any FHIR server up-to-date will support an IG with that Standard Extension in it?
2) What are the methods of balloting a standard extension? I think one way is as part of a Release build, but that feels like it could take waiting years for the next R ballot. I think another is having the proposed extension in an IG that is balloted. Can this IG contain just the extension information or must it be the complete IG in which you want to incorporate the extension?
And if I got anything wrong or missed another approach, please let me know since I'm in continuous learning mode :)
Scott
Lloyd McKenzie (Apr 07 2022 at 14:48):
- There's no requirement in the base FHIR specification to accept any data element (core or extension) unless it's a mandatory element - and even then, you can ignore it.
- The only way anything in the core spec is balloted is when we do a release ballot. And yes, it takes years. You're certainly free to create extensions within your IG if you can't wait for something defined in core.
Scott Gordon (Apr 07 2022 at 16:28):
So here's my confusion:
To be honest I had always thought the whole point of extensions (from the very beginning) is that IGs based on a published Release of FHIR can absolutely use any extensions that are needed for unique data needs AND a FHIR server (supporting the Release version) will support that IG with no issue. Meaning you should be able to have people implement your IG with your data needs using off the shelf FHIR servers and associated IT.
But recently I'd heard in different places that if you just write an extension of your own and put it in an IG - based on a current FHIR release (say R4) - that a vanilla FHIR server that supports R4 will not be able to understand those extensions unless massive software customizations are done to a server and associated IT. In other words, an IG with extensions won't be able to actually support transmission of your data, etc, in reality. The solution I'd heard was to make the extension "Standard" - which apparently requires some major balloting work anyway.
Thus, while extensions sounded nice and a way to avoid the multi-year effort to get your elements of unique interest to work with FHIR, this "standard extension" wrinkle makes it sound like the whole extension thing doesn't actually work even to test it against a vanilla server, unless you spend a few years balloting it to make it Standard.
But also, this sounds so different then the explanation of extensions I've understood to date, that I'm definitely very confused.
Is one of these correct - or closer to correct?
Lloyd McKenzie (Apr 07 2022 at 16:37):
A vanilla FHIR server that uses an internal FHIR storage mechanism (e.g. something build off one of the reference implementations like Smile CDR), will be able to store any arbitrary extension. It won't "understand" it, but then it doesn't really "understand" anything. If you're looking for support in something that doesn't have a FHIR persistence layer (e.g. an EHR), then it's not going to support any extensions it hasn't been specifically coded to support - whether those extensions are defined in the core spec or an IG doesn't matter. That also goes for 'core' elements - there are core elements the EHRs won't recognize either.
Defining 'standard' extensions in the core spec is a way to ensure consistent support of a use-case that doesn't meet the 80% rule, but will still be needed across a wide range of IGs throughout the world where it doesn't really make sense to define it as IG-specific. If you need the 'standard' extension to be available in an earlier version of FHIR, then you'll have to define an IG-specific extension as a short term solution and set an expectation for migration to the 'core' extension when implementers move to the new version of FHIR.
Last updated: Apr 12 2022 at 19:14 UTC
