Stream: implementers
Topic: Doodle Poll for extension types
Grahame Grieve (Feb 28 2018 at 15:48):
We have an unclear policy about what types should be allowed in extension. There's a number of types that are obviously yes, and some that are obviously no. But then there's a few where it's not clear:
Grahame Grieve (Feb 28 2018 at 15:51):
vote on those ones here: https://doodle.com/poll/uce8uuhbh2397yd6
Grahame Grieve (Feb 28 2018 at 15:51):
note that the poll doesn't ask for you vote on ones where there's no question
Marten Smits (Feb 28 2018 at 16:10):
I agree on Dosage, and have my doubts about ContactDetail...
Melva Peters (Feb 28 2018 at 16:15):
If there are extensions needed for dosage, it would be great if tracker items could be created for consideration by Pharmacy to be added to Core.
Grahame Grieve (Feb 28 2018 at 16:32):
yep that would be normal process. but this is the opposite: can you extend something with a dosage?
Lloyd McKenzie (Feb 28 2018 at 17:00):
I think that it's unlikely to be useful to use a lot of these types as extensions - and I'm confused why some of them even exist. But it's hard to say that no, there's no way this could ever be useful in an extension.
Grahame Grieve (Feb 28 2018 at 23:28):
this is part of closing out GF#13363. @Lloyd McKenzie @Ewout Kramer @Josh Mandel (and anyone else) please review build.fhir.org/datatypes.html introduction with regard to these changes.
Other than the open question about extension.value, do we really want modifier extensions on Timing? Adding this would complicated modifiers a lot, and I've seen no use cases...
Lloyd McKenzie (Feb 28 2018 at 23:34):
"unlike all the other types do" -> "while all of the other types do not"
Bryn Rhodes (Feb 28 2018 at 23:58):
What is the reason for not allowing those types as extensions? RelatedArtifact, for example, I can see adding that as an extension to a ValueSet so that I can use it like a KnowledgeResource. I have to admit I've never understood why we would disallow those types in an extension.
Grahame Grieve (Mar 01 2018 at 00:02):
well, allowing types in extensions creates work for people. We don't want to do that for no reason. I'm fine with doing it for a reason
Bryn Rhodes (Mar 01 2018 at 00:05):
For the types that are used for elements in MetadataResource at least, I'd love to be able to define extensions for those, because the alternative is to just replicate the structure as a complex extension.
Grahame Grieve (Mar 01 2018 at 00:21):
well, the question is, where do you want to use them. You have use case for all of them?
Grahame Grieve (Mar 01 2018 at 01:21):
and I now have all the sources of this list sourced from a single location now, so now nore having different parts of the spec telling different stories
Grahame Grieve (Mar 01 2018 at 01:22):
@Bryn Rhodes I see you voted for all data types, including the IDMP ones.... I really think that there's a difference between a general purpose data type, and a context specific one. the IDMP ones are .. like Meta and Narrative
Bryn Rhodes (Mar 01 2018 at 01:41):
Because to me, the whole reason to define the DataType is so you can reuse it.
Bryn Rhodes (Mar 01 2018 at 01:42):
I don't follow this: "and I now have all the sources of this list sourced from a single location now, so now nore having different parts of the spec telling different stories", can you clarify?
Grahame Grieve (Mar 01 2018 at 02:00):
I had various places in the spec where the list was maintained, and they weren't entirely in sync
Lloyd McKenzie (Mar 01 2018 at 02:00):
Why is Meta a data type, by the way? We don't re-use it anywhere. Could it not be a complex type on Resource?
Lloyd McKenzie (Mar 01 2018 at 02:01):
Some re-useable structures exist for use in very limited circumstances and don't necessarily make sense for general use "wherever implementer creativity might suggest"
Grahame Grieve (Mar 01 2018 at 02:20):
we reuse meta in some operations
Bryn Rhodes (Mar 01 2018 at 02:33):
The ones I have specific use cases for are ParameterDefinition, DataRequirement, RelatedArtifact, ContactDetail, Contributor (though that might go away), TriggerDefinition, and UsageContext. All the use cases are about enabling decision support or knowledge artifact related functionality where it isn't present on the base resource.
Bryn Rhodes (Mar 01 2018 at 02:34):
I'm happy to change my vote to those if it really is the case that we want to discourage reuse of some structures, but I think a clear description of when we discourage versus when we allow and why would be beneficial.
Grahame Grieve (Mar 01 2018 at 02:54):
I think the answer right now is :
- we know of a user case
- the definition creates value in places other then defined
e.g. Meta and Narrative definitions are specific to the place in which they are defined. And Extension is never in the list of types for obvious reasons
Last updated: Apr 12 2022 at 19:14 UTC
