FHIR Chat · Constraining Bundle Entries · implementers

Stream: implementers

Topic: Constraining Bundle Entries

Richard Kavanagh (Feb 22 2017 at 07:59):

We have a use case where we need to constrain the entries in a Bundle. What is the correct way to achieve this?

1) How would you constrain the first entry to be a "MessageHeader" resource?
2) How would you constrain the first entry to be a "MessageHeader" with Profiles "xxxxx"?

FHIR stipulates that certain Bundle types have constraints, looking for a way to describe these in a StructureDefinition.

A "FHIR Document" Bundle states the first entry is a Composition
A "FHIR Message" Bundle states the first entry is a MessageHeader

Lloyd McKenzie (Feb 22 2017 at 09:26):

I've done it using invariants. In principle you can do it with slicing, but the validator used to have trouble slicing through Resource (as opposed to Reference)

Lloyd McKenzie (Feb 22 2017 at 09:27):

In terms of profiles, at the moment with FHIRPath the best you can do is force a given profile to be declared (and then rely on the validator to validate against that profile). There isn't yet a mechanism in FHIRPath to assert that a given element must be valid against a specified profile, though a request has been made to add such a feature.

Oliver Egger (Feb 22 2017 at 10:32):

I have currently set it up with slicing the following way for a fhir document enforing a composition and it works with the validator:

<differential>
        <element id="Bundle">
            <path value="Bundle" />
            <min value="1" />
            <max value="1" />
        </element>
        <element id="Bundle.type">
            <path value="Bundle.type" />
            <fixedCode value="document" />
        </element>
        <element id="Bundle.entry">
            <path value="Bundle.entry" />
            <slicing>
                <discriminator>
                    <type value="type" />
                    <path value="resource.type" />
                </discriminator>
                <ordered value="true" />
                <rules value="openAtEnd" />
            </slicing>
            <min value="1" />
            <max value="*" />
        </element>
        <element id="Bundle.entry.resource:Composition">
            <path value="Bundle.entry.resource" /> 
          <sliceName value="Composition" />
            <min value="1" />
            <max value="1" />
            <type>
                <code value="Composition" />
                <profile value="snip"/> 
            </type>
        </element>
    </differential>

Richard Kavanagh (Feb 22 2017 at 10:39):

@Lloyd McKenzie That's what I feared... For DSTU2 the base resources dont have FHIRPath so will need to see what can be achieved in that area looks like we will have to inject a little non standard validation.

As for using the "validator" then shaping things to work around that seems strange especially considering that will not be a choice that many people make.

@Oliver Egger Your suggestions gets us half way to where we need to be and looks like an approach we'll explore - thank you.

As for the complete requirements then I guess it's something that FHIR just does not support at this point in time.

Kevin Mayfield (Feb 22 2017 at 10:39):

I've done similar to Oliver but this was for display purposes (using Endeavour/InterOpen's profile generator). [Document Bundle http://test-rr8.trust.leedsth.nhs.uk:8080/web/fhir/Bundle.Document.html - N3 connection is required]

Oliver Egger (Feb 22 2017 at 11:56):

@Richard Kavanagh my example is also R3, for DSTU2 it would be

<slicing>
                <discriminator value="resource.@type" />
                <ordered value="true" />
                <rules value="openAtEnd" />
            </slicing>

Lloyd McKenzie (Feb 22 2017 at 14:45):

@Richard Kavanagh It's fully enforceable with xpath too. If you intend to use the validator and don't have time/ability to enhance it, then its limitations are relevant (it was for my project). Perfectly fine for it not to be relevant to you :)

Grahame Grieve (Feb 24 2017 at 19:04):

I think that FHIRPath is available in R2 in the C# code. It certainly is in java

Grahame Grieve (Feb 24 2017 at 19:04):

forcing an element to conform to a slice in a FHIRPath invariant:

Grahame Grieve (Feb 24 2017 at 19:06):

[some path].conformsTo("http://hl7.org/fhir/StructureDefinition/integer")

Grahame Grieve (Feb 24 2017 at 19:06):

though a profile URL would be appropriate, not a base type

Lloyd McKenzie (Feb 24 2017 at 20:14):

conformsTo is new and not yet supported by the Java code, correct?

Grahame Grieve (Feb 24 2017 at 20:15):

it's not new. but agree it's not implemented in the code yet

Grahame Grieve (Feb 24 2017 at 20:15):

not sure about using it in the validator either - could easily get circular

Lloyd McKenzie (Feb 24 2017 at 20:18):

Not sure about "easily" but it's within the realm of theoreticaly possibility

Brian Postlethwaite (Feb 26 2017 at 00:51):

Yes, can confirm that the fhirpath expressions are in the c# code also.

Brian Postlethwaite (Feb 26 2017 at 00:51):

Both in the invariant definitions and also the search parameter expressions.
(there was a standard extension added to hold them)

Last updated: Apr 12 2022 at 19:14 UTC