FHIR Chat · Custom value set for Identifier.type causes warning messages · implementers

Stream: implementers

Topic: Custom value set for Identifier.type causes warning messages

Ross Shnaper (Dec 05 2017 at 03:05):

I have a Patient profile with custom value set for Identifier.type binding that includes the value of JHN however when running the validator I still see the following warning message:

None of the codes provided are in the value set http://hl7.org/fhir/ValueSet/identifier-type (http://hl7.org/fhir/ValueSet/identifier-type, and a code should come from this value set unless it has no suitable code) (codes = http://hl7.org/fhir/v2/0203#JHN)

Here's the excerpt from my profile:

        <element id="Patient.identifier">
            <path value="Patient.identifier"/>
            <slicing>
                <discriminator>
                    <type value="value"/>
                    <path value="type.coding.system"/>
                </discriminator>
                <discriminator>
                    <type value="value"/>
                    <path value="type.coding.code"/>
                </discriminator>
                <rules value="closed"/>
            </slicing>
            <min value="1"/>
            <max value="2"/>
            <mustSupport value="true"/>
        </element>
        <element id="Patient.identifier:hcnIdentifier">
            <path value="Patient.identifier"/>
            <sliceName value="hcnIdentifier"/>
            <short value="A health card number for this patient"/>
            <definition value="A health card number for this patient."/>
            <min value="1"/>
            <max value="1"/>
            <mustSupport value="true"/>
            <binding>
                <strength value="required"/>
                <valueSetReference>
                    <reference value="http://cihi.ca/fhir/irrs/ValueSet/irrs-identifier-type"/>
                </valueSetReference>
            </binding>
        </element>

Does anyone know how to get rid of that warning message?

Lloyd McKenzie (Dec 05 2017 at 03:13):

At present, the validator validates against the base resource as well as any declared profiles. The warning is triggered when we validate against the base resource. You could make a change request for us to add enough smarts to the validator that the warning would be suppressed (it would still show up when validating the profile). However, it won't be an easy change to make and I have no clue when (or if) it'll get made.

Eric Haas (Dec 05 2017 at 03:19):

Does this warning pop up even when you have created an extended valueset?

Lloyd McKenzie (Dec 05 2017 at 03:24):

Yes

Lloyd McKenzie (Dec 05 2017 at 03:25):

Because it validates against the resource value set when it validates against the resource

Eric Haas (Dec 05 2017 at 03:43):

What about if you validate against the profile when in meta.profile?

Lloyd McKenzie (Dec 05 2017 at 04:17):

We always validate against the underlying resource whether a profile is specified or not

Ken Sinn (Nov 05 2020 at 19:00):

Just to be clear, validator will always generate an error on an extensible binding, even if a profile declares and specifies the expanded valueset? Would there be any way to drop the severity to informational, rather than warning?

Lloyd McKenzie (Nov 05 2020 at 19:19):

It shouldn't give you an error, just a warning

Ken Sinn (Nov 05 2020 at 19:25):

Agreed, it's "just a warning", but we're aggressively error-checking and warning-checking values. If the profile binding is properly defined, it feels like this should be informational rather than a warning.

Lloyd McKenzie (Nov 05 2020 at 19:31):

Warning says "this is a potential error and requires human review to determine whether it's an error or not" - which is exactly the case here.

Lloyd McKenzie (Nov 05 2020 at 19:31):

A human needs to look at the code and figure out whether the associated concept could possibly have been expressed (possibly at a different level of precision) using one of the codes in the bound value set.

Ken Sinn (Nov 05 2020 at 21:00):

That makes sense from the perspective of a testing tool, but that makes the validator code impractical for run-time validation, as you're either stuck with a lot of warnings in your logs for otherwise properly-defined profiles and valuesets without the ability to suppress them.

Robert McClure (Nov 05 2020 at 21:02):

I Agree and question why the validator can not validate against the defined value set in the profile. Why is that such an odd request?

ryan moehrke (Nov 05 2020 at 22:12):

If i remember the logic it does validate against the binding in the profile, it just also validates against the base binding which is why it ends up throwing the warnings..

Lloyd McKenzie (Nov 05 2020 at 22:44):

The issue is if you're using a code that's not from the value set, it's going to raise a warning - because it might be invalid. If you want to ignore those in production you can, but they're legitimate warnings and it's entirely possible that some of the codes you're receiving are erroneous - because they could have been expressed within the value set.

Lloyd McKenzie (Nov 05 2020 at 22:45):

All warnings are things that require humans to check. It's up to the implementer to decide if they care enough about them to have humans actually check them.

Ken Sinn (Nov 10 2020 at 18:50):

Are there any ways to classify types of Warning messages, e.g. value outside of Extensible valueset, or profile not found, so that they can be easily identified/categorized? And possibly be suppressed via command-line arguments?

Lloyd McKenzie (Nov 10 2020 at 19:28):

So far, I don't think we've assigned 'codes' to the different issue types, but I suppose it might be possible for us to do that. You could then filter by looking at the results as an OperationOutcome. You could submit a change request for that capability to be added to the validator. I wouldn't count on it happening soon though as it's a pretty big undertaking...

Grahame Grieve (Nov 12 2020 at 10:23):

@Ken Sinn several things to say about this:

• it seems you are using an old version of the validator, because the current validator doesn't make that warning at all if there's a profile for it to validate against
• if you are using in the context of HAPI, you can change the level of a message.
• if you are running from the command line, then you can't, but I don't think you should need to if you have the current version

Ken Sinn (Nov 12 2020 at 11:13):

I'll double check over the next few days using a stripped-down example profile + valueset, but I was using a validator build from last week. I'll confirm then ping.

frank cao (Nov 20 2020 at 14:59):

Grahame Grieve said:

Ken Sinn several things to say about this:

• it seems you are using an old version of the validator, because the current validator doesn't make that warning at all if there's a profile for it to validate against
• if you are using in the context of HAPI, you can change the level of a message.
• if you are running from the command line, then you can't, but I don't think you should need to if you have the current version

Grahame, should we use "-profile" to explicitly specify the profile, or validator will use "-ig" to find the profile? In our mressages, we have meta.profile.

Grahame Grieve (Nov 23 2020 at 06:50):

-ig tells the validator what to load.
-profile tells it to test against a profile.

It will automatically validate on meta.profile if it sees it there, if the profile(s) referred to have been loaded

frank cao (Nov 23 2020 at 14:48):

Much appreciated!

Last updated: Apr 12 2022 at 19:14 UTC