FHIR Chat · Is eld-1 correct in the context of an differential? · conformance

Stream: conformance

Topic: Is eld-1 correct in the context of an differential?

Matthijs van der Wielen (Mar 02 2021 at 13:12):

Background:
If I have a profile with the following slicing:

        <element id="Organization.identifier">
            <path value="Organization.identifier" />
            <slicing>
                <discriminator>
                    <type value="value" />
                    <path value="type.coding.code" />
                </discriminator>
                <rules value="open" />
            </slicing>

And I derive a profile from this and change the slicing rules from "open" to "closed" the diff looks like this:

 <element id="Organization.identifier">
            <path value="Organization.identifier" />
            <slicing>
                <rules value="closed" />
            </slicing>
            <mustSupport value="true" />
        </element>

And the .NET validator throws an eld-1.

Should the eld-1 only be run on a snapshot? Now it's context is snapshot and differential.

Lloyd McKenzie (Mar 02 2021 at 14:06):

You need to repeat the discriminator - that bit isn't inherited if you drill down into slicing. (At least that's the way the tooling currently works and it's not clear why that's unreasonable.)

Chris Moesel (Mar 02 2021 at 14:58):

Why should you have to repeat anything other than identifiers (id/path) in a differential? I feel like we complicate matters by having special (unspecified) rules about what data should or should not be redundantly repeated in the differential. It's much clearer for everyone if the rule is that you only have to repeat what is actually different. There are similar undocumented rules for how arrays work in differentials and the only way to figure out the "rule" there is to experiment w/ the publisher and see how it behaves -- which is not ideal.

Lloyd McKenzie (Mar 02 2021 at 15:01):

Feel free to submit a change request that makes that clear. My understanding is that all elements in differential are optional, but once you walk into an element, you need to specify the whole thing

Grahame Grieve (Mar 02 2021 at 19:47):

I do think that eld-1 should only apply to a snapshot, but it can be satisfied by doing extra work

Ward Weistra (Mar 03 2021 at 13:53):

deleted

Firely Bot (Mar 03 2021 at 13:53):

:warning: The argument eld-1 was not recognized. Use @Firely-Bot issue create ? for more information.

Ward Weistra (Mar 03 2021 at 13:54):

@Firely Bot issue create "Let eld-1 only be applied to snapshot, not differential"

• Given a resource 1 with slicing on element A
• And a resource 2 derived from resource 1, which:
  • Makes a change to slicing of element A (eg. changing closed to open slicing)
  • And does not repeat the discriminator in element A
• eld-1 fires, complaining element A in resource 2 does not have a discriminator set.

Proposal: Make eld-1 only applicable to the snapshot part of a resource, eliminating the need to repeat all slicing information in a derived resource.

https://www.hl7.org/fhir/profiling.html#reslicing is already clear the discriminator inherits to the child resources:

If a discriminator for an element is declared in a parent profile, child profiles referencing that element:
SHALL include all the same discriminators

Firely Bot (Mar 03 2021 at 13:54):

Select the issue type from project FHIR you want to report:

Change Request, Technical Correction, Question or Comment

Don't have an HL7 Jira account yet? Create one for free.

Jens Villadsen (Mar 03 2021 at 13:55):

@Firely Bot you're pretty chatty, aren't ya :smile:

Firely Bot (Mar 03 2021 at 13:55):

:warning: Command youre pretty chatty, arent was not recognized. Use @Firely-Bot ? for more information.

Ward Weistra (Mar 03 2021 at 13:58):

@Firely Bot issue show FHIR-31400

Firely Bot (Mar 03 2021 at 13:58):

FHIR-31400 Let eld-1 only be applied to snapshot, not differential
Status: Submitted, Type: Change Request

Yunwei Wang (Mar 03 2021 at 18:46):

@Ward Weistra 1) how does firely bot know your JIRA account? 2) After create issue, it would be better to return the JIRA ticket/link

Lloyd McKenzie (Mar 03 2021 at 20:01):

If the firely bot creates the issue under any account other than the requester's, that's problematic...

Ward Weistra (Mar 03 2021 at 21:19):

@Yunwei Wang @Lloyd McKenzie It's just creating a link for you :smile: Not much more fancy than a mailto: link filling the subject and body if you provide them. Hence it also doesn't have any idea if you actually clicked one of the issue types to create a ticket and what the number would be.

Ward Weistra (Mar 03 2021 at 21:23):

Feel free to test by clicking one of these below, nothing will happen until on the resulting page you click the 'Create' button. So, you can also summon the links for other people and let them create. The only handy thing it does add is an automatic link back from the Jira ticket to the thread on Zulip where the issue was created from :point_down:

Ward Weistra (Mar 03 2021 at 21:23):

@Firely Bot issue create

Firely Bot (Mar 03 2021 at 21:23):

Select the issue type from project FHIR you want to report:

Change Request, Technical Correction, Question or Comment

Don't have an HL7 Jira account yet? Create one for free.

Josh Mandel (Mar 03 2021 at 21:25):

When I click these links I get:

image.png

Richard Townley-O'Neill (Mar 04 2021 at 06:23):

@Ward Weistra

And a resource 2 derived from resource 1, which:
Makes a change to slicing of element A (eg. changing closed to open slicing)

Isn't opening a closed slicing in a derived profile impossible? :innocent:

Ward Weistra (Mar 04 2021 at 10:10):

@Richard Townley-O'NeillFair point. Ticket does not include making that possible :wink:
@Josh Mandel That's correct! Looks a bit scary with those warnings, but nothing you can't resolve on that screen.

Last updated: Apr 12 2022 at 19:14 UTC