FHIR Chat · Nictiz profiles/extensions missing snapshot · implementers

Stream: implementers

Topic: Nictiz profiles/extensions missing snapshot

Anand Mohan Tumuluri (Jun 06 2019 at 20:42):

We are trying to add support for NL/Nictiz profiles/extensions and are unable to find/download the profiles/extensions with snapshot provided. If a profile doesn't have a snapshot filled, the validator(R4) gives a meaningful error message "StructureDefinition has no snapshot - validation is against the snapshot, so it must be provided". However, if the one of the extensions do not have a snapshot, it results in a IndexOutOfBoundException as the validator seems to be looking for the first element even if none exists. The problematic line is https://github.com/jamesagnew/hapi-fhir/blob/master/hapi-fhir-validation/src/main/java/org/hl7/fhir/r4/validation/InstanceValidator.java#L1157

Anand Mohan Tumuluri (Jun 06 2019 at 20:45):

Two questions
1. Can anyone help me find the Nictiz STU3 Zib2017 profiles with snapshot filled?
2. Can the above bug be fixed in the Validator?

Vadim Peretokin (Jun 06 2019 at 21:10):

It really is a bug in the validator that it's not generating the snapshot, but for now you can use Torinox to create them @Anand Mohan Tumuluri

Anand Mohan Tumuluri (Jun 07 2019 at 03:56):

I dont think the validator generates the snapshot as such. It relies on the snapshots to be already provided.

Anand Mohan Tumuluri (Jun 07 2019 at 03:59):

I am still googling for Nictiz profiles with snapshots but so far am unsuccessful. I know I can use the RI tooling to generate snapshots but isn't it the understanding that profiles should publish snapshot for them to be used in validation?

Anand Mohan Tumuluri (Jun 07 2019 at 04:02):

We are getting this issue very often because the current tooling (Simplifier et al) doesn't seem to publish profiles with snapshot.

Grahame Grieve (Jun 07 2019 at 04:41):

the validator does not rely on the snapshots to be generated as of 48 hours ago (thanks @Alexander Henket )

Anand Mohan Tumuluri (Jun 07 2019 at 04:57):

So there's no such understanding that snapshots are mandatory for validation and it is just a deficiency in the validator implementation?

Grahame Grieve (Jun 07 2019 at 04:59):

it was a bug - snapshots used to be generated and they are again now

Anand Mohan Tumuluri (Jun 07 2019 at 04:59):

Unfortunately I still have to wait for the next release of HAPI to get this change and I am not sure if this helps me at all.

Grahame Grieve (Jun 07 2019 at 05:01):

well, you should be using the R5 validator now, not the R4 one. The R4 one is no longer maintained. I need to get around to cleaning up the code so I can delete it.

Grahame Grieve (Jun 07 2019 at 05:01):

You'll have to ask on HAPI support when the next release is due

Anand Mohan Tumuluri (Jun 07 2019 at 05:02):

OK, I am sorry, my understanding of the profile publication process is very limited. Are you saying that the profiles would indeed be published with snapshots?

Grahame Grieve (Jun 07 2019 at 05:02):

or you can generate the snapshots yourself - it's pretty straight forward:

Grahame Grieve (Jun 07 2019 at 05:02):

  public void prepare() {
    for (StructureDefinition sd : context.allStructures()) {
      try {
        makeSnapshot(sd);
      } catch (Exception e) {
        System.out.println("Process Note: Unable to generate snapshot for "+sd.present());
      }
    }
  }

  private void makeSnapshot(StructureDefinition sd) throws DefinitionException, FHIRException {
    if (sd.hasSnapshot())
      return;
    StructureDefinition sdb = context.fetchResource(StructureDefinition.class, sd.getBaseDefinition());
    if (sdb != null) {
      makeSnapshot(sdb);
      new ProfileUtilities(context, null, null).generateSnapshot(sdb, sd, sd.getUrl(), null, sd.getName());
    }

  }

Grahame Grieve (Jun 07 2019 at 05:03):

the IG publisher always publishes snapshots as well. But it's not a requirement to do that. So add that code above somewhere in your loading code, and you should be right

Anand Mohan Tumuluri (Jun 07 2019 at 05:03):

Yes, I am aware of this like I mentioned. (ProfileUtilities/RI Tooling)

Anand Mohan Tumuluri (Jun 07 2019 at 05:04):

Thanks for your help. I will proceed this route. But IGs are not required to publish snapshots any more?

Grahame Grieve (Jun 07 2019 at 05:11):

since I don't think we ever required IGs to publish snap shots, I don't think you can say that we don't require it anymore. The IG Publisher will continue to publish them though - and I am pushing all the tool chains to end up in the IG publisher

Grahame Grieve (Jun 07 2019 at 05:11):

We may require that, yet

Lloyd McKenzie (Jun 07 2019 at 15:17):

IGs that meet HL7's quality criteria will have to have snapshots to render properly. And if they're producing the snapshots, I think it's reasonable to expect them to publish them. However, not all IGs will necessarily meet HL7's quality criteria

Anand Mohan Tumuluri (Jun 08 2019 at 00:02):

Even after generating snapshot, I see that some of the Nictiz profiles have issues with them. RI/HAPI's R4 validator gives the below errors
eOverdrachtTransferDate.json

{
    "resourceType": "OperationOutcome",
    "issue": [
        {
            "extension": [
                {
                    "url": "http://hl7.org/fhir/StructureDefinition/operationoutcome-issue-source",
                    "valueCode": "InstanceValidator"
                }
            ],
            "severity": "error",
            "code": "invariant",
            "details": {
                "text": "Constraints must be unique by key [constraint.select(key).isDistinct()]"
            },
            "location": [
                "StructureDefinition.snapshot.element[1] (line 1, col 996)"
            ]
        }
    ]
}

eAfspraakAppointmentOnlineEditable.json, ZIB-Deviating-Administration.json, MedicationOverview-Verification.json

{
    "resourceType": "OperationOutcome",
    "issue": [
        {
            "extension": [
                {
                    "url": "http://hl7.org/fhir/StructureDefinition/operationoutcome-issue-source",
                    "valueCode": "InstanceValidator"
                }
            ],
            "severity": "error",
            "code": "invariant",
            "details": {
                "text": "No slicing on the root element [element.first().slicing.empty()]"
            },
            "location": [
                "StructureDefinition.differential"
            ]
        }
    ]
}

I got the second error on Grahame Grieve's server at http://test.fhir.org/r3 but not the first

Anand Mohan Tumuluri (Jun 08 2019 at 00:03):

Any body from HL7 NL/Nictiz in this forum?

Anand Mohan Tumuluri (Jun 08 2019 at 00:06):

The first error is due to the derived extension (re)defining the ext-1 constraint that is already declared in base. The second error is due to not having the root element Extension in the differential and starting with Extension.extension and slicing it.

Grahame Grieve (Jun 08 2019 at 02:41):

@Alexander Henket on the first error. The validator in test.fhir.org/r3 is running behind, and is not reliable

Alexander Henket (Jun 08 2019 at 11:41):

Hi all: we are waiting for Simplifier to produce snapshots in the package upon producing a package. We really don't want them in our master definitions. Because we ourselves also need the snapshots for Touchstone, we have decided to produce them separately in GitHub: https://github.com/Nictiz/Nictiz-STU3-Zib2017/releases. @Anand Mohan Tumuluri

Alexander Henket (Jun 08 2019 at 11:43):

Sorry for coming late to the thread with this info. It is still a good thing for the validator to handle the snapshots. Thanks for that @Grahame Grieve

Alexander Henket (Jun 08 2019 at 11:46):

on the first error. The validator in test.fhir.org/r3 is running behind, and is not reliable

Not sure if that affects us, but it might affect our implementers.

Anand Mohan Tumuluri (Jun 10 2019 at 22:09):

Thanks a lot @Alexander Henket

Anand Mohan Tumuluri (Jun 11 2019 at 01:26):

RI/HAPI validation issues with the snapshots
StructureDefinition - 400 zib-Infusion-Product.json
StructureDefinition.snapshot.element[27].example.valueUri - URI values cannot have whitespace

StructureDefinition - 400 images-List.json
StructureDefinition.snapshot.element[20].example.valueUri - URI values cannot have whitespace

StructureDefinition - 400 zib-FeedingTubeSystem-Product.json
StructureDefinition.snapshot.element[27].example.valueUri - URI values cannot have whitespace

StructureDefinition - 400 nl-core-person.json
StructureDefinition.snapshot.element[16].example.valueUri - URI values cannot have whitespace
StructureDefinition.differential - No slicing on the root element [element.first().slicing.empty()
{"resourceType":"OperationOutcome","issue":[{"extension":[{"url":"http://hl7.org/fhir/StructureDefinition/operationoutcome-issue-source","valueCode":"InstanceValidator"}],"severity":"error","code":"structure","details":{"text":"URI values cannot have whitespace"},"location":["StructureDefinition.snapshot.element[16].example.valueUri (line 1, col 20183)"]},{"extension":[{"url":"http://hl7.org/fhir/StructureDefinition/operationoutcome-issue-source","valueCode":"InstanceValidator"}],"severity":"error","code":"invariant","details":{"text":"No slicing on the root element [element.first().slicing.empty()]"},"location":["StructureDefinition.differential"]}]}

StructureDefinition - 400 mp612-DispenseToFHIRConversion-Organization.json
StructureDefinition.snapshot.element[16].example.valueUri - URI values cannot have whitespace
StructureDefinition.snapshot.element[25].example.valueUri - URI values cannot have whitespace
StructureDefinition.snapshot.element[34].example.valueUri - URI values cannot have whitespace

StructureDefinition - 400 gp-DiagnosticResult.json
{"resourceType":"OperationOutcome","issue":[{"extension":[{"url":"http://hl7.org/fhir/StructureDefinition/operationoutcome-issue-source","valueCode":"InstanceValidator"}],"severity":"error","code":"invariant","details":{"text":"No slicing on the root element [element.first().slicing.empty()]"},"location":["StructureDefinition.differential"]}]}

StructureDefinition - 400 images-Media.json
StructureDefinition.snapshot.element[23].example.valueUri - URI values cannot have whitespace

StructureDefinition - 400 zib-VaccinationRecommendation.json
{"resourceType":"OperationOutcome","issue":[{"extension":[{"url":"http://hl7.org/fhir/StructureDefinition/operationoutcome-issue-source","valueCode":"InstanceValidator"}],"severity":"error","code":"invariant","details":{"text":"provide either a reference or a description (or both) [valueSet.exists() or description.exists()]"},"location":["StructureDefinition.differential.element[4].binding"]}]}

StructureDefinition - 400 nl-core-practitioner.json
StructureDefinition.snapshot.element[16].example.valueUri - URI values cannot have whitespace
StructureDefinition.snapshot.element[25].example.valueUri - URI values cannot have whitespace
StructureDefinition.snapshot.element[34].example.valueUri - URI values cannot have whitespace

StructureDefinition - 400 zib-MedicalDeviceProduct.json
StructureDefinition.snapshot.element[27].example.valueUri - URI values cannot have whitespace

StructureDefinition - 400 nl-core-organization.json
StructureDefinition.snapshot.element[16].example.valueUri - URI values cannot have whitespace
StructureDefinition.snapshot.element[25].example.valueUri - URI values cannot have whitespace
StructureDefinition.snapshot.element[34].example.valueUri - URI values cannot have whitespace

StructureDefinition - 400 zib-AdministrationAgreement.json
{"resourceType":"OperationOutcome","issue":[{"extension":[{"url":"http://hl7.org/fhir/StructureDefinition/operationoutcome-issue-source","valueCode":"InstanceValidator"}],"severity":"error","code":"invariant","details":{"text":"provide either a reference or a description (or both) [valueSet.exists() or description.exists()]"},"location":["StructureDefinition.differential.element[13].binding"]}]}

StructureDefinition - 400 gp-LaboratoryResult.json
{"resourceType":"OperationOutcome","issue":[{"extension":[{"url":"http://hl7.org/fhir/StructureDefinition/operationoutcome-issue-source","valueCode":"InstanceValidator"}],"severity":"error","code":"invariant","details":{"text":"No slicing on the root element [element.first().slicing.empty()]"},"location":["StructureDefinition.differential"]}]}

StructureDefinition - 400 zib-Infusion.json
{"resourceType":"OperationOutcome","issue":[{"extension":[{"url":"http://hl7.org/fhir/StructureDefinition/operationoutcome-issue-source","valueCode":"InstanceValidator"}],"severity":"error","code":"invariant","details":{"text":"provide either a reference or a description (or both) [valueSet.exists() or description.exists()]"},"location":["StructureDefinition.differential.element[5].binding"]},{"extension":[{"url":"http://hl7.org/fhir/StructureDefinition/operationoutcome-issue-source","valueCode":"InstanceValidator"}],"severity":"error","code":"invariant","details":{"text":"provide either a reference or a description (or both) [valueSet.exists() or description.exists()]"},"location":["StructureDefinition.differential.element[7].binding"]}]}

StructureDefinition - 400 MedicationOverview.json
{"resourceType":"OperationOutcome","issue":[{"extension":[{"url":"http://hl7.org/fhir/StructureDefinition/operationoutcome-issue-source","valueCode":"InstanceValidator"}],"severity":"error","code":"invariant","details":{"text":"No slicing on the root element [element.first().slicing.empty()]"},"location":["StructureDefinition.differential"]}]}

StructureDefinition - 400 zib-DrugUse.json
{"resourceType":"OperationOutcome","issue":[{"extension":[{"url":"http://hl7.org/fhir/StructureDefinition/operationoutcome-issue-source","valueCode":"InstanceValidator"}],"severity":"error","code":"code-invalid","details":{"text":"Coding.system must be an absolute reference, not a local reference"},"location":["StructureDefinition.snapshot.element[111].example.valueCodeableConcept.coding (line 1, col 159521)"]},{"extension":[{"url":"http://hl7.org/fhir/StructureDefinition/operationoutcome-issue-source","valueCode":"InstanceValidator"}],"severity":"error","code":"code-invalid","details":{"text":"Coding.system must be an absolute reference, not a local reference"},"location":["StructureDefinition.differential.element[27].example.valueCodeableConcept.coding (line 1, col 159521)"]}]}

StructureDefinition - 400 zib-Infusion-AdministeringSystem.json
StructureDefinition.snapshot.element[28].example.valueUri - URI values cannot have whitespace

StructureDefinition - 400 mp612-DispenseToFHIRConversion-AdministrationAgreement.json
StructureDefinition.snapshot.element[27].example.valueUri - URI values cannot have whitespace

StructureDefinition - 400 mp612-DispenseToFHIRConversion-Dispense.json
StructureDefinition.snapshot.element[29].example.valueUri - URI values cannot have whitespace
StructureDefinition.snapshot.element[39].example.valueUri - URI values cannot have whitespace

StructureDefinition - 400 zib-FreedomRestrictingMeasures.json
{"resourceType":"OperationOutcome","issue":[{"extension":[{"url":"http://hl7.org/fhir/StructureDefinition/operationoutcome-issue-source","valueCode":"InstanceValidator"}],"severity":"error","code":"invariant","details":{"text":"provide either a reference or a description (or both) [valueSet.exists() or description.exists()]"},"location":["StructureDefinition.differential.element[4].binding"]}]}

StructureDefinition - 400 zib-MedicationAdministration.json
StructureDefinition.snapshot.element[28].example.valueUri - URI values cannot have whitespace

StructureDefinition - 400 zib-TobaccoUse.json
{"resourceType":"OperationOutcome","issue":[{"extension":[{"url":"http://hl7.org/fhir/StructureDefinition/operationoutcome-issue-source","valueCode":"InstanceValidator"}],"severity":"error","code":"structure","details":{"text":"if a date has a time, it must have a timezone"},"location":["StructureDefinition.snapshot.element[33].example.valueDateTime (line 1, col 159553)"]},{"extension":[{"url":"http://hl7.org/fhir/StructureDefinition/operationoutcome-issue-source","valueCode":"InstanceValidator"}],"severity":"error","code":"structure","details":{"text":"if a date has a time, it must have a timezone"},"location":["StructureDefinition.differential.element[11].example.valueDateTime (line 1, col 159553)"]}]}

StructureDefinition - 400 zib-MedicationAgreement.json
{"resourceType":"OperationOutcome","issue":[{"extension":[{"url":"http://hl7.org/fhir/StructureDefinition/operationoutcome-issue-source","valueCode":"InstanceValidator"}],"severity":"error","code":"structure","details":{"text":"URI values cannot have whitespace"},"location":["StructureDefinition.snapshot.element[72].example.valueCodeableConcept.coding.system (line 1, col 176179)"]},{"extension":[{"url":"http://hl7.org/fhir/StructureDefinition/operationoutcome-issue-source","valueCode":"InstanceValidator"}],"severity":"error","code":"invariant","details":{"text":"provide either a reference or a description (or both) [valueSet.exists() or description.exists()]"},"location":["StructureDefinition.differential.element[12].binding"]},{"extension":[{"url":"http://hl7.org/fhir/StructureDefinition/operationoutcome-issue-source","valueCode":"InstanceValidator"}],"severity":"error","code":"structure","details":{"text":"URI values cannot have whitespace"},"location":["StructureDefinition.differential.element[38].example.valueCodeableConcept.coding.system (line 1, col 176179)"]}]}

StructureDefinition - 400 zib-MedicationUse.json
{"resourceType":"OperationOutcome","issue":[{"extension":[{"url":"http://hl7.org/fhir/StructureDefinition/operationoutcome-issue-source","valueCode":"InstanceValidator"}],"severity":"error","code":"invariant","details":{"text":"provide either a reference or a description (or both) [valueSet.exists() or description.exists()]"},"location":["StructureDefinition.differential.element[10]

Anand Mohan Tumuluri (Jun 15 2019 at 01:17):

@Alexander Henket can you please let me know if I should post these issues somewhere? Is there a tracker for Nictiz?

Alexander Henket (Jun 18 2019 at 12:56):

@Anand Mohan Tumuluri : bugs for this should be reported through https://bits.nictiz.nl/browse/MM. Login not required, all bugs are public

Alexander Henket (Jun 18 2019 at 13:10):

I see a lot of errors are about a white in a URI. Example fragment of where that goes sour:

<example>
  <label value="General" />
  <valueUri value="http://www.acme.com/identifiers/patient or urn:ietf:rfc:3986 if the Identifier.value itself is a full uri" />
</example>

I've tracked back to where that comes from, and the source is in the dependency we have on the FHIR Core Datatypes as expressed in Simplifier here: https://simplifier.net/Simplifier.Core.Stu3.DataTypes/Identifier/~xml

@Martijn Harthoorn / @Michel Rutten : Could one of you comment here?

Alexander Henket (Jun 18 2019 at 13:12):

This 'error' is a bug in HAPI/the fhirPath expression:

StructureDefinition - 400 nl-core-person.json
StructureDefinition.differential - No slicing on the root element [element.first().slicing.empty()

The fragment it considers is this:

  <differential>
    <element id="Person.identifier">
      <path value="Person.identifier" />
      <slicing>
        <discriminator>
          <type value="value" />
          <path value="system" />
        </discriminator>
        <rules value="open" />
      </slicing>

As you can see, there is slicing on the first element in the differential, but that element is not the root element of the resource. Hence the check does not apply. The same is true for every other occurrence of this error. We never sliced the root element in the differential. Forge will always remove elements from the differential that do not have any change in them. Hence, unless we 'fake' a change in the resource root element, it will not be present in the differential.

Alexander Henket (Jun 18 2019 at 13:21):

This is another bug in the HAPI validator:

StructureDefinition - 400 zib-AdministrationAgreement.json
"provide either a reference or a description (or both) [valueSet.exists() or description.exists()]"

The fragment is:

<binding>
  <strength value="required" />
</binding>

What this does is make the binding strength required while the full valueset binding/description lives in the extension in this path. While you 'could' restate valueSet+description this is just error prone. As far ass I know the validator check that trigger this false negative has been updated to only work on bindings in the snapshot where everything is expected to be completed (which it is).

Alexander Henket (Jun 18 2019 at 13:26):

I believe these three types of errors are the only ones listed. Of those there isn't anything we can do right now as we depend on an updated datatype package in Simplifier, and on relaxed validation in HAPI, as far as I can tell. I'm not sure how to request an update for HAPI, but I believe @Grahame Grieve co maintains the underlying logic?

Michel Rutten (Jun 18 2019 at 14:18):

@Alexander Henket concerning the first issue, looks like an error in the official STU3 core definition of Identifier datatype (in profiles-types), seems fixed in R4.

[STU3] profiles-types.xml:

<element id="Identifier.system">
  <!-- ... -->
  <example>
    <label value="General" />
    <valueUri value="http://www.acme.com/identifiers/patient or urn:ietf:rfc:3986 if the Identifier.value itself is a full uri" />
  </example>

[R4] profiles-types.xml:

<element id="Identifier.system">
  <!-- ... -->
  <example>
    <label value="General"/>
    <valueUri value="http://www.acme.com/identifiers/patient"/>
  </example>

Note that the STU3 definition specifies an invalid example uri value.

Michel Rutten (Jun 18 2019 at 14:23):

Spurious warnings about invalid slice names on the root element have been reported for a while, this is a known bug in the Java validator. Invariant sdf-20 disallows slice names on the root element; however the first element included in the differential component may (and often will) not be the root element.

Grahame Grieve (Jun 18 2019 at 17:58):

these all look like issues in the invariants - please create tasks for when we release a patch on R3 in about 6 weeks time

Alexander Henket (Jun 18 2019 at 23:04):

sdf-20 seems sufficiently covered for STU3: GF#20391, GF#20339, GF#13768

eld-10 is was fixed through GF#13782 in R4 -- I added GF#22712 to flag it for STU3

the illegal datatype example is discussed here: GF#17431 -- I added GF#22711 to flag it for STU3

Let me know if you need anything else @Grahame Grieve

Alexander Henket (Jun 18 2019 at 23:11):

@Michel Rutten : Thanks. As long as the illegal example is in the Simplifier core datatype package, it would seem impossible to produce valid snapshots as identifier.system is in any snapshot. We could wait for the official patch on STU3 to be released, update Simplifier and then update our dependency, and in the mean try hold off publications on our side. Alternatively we could patch all snapshots after creating them. The other option is an update in the identifier.system example in advance of the official STU3 patch.
What would you advise?

Anand Mohan Tumuluri (Jun 19 2019 at 20:36):

We ignored validation of the profiles for now and moved on to validating the published example resources against these profiles. For Appointment examples, the errors we get are (other than trivial processing instruction and xsi:schemaLocation errors):

• Could not match discriminator (coding.system) for slice Appointment.specialty:specialtyAGB in profile http://nictiz.nl/fhir/StructureDefinition/eAfspraak-Appointment - does not have fixed value, binding or existence assertions
• Could not match discriminator (coding.system) for slice Appointment.specialty:specialtyUZI in profile http://nictiz.nl/fhir/StructureDefinition/eAfspraak-Appointment - does not have fixed value, binding or existence assertions

Michel Rutten (Jun 20 2019 at 10:10):

@Alexander Henket, not sure if this works for you, but since this is caused by an issue in the spec and is therefore out of your control, I'd propose to ignore the invalid uri validation error for now (i.e. consider this a "known issue"), until HL7 has published a technical correction.
However if that causes confusion and you really need to suppress the validation error, then I suggest to (temporarily) override the invalid uri example values in the diff of all the consuming profiles.

Alexander Henket (Jun 20 2019 at 13:48):

@Michel Rutten Thanks. We would not notice this as we do not check the snapshots through HAPI. We load them in Touchstone. It they work there, we assume they are valid. Touchstone uses the validator (STU3).

In a sense it is a good thing that Simplifier cannot produce snapshots yet. We produce those separate from the package, so we can also post-process them and just kick out the problematic examples before uploading to github

Alexander Henket (Jun 20 2019 at 14:00):

@Anand Mohan Tumuluri I honestly do not know what that error means. Appointment.specialty has two slices defined. Each carries an extensible binding to a ValueSet. The ValueSets have different systems they bind to.

I cannot reproduce what you saw when I validate the examples on Simplifier (other things, but not that)

Anand Mohan Tumuluri (Oct 01 2019 at 23:25):

Sorry for restarting this old thread. We had tried to validate profiles and valuesets from Nictiz 1.2.0 release ignoring some of the validation errors from above. Now only 2 issues remain w.r.t. profiles
zib-TobaccoUse.xml: The example dateTime value does not have a timezone as per the spec.

{
  "resourceType": "OperationOutcome",
  "issue": [
    {
      "extension": [
        {
          "url": "http://hl7.org/fhir/StructureDefinition/operationoutcome-issue-source",
          "valueCode": "InstanceValidator"
        }
      ],
      "severity": "error",
      "code": "invalid",
      "details": {
        "text": "if a date has a time, it must have a timezone"
      },
      "location": [
        "StructureDefinition.snapshot.element[33].example.valueDateTime (line 1, col 52887)"
      ]
    },
    {
      "extension": [
        {
          "url": "http://hl7.org/fhir/StructureDefinition/operationoutcome-issue-source",
          "valueCode": "InstanceValidator"
        }
      ],
      "severity": "error",
      "code": "invalid",
      "details": {
        "text": "if a date has a time, it must have a timezone"
      },
      "location": [
        "StructureDefinition.differential.element[11].example.valueDateTime (line 1, col 222920)"
      ]
    }
  ]
}

zib-DrugUse.xml: The example coding for Observation.component:RouteOfAdministration.value[x]:valueCodeableConcept uses a OID without specifying it as urn:oid:

<system value="2.16.840.1.113883.2.4.4.9" />

{
  "resourceType": "OperationOutcome",
  "issue": [
    {
      "extension": [
        {
          "url": "http://hl7.org/fhir/StructureDefinition/operationoutcome-issue-source",
          "valueCode": "InstanceValidator"
        }
      ],
      "severity": "error",
      "code": "code-invalid",
      "details": {
        "text": "Coding.system must be an absolute reference, not a local reference"
      },
      "location": [
        "StructureDefinition.snapshot.element[111].example.valueCodeableConcept.coding (line 1, col 172501)"
      ]
    },
    {
      "extension": [
        {
          "url": "http://hl7.org/fhir/StructureDefinition/operationoutcome-issue-source",
          "valueCode": "InstanceValidator"
        }
      ],
      "severity": "error",
      "code": "code-invalid",
      "details": {
        "text": "Coding.system must be an absolute reference, not a local reference"
      },
      "location": [
        "StructureDefinition.differential.element[27].example.valueCodeableConcept.coding (line 1, col 224000)"
      ]
    }
  ]
}

Anand Mohan Tumuluri (Oct 01 2019 at 23:27):

Next, coming to ValueSets, there is one error in RedenWijzigenStakenMedicatiegebruikCodelijst-2.16.840.1.113883.2.4.3.11.60.20.77.11.37--20181218104254.xml with url http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.20.77.11.37--20181218104254
The error is with display having a whitespace at the start as shown below

<include>
            <system value="urn:oid:2.16.840.1.113883.2.4.3.11.60.20.77.5.2.2"/>
            <concept>
                <code value="16"/>
                <display value=" Allergie of non-allergische overgevoeligheid of bijwerking"/>
            </concept>

{
  "resourceType": "OperationOutcome",
  "issue": [
    {
      "extension": [
        {
          "url": "http://hl7.org/fhir/StructureDefinition/operationoutcome-issue-source",
          "valueCode": "InstanceValidator"
        }
      ],
      "severity": "warning",
      "code": "invalid",
      "details": {
        "text": "value should not start or finish with whitespace"
      },
      "location": [
        "ValueSet.compose.include[3].concept[1].display (line 1, col 3553)"
      ]
    }
  ]
}

Anand Mohan Tumuluri (Oct 01 2019 at 23:30):

Also, there seem to be atleast 11 ValueSets which include the whole of SNOMED-CT without any filter as below

<compose>
        <include>
            <system value="http://snomed.info/sct"/>
        </include>
    </compose>

Since we pre-compute the expansions at the time of writing of ValueSet, this causes enormous delays in importing these ValueSets.

Anand Mohan Tumuluri (Oct 02 2019 at 00:00):

@Alexander Henket

Grahame Grieve (Oct 02 2019 at 00:08):

Since we pre-compute the expansions at the time of writing of ValueSet

You can't do that

Anand Mohan Tumuluri (Oct 02 2019 at 00:51):

Well, if we dont pre-compute, then testing for ValueSet membership during resource validation would be very costly right? We were OK with pre-computing during ValueSet Create/Update for base and US Core. If I remember correctly, other than encounter-reason and body-site, the other valuesets are not big.

Grahame Grieve (Oct 02 2019 at 01:53):

that was just chance. The $validate-code operation is what the validator uses, so that you don't have to pre-compute expansions

Anand Mohan Tumuluri (Oct 02 2019 at 04:19):

Yes, we implemented $validate-code based on the expansions. Otherwise, we would have had to expand the ValueSet at the $validate-code invocation which would be very costly.

Anand Mohan Tumuluri (Oct 02 2019 at 04:24):

Of course, we could have avoided duplicating whole code systems like SNOMED-CT as part of expansion, but I am wondering about the reason having many ValueSets including/importing whole of SNOMED-CT.

Grahame Grieve (Oct 02 2019 at 04:42):

because any SNOMED code is valid

Anand Mohan Tumuluri (Oct 02 2019 at 05:51):

Isn't that possible/preferable using ValueSet.compose.include.valueSet either using the implicit SNOMED ValueSet uri or using an explicitly defined ValueSet? Is there any advantage to have many ValueSets independently including from SNOMED? Sorry for the newbie questions, just trying to understand better.

Anand Mohan Tumuluri (Oct 02 2019 at 05:52):

But anyway, this is not breaking us currently, just some multi second delay to load the ValueSet. I really appreciate if anyone can answer regarding the other issues above

Anand Mohan Tumuluri (Oct 02 2019 at 05:55):

Also, while validating the Nictiz published resource examples against the profiles, the major cause of errors seems to be with slicing like below:

Anand Mohan Tumuluri (Oct 02 2019 at 05:55):

Could not match discriminator (coding.system) for slice Appointment.specialty:specialtyAGB in profile http://nictiz.nl/fhir/StructureDefinition/eAfspraak-Appointment - does not have fixed value, binding or existence assertions

Anand Mohan Tumuluri (Oct 02 2019 at 05:57):

That accounts for nearly 70% of validation errors from RI/HAPI.

Grahame Grieve (Oct 02 2019 at 06:21):

Is there any advantage to have many ValueSets independently including from SNOMED

No, there isn't.

Grahame Grieve (Oct 02 2019 at 06:21):

but quite a few systems can't cope with the implicit value sets for SNOMED CT

Alexander Henket (Oct 02 2019 at 08:18):

Next, coming to ValueSets, there is one error in RedenWijzigenStakenMedicatiegebruikCodelijst-2.16.840.1.113883.2.4.3.11.60.20.77.11.37--20181218104254.xml <snip> The error is with display having a whitespace at the start as shown below

The ValueSets you see are created as exports from non FHIR CodeSystems/ValueSets. I think it is principally wrong in FHIR to have an invariant that effectively limits what a valid display name for a given code in a code system can be. It is just not for FHIR to decide. That invariant imho has to go away. That being said: in this particular case we can influence the master definition and so I have. We have just released an update to the package 1.2.0 yesterday. The next one is planned for end of October.

Note: I have not been able to find any invariant in the spec that governs the error from the validator (http://hl7.org/fhir/STU3/valueset.html) so it might be that the error lives in the validator only.

I've logged: https://bits.nictiz.nl/browse/MM-593

Grahame Grieve (Oct 02 2019 at 08:37):

actually the issue is in the terminology server. I've fixed it but not deployed it.

Grahame Grieve (Oct 02 2019 at 08:38):

The invariant simply says that a display can't have leading or trailing whitespace, and that's anchored in XML rules. You can't really claim that the whitespace is meaningful?

Alexander Henket (Oct 02 2019 at 08:41):

can you please let me know if I should post these issues somewhere? Is there a tracker for Nictiz?

As replied here before: bugs for this should be reported through https://bits.nictiz.nl/browse/MM. Login not required, all issues are public

Alexander Henket (Oct 02 2019 at 08:45):

The invariant simply says that a display can't have leading or trailing whitespace, and that's anchored in XML rules. You can't really claim that the whitespace is meaningful?

I cannot and I am not. I'm just saying the the terminologists do what they do in creating the display names. I just apply a FHIR 'jacket' or syntax to it. FHIR should not judge the whitespace on display names: they are outside of FHIRs span of control.

That being said: in this very case I am able to talk to the creators directly and have already convinced them to drop the leading whitespace even though the definition was already final and published in many other forms than just for FHIR. So: this problem will be solved, but the bigger picture still remains.

Alexander Henket (Oct 02 2019 at 08:55):

Also, there seem to be at least 11 ValueSets which include the whole of SNOMED-CT without any filter as below <snip> Since we pre-compute the expansions at the time of writing of ValueSet, this causes enormous delays in importing these ValueSets.

I understand it may be cumbersome to deal with that, but there simply is no reuse of value sets by the underlying zibs by design. Whenever there is a need for a value set, the definition is crafted for that specific purpose. The decision making process at the ZIB Centrum in crafting terminology for the zibs has decided that reuse of value sets is not semantically possible because each context is unique. The advantage is that maintenance on any given value set created this way can be done with only 1 context in mind.

I may or may not agree with you that a value set that lists SNOMED CT without any restriction is not a very useful or even perhaps semantically sound statement in a given context, but discussing changes can only be done through the ZIB Centrum that governs the zib contents that the FHIR IGs depend on. You may find the ZIB Centrum information here https://www.nictiz.nl/standaardisatie/zib-centrum/

Alexander Henket (Oct 02 2019 at 09:01):

We had tried to validate profiles and valuesets from Nictiz 1.2.0 release ignoring some of the validation errors from above. Now only 2 issues remain w.r.t. profiles zib-TobaccoUse.xml: The example dateTime value does not have a timezone as per the spec.

Maybe I misread the spec, but I don't see that requirement for dateTime. Only for instant. I have also validated the example manually against the regex pattern in the spec and found it matched. Why would you say it is not?

matches('2012-02-28T00:00:00', '-?[0-9]{4}(-(0[1-9]|1[0-2])(-(0[0-9]|[1-2][0-9]|3[0-1])(T([01][0-9]|2[0-3]):[0-5][0-9]:[0-5]0-9?(Z|(\+|-)((0[0-9]|1[0-3]):[0-5][0-9]|14:00)))?)?)?')

Grahame Grieve (Oct 02 2019 at 09:46):

"If hours and minutes are specified, a time zone SHALL be populated"

Alexander Henket (Oct 02 2019 at 12:50):

Right, that is true. I've read right past that. @Anand Mohan Tumuluri I've flagged this for update in the next update cycle here: https://bits.nictiz.nl/browse/MM-594

Anand Mohan Tumuluri (Oct 02 2019 at 19:01):

Could not match discriminator (coding.system) for slice Appointment.specialty:specialtyAGB in profile http://nictiz.nl/fhir/StructureDefinition/eAfspraak-Appointment - does not have fixed value, binding or existence assertions

I dont see any ElementDefinition for the element corresponding to the discriminator coding.system with type as value. I think this is a common problem across many Nictiz profiles. I will open a tracker item for this.

Anand Mohan Tumuluri (Oct 02 2019 at 19:44):

Posted https://bits.nictiz.nl/browse/MM-597 for the issue with zib-DrugUse.xml using a OID without urn:oid

Anand Mohan Tumuluri (Oct 02 2019 at 20:24):

Each slice must use the element definition for the element in the discriminator(s) to ensure that the slices are clearly differentiated (by assigning a fixed value, a specific type, or a profile, depending on the discriminator type. If the type is 'value', then the element definition must use either ElementDefinition.fixed[x] or, if the element has a terminology binding, a required binding with a Value Set that enumerates the list of possible codes in the value set ("extensional definition").

Is my understanding right that the profile should have the ElementDefinition for the element corresponding to the path given in discriminator?

Anand Mohan Tumuluri (Oct 02 2019 at 21:23):

Posted https://bits.nictiz.nl/browse/MM-598 for the issue Could not match discriminator ... for slice ... in profile ... - does not have fixed value, binding or existence assertions

Alexander Henket (Oct 03 2019 at 00:09):

@Grahame Grieve We slice by value set in a number of cases. Each value set carries codes from a different system, so we define our discriminator based on value of system. Apparently HAPI has beef with that. We have not heard complaints from other systems thus far.

• Is what we do allowable? I believe so, but just checking
• Is there a better way?
• Would having required bindings rather than extensible help here?

Example:

    <element id="PractitionerRole.specialty.coding">
      <path value="PractitionerRole.specialty.coding" />
      <slicing>
        <discriminator>
          <type value="value" />
          <path value="system" />
        </discriminator>
        <rules value="open" />
      </slicing>
    </element>
    <element id="PractitionerRole.specialty.coding:SpecialtyUZI">
      <path value="PractitionerRole.specialty.coding" />
      <sliceName value="SpecialtyUZI" />
        <strength value="extensible" />
        <valueSetReference>
          <reference value="http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.40.2.17.1.6--20171231000000" />
          <display value="SpecialismeUZICodelijst" />
        </valueSetReference>
      </binding>
    </element>
    <element id="PractitionerRole.specialty.coding:SpecialtyAGB">
      <path value="PractitionerRole.specialty.coding" />
      <sliceName value="SpecialtyAGB" />
        <strength value="extensible" />
        <valueSetReference>
          <reference value="http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.40.2.17.1.7--20171231000000" />
          <display value="SpecialismeAGBCodelijst" />
        </valueSetReference>
      </binding>
    </element>

Alexander Henket (Oct 03 2019 at 00:21):

Posted https://bits.nictiz.nl/browse/MM-597 for the issue with zib-DrugUse.xml using a OID without urn:oid

@Anand Mohan Tumuluri MM-597 Fixed and marked for next update

Alexander Henket (Oct 03 2019 at 00:33):

@Anand Mohan Tumuluri MM-598 updated

Grahame Grieve (Oct 03 2019 at 05:52):

looks like you forgot <binding> in your copy. But it's possible that the validator is not handling this right - can you give me an instance and a profile as a test case so I can investigate?

Alexander Henket (Oct 03 2019 at 07:44):

@Grahame Grieve O dear, in creating a somewhat condensed view I deleted too much I see. The original is on GitHub and there you may also find an example. Alternatively you could work with the current package as a whole from Simplifier

Grahame Grieve (Oct 03 2019 at 08:13):

where can I find the definition for the code system urn:oid:2.16.840.1.113883.2.4.6.7?

Grahame Grieve (Oct 03 2019 at 08:14):

same for http://fhir.nl/fhir/NamingSystem/uzi-rolcode

Alexander Henket (Oct 03 2019 at 15:13):

@Grahame Grieve There is no FHIR expression for many of our CodeSystems. For OIDs we have the OID Registry which allows for export of NamingSystems.

• http://decor.nictiz.nl/fhir/3.0/hl7nl/NamingSystem/2.16.840.1.113883.2.4.6.7 (Vektis Zorgverlenersspecificatie)
  ** Codes maintained in a non-FHIR-aware online system by some government body. Systems can subscribe themselves to updates in a non-FHIR way or download Excel files from the website when they see fit.

• http://decor.nictiz.nl/fhir/3.0/hl7nl/NamingSystem/?value=http://fhir.nl/fhir/NamingSystem/uzi-rolcode&id-type=uri or

• http://decor.nictiz.nl/fhir/3.0/hl7nl/NamingSystem/2.16.840.1.113883.2.4.15.111 (uzi-rolcode)
  ** Codes maintained in a Certificate Practice Statement document in PDF based on national law by some government body. Periodically copied manually into a DECOR ValueSet and exported from there.

But those CodeSystem contents are not relevant for the slice determination based on system are they? Not having access to code systems contents, only affects what FHIR validation you could perform on the code.

Grahame Grieve (Oct 03 2019 at 19:48):

the validator is not smart enough at this time to see that:

• you have fixed the value of system
• you have bound the slices of Coding to a value set
• the value set specifies a fixed system
• it can therefore figure out the slicing.

It says "you fixed the system. I'm looking for a fixed value for system". So then you get ```Could not match discriminator ... for slice ... in profile ... - does not have fixed value, binding or existence assertions````

Grahame Grieve (Oct 03 2019 at 19:48):

and nor is it smart enough to figure that out without access to the code system definition either.

Grahame Grieve (Oct 03 2019 at 19:49):

(since it would use the terminology server for that, and it will say, can't access the code system to know what is going on)

Grahame Grieve (Oct 03 2019 at 19:50):

And I think that what you are doing isn't conformant:

Each slice must use the element definition for the element(s) in the discriminator(s)

Alexander Henket (Oct 04 2019 at 14:32):

I really fail to see why the profile validator would need a terminology server to find out what the value for system is when it has the ValueSet telling it just that? The only thing a terminology server could tell it that the ValueSet doesn't is which codes belong to the system, but for slicing this is not interesting. For instance validation you might need it, but alas I will never be able to distribute systems outside of my control or behind a pay wall (medication codes are to name one)

What do you recommend for this situation in STU3? It sounds like the slicing mechanism has a missing feature: slicing by ValueSet is quite common for us.

Alexander Henket (Oct 04 2019 at 14:41):

@Grahame Grieve Presumably I could duplicate what the ValueSet is already telling me by adding a fixed system in the profile matching the ValueSet system? Forge at least lets me do that. Not sure what to do for ValueSets that pick from more than 1 system, but I did not check if we have those.

    <element id="PractitionerRole.specialty.coding">
      <path value="PractitionerRole.specialty.coding" />
      <slicing>
        <discriminator>
          <type value="value" />
          <path value="system" />
        </discriminator>
        <rules value="open" />
      </slicing>
    </element>
    <element id="PractitionerRole.specialty.coding:SpecialtyUZI">
      <path value="PractitionerRole.specialty.coding" />
      <sliceName value="SpecialtyUZI" />
      <short value="SpecialtyUZI" />
      <alias value="SpecialismeUZI" />
      <binding>
        <extension url="http://hl7.org/fhir/StructureDefinition/elementdefinition-bindingName">
          <valueString value="PractitionerSpecialty" />
        </extension>
        <strength value="extensible" />
        <valueSetReference>
          <reference value="http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.40.2.17.1.6--20171231000000" />
          <display value="SpecialismeUZICodelijst" />
        </valueSetReference>
      </binding>
    </element>
    <element id="PractitionerRole.specialty.coding:SpecialtyUZI.system">
      <path value="PractitionerRole.specialty.coding.system" />
      <fixedUri value="http://fhir.nl/fhir/NamingSystem/uzi-rolcode" />
    </element>
    <element id="PractitionerRole.specialty.coding:SpecialtyAGB">
      <path value="PractitionerRole.specialty.coding" />
      <sliceName value="SpecialtyAGB" />
      <short value="SpecialtyAGB" />
      <alias value="SpecialismeAGB" />
      <binding>
        <extension url="http://hl7.org/fhir/StructureDefinition/elementdefinition-bindingName">
          <valueString value="PractitionerSpecialty" />
        </extension>
        <strength value="extensible" />
        <valueSetReference>
          <reference value="http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.40.2.17.1.7--20171231000000" />
          <display value="SpecialismeAGBCodelijst" />
        </valueSetReference>
      </binding>
    </element>
    <element id="PractitionerRole.specialty.coding:SpecialtyAGB.system">
      <path value="PractitionerRole.specialty.coding.system" />
      <fixedUri value="urn:oid:2.16.840.1.113883.2.4.6.7" />
    </element>

Alexander Henket (Oct 04 2019 at 14:48):

And I think that what you are doing isn't conformant:

Each slice must use the element definition for the element(s) in the discriminator(s)

If you would let me in on what that message means I could agree or disagree :-) If I understand what it means correctly, I tend to disagree. I have an ElementDefinition that, through its binding, defines what the system is that I use to slice. So far I see a tooling issue, not a profile issue. More than happy to implement a workaround if one exists for STU3 that does not involve having to produce CodeSystems for systems I cannot produce.

Grahame Grieve (Oct 04 2019 at 20:33):

I really fail to see why the profile validator would need a terminology server to find out what the value for system is when it has the ValueSet telling it just that

I sad it wasn't smart enough to do that. Not that it's impossible. I might be able to sort that out - there's enough information present, but I don't think that what you are doing is conformant.

Grahame Grieve (Oct 04 2019 at 20:35):

Each slice must use the element definition for the element(s) in the discriminator(s)

You nominate the element on which you slice - system
So the validator goes looking for the element definition for the element in the discriminator - system, and doesn't find one

Grahame Grieve (Oct 04 2019 at 20:36):

the fixedUri approach looks like it should work. if it doesn't, we can review further.

Alexander Henket (Oct 07 2019 at 07:33):

I sad it wasn't smart enough to do that. Not that it's impossible.

Ok good then I missed that nuance.

Alexander Henket (Oct 07 2019 at 07:42):

the fixedUri approach looks like it should work. if it doesn't, we can review further.

Ok, I will try to test that. There is a second solution. Looking in our archives of logged issues I found MM-433 that proposes to use $this + value set binding required (not: extensible). I'm told the .Net validator has been updated to support that as recent as last week. I'd expect that the Java validator would support the same. -- related topic: https://chat.fhir.org/#narrow/stream/179177-conformance/topic/Slicing.20and.20value.20sets

There is something uneasy about adding an ElementDefinition system to the profile: I do not want to duplicate ValueSet definitions in my profiles as that may go out of sync.

There is also something uneasy in using $this as discriminator: how do I know what the rules are for the validator in that case? I would expect code + system, with fallback on just system if there is no expansion for the ValueSet. I definitely do not expect any check on display, version or userSelected to determine the slice. Is that how it is supposed to work, or is that just my interpretation?

Alexander Henket (Oct 07 2019 at 08:26):

@Grahame Grieve I wanted to check what happens with our profiles in the validator, and downloaded the validator. I don't get far using either the Simplifier package or the base folder:

mbp:STU3 ahenket$ java -jar org.hl7.fhir.validator.jar -ig nictiz.fhir.nl.stu3.zib2017-1.3.0.tgz -version 3.0 -recurse -debug instances/medmij-bgz-fhir3-0-1-allergyintolerance-ts-01.xml
FHIR Validation tool Version 4.0.23-SNAPSHOT - Built 2019-10-02T15:02:10.634+10:00 - Git 17e7333bcab7
Detected Java version: 1.8.0_121 from /Library/Java/JavaVirtualMachines/jdk1.8.0_121.jdk/Contents/Home/jre on x86_64 (64bit). 3641MB available
Arguments: -ig nictiz.fhir.nl.stu3.zib2017-1.3.0.tgz -version 3.0 -recurse -debug instances/medmij-bgz-fhir3-0-1-allergyintolerance-ts-01.xml
Directories: Current = /Users/ahenket/Development/FHIR/STU3, Package Cache = /Users/ahenket/.fhir/packages
  .. connect to tx server @ http://tx.fhir.org
  .. definitions from hl7.fhir.core#3.0.1
    (v3.0.1)
+  .. load IG from nictiz.fhir.nl.stu3.zib2017-1.3.0.tgz
Loading nictiz.fhir.nl.stu3.zib2017-1.3.0.tgz to the package cache
  Fetching:.......................... done.
Exception in thread "main" java.lang.UnsupportedOperationException: JsonNull
    at com.google.gson.JsonElement.getAsString(JsonElement.java:192)
    at org.hl7.fhir.utilities.cache.NpmPackage.canonical(NpmPackage.java:278)
    at org.hl7.fhir.utilities.cache.PackageCacheManager.extractLocally(PackageCacheManager.java:525)
    at org.hl7.fhir.r5.validation.ValidationEngine.loadPackage(ValidationEngine.java:616)
    at org.hl7.fhir.r5.validation.ValidationEngine.loadIgSource(ValidationEngine.java:511)
    at org.hl7.fhir.r5.validation.ValidationEngine.loadIg(ValidationEngine.java:776)
    at org.hl7.fhir.r5.validation.Validator.main(Validator.java:481)

mbp:STU3 ahenket$ java -jar org.hl7.fhir.validator.jar -ig ../../GitHub/Nictiz/Nictiz-STU3-Zib2017/Profiles\ -\ ZIB\ 2017/  -version 3.0 -recurse -debug instances/medmij-bgz-fhir3-0-1-allergyintolerance-ts-01.xml
FHIR Validation tool Version 4.0.23-SNAPSHOT - Built 2019-10-02T15:02:10.634+10:00 - Git 17e7333bcab7
Detected Java version: 1.8.0_121 from /Library/Java/JavaVirtualMachines/jdk1.8.0_121.jdk/Contents/Home/jre on x86_64 (64bit). 3641MB available
Arguments: -ig "../../GitHub/Nictiz/Nictiz-STU3-Zib2017/Profiles - ZIB 2017/" -version 3.0 -recurse -debug instances/medmij-bgz-fhir3-0-1-allergyintolerance-ts-01.xml
Directories: Current = /Users/ahenket/Development/FHIR/STU3, Package Cache = /Users/ahenket/.fhir/packages
  .. connect to tx server @ http://tx.fhir.org
  .. definitions from hl7.fhir.core#3.0.1
    (v3.0.1)
+  .. load IG from ../../GitHub/Nictiz/Nictiz-STU3-Zib2017/Profiles - ZIB 2017/
Exception in thread "main" java.lang.StringIndexOutOfBoundsException: String index out of range: -1
    at java.lang.String.substring(String.java:1967)
    at org.hl7.fhir.utilities.Utilities.path(Utilities.java:549)
    at org.hl7.fhir.r5.validation.ValidationEngine.loadIgSource(ValidationEngine.java:502)
    at org.hl7.fhir.r5.validation.ValidationEngine.loadIg(ValidationEngine.java:776)
    at org.hl7.fhir.r5.validation.Validator.main(Validator.java:481)

What am I missing? It also seems to error out on r5 classes after recognizing I'm calling on stu3.

Grahame Grieve (Oct 07 2019 at 09:16):

I think you need the technical correction and package reconciliation to happen before that sequence will work

Grahame Grieve (Oct 07 2019 at 09:16):

I'll add it to my queue

Alexander Henket (Oct 07 2019 at 10:00):

@Grahame Grieve There's more. In Eclipse I can get more useful errors (no idea why though). I fear the validator needs more updates, or at least I don't get why the profiles would be in error:

• We have added an extension in our set to support PractitionerRole in places where STU3 forgot to list it. We then added the extension to our profiles under path Annotation.author[x].extension. We obviously had to slice extension, but never saw a need to slice Annotation.author[x] itself. The validator however seems to be forcing us into that, but the extension is valid across all slices so I don't see why.

Exception in thread "main" java.lang.Error: Can't have children on an element with a polymorphic type - you must slice and constrain the types first (sortElements: Annotation.author[x]:Reference{[CanonicalType[http://hl7.org/fhir/StructureDefinition/Practitioner], CanonicalType[http://hl7.org/fhir/StructureDefinition/Patient], CanonicalType[http://hl7.org/fhir/StructureDefinition/RelatedPerson]]}, string)

• We have a Bundle profile that slices Bundle.entry.resource and assigns type List to that. It then marks Bundle.entry.resource.subject as "bundled" reference. Forge thinks that's fine. The validator does not.

Unable to generate snapshot for http://nictiz.nl/fhir/StructureDefinition/Bundle-MedicationOverview because Profile Medication Overview response structure (http://nictiz.nl/fhir/StructureDefinition/Bundle-MedicationOverview). Error generating snapshot: Error sorting Differential: StructureDefinition http://nictiz.nl/fhir/StructureDefinition/Bundle-MedicationOverview: Differential contains path Bundle.entry.resource.subject which is not found in the base

• We generally have open slicing. Forge thinks that's fine and will happily produce snapshots. The validator does not and can only continue if I let Forge generate snapshots

Unable to generate snapshot for http://nictiz.nl/fhir/StructureDefinition/zib-InstructionsForUse: Error at path null: Type slicing with slicing.rules != closed

• We generally add XSD/SCH to instances as an immediate low key way to know we have valid instances. The validator marks that as an error, rather than a warning. That seems overdoing it imo.

Grahame Grieve (Oct 07 2019 at 14:37):

where do I get instances/medmij-bgz-fhir3-0-1-allergyintolerance-ts-01.xml in your example?

Alexander Henket (Oct 07 2019 at 16:35):

@Grahame Grieve It is in the Simplifier package 1.3.0. It is also on GitHub

I've been at it all day today and I've at least made some progress. Based on our ticket MM-433 I've committed changes to all profiles that do slicing by ValueSet. They now all have discriminator $this and all bindings are now required. Everything has been committed in the GitHub develop branch.

• If I create the snapshots, then the validator validates most cases as expected
• If I do not create the snapshots, the validator fails to build those
• discriminator $this does not work when I have slice based based on fixed code + system and a slice based on ValueSet
  • Profile zib-LaboratoryTestResult-Observation.xml and medmij-bgz-fhir3-0-1-labresult-ts-01.xml will get you reproduction

Grahame Grieve (Nov 13 2019 at 23:40):

just circling back - did we get to the bottom of this?

Alexander Henket (Nov 14 2019 at 11:49):

@Grahame Grieve I think we now know how to profile certain slicing cases within the specification. My recollection is that tooling updates are still required here and there, but details of which tooling needs which update, escapes me. The short version of my recollection for the Java validator was that snapshot generation is the biggest issue, while the slicing thing based on patterns either directly or by binding is supported. For .Net, snapshot generation is no issue, but the slicing is. Same goes for Touchstone.

We have not yet applied the pattern thing throughout the package yet. My thinking:

• We create a package that has the slicing as agreed here
• We test that against the Java validator, and feed you with that?

Grahame Grieve (Nov 14 2019 at 12:08):

sure

Last updated: Apr 12 2022 at 19:14 UTC