FHIR Chat · extensions syntax · implementers

Stream: implementers

Topic: extensions syntax


view this post on Zulip 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

view this post on Zulip Igor Sirkovich (Apr 15 2016 at 13:44):

https://lightmyfhir.org/

view this post on Zulip Martijn Harthoorn (Apr 15 2016 at 13:53):

Yes, I read those. But after that?

view this post on Zulip Martijn Harthoorn (Apr 15 2016 at 13:53):

I couldn't find any discussion here on zulip.

view this post on Zulip Lloyd McKenzie (Apr 15 2016 at 18:33):

There was some, but it sort of lost steam

view this post on Zulip Igor Sirkovich (Apr 15 2016 at 19:25):

https://chat.fhir.org/#narrow/stream/implementers/subject/Representing.20Extensions

view this post on Zulip 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

view this post on Zulip Grahame Grieve (Apr 15 2016 at 19:43):

but it was a very useful discussion because we're not done with syntax yet....

view this post on Zulip Paul Knapp (Apr 15 2016 at 21:28):

I think ITS would like to join th ediscussion in Motreal on this topic.

view this post on Zulip 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.

view this post on Zulip 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...

view this post on Zulip 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.

view this post on Zulip Paul Knapp (Apr 18 2016 at 05:27):

starts with an underscore (JSON only)

view this post on Zulip 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?

view this post on Zulip 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>

view this post on Zulip Chris Grenz (Apr 19 2016 at 21:12):

Will include in upcoming list of examples....

view this post on Zulip 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

view this post on Zulip 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"...

view this post on Zulip Chris Grenz (Apr 20 2016 at 15:43):

@Lloyd McKenzie Thoughts?

view this post on Zulip Chris Grenz (Apr 20 2016 at 15:43):

@James Agnew Does HAPI support using extension values as discriminators?

view this post on Zulip 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. :)

view this post on Zulip Chris Grenz (Apr 20 2016 at 15:45):

So @Grahame Grieve would have to answer?

view this post on Zulip 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.

view this post on Zulip 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]).

view this post on Zulip Chris Grenz (Apr 20 2016 at 15:51):

But glad to jump in! ;)

view this post on Zulip 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.

view this post on Zulip Grahame Grieve (Apr 20 2016 at 21:25):

validator doens't support this, but technically, the discriminator is a fluent path expression

view this post on Zulip 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"?

view this post on Zulip 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?

view this post on Zulip 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...?

view this post on Zulip 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).

view this post on Zulip Chris Grenz (Apr 22 2016 at 15:11):

hate that slicing extensions is "too advanced" though...goes against the "no stigma for extensions" ethos....

view this post on Zulip 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.

view this post on Zulip 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.

view this post on Zulip 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.

view this post on Zulip Chris Grenz (Apr 22 2016 at 15:20):

I'll be there - Sat thru Tues (flying Wed)

view this post on Zulip 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?

view this post on Zulip Chris Grenz (Apr 22 2016 at 16:08):

That'd be great!

view this post on Zulip 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....

view this post on Zulip Chris Grenz (Apr 26 2016 at 19:17):

Working on use cases - will have some for WGM discussion...

view this post on Zulip 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.

view this post on Zulip 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...

view this post on Zulip Grahame Grieve (Apr 26 2016 at 19:22):

when would it not allow extension?

view this post on Zulip 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'

view this post on Zulip Chris Grenz (Apr 26 2016 at 19:23):

As defined, value[x].extension would always be legal, but not value[x].coding.code

view this post on Zulip Grahame Grieve (Apr 26 2016 at 19:23):

well, this:|

Observation.value[x].coding.code

is not valid

view this post on Zulip 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....

view this post on Zulip Grahame Grieve (Apr 26 2016 at 19:24):

in an element definition path, yes, that's correct.

view this post on Zulip 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.

view this post on Zulip Chris Grenz (Apr 26 2016 at 19:27):

Is [x] always an Element?

view this post on Zulip 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

view this post on Zulip Grahame Grieve (Apr 26 2016 at 19:28):

everything is always an element except for the base resource itself

view this post on Zulip Chris Grenz (Apr 26 2016 at 19:28):

There's no [x] that allows Resource?

view this post on Zulip Chris Grenz (Apr 26 2016 at 19:28):

Can we make that a SHALL?

view this post on Zulip Grahame Grieve (Apr 26 2016 at 19:29):

which bit?

view this post on Zulip 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].

view this post on Zulip 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...

view this post on Zulip 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.

view this post on Zulip Chris Grenz (Apr 26 2016 at 19:31):

so [x].extension and [x].id would be the only things allowed a children of [x]

view this post on Zulip 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.

view this post on Zulip Grahame Grieve (Apr 26 2016 at 19:35):

well, at the moment, it is

view this post on Zulip 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?

view this post on Zulip Grahame Grieve (Apr 26 2016 at 21:00):

no. that's not legal. it has to be one type

view this post on Zulip 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