FHIR Chat · Type not shown in differential table · IG creation

Stream: IG creation

Topic: Type not shown in differential table

Richard Townley-O'Neill (Dec 10 2019 at 05:27):

I have a profile of Practitioner in which the differential table does not show the data types for the children of Practitioner.qualification.
This looks like an igPublisher problem
pasted image

Richard Townley-O'Neill (Dec 10 2019 at 05:28):

The structure definition is at https://github.com/AuDigitalHealth/ci-fhir-stu3/blob/master/output/SharedMedicinesList/StructureDefinition-practitioner-dh-base-1.xml
The display can be found in full-ig.zip at https://github.com/AuDigitalHealth/ci-fhir-stu3/blob/master/output/SharedMedicinesList/full-ig.zip

Richard Townley-O'Neill (Dec 10 2019 at 05:29):

@Grahame Grieve any ideas?

Grahame Grieve (Dec 10 2019 at 05:37):

I'll add it to my list

Richard Townley-O'Neill (Dec 10 2019 at 05:38):

The problem is also there in our R4 version of the profile.

Grahame Grieve (Dec 12 2019 at 01:31):

ok well, now it doesn't build:

Unable to generate snapshot for http://ns.electronichealth.net.au/ci/fhir/3.0/StructureDefinition/patient-dh-base-1 in C:\work\org.hl7.fhir.igs\ci-fhir-stu3\resources\patient-dh-base-1:
Unexpected condition in differential: type-slice.type-list.size() != 1 at Patient.deceased[x]/deceasedBoolean

Grahame Grieve (Dec 12 2019 at 01:31):

that's a new rule I added

Richard Townley-O'Neill (Dec 12 2019 at 04:27):

We want to make Patient.deceased mustSupport and have an extension on Patient.deceased[x]:deceasedDateTime. So we produced:

    <element id="Patient.deceased[x]">
      <path value="Patient.deceased[x]"/>
      <mustSupport value="true"/>
    </element>
    <element id="Patient.deceased[x]:deceasedBoolean">
      <path value="Patient.deceased[x]"/>
      <sliceName value="deceasedBoolean"/>
      <short value="Boolean indicates if individual is deceased"/>
      <mustSupport value="true"/>
    </element>
    <element id="Patient.deceased[x]:deceasedDateTime">
      <path value="Patient.deceased[x]"/>
      <sliceName value="deceasedDateTime"/>
      <short value="Indicates date-time the individual died"/>
      <mustSupport value="true"/>
    </element>
    <element id="Patient.deceased[x]:deceasedDateTime.extension:accuracyIndicator">
      <path value="Patient.deceased[x].extension"/>
      <sliceName value="accuracyIndicator"/>
      <mustSupport value="true"/>
    </element>

Richard Townley-O'Neill (Dec 12 2019 at 04:28):

Any ideas what is wrong? @Grahame Grieve

Richard Townley-O'Neill (Dec 13 2019 at 03:16):

It now builds OK with v19 of the publisher. :tada:

Richard Townley-O'Neill (Dec 13 2019 at 03:16):

But in the profiles of Practitioner the differential table still does not show the data types for the children of Practitioner.qualification.

Richard Townley-O'Neill (Dec 13 2019 at 03:17):

@Grahame Grieve

Grahame Grieve (Dec 13 2019 at 05:41):

so, looking at this. There's a problem:

Grahame Grieve (Dec 13 2019 at 05:41):

pasted image

Grahame Grieve (Dec 13 2019 at 05:42):

the problem is that you take a profile that has slicing (on Practitioner.qualification), and then ignore that and make all the elements of the underlying element must support.

Grahame Grieve (Dec 13 2019 at 05:43):

do you mean to make a rule on all the slices? because you probably did, but technically, that's multiple inheritance. And I'm pretty sure we said that doesn't happen

Grahame Grieve (Dec 13 2019 at 05:45):

yes; see: https://chat.fhir.org/#narrow/stream/179177-conformance/topic/More.20about.20Slicing/near/172028815

Lloyd McKenzie (Dec 13 2019 at 12:26):

It's not so much multiple inheritance as it is dual profiles. Elements must meet the profile of the base and the profile of the slices. You did indicate that the snapshot for the slices won't necessarily include everything from the base.

Richard Townley-O'Neill (Dec 16 2019 at 03:42):

the problem is that you take a profile that has slicing (on Practitioner.qualification), and then ignore that and make all the elements of the underlying element must support.
do you mean to make a rule on all the slices? because you probably did, but technically, that's multiple inheritance. And I'm pretty sure we said that doesn't happen

We want to say that you must support qualification and all of its children, whether they are part of a slice or not.

Grahame Grieve (Dec 16 2019 at 03:43):

then you have to iterate the slices in the diff

Richard Townley-O'Neill (Dec 16 2019 at 03:54):

If I put must support on elements in a slice, those elements display nicely. Yay!
If I put must support on elements in the base, those elements display without type.
If I do not put must support on elements in the base, there is no requirement to support uses of the element that do not meet the slice.

Richard Townley-O'Neill (Dec 16 2019 at 03:55):

So iterating the slices in the diff does not give us the constraints that we want.

Richard Townley-O'Neill (Dec 16 2019 at 04:23):

So slicing an element limits the use of must support, and other constraints, that apply to all iterations, even in iterations that do not match any of the defined slices.
Is this just a tooling issue, so that we can put must support on a sliced element with the only issue being how it is displayed? And possibly how validators react?
Is this a modelling issue, so that we are creating an ill defined resource when we put must support on a sliced element?

Grahame Grieve (Dec 16 2019 at 04:25):

well, first of all, must-support is not relevant for validators

Richard Townley-O'Neill (Dec 16 2019 at 04:26):

Of course!

Richard Townley-O'Neill (Dec 16 2019 at 04:26):

Is it just a display issue?

Grahame Grieve (Dec 16 2019 at 13:58):

well, it was a snapshot generation issue. A tough one, too. The issue was that the unslice constraints crossed a type boundary. It took me a long time to isolate that case from the others. Anyway, committed and released now

Richard Townley-O'Neill (Dec 17 2019 at 07:20):

Still not working with v 1.0.24-SNAPSHOT. :sad:

Last updated: Apr 12 2022 at 19:14 UTC