Stream: implementers
Topic: Must Support / Mandatory
Bapi Behera (Apr 08 2021 at 20:16):
Could you please help, What is the difference between Must Support / Mandatory FHIR data elements with respect to Client/Server implementation?
Michele Mottini (Apr 08 2021 at 20:28):
Server must always populate mandatory elements (min. cardinality 1). The definition of must support can be different depending on the implementation guide, but a rule of thumb is that server must populate must support element if they have the data
Lloyd McKenzie (Apr 09 2021 at 04:30):
As an example, you might make "deceasedDate" mustSupport, but it would be odd to make it mandatory. Depending on the IG, that might mean "System must be able to store if received", "must be able to display to user", "must be able to capture from user", "must be able to transmit to downstream systems", "must consider as part of decision support logic", etc. mustSupport can only be evaluated by looking at the behavior of the system - it can't be evaluated just by looking at an instance.
Bapi Behera (Apr 09 2021 at 12:50):
Thanks Lloyd for the good example. that make sense. So When we do not have the "deceasedDate", can we send NullFlavor code?
Ex: UNK unknown
https://www.hl7.org/fhir/v3/NullFlavor/cs.html#definition
Bapi Behera (Apr 09 2021 at 12:52):
Michele Mottini said:
Server must always populate mandatory elements (min. cardinality 1). The definition of must support can be different depending on the implementation guide, but a rule of thumb is that server must populate must support element if they have the data
Agree. I am trying to define a best practice to manage the must support element. If no data available, can we send the NullFlavor code?
Vish (Apr 09 2021 at 13:14):
You could refer, missing data guidelines defined as per US Core General Guidelines.
http://hl7.org/fhir/us/core/general-guidance.html#missing-data
Michele Mottini (Apr 09 2021 at 13:33):
If no data available and the element is not required you just omit it - no need to do anything special
Michele Mottini (Apr 09 2021 at 13:34):
So if deceasedDate is must support but not required you just don't populate that element for people that are still alive
Lloyd McKenzie (Apr 09 2021 at 16:35):
Also, be aware that elements that have 'required' vocabulary bindings can't use extensions to bypass missing data. If the profile says an element is mandatory with a required binding, and you don't have a value, then you can't comply with the profile
Shamil Nizamov (Apr 15 2021 at 18:18):
Lloyd McKenzie said:
Also, be aware that elements that have 'required' vocabulary bindings can't use extensions to bypass missing data. If the profile says an element is mandatory with a required binding, and you don't have a value, then you can't comply with the profile
Would it be useful to explicitly mention that in the 4.1.5.1 Required? Currently this section does not give that sense.
Eric Haas (Apr 15 2021 at 18:44):
There is already a tracker to do that.
Shamil Nizamov (Apr 16 2021 at 00:23):
I've just checked, the FHIR validator does not fail a required (1..1) MS element with the Required binding. E.g., US Core DiagnosticReport.status, the profile was specified.
Grahame Grieve (Apr 16 2021 at 00:26):
can you provide and example, and what your validator output is please
Shamil Nizamov (Apr 16 2021 at 00:42):
E.g., DiagnosticReport.status with meta.profile bound to http://hl7.org/fhir/us/core/StructureDefinition/us-core-diagnosticreport-lab defined as following:
...
"_status": {
"extension": [
{
"url": "http://hl7.org/fhir/StructureDefinition/data-absent-reason",
"valueCode": "unknown"
}
]
},
...
No warnings or errors in valitions.xml/html outputs.
I'll probably to try with the DocumentReference.status as well.
Shamil Nizamov (Apr 16 2021 at 00:59):
No warning or error for this one as well:
{
"resourceType": "DocumentReference",
"meta": {
"profile": [
"http://hl7.org/fhir/us/core/StructureDefinition/us-core-documentreference"
]
},
"_status": {
"extension": [
{
"url": "http://hl7.org/fhir/StructureDefinition/data-absent-reason",
"valueCode": "unknown"
}
]
},
"type": {
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/v3-NullFlavor",
"code": "UNK"
}
]
},
"category": [
{
"coding": [
{
"system": "http://hl7.org/fhir/us/core/CodeSystem/us-core-documentreference-category",
"code": "clinical-note"
}
]
}
],
"subject": {
"reference": "Patient/example"
},
"content": [
{
"attachment": {
"_contentType": {
"extension": [
{
"url": "http://hl7.org/fhir/StructureDefinition/data-absent-reason",
"valueCode": "unknown"
}
]
},
"_data": {
"extension": [
{
"url": "http://hl7.org/fhir/StructureDefinition/data-absent-reason",
"valueCode": "unknown"
}
]
}
}
}
]
}
Only info that "None of the codings provided are in the value set http://hl7.org/fhir/ValueSet/c80-doc-typecodes (http://hl7.org/fhir/ValueSet/c80-doc-typecodes), and a coding is recommended to come from this value set) (codes = http://terminology.hl7.org/CodeSystem/v3-NullFlavor#UNK)"
NullFlavor is allowed by USCoreDocumentReferenceType.
Grahame Grieve (Apr 16 2021 at 05:50):
right, that one is valid
Lloyd McKenzie (Apr 16 2021 at 16:25):
How is that one valid?
Lloyd McKenzie (Apr 16 2021 at 16:25):
If you have a required binding, you must have a code from the value set. No exceptions (including with extensions)
Grahame Grieve (Apr 18 2021 at 22:18):
no if you have a value, it must be from the value set. In this case, there's no value
Eric Haas (Apr 19 2021 at 15:03):
@Grahame Grieve we have been operating under the same rules that Lloyd stated for quite some time now.
Lloyd McKenzie (Apr 19 2021 at 15:19):
The rules are clear. If you have an element in the instance, it must have a value from the binding. Extensions do not waive this requirement.
Lloyd McKenzie (Apr 19 2021 at 15:20):
The following rules apply when required bindings are used with the CodeableConcept data type:
at least one Coding element SHALL be present
one of the Coding values SHALL be from the specified value set
text can be provided as well, and is always recommended, but is not an acceptable substitute for the required code
Lloyd McKenzie (Apr 19 2021 at 15:22):
It makes no sense that we'd impose greater constraint on CodeableConcept than we do on 'code'.
Grahame Grieve (Apr 20 2021 at 01:34):
well, so they are. I've updated the validator. One test case changed from passing to failing. I guess the next release will break something
Robert McClure (Apr 20 2021 at 16:35):
@Lloyd McKenzie A bit of a hijack but you have made clear and we've seen that using slicing an IG can specify the use of a value not in the required binding therefore an instance can contain values that conform to the slice, and not the required binding. So which is it?
Eric Haas (Apr 20 2021 at 16:47):
Robert McClure said:
Lloyd McKenzie A bit of a hijack but you have made clear and we've seen that using slicing an IG can specify the use of a value not in the required binding therefore an instance can contain values that conform to the slice, and not the required binding. So which is it?
from the spec
The following rules apply when required bindings are used with the CodeableConcept data type:
at least one Coding element SHALL be present
one of the Coding values SHALL be from the specified value set
text can be provided as well, and is always recommended, but is not an acceptable substitute for the required code
[emphasis mine]
Eric Haas (Apr 20 2021 at 16:49):
so if required binding to LOINC then this is OK...
slice the first coding to be LOINC 1234-5
slice the second coding to be "foo"
Lloyd McKenzie (Apr 20 2021 at 22:15):
If you have a binding for the overall CodeableConcept and also have bindings on CodeableConcept.coding slices, they all apply (though if the slices are optional, then you're not guaranteed of adherence to those slices). If there's a required binding to SNOMED for the base element, a slice binding to ICD10 adds an expectation for ICD10 but doesn't remove the base expectation for SNOMED.
Side note, there's no ordering to the Codings, so it doesn't matter if SNOMED appears in the 1st coding or the 17th. If it appears somewhere, you've met the requirement. (It's non-conformant to mandate order for the Codings because there is no meaning assigned to the order.)
Last updated: Apr 12 2022 at 19:14 UTC
