Stream: implementers
Topic: Minimize or even avoid extensions
Lin Zhang (Nov 18 2020 at 14:35):
Any way to do that? Or does it make any sense? For example, to accelerate ingesting data before further data standardization/normalization.
Lloyd McKenzie (Nov 18 2020 at 14:51):
Minimizing/avoiding extensions means minimizing/avoiding use-case specific and country-specific data elements. If your objective is only to capture/share what you're confident that pretty much every other system will recognize/understand, that's fine. However, if you want to support the needs of a specific space, you're going to need extensions. Extensions are a normal - even essential part of FHIR. Extensions don't necessarily represent "non-standardized" data. They simply represent "specialized" data - and there's lots of specialization in different parts of the healthcare space.
Lin Zhang (Nov 18 2020 at 15:18):
Thanks, Lloyd:blush: You are right. Actually I'm wondering whether a FHIR server could used as a staging store for later processing. Something like a server with not so many constraints.
Lloyd McKenzie (Nov 18 2020 at 15:22):
So your question is "Should I have a preliminary storage area that can accept anything separate from my 'main' storage area?"?
That's certainly a possibility. However, keep in mind that your external interface has to meet the contract of that interface. If someone says "please store this" and you respond with "yes, stored, here's the id", you don't want that statement to suddenly become untrue when you propagate the data to your internal system and you want the id you returned to be valid for subsequent search results, etc.
Yunwei Wang (Nov 18 2020 at 16:35):
@Lin Zhang It is not a question on limiting the extensions used in resource. You server should at least process extensions it understand. It can ignore extensions it does not support. This is why server should have CapabilityStatement to indicate what it support.
Lin Zhang (Nov 18 2020 at 23:32):
@Lloyd McKenzie Yep, that's my question. Thanks for your straightforward explanation :)
Lin Zhang (Nov 18 2020 at 23:35):
@Yunwei Wang OK. Many thanks.
Last updated: Apr 12 2022 at 19:14 UTC
