FHIR Chat · validate slice where discriminator.type="type" · implementers

Stream: implementers

Topic: validate slice where discriminator.type="type"

Richard Ettema (Sep 25 2020 at 21:38):

I ran into an issue using the Java Validator with a profile on DocumentManifest that defines slicing on the content element where discriminator.type="type". One slice, "pReference", is defined on content that defines two (2) Reference types each with different targetProfile on DocumentReference.

<element id="DocumentManifest.content.p[x]:pReference">
  <path value="DocumentManifest.content.p[x]" />
  <sliceName value="pReference" />
  <type>
    <code value="Reference" />
    <targetProfile value="http://nictiz.nl/fhir/StructureDefinition/IHE.MHD.Minimal.DocumentReference" />
  </type>
  <type>
    <code value="Reference" />
    <targetProfile value="http://hl7.org/fhir/StructureDefinition/DocumentReference" />
  </type>
</element>

The Java Validator returns the following warning against this part of the profile:

WARNING: Discriminator ($this) is based on type, but slice DocumentManifest.content.p[x] does not declare a type.

Examination of the Java Validator source shows that the slice matching logic for discriminator equal to "type" is restricting the number of types in the slice element to one and only one. When this fails, the above generic warning is thrown.

In a discussion of this logic with @Ardon Toonstra from Firely, Ardon replied that the .NET Validator supports this scenario where the sliced element can have multiple types.

The FHIR specification Profiling page section on Slicing and the "type" discriminator does not seem to clearly define whether a single type or multiple types in the slice are allowed. Looking for guidance.

Ardon Toonstra (Sep 28 2020 at 07:34):

Thanks Richard. Perhaps good to mention that this concerns FHIR STU3.

Richard Ettema (Sep 28 2020 at 12:35):

Ardon, yes, thank you. Though the current Java validator code contains this logic so, the impact is for all official versions of FHIR - DSTU2, STU3, R4 and R5(CI).

Grahame Grieve (Sep 28 2020 at 22:57):

do you have a test case? This looks like one of those things where we just took a short cut

Richard Ettema (Sep 28 2020 at 23:09):

The example I describe is from the Nictiz MedMij profiles where they have incorporated the IHE MHD profiles. The specific profile is http://nictiz.nl/fhir/StructureDefinition/IHE.MHD.DocumentManifest and currently has this issue with multiple types in the slice element as described above.

Here's the test DocumentManifest resource to validate against the Nicitz MedMij profiles: pdfa-documentmanifest1.xml

I need to drop offline now for the day. I can work on this tomorrow if you need something else.

Grahame Grieve (Oct 08 2020 at 02:53):

@Richard Ettema I've had a look at this. I'm not sure I follow. I validated the instance you provided against the profile you provided:

*FAILURE*: 1 errors, 0 warnings, 0 notes
  Error @ DocumentManifest.type.coding[0] (line 68, col13) : Invalid System URI: http://loinc.org/

Then I replaced the content reference with an attachment:

*FAILURE*: 3 errors, 0 warnings, 0 notes
  Error @ DocumentManifest.type.coding[0] (line 68, col13) : Invalid System URI: http://loinc.org/
  Error @ DocumentManifest.content[0].p.ofType(Attachment) (line 85, col18) : This element does not match any known slice  defined in the profile http://nictiz.nl/fhir/StructureDefinition/IHE.MHD.DocumentManifest and slicing is CLOSED: DocumentManifest.content[0].p.ofType(Attachment): Does not match slice 'pReference'
  Error @ DocumentManifest.content[0] (line 84, col12) : Profile http://nictiz.nl/fhir/StructureDefinition/IHE.MHD.DocumentManifest, Element 'DocumentManifest.content[0].p[x][pReference]': minimum required = 1, but only found 0

Grahame Grieve (Oct 08 2020 at 02:53):

that looks like the right errors to me. So what's the problem?

Richard Ettema (Oct 12 2020 at 19:23):

@Grahame Grieve The validation warning message is from using an earlier version of the validator. I since confirmed the same results you are seeing with the latest validator.

However, that actually brings up a new question - why isn't the latest validator giving the expected warning message that the slice has multiple types?

I'm looking at the InstanceValidator class sliceMatches() method where I would expect the following else if clause to evaluate to true and produce that expected message:

else if (criteriaElement.getType().size() > 1)
  throw new DefinitionException(context.formatMessage(I18nConstants.DISCRIMINATOR__IS_BASED_ON_TYPE_BUT_SLICE__IN__HAS_MULTIPLE_TYPES_, discriminator, ed.getId(), profile.getUrl(), criteriaElement.typeSummary()));

Grahame Grieve (Oct 14 2020 at 00:38):

ah. because in my R5 internal form, the types are collapsed since there's only an actual single type

Last updated: Apr 12 2022 at 19:14 UTC