Stream: IG creation
Topic: Validation issue - profile in different IG
Sarah Gaunt (Oct 15 2021 at 04:10):
I have a validation issue that I can't figure out.
The BFDR IG references profiles defined in the Vital Records Common Profiles IG.
Re: this profile: http://build.fhir.org/ig/HL7/vr-common-library/branches/master/StructureDefinition-Observation-number-prenatal-visits.html
The exact same example (only differs by id) validates differently between the two IGs. When the example is in the "owning" IG, the informational messages say it correctly validates against the one profile it's supposed to validate against (http://build.fhir.org/ig/HL7/vr-common-library/branches/master/qa.html):
image.png
When it's in the IG that references the owning IG, the informational messages say it is validating against 16 (!!!) profiles (http://build.fhir.org/ig/HL7/fhir-bfdr/branches/master/qa.html):
image.png
Then, I'm pretty sure, this is causing multiple matching slicing errors in the containing Composition like: Profile http://hl7.org/fhir/us/bfdr/StructureDefinition/Composition-jurisdiction-live-birth-report, Element matches more than one slice - numberPrenatalCareVisits, cigaretteSmokingBeforeDuringPregnancy
A weird thing too is that all the errors I am now getting about multiple matching slices were not there until I used -resetTx when running (and subsequently deleted the inputcache from the git directory). The errors were only surfaced when Lynn was trying to publish and was reporting errors that I wasn't getting in the CI build nor my local build.
It's got to be something I'm doing wrong, but I can't see what it is...
Lloyd McKenzie (Oct 15 2021 at 04:20):
What are you slicing on?
Sarah Gaunt (Oct 15 2021 at 04:22):
Composition.section.entry:
<discriminator>
<type value="profile"/>
<path value="$this.resolve()"/>
</discriminator>
Sarah Gaunt (Oct 15 2021 at 04:23):
I did consider that the patternCodeableConcept in the profiles was causing an issue, but I changed to fixedCodeableConcept, and tested and no difference (other than the errors that I then got because of display and text being included).
Sarah Gaunt (Oct 15 2021 at 04:25):
It's not just that profile, btw - almost all the examples in the non-owning guide are validating against multiple profiles.
Sarah Gaunt (Oct 15 2021 at 04:26):
I chose that one specifically because it's an "easy" profile - i.e. Observation.code is bound to a LOINC code and not a phin vads code...
Lloyd McKenzie (Oct 15 2021 at 13:07):
What's likely happening then is that it's validating against all the possible profiles and not finding a match against any - so it's listing all of them. Try validating just that instance against just the profile you think it's valid against.
Sarah Gaunt (Oct 15 2021 at 19:15):
Yes, but why is it not finding a match against any of them? And why is the same sample file finding the proper match in one IG but then finding multiple matches in another IG?
What do you mean "Try validating just that instance against just the profile you think it's valid against". How do I do that?
Lloyd McKenzie (Oct 15 2021 at 20:00):
Invoke the validator and assert the profile id
Sarah Gaunt (Oct 15 2021 at 20:27):
Ok tx will try...
Sarah Gaunt (Oct 18 2021 at 22:23):
So if I run java -jar "validator_cli.jar" "input\resources\observation\observation-number-prenatal-visits-jada-ann-quinn.xml" -version 4.0.1 -ig hl7.fhir.us.bfdr#current -profile http://hl7.org/fhir/us/vr-common-library/StructureDefinition/Observation-number-prenatal-visits -output validation.xml
I get
<extension url="http://hl7.org/fhir/StructureDefinition/operationoutcome-file">
<valueString value="input\resources\observation\observation-number-prenatal-visits-jada-ann-quinn.xml"/>
</extension>
<issue>
<severity value="information"/>
<code value="informational"/>
<details>
<text value="All OK"/>
</details>
</issue>
Sarah Gaunt (Oct 18 2021 at 22:32):
I'm thinking there is a possibly(?) an issue with the way the IG publisher is validating against profiles that it is referencing from other IGs.
When I look at the Vital Records Common Profiles IG - which has zero examples that reference against profiles that aren't defined in the same IG, every single profile only has one informational validation message and they all look like: Observation: Validated against this.Observation - APGAR Score - i.e. not mention of meta or trying to validate against any other profiles or the base profile or anything. http://build.fhir.org/ig/HL7/vr-common-library/qa.html
When I look at pretty much any other IG that references profiles in another IG (US Core mostly), there are multiple validations when the profile being referenced isn't defined in the IG there are multiple informational validation messages that look like: Observation: Validated against fhir.Observation and hl7.fhir.us.core.US Core Laboratory Result Observation Profile (per meta) - it looks like it isn't validating properly - like only validating against the US Core Lab Result profile because it's in meta, not because it's finding a "real" match... https://build.fhir.org/ig/HL7/dental-data-exchange/branches/master/qa.html, https://build.fhir.org/ig/HL7/fhir-mCODE-ig/branches/master/qa.html, etc.
Maybe this is the way it's supposed to work? It's not causing problems in other IGs because they are only using US Core and it is causing problems with BFDR and the VR Common Profiles library, because the Common Profiles library has lots of Observation profiles and then BFDR checks all of them. (Causing issues with slicing on those multiple "matching" profiles).
@Grahame Grieve @Lloyd McKenzie - thoughts? Am I barking up a totally wrong tree here?
Sarah Gaunt (Oct 19 2021 at 02:43):
Sarah Gaunt said:
A weird thing too is that all the errors I am now getting about multiple matching slices were not there until I used -resetTx when running (and subsequently deleted the inputcache from the git directory). The errors were only surfaced when Lynn was trying to publish and was reporting errors that I wasn't getting in the CI build nor my local build.
So I just did what you're talking about in this thread: https://chat.fhir.org/#narrow/stream/179252-IG-creation/topic/CI.20not.20working - i.e. first run with -resetTx and second run without and in the first run I get the slicing errors about multiple matching slices but in the second run I don't get the errors (i.e. the one that uses the cache doesn't have the errors). So clearly this is part of the issue here.
When the IG Publisher is fixed, which is the correct validation output, the one with -resetTx or the one that is using the cache?
Lloyd McKenzie (Oct 19 2021 at 04:14):
@Grahame Grieve, thoughts?
Sarah Gaunt (Oct 19 2021 at 23:34):
So I think the -resetTx thing can be ignored. The cached terminology data was clearly hiding errors (not exactly sure why that would hide multiple slice matching errors, but...).
The differences in validation when a profile is not defined in the IG and is referencing another IG, I think is a problem?
Grahame Grieve (Oct 20 2021 at 17:40):
so looking at this, @Sarah Gaunt I don't see the problem. It might be because I'm running the pre-release publisher - I've made changes that matter in this regard. But: yes, the resource is validated against 16 profiles because you sliced by profile. so it has to be checked against the profiles in order to find out whether it conforms to them. I don't get slicing errors in any of the compositions (probably that's what I fixed)
Sarah Gaunt (Oct 20 2021 at 19:26):
Well, it is the Composition errors that I'm primarily stressing about and have been trying to debug for the past week - the multiple matching profiles errors. If you're not getting them with the new publisher, that's excellent! :grinning:
I guess I'm unsure how the validation works then.
Are you saying that if a profile, say ObservationA, is included in an IG and then is used for slicing, in say, CompositionA, the validation/validation messages for ObservationA (not the validation/validation messages for CompositionA where ObservationA is included) is different to how ObservationA would have been validated if it weren't included in any slicing in CompositionA?
i.e. if I remove ObservationA from slicing in CompositionA, there would only be the one validation message - exactly the same as the one validation message where it validates in the "owning" IG - the top validation for the profile would change from looking like the top example to the bottom example?
Grahame Grieve (Oct 20 2021 at 19:32):
yes. It's just telling you which profiles that observation was validated against, and if you slice by profile, then it will be validated against all the profiles in the slices in order to know which profiles it matches.
Sarah Gaunt (Oct 20 2021 at 19:40):
Ok thanks, makes sense I think. I guess it was a red herring due to the Composition multiple matching errors.
Sarah Gaunt (Oct 20 2021 at 20:10):
@Grahame Grieve not to hassle you or anything, but do you have an ETA on the new publisher?
Grahame Grieve (Oct 20 2021 at 20:16):
sometime today, I think
Last updated: Apr 12 2022 at 19:14 UTC
