FHIR Chat · Grouping extensions · implementers

Stream: implementers

Topic: Grouping extensions


view this post on Zulip Elliot Silver (Feb 24 2017 at 18:08):

Hi, I was talking with some developers who wanted to define a "parent" extension to a resource, and define a bunch of "child" extensions which hang off the parent. The parent extension serves no purpose (and has no value[x]) other than to group the child extensions so that all of those developer's extensions are together, rather than having each of them directly attached to the resource. This approach feels wrong to me, but I was having trouble expressing why. Is this a reasonable thing to do? Why or why not?

view this post on Zulip Sadiq Saleh (Feb 24 2017 at 18:10):

Maybe I am misunderstanding your question, but isn't this a complex extension?

view this post on Zulip Elliot Silver (Feb 24 2017 at 18:15):

Yes, but in my mind there is no need for it to be. I could see a complex extension if there was a bunch of interrelated information and having one without the other didn't make sense. But this developer is using the grouping because they think its tidier that way and the child extensions really are unrelated to one another.
I don't like it, because it feels like it would be more difficult to to reuse the extensions, but I'm not sure about that.

view this post on Zulip Lloyd McKenzie (Feb 24 2017 at 18:24):

Introducing nesting layers that have no semantic meaning seems like a bad idea to me. The order and grouping of extensions is meaningless (beyond multiple repetitions of the same extension). Forcing certain extensions to be grouped together is likely to cause interoperability issues if different profilers start dictating that particular extensions need to be grouped in particular ways. So, while there's no prohibition against doing this, I'd certainly label it as questionable/poor practice. (Note that creating a complex extension when you need to is fine - e.g. you need a set of elements to repeat together or to be included/excluded as a group.)

view this post on Zulip Sadiq Saleh (Feb 24 2017 at 18:26):

Thanks for the clarification

view this post on Zulip Elliot Silver (Feb 24 2017 at 18:29):

Thanks @Lloyd McKenzie , that expresses my reservations well.


Last updated: Apr 12 2022 at 19:14 UTC