Stream: CARIN IG for Blue Button®
Topic: Validation Issues
Jason Teeple (Sep 17 2020 at 20:37):
Hi @Saul Kravitz we are trying to validate against the latest CARIN IG and we are finding we cannot validate when Data Absence Reason Extension is used. For example, if we do not have patient.name, we would followed:
{
"resourceType" : "Patient",
...
"name": [
{
"extension": [
{
"url": "http://hl7.org/fhir/StructureDefinition/data-absent-reason",
"valueCode": "unknown"
}
]
}
]
"telecom" :
...
}
However, when validating against the latest CARIN IG, we get an error stating that patient.name is required. When we validate against USCore, we pass without error.
Any suggestions on what may be causing the issue? Is it an IG problem, validator, other? Appreciate some guidance.
Saul Kravitz (Sep 17 2020 at 20:43):
Does the validator state anything useful?
Jason Teeple (Sep 17 2020 at 21:13):
- .. load IG from hl7.fhir.us.carin-bb#0.3.1
.. validate [C:\fhir\requests\fhir_resource_20200917T161102.json]
FAILURE validating C:\fhir\requests\fhir_resource_20200917T161102.json: error:1 warn:1 info:6
Error @ Patient.name[0] (line 25, col18) : us-core-8: Patient.name.given or Patient.name.family or both SHALL be present [family.exists() or given.exists()]
Information @ Patient.extension[0] (line 37, col18) : This element does not match any known slice defined in the profile http://hl7.org/fhir/us/carin-bb/StructureDefinition/CARIN-BB-Patient
Information @ Patient.extension[1] (line 48, col18) : This element does not match any known slice defined in the profile http://hl7.org/fhir/us/carin-bb/StructureDefinition/CARIN-BB-Patient
Information @ Patient.extension[2] (line 59, col18) : This element does not match any known slice defined in the profile http://hl7.org/fhir/us/carin-bb/StructureDefinition/CARIN-BB-Patient
Information @ Patient.extension[0] (line 37, col18) : Unknown extension http://hl7.org/fhir/us/core/ValueSet/omb-ethnicity-category
Information @ Patient.extension[1] (line 48, col18) : Unknown extension http://hl7.org/fhir/us/core/ValueSet/omb-race-category
Information @ Patient.extension[2] (line 59, col18) : Unknown extension http://hl7.org/fhir/us/core/ValueSet/birthsex
Warning @ Patient.identifier[0].type (line 13, col36) : 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/us/carin-bb/CodeSystem/IdentifierTypeCS#mb)
Jason Teeple (Sep 17 2020 at 22:20):
I am having my team go back and confirm which IG they are validating against. Looks like you, @Saul Kravitz , addressed a similar issue here: https://chat.fhir.org/#narrow/stream/204607-CARIN-IG.20for.20Blue.20Button.C2.AE/topic/Validating.20with.20the.20CI.20IG
Jason Teeple (Sep 18 2020 at 20:50):
@Saul Kravitz I looked at the StructureDefintion and cannot find data-absent, data absent, or data absence in any profile. Is there something I am missing?
I would have thought that I'd find at least something similar to:
human" : "If there is no component or hasMember element then either a value[x] or a data absent reason must be present.",
"expression" : "(component.empty() and hasMember.empty()) implies (dataAbsentReason.exists() or value.exists())",
"xpath" : "f:component or f:memberOF or f:*[starts-with(local-name(.), 'value')] or f:dataAbsentReason",
Am I over thinking here? Appreciate any feedback.
Saul Kravitz (Sep 18 2020 at 21:07):
@Jason Teeple I don’t think you will find it in an IG. I think it is a general mechanism for flagging a reason for missing data. Search on data absent reason extension. I’m trying to find a coherent description. When I do I’ll post it here.
Jason Teeple (Sep 19 2020 at 00:37):
@Saul Kravitz If you look at the structure definition, you should find the mechanism. For example, take a look either of these USCore Profiles: http://hl7.org/fhir/us/core/StructureDefinition-us-core-patient.json.html http://hl7.org/fhir/us/core/StructureDefinition-pediatric-bmi-for-age.json.html
Search data-absent and you will see what I am referencing.
I am not finding similar concepts within the CARIN Patient Structure Definition or any other resource Structure Definition.
Michele Mottini (Sep 19 2020 at 01:03):
US Core decided to allow omitting required fields using dataAbsentReason - see https://www.hl7.org/fhir/us/core/general-guidance.html#must-support
Michele Mottini (Sep 19 2020 at 01:04):
That does not mean that the CARIN IG has to do the same - and doing that would not be fixing a validation problem but a material change in the implementation guide
Lloyd McKenzie (Sep 19 2020 at 01:20):
Da Vinci expects to explicitly expose DAR in their IGs where they feel it must be supported - and don't allow its use for mandatory elements where we haven't explicitly enabled it - because there are some mandatory elements where it genuinely makes no sense to send the instance unless the value is present. As well, we don't mark elements as mandatory unless we genuinely expect them to always be present, not just "really ought to be present".
Lloyd McKenzie (Sep 19 2020 at 01:20):
However, for anything we inherit from US Core, the US Core rules apply - we can't override those.
Jason Teeple (Sep 19 2020 at 11:26):
The CARIN IG states: If the source system does not have data for a Must Support data element with minimum cardinality = 0, the data element is omitted from the resource. If the source system does not have data for a required data element (in other words, where the minimum cardinality is > 0), follow guidance defined in the core FHIR specification and summarized in the US Core.
http://build.fhir.org/ig/HL7/carin-bb/Guidance.html#missing-data
Jason Teeple (Sep 19 2020 at 11:39):
Lloyd McKenzie said:
However, for anything we inherit from US Core, the US Core rules apply - we can't override those.
I could be misunderstanding, but it looks like Patient.name did not inherit the USCore rules.
https://build.fhir.org/ig/HL7/US-Core-R4/StructureDefinition-us-core-patient.json.html
http://build.fhir.org/ig/HL7/carin-bb/StructureDefinition-C4BB-Patient.profile.json.html
Jason Teeple (Sep 19 2020 at 11:46):
Michele Mottini said:
That does not mean that the CARIN IG has to do the same - and doing that would not be fixing a validation problem but a material change in the implementation guide
Since the CARIN IG states rules for missing data, wouldn't the structure definitions need to be updated? Validating against the structure definition and using the DAR rules consistent with the CARIN IG definition would expose validation issues, would it not?
Lloyd McKenzie (Sep 19 2020 at 14:14):
mustSupport can't be validated by looking at an instance, only by looking at system behavior (was the element stored, was it displayed, is it possible to capture it, etc.) I see patient.name marked as mustSupport in the BB profile. The descriptive rules around mustSupport are in the text of the US-Core IG - and are inherited by reference. They don't appear in the actual profiles.
Jason Teeple (Sep 19 2020 at 18:34):
Lloyd McKenzie said:
mustSupport can't be validated by looking at an instance, only by looking at system behavior (was the element stored, was it displayed, is it possible to capture it, etc.) I see patient.name marked as mustSupport in the BB profile. The descriptive rules around mustSupport are in the text of the US-Core IG - and are inherited by reference. They don't appear in the actual profiles.
I am not connecting what you are saying. Why would rules inherited from profile A, not appear in profile B; specifically within the structure definition?
We have data mapped, there are instances when there is a MustSupport/Required (Support flag + 1...1/1...*) and the data is available. However, there are also instances when the data may not be available (happens more than folks like to admit). When the data is not available, we follow the rules outlined in USCore for Missing Data.
Using the ONC FHIR Validator (https://inferno.healthit.gov/validator/), advanced options, I load a standalone profile (http://build.fhir.org/ig/HL7/carin-bb/StructureDefinition-C4BB-Patient.profile.json.html) and input my resource to validate. If, for example, my Patient profile has a DAR for Patient.name, validating against CARIN 4 BB, I will get an error. However, if I take my same resource and validate against https://build.fhir.org/ig/HL7/US-Core-R4/StructureDefinition-us-core-patient.json.html, I will not get an error.
If CARIN 4BB inherits rules from USCore, then the rules are not applied during validation.
Lloyd McKenzie (Sep 20 2020 at 02:43):
The mustSupport declartions from the base profile are inherited. The descriptive language explaining how mustSupport works in US Core aren't declared in profiles, they're declared in IG text - and there's no inheritance mechanism for that. However, it applies none-the-less.
Lloyd McKenzie (Sep 20 2020 at 02:44):
The validator totally ignores mustSupport. It has nothing to do with DAR and has nothing to do with instance validation. mustSupport is all about system capability, not instances.
Jason Teeple (Sep 20 2020 at 11:11):
We are focusing on the wrong part of my concern.
I am more focused on DAR than mustSupport. I understand that mustSupport is system capability, and not instance.
Let me rephrase my questions:
(1) How should DAR be represented in the IG , profile, and structure definition?
(2) How should the appropriate use of DAR be validated?
(3) Can DAR be validate using a validator?
https://confluence.hl7.org/display/FHIR/Using+the+FHIR+Validator
http://inferno.healthit.gov/validator/
CARIN BB states when DAR should be applied, required 1...1 / 1...* and follow USCore Guidance.
Using the ONC FHIR Validator (https://inferno.healthit.gov/validator/), advanced options, I load a standalone profile (http://build.fhir.org/ig/HL7/carin-bb/StructureDefinition-C4BB-Patient.profile.json.html) and input my resource to validate. If, for example, my Patient resource has a DAR for Patient.name, validating against CARIN 4 BB, I will get an error. However, if I take the same Patient resource and validate against https://build.fhir.org/ig/HL7/US-Core-R4/StructureDefinition-us-core-patient.json.html, I will not get an error.
Lloyd McKenzie (Sep 20 2020 at 13:25):
- By default, DAR is allowed everywhere unless there are explicit constraints against it.
- Making individual constraints against it is a huge amount of work, so if there are going to be constraints, they'll typically be expressed in text and not enforced in the profile. (You could create a global prohibition with an invariant, but if you're going to allow its use anywhere, then the prohibition needs to enumerate all the allowed places, which quickly becomes untenable. ) So, in general, the best that can be done is declaring DAR in those places you expect it to be used and creating invariants that require it when a value is absent (and disallow it when a value is present)
- What's described in #2 can be done. However, prohibiting DAR in those places where you don't want it will be quite challenging.
Jason Teeple (Sep 20 2020 at 14:08):
Thanks @Lloyd McKenzie, this helps immensely. Including @Saul Kravitz b/c he was asking a similar question in another stream.
Saul Kravitz (Sep 20 2020 at 22:53):
Thx @Jason Teeple and @Lloyd McKenzie .
Would be very helpful if everything in @Lloyd McKenzie description above was documented somewhere... is it? One intelligent reader (@Jason Teeple ) and another reader (me) couldn’t figure it out by searching the FHIR documentation.
Lloyd McKenzie (Sep 20 2020 at 22:54):
DAR isn't documented specially, because it's not special. It's an extension like any other.
Jason Teeple (Oct 09 2020 at 00:08):
I suspect DAR has the potential to be an abused extension if the intended usage is not well documented.
Lloyd McKenzie (Oct 09 2020 at 04:27):
There are lots of extensions that could be sent in place of a value - for a variety of reasons. Any of those could be abused - and some extensions could be created with the sole objective of bypassing a required element and not doing anything else at all. Placing additional documentation around DAR isn't going to prevent that issue.
Last updated: Apr 12 2022 at 19:14 UTC
