Stream: CARIN IG for Blue Button®
Topic: EOB.diagnosis.type
Daniel Venton (Dec 03 2020 at 20:37):
According to conformance is a singleton:
... diagnosis S 1..* BackboneElement Pertinent diagnosis information
.... type S 1..1 CodeableConcept Timing or nature of the diagnosis
Binding: C4BB Claim Inpatient Institutional Diagnosis Type (required)
This example shows it as an array though (I assume other examples may as well):
http://hl7.org/fhir/us/carin-bb/ExplanationOfBenefit-EOBInpatient1.json.html
"diagnosis" : [
{
"sequence" : 1,
"diagnosisCodeableConcept" : {
"coding" : [
{
"system" : "http://hl7.org/fhir/sid/icd-10-cm",
"code" : "S06.0x1A"
}
]
},
"type" : [
{
"coding" : [
{
"system" : "http://terminology.hl7.org/CodeSystem/ex-diagnosistype",
"code" : "principal"
}
]
}
]
}
]
Daniel Venton (Dec 09 2020 at 14:18):
The base EOB resource it is an array 0..{splat}, CARIN BB confuses the issue by making it 1..1 because they require it. The CARIN IG should probably be 1..{splat} to show required to have, without obscuring the array-ness of the element. If there can only be 1, is there a cardinality rule that says only one slot of the array is allowed to be filled or would that just be a rule?
Michele Mottini (Dec 09 2020 at 14:53):
diagnosis is an array in the base specs, and is required and can have multiple values in CARIN BB (1..*). diagnosis.diagnosis[x] and diagnosis.type are NOT arrays in the base specs, they can both have at most a single value, and CARIN BB makes them required. The example matches that
Daniel Venton (Dec 09 2020 at 15:11):
Really?
http://hl7.org/fhir/R4/explanationofbenefit.html
.. diagnosis 0..* BackboneElement Pertinent diagnosis information
.... sequence 1..1 positiveInt Diagnosis instance identifier
.... diagnosis[x] 1..1 Nature of illness or problem
ICD-10 Codes (Example)
..... diagnosisCodeableConcept CodeableConcept
..... diagnosisReference Reference(Condition)
.... type 0..* CodeableConcept Timing or nature of the diagnosis. <-- Looks like an array to me
Example Diagnosis Type Codes (Example)
Michele Mottini (Dec 09 2020 at 15:17):
Oh yes, you are very right, sorry - I was looking at diagnosis[x] - type is an array, and yes, it would make more sense to make to 1..* instead than 1..1 but that ship has sailed I guess
Saul Kravitz (Dec 09 2020 at 15:45):
If you think there is an error, please create a Jira issue against the specification.
Development of the IG continues for additional EOB types, and inevitable mopping up operations can be included.
Josh Lamb (Dec 09 2020 at 15:51):
In the case of Inpatient EOB, I think that diagnosis.type should be 1..1 and is not an error. Based upon the allowable diagnosis types, multiple would be invalid.
Daniel Venton (Dec 09 2020 at 19:55):
multiple might be invalid use, but by documenting it this way it appears to be a singleton not an array, and the base spec is an array. So there needs to be some indicator here that it's still an array, but you are only allowed 1 filled slot, my opinion.
Also, if I was considering making a jira issue, what project in jira would be used for the CARIN IG.
Josh Lamb (Dec 09 2020 at 21:02):
Okay, I see the the point you were trying to raise originally now. The example has diagnosis.type as an array with a single entry. This is valid since the structure is an array. Are you asking for a notation within the example?
Michele Mottini (Dec 09 2020 at 21:16):
I do not understand what's the point of forbidding more than one type - as long as there is a valid type what does it matter if there are other?
Daniel Venton (Dec 09 2020 at 21:16):
I think the conformance page needs to have some way of saying this is still an array, this IG didn't change the data type from CodeableConcept[] to CodeableConcept. I know it's not allowed to change the data type, but the way it is now it reads like it did. If the only thing I read was the CARIN IG conformance, then I would think it was a singleton; if I then compared the CARIN example to the conformance I'd think the example was wrong for having an array. Only after going back to base FHIR would I see that it is actually an array and realize that the CARIN IG conformance mislead me.
Josh Lamb (Dec 09 2020 at 21:21):
@Michele Mottini in general I agree, I think the intent was to indicate that something is, as an example, either 'Primary' or 'Secondary' it cannot be both.
@Daniel Venton From a UI/Rendering perspective is this an issue? It may be, I am just trying to think of how that would help, or if it would add clutter. The structure definition will provide explicit type information.
Daniel Venton (Dec 09 2020 at 21:59):
I don't have a UI. What I have is a bunch of FHIR novices (myself inc) developing a server, which means there are questions around, the example has this, the output is this, the conformance page is this, the base FHIR says this doesn't that contradict what is here..... I know what it is now so I can explain it to them, I was hoping to forestall anybody being confused.
Saul Kravitz (Dec 09 2020 at 22:58):
@Daniel Venton - I think you are taking issue with FHIR IG rendering conventions, not the IG. Once the decision was made (not by me) to constrain the maximum cardinality of diagnosis.type to 1, that is how it looks. Always.
In other words, you would make the same comment about any IG that you looked at. To the extent that is correct, I recommend the IG Creation thread.
Last updated: Apr 12 2022 at 19:14 UTC
