FHIR Chat · Slice closed rule validation · implementers

Stream: implementers

Topic: Slice closed rule validation

JL (May 11 2017 at 14:11):

I asked this on the HAPI FHIR google groups forum, but didn't get a response. I do wonder, given the class name, if the code in question is not really from the HAPI team though. Anyways, trying this question here to see if anyone knows the answer. I basically created a StructureDefinition in Forge and want to validate an XML input against that definition.

JL (May 11 2017 at 14:12):

Sorry, pressed entered by mistake. :) This is the original question posted on HAPI google groups:

I created a profile using Forge where only certain identifiers are permitted for a resource. It created a StructureDefinition that contains this:

    <element>
        <path value="Patient.identifier" />
        <slicing>
            <discriminator>
                <type value="value" />
                <path value="type.coding.system" />
            </discriminator>
            <discriminator>
                <type value="value" />
                <path value="type.coding.code" />
            </discriminator>
            <rules value="closed" />
        </slicing>
    </element>

I wanted to validate a resource against definition using HAPI, but it seems HAPI does not validate slicing closed rules? I took a look at org.hl7.fhir.dstu3.validation.InstanceValidator, and I can't seem to find any code that checks for a closed slicing rule. I see some logic around line 3003 for open rules, but no references for closed rule. I am using HAPI FHIR 2.4. Please advise.

Michel Rutten (May 11 2017 at 14:42):

Looks like the validator in the .NET API also doesn't verify this yet. TODO

Lloyd McKenzie (May 11 2017 at 14:50):

The FHIR validator has different rules for open vs. "not open" but doesn't distinguish between openAtEnd and closed. So definitely more work to happen. Out of curiosity, why are you using closed? It's sort of similar to declaring "final" in Java, which is hard to use well.

JL (May 11 2017 at 15:14):

Thanks for the reply, Llyod. I was trying to declare that our system takes "these" identifiers and other identifiers will be ignored. Having written that, I think openAtEnd might be a better rule. I was interested in testing out the validation though, which was why I chose "closed" in the beginning because it was more restrictive.

Lloyd McKenzie (May 11 2017 at 16:23):

Open is preferable to OpenAtEnd. OpenAtEnd says yours have to appear first, which is generally not good practice - order has no meaning and forces the sender to customize order just for you.

JL (May 11 2017 at 16:25):

Good point - thanks

Eric Haas (May 12 2017 at 05:38):

So why do we have that as an option?

Lloyd McKenzie (May 12 2017 at 09:23):

Because there are some implementations that will need to be able to say "our stuff must come first" or "only our stuff is allowed". It's not good practice, but sometimes it's implementation reality.

Last updated: Apr 12 2022 at 19:14 UTC