FHIR Chat · Slicing by code and matching slice with empty code · conformance

Stream: conformance

Topic: Slicing by code and matching slice with empty code

view this post on Zulip Simone Heckmann (Mar 02 2018 at 10:38):

Hi, I'm having issues with the following profile:
https://simplifier.net/medikationsplanplus/medicationstatement-1
I have 5 slices for MedicationStatement.dosage:
morning, noon, evening, night and freetext.
I am currently slicing by dosage.timing.code.coding.code with the first four slices having distinct fixed codes each.
The fifth slice however is supposed to define the dosage as free text, with dosage.timing.code set to 0..0.

The following example should match with the "morning/morgens" slice due to the fixed code "CM", but apparently, the validator matches it with the last freetext/freitext slice:

    <dosage>
        <timing>
            <code>
                <coding>
                    <system value="http://hl7.org/fhir/v3/TimingEvent" />
                    <code value="CM" />
                </coding>
            </code>
        </timing>
        <doseQuantity>
            <value value="1" />
            <unit value="{Stück}" />
            <system value="http://unitsofmeasure.org" />
            <code value="{Stück}" />
        </doseQuantity>
    </dosage>

https://simplifier.net/medikationsplanplus/MedicationStatement-example-4
Is the slicing definition incorrect or is the validator off?

view this post on Zulip Simone Heckmann (Mar 02 2018 at 10:40):

Normally, I would have defined the last slice as @default slice, so the instance will only be matched against this slice, if all others don't match.
But that's not working in STU3 due to the invariant that doesn't allow the slice name "@default". Does anyone have an idea for a workaround?

view this post on Zulip Simone Heckmann (Mar 02 2018 at 11:16):

I'm currently experimenting with adding a type=exists path=timing.code discriminator, but that doesn't seem to make any difference...

view this post on Zulip Simone Heckmann (Mar 02 2018 at 11:31):

Nah. I don't get it. IMO the instance should clearly match against the first slice, but the validator insist on matching it against the last. No idea what's going on here...

view this post on Zulip Simone Heckmann (Mar 02 2018 at 12:07):

I have now fixed timing.code.coding.code in the "freitext" slice to the Dummy Code "FREE", now the validator seems to match the instance correctly to the first "Morgens"-slice. So the problem appears to be that while the first slice matches correctly, the instance also matches against the last slice, which evetually takes precedence.

...so I guess the workaround I am looking for might be to move the freitext-slice to the top of the list..

view this post on Zulip Simone Heckmann (Mar 02 2018 at 12:15):

Nope. Even with the freitext-slice moved to the top, the instance doesn't validate :(

view this post on Zulip Lloyd McKenzie (Mar 02 2018 at 15:41):

Can you create a test-case for us in build\tests\validation-examples and raise a tracker item?

view this post on Zulip Simone Heckmann (Mar 02 2018 at 17:42):

ok. where do I need to put the profile? Or is it sufficient if it's published on Simplifier?

view this post on Zulip Lloyd McKenzie (Mar 02 2018 at 18:07):

It can go in that same folder

view this post on Zulip Michel Rutten (Mar 05 2018 at 09:58):

Hi @Simone Heckmann, invariant eld-16 for sliceName has a couple of issues:
https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemBrowse&tracker_id=677&summary=eld-16
We should fix this invariant to allow for:

  • / forward slashes (for reslicing)
  • [ and ] characters (for type slicing)
  • @default

view this post on Zulip Lloyd McKenzie (Mar 05 2018 at 15:10):

@Michel Rutten can you add a tracker ASAP?

view this post on Zulip Michel Rutten (Mar 05 2018 at 15:40):

Hi @Lloyd McKenzie,gForge already contains a number of issues concerning eld-16:
GF#13217, GF#13769, GF#13771, GF#14389, GF#15133

view this post on Zulip Grahame Grieve (Mar 05 2018 at 15:41):

it's on my list for this week

view this post on Zulip Simone Heckmann (Mar 11 2018 at 15:02):

@Michel Rutten @Ewout Kramer : we fixed a problem with the ValueSet, now HAPI validates the example successfully, but Simplifier still gives an error. Could this be an issue with the .NET-Validator?

view this post on Zulip Michel Rutten (Mar 12 2018 at 13:32):

@Simone Heckmann Could be. Ewout just returned from HIMSS. I'll ask him to investigate.

view this post on Zulip Brian Postlethwaite (Mar 13 2018 at 08:28):

This could be the same issue that i was looking at @michel.

view this post on Zulip Michel Rutten (Mar 13 2018 at 08:28):

Yes, could be.

view this post on Zulip Ewout Kramer (Mar 15 2018 at 14:03):

This could be the same issue that i was looking at @michel.

What is this about?

view this post on Zulip Simone Heckmann (Mar 19 2018 at 12:24):

The only solution I can think of so far is to remodel the whole dosage-part by using invariants instead of slicing, but I'd much rather not :-/
The idea I had about using a dummy code for the freetext slice fell flat, because I'd need to introduce a new code but the binding is "required".

view this post on Zulip Simone Heckmann (Apr 04 2018 at 20:03):

...any news about this issue?

view this post on Zulip Simone Heckmann (Apr 04 2018 at 20:04):

@Ewout Kramer @Brian Postlethwaite @Michel Rutten

view this post on Zulip Ewout Kramer (Apr 09 2018 at 08:06):

...any news about this issue?

Yes, I think @Brian Postlethwaite created a fix for this, which I will look at today or tomorrow to pull it in. @Brian Postlethwaite, is this the issue fixed here (https://github.com/ewoutkramer/fhir-net-api/pull/558)?

view this post on Zulip Brian Postlethwaite (Apr 09 2018 at 09:21):

Yes, this is the one.
Please look at it with a critical eye, as I'm not certain of it, just that it resolved my immediate issue.

view this post on Zulip Ewout Kramer (Apr 09 2018 at 10:05):

I expect it to be a temporary fix, since we need to change the way we deal with discriminators....

view this post on Zulip Simone Heckmann (May 11 2018 at 12:18):

@Ewout Kramer do you have any information of whether the fix has been deployed to Simplifier? Because my validation still errors...

view this post on Zulip Ewout Kramer (May 12 2018 at 13:55):

@Ewout Kramer do you have any information of whether the fix has been deployed to Simplifier? Because my validation still errors...

It has been deployed in the new 0.95 version of the .NET API - but it takes a bit of time before Simplifier will upgrade.... @Martijn Harthoorn knows more about that!

view this post on Zulip Martijn Harthoorn (May 15 2018 at 08:03):

0.95.0-alpha1.

view this post on Zulip Martijn Harthoorn (May 15 2018 at 08:04):

We can upgrade this week if necessary.

view this post on Zulip Ewout Kramer (May 15 2018 at 08:29):

0.95.0-alpha1.

alpha1 is the currently used version? Ok, that makes sense since we fixed it in the final 0.95 as it was published last month, but was not yet fixed in the alpha.

view this post on Zulip Martijn Harthoorn (May 15 2018 at 08:30):

ok. Will do an update this week.

view this post on Zulip Simone Heckmann (May 15 2018 at 12:37):

Thanks guys! On a similar note: do you plan on adding support for discriminators testing for existence of elements?

view this post on Zulip Michel Rutten (May 16 2018 at 07:31):

Does this even need a special construct? If you discriminate on a certain child element, then I would expect missing elements to be matched separately (in their own bucket/slice).

view this post on Zulip Simone Heckmann (May 16 2018 at 07:52):

I get an "unsupported" message from Simplifier validation: https://simplifier.net/medikationsplanplus/medicationstatement-example/$validate

Last updated: Apr 12 2022 at 19:14 UTC


An HL7 Website -