FHIR Chat · Constraining a Resource

Stream: shorthand

Topic: Constraining a Resource

Craig Newman (May 19 2020 at 17:59):

I'm trying to create a profile on Bundle and constrain the first resource in .entry to a particular MessageHeader profile. Looking at other IGs, it feels like I need to do this:
entry[<slice name>].resource ^type.profile = <desired profile>
I tried using the name of the profile I created (BDRMessageHeader) and while it didn't cause a Sushi error, it didn't display correctly. It works fine when I give it the explicit URL for the desired profile. Should this work with just the profile name (like it does when you restrict a Reference element)? Or am I constraining it the wrong way?

Nick Freiter (May 19 2020 at 18:47):

I think in this situation you would want to use an only rule, as described in more detail here: http://build.fhir.org/ig/HL7/fhir-shorthand/branches/master/reference.html#data-type-restriction-rules. As an example, I think you would want something like this:

* entry[specialMessage].resource only BDRMessageHeader

Assuming that specialMessage is a slice you have added to the entry element already.

Vassil Peytchev (May 19 2020 at 18:51):

Is it possible to simply state

* entry[0].resource only BDRMessageHeader

Craig Newman (May 19 2020 at 19:03):

Sushi doesn't seem to like Vassil's solution. I get an error of "No element found at path entry[0].resource"

Nick Freiter (May 19 2020 at 19:34):

In the context of a profile, we can't constrain specific elements in the entry array. The entry array is an element that has cardinality 0..*, and we can constrain the contents of that array using slicing, but you can't put a constraint on an element at the 0th index.

Chris Moesel (May 19 2020 at 19:51):

If you really want to constrain the first entry, you may be able to do that by setting ordered in the slicing definition, but the FHIR spec seems to discourage that. I'm also not sure how it works with elements that don't belong to a slice (do they go before or after the ordered slices?).

The other approach to enforce a type constraint on the first entry resource would be to use an invariant with a FHIRPath expression saying that the first entry resource must be a certain type.

Craig Newman (May 19 2020 at 20:07):

I may be going overboard given the base spec is very clear that the first entry in a message bundle must be a MessageHeader but it did seem worth it to specify the profile to use. I currently have this:

entry ^slicing.discriminator.type = #type
entry ^slicing.discriminator.path = "resource"
entry ^slicing.rules = #open
entry ^slicing.ordered = true
entry ^slicing.description = "First entry must be MessageHeader"
entry contains MessageHeader 1..1
entry[MessageHeader].resource 1..1
entry[MessageHeader].resource only BDRMessageHeader

But I have to admit that discriminators confuse me. Should the path be resource.resolve()?

Vassil Peytchev (May 19 2020 at 20:11):

It seems to me that the ability to constrain the first entry in a Bundle without making the whole array of entries ordered is something that is necessary for documents, messages, and notifications. The proper way to do that needs to be called out as a pattern to follow. Would that be "an invariant with a FHIRPath expression saying that the first entry resource must be a certain type"?

Chris Moesel (May 20 2020 at 17:42):

@Craig Newman -- if the target is a reference, you need resolve(), otherwise, you do not. Since entry.resource is not a reference, I think your discriminator path is OK.

Chris Moesel (May 20 2020 at 17:45):

@Lloyd McKenzie -- is there a standard way to say that the first element in a list must be of a certain type or profile (for example some kind of "header" type)? We've established that you might be able to do this with an ordered slicing, but a FHIRPath constraint might be better. Are those the options? Is one preferable?

Lloyd McKenzie (May 20 2020 at 19:27):

There's a change request to allow slicing by position, but it's not applied yet. (And it would only be appropriate for arrays where the order has defined meaning in the core spec - e.g. HumanName.given)

Chris Moesel (May 20 2020 at 19:30):

So is there a recommendation for specifying the first item in a list using R4?

Lloyd McKenzie (May 20 2020 at 19:37):

Other than with an invariant, no.

Luke Duncan (Aug 07 2020 at 17:50):

I've run into a similar issue, but the main problem I'm having is more about getting an example to display in the order I'd like. No matter what I try it puts the MessageHeader in a bundle at the end.

This is how the profile is defined for Bundle.entry:

entry 2..2
entry ^slicing.discriminator.type = #type
entry ^slicing.discriminator.path = "resource"
entry ^slicing.rules = #closed
entry ^slicing.ordered = true
entry contains
PMIRMessageHeaderEntry 1..1 and
PMIRBundleHistoryEntry 1..1

And when I try to create an example using this, I put it in like this (there is more content, but just as an example)

entry[PMIRMessageHeaderEntry].fullUrl = "http://example.com/fhir/MessageHeader/1"
entry[PMIRBundleHistoryEntry].fullUrl = "http://example.come/fhir/Bundle/abc"

And the output always puts the MessageHeader last. I tried reversing the order, I tried changing the slice names so the Header came first alphabetically. It always puts the MessageHeader as the second entry in the Bundle. I understand the entry isn't really ordered, but it's odd that SUSHI puts the header last no matter what the input is.