Stream: implementers
Topic: extensions syntax
Martijn Harthoorn (Apr 15 2016 at 12:31):
Has there been any discussion on alternative extension syntax, since Grahame's blog? http://www.healthintersections.com.au/?p=2467
Igor Sirkovich (Apr 15 2016 at 13:44):
Martijn Harthoorn (Apr 15 2016 at 13:53):
Yes, I read those. But after that?
Martijn Harthoorn (Apr 15 2016 at 13:53):
I couldn't find any discussion here on zulip.
Lloyd McKenzie (Apr 15 2016 at 18:33):
There was some, but it sort of lost steam
Igor Sirkovich (Apr 15 2016 at 19:25):
https://chat.fhir.org/#narrow/stream/implementers/subject/Representing.20Extensions
Grahame Grieve (Apr 15 2016 at 19:43):
yes. it didn't get the kind of support that would be needed to drive that kind of change. And frankly, I didn't think any of the json proposals were better than the one that already lost steam
Grahame Grieve (Apr 15 2016 at 19:43):
but it was a very useful discussion because we're not done with syntax yet....
Paul Knapp (Apr 15 2016 at 21:28):
I think ITS would like to join th ediscussion in Motreal on this topic.
Grahame Grieve (Apr 15 2016 at 23:00):
ITS will have to host it. Because there's no energy elsewhere, as far as i can tell.
David Hay (Apr 18 2016 at 00:59):
when extending a primitive type - does the extended name start or end with underscore? This page differs from this one...
Vadim Peretokin (Apr 18 2016 at 01:02):
Good find. I haven't seen the suffix version anywhere in use, leads me to think the latter page is incorrect.
Paul Knapp (Apr 18 2016 at 05:27):
starts with an underscore (JSON only)
Chris Grenz (Apr 19 2016 at 21:06):
What's the discriminator syntax for slicing by the value of an extension? E.g. if you have a complex extension and want to (re)slice the extension by one of the sub-elements, how?
Chris Grenz (Apr 19 2016 at 21:11):
Research auth is a complex extension with type (valueCode) and date (valueDate) sub-elements. I want to re-slice researchAuth by type:
<element> <path value="Patient.extension" /> <slicing> <discriminator value="@url" /> <rules value="open" /> </slicing> </element> <element> <path value="Patient.extension" /> <name value="researchAuth" /> <slicing> <discriminator value="???WHAT GOES HERE???" /> <rules value="open" /> </slicing> <type> <code value="Extension" /> <profile value="http://example.com/fhir/StructureDefinition/patient-research-authorization" /> </type> </element> <element> <path value="Patient.extension" /> <name value="researchAuth/MNAuth" /> </element> <element> <path value="Patient.extension.extension.valueCode" /> <name value="researchAuth/MNAuth.type.valueCode" /> <fixedCode value="Minnesota" /> </element>
Chris Grenz (Apr 19 2016 at 21:12):
Will include in upcoming list of examples....
Marten Smits (Apr 20 2016 at 08:35):
You probably picked the most complicated case. Reslicing on complex extensions by type.
After reading the discriminator section on the profiling page ( http://hl7.org/fhir/profiling.html#discriminator ) , my first guess would be that the discriminator would be: extension.@type
Chris Grenz (Apr 20 2016 at 15:42):
@Marten Smits @type slices by datatype...I need to slice by the extension with relative url "type"...
Chris Grenz (Apr 20 2016 at 15:43):
@Lloyd McKenzie Thoughts?
Chris Grenz (Apr 20 2016 at 15:43):
@James Agnew Does HAPI support using extension values as discriminators?
James Agnew (Apr 20 2016 at 15:45):
HAPI packages the RI validator for this stuff, and to be honest I have no idea if that is supported or not. :)
Chris Grenz (Apr 20 2016 at 15:45):
So @Grahame Grieve would have to answer?
Lloyd McKenzie (Apr 20 2016 at 15:49):
I'm so pleased to have someone else coming up with the torturous use-cases for Grahame :) I'm honestly not sure.
Chris Grenz (Apr 20 2016 at 15:50):
This one's not going to be fringe as extensions get more use. Every slicing of an extension will be a re-slice (since the orginal slice is @url) and will be dependent on some sub-extension (or value[x]).
Chris Grenz (Apr 20 2016 at 15:51):
But glad to jump in! ;)
James Agnew (Apr 20 2016 at 16:51):
For what it's worth, if you have test cases I will gladly add them to the unit test library.
Grahame Grieve (Apr 20 2016 at 21:25):
validator doens't support this, but technically, the discriminator is a fluent path expression
Ewout Kramer (Apr 21 2016 at 07:53):
Must admit this is too advanced for me as well. So, if we switched to fluentpath now, would that be an expression with an and, like "url=xxx and value = yyy"?
Chris Grenz (Apr 22 2016 at 14:56):
are there any constraints on what can be a discriminator? Certainly parent should be dis-allowed...should we put some complexity bounds here?
Michel Rutten (Apr 22 2016 at 15:06):
In theory, yes. However, I don't expect most clients/servers to implement full support for slicing and all of it's wonderful complexity. Probably standard support is limited to the simple use cases / default discriminators. Anything more complex requires a considerable implementation effort. So I am not sure if a list of constraints on the discriminator element would be used a lot...?
Chris Grenz (Apr 22 2016 at 15:09):
Seems we should have some kind of "levels of conformance" to define how fully slicing is supported. Or maybe a list of on/off features (slicing by @profile supported/not supported).
Chris Grenz (Apr 22 2016 at 15:11):
hate that slicing extensions is "too advanced" though...goes against the "no stigma for extensions" ethos....
Michel Rutten (Apr 22 2016 at 15:13):
Maybe the Conformance resource could provide some additional information on slicing support? Need to think about how to serialize this information efficiently. List of all supported discriminator paths / types? Not sure if that would work.
Chris Grenz (Apr 22 2016 at 15:14):
That would be a big list! ;) I was thinking more along the lines of general capability rather than specific path.
Michel Rutten (Apr 22 2016 at 15:17):
I agree that common/frequent use cases should be relatively simple to specify, at least that should be the goal. IIRC, you've identified a couple of interesting slicing use cases that aren't covered yet, or way too complex (e.g. extension, ordinal). Are you visiting the HL7 Montreal WGM? I think it would be useful to have a joint discussion on this topic with the FHIR core team.
Chris Grenz (Apr 22 2016 at 15:20):
I'll be there - Sat thru Tues (flying Wed)
Michel Rutten (Apr 22 2016 at 15:33):
I'm attending the full week. If you have some spare time, I would definitely like to meet up and go through these cases. Usually there is a late core team pizza session on thursday evening were advanced stuff like this is being discussed. But since you are leaving on tuesday, maybe we should plan an earlier meeting?
Chris Grenz (Apr 22 2016 at 16:08):
That'd be great!
Ewout Kramer (Apr 26 2016 at 18:32):
Yes, I think there is benefit in identifying common and advanced cases. Maybe advanced cased would be better serverd using FP invariants rather than increasing the complexity of the slicing system. Though that would be less "declarative" and would probably inhibit some of the uses Chris has imaginged using SD for....
Chris Grenz (Apr 26 2016 at 19:17):
Working on use cases - will have some for WGM discussion...
Chris Grenz (Apr 26 2016 at 19:19):
On a new topic - can one extend value[x] directly or must one use a typed version. For example, can I:
<element> <path value="Patient.extension.value[x].extension" /> <name value="ext1.value[x].ext2" /> ...snip...
or must I:
<element> <path value="Patient.extension.valueCode.extension" /> <name value="ext1.valueCode.ext2" /> ...snip...
Typing of value[x] is variable...can't easily determine that it's an Element which would allow extension.
Chris Grenz (Apr 26 2016 at 19:22):
Answer should be consistent with whether this is legal:
<element> <path value="Observation.value[x].coding.code" /> ...snip...
Grahame Grieve (Apr 26 2016 at 19:22):
when would it not allow extension?
Ewout Kramer (Apr 26 2016 at 19:22):
I think the first one would extend value[x], where [x] still has a choice of multiple types. In the second one, valueCode would have constrained the value to just Code, and you're adding an extension to that. So, it does not matter for the extension, but it does imply what happens to the parent element 'value'
Chris Grenz (Apr 26 2016 at 19:23):
As defined, value[x].extension would always be legal, but not value[x].coding.code
Grahame Grieve (Apr 26 2016 at 19:23):
well, this:|
Observation.value[x].coding.code is not valid
Chris Grenz (Apr 26 2016 at 19:24):
So something[x].child is only legal if child is found in all possible [x] types? That's a pain....
Grahame Grieve (Apr 26 2016 at 19:24):
in an element definition path, yes, that's correct.
Chris Grenz (Apr 26 2016 at 19:25):
So a profile validator needs to check ALL the types to make sure that the child is present in each? Oye, ok.
Chris Grenz (Apr 26 2016 at 19:27):
Is [x] always an Element?
Grahame Grieve (Apr 26 2016 at 19:27):
I don't believe that there's any context where a path refers to more than one type
Grahame Grieve (Apr 26 2016 at 19:28):
everything is always an element except for the base resource itself
Chris Grenz (Apr 26 2016 at 19:28):
There's no [x] that allows Resource?
Chris Grenz (Apr 26 2016 at 19:28):
Can we make that a SHALL?
Grahame Grieve (Apr 26 2016 at 19:29):
which bit?
Chris Grenz (Apr 26 2016 at 19:29):
That [x] can only be Elements and that only Element elements are allowed in path after [x].
Chris Grenz (Apr 26 2016 at 19:31):
To avoid stuff like extension.value[x].value if [x] allows Identifier and Quantity. Basically trying to avoid having to interrogate all the types to determine what's valid...
Grahame Grieve (Apr 26 2016 at 19:31):
right. you can assume that this is SHALL. we don't say this directly in that forma, because we don't need to.
Chris Grenz (Apr 26 2016 at 19:31):
so [x].extension and [x].id would be the only things allowed a children of [x]
Chris Grenz (Apr 26 2016 at 19:33):
By your assertion above, anything allowed in ALL of the value[x] types would be allowed as children of value[x]...I'd like to see that limited to id and extension.
Grahame Grieve (Apr 26 2016 at 19:35):
well, at the moment, it is
Chris Grenz (Apr 26 2016 at 19:37):
Ok, to be explicit, is <path value="Extension.value[x].system" />
legal if the types of value[x] are limited to Identifier and Quantity?
Grahame Grieve (Apr 26 2016 at 21:00):
no. that's not legal. it has to be one type
Chris Grenz (Apr 26 2016 at 21:01):
And <path value="Extension.value[x].extension" />
is legal (with no type restrictions on value[x]) since extension is part of Element?
Last updated: Apr 12 2022 at 19:14 UTC