Stream: implementers
Topic: inline details from extension definitions
Josh Mandel (Feb 24 2020 at 22:02):
@Mark Kramer raised FHIR#26360, asking for better computable paths to resolve the meaning of extensions. Part of this can be fixed with strong (more computable) definitions hosted at the Extension.url, e.g. to make sure http://hl7.org/fhir/R4/elementdefinition-definitions.html#ElementDefinition.code is populated when relevant. Given this ability, how important do folks think it would be to also provide this kind of information inline.
Mark Kramer (Feb 24 2020 at 23:17):
I responded to your question in the issue FHIR#26360.
Chris Moesel (Feb 25 2020 at 00:01):
@Josh Mandel -- When you suggest setting the code on the Extension.url element -- I assume you mean in the StructureDefinition that defines the extension (as opposed to putting it on the url element of a use of the extension in some other profile), right? I just want to be sure I'm tracking...
Josh Mandel (Feb 25 2020 at 00:37):
That's right -- the algorithm for a client would be to dereflference the URL found in the extension and then to review the element definitions found there.
Grahame Grieve (Feb 25 2020 at 01:24):
@Mark Kramer several comments on the task (and your comment in the task):
-
you equate extensions to observations but this would not usually be true. Generally, if it has a LOINC code, it should be an observation. There's a grey area, and you you picked an example from there, but that shouldn't drive general policy
-
I'm interested how many other extensions you identify that have codes that can be assigned? How useful are these codes? (see some stats below)
Finally, I believe it is allowable to bind ElementDefinition.code to a value set
-
I don't believe we have any machinery for this other than profiling structure definition itself. Is that what you mean?
-
I think that adding CodeableConcept to Extension will make all but a few much more unhappy with extensions
-
Why Coding and not CodeableConcept? because the inherent thing you are doing here is different, and the assertion of code binding is much tighter
Grahame Grieve (Feb 25 2020 at 01:24):
these stats are just for r4 core:
Total Structures: 658 Structures with KeyWords: 0 Structures with Element that have codes: 0 Total Extensions: 396 Extensions with KeyWords: 0 Extensions with Element that have codes: 0
Grahame Grieve (Feb 25 2020 at 01:25):
I'll have a go at doing this for all IGs in the ci-build system later
Grahame Grieve (Feb 25 2020 at 02:40):
for all the r4 packages I could find to load:
Total Structures: 2172 Structures with KeyWords: 0 Structures with Element that have codes: 0 Total Extensions: 773 Extensions with KeyWords: 0 Extensions with Element that have codes: 0
Grahame Grieve (Feb 25 2020 at 02:42):
we're really making use of those features, that's for sure
Mark Kramer (Feb 27 2020 at 14:48):
This is the single area where FHIR implementations are complete consistent :upside_down: . To your points, @Grahame Grieve:
- Sure, and extension isn't an Observation; they are more like Observation.component, and I've been in MANY discussions about whether {thing X} should be an extension or a component.
- Yes, I was talking about binding the ElementDefinition.code to a value set, but on second thought, I agree there is no (reasonable) way to do that.
- An optional element shouldn't upset people. If they don't want to send it, well, it's optional. But for some things, like the BirthSex example, it is entirely reasonable to supply a code to let receivers know the meaning of the extension.
Lloyd McKenzie (Feb 27 2020 at 15:35):
It's always been reasonable - but so far, there's not much in the way of incentive. Nor much likelihood of validation/review...
Last updated: Apr 12 2022 at 19:14 UTC
