Stream: CARIN IG for Blue Button®
Topic: Explanation Of Benefit meta.profile
Daniel Venton (Dec 02 2020 at 14:24):
The IG says, (from inpatient
Name Flags Card. Type Description & Constraintsdoco
.. ExplanationOfBenefit I 0..* C4BBExplanationOfBenefit Explanation of Benefit resource
... meta SΣ 1..1 Meta Metadata about the resource
.... profile SΣ 1..* canonical(StructureDefinition) Profiles this resource claims to conform to
What it doesn't say is what the value shall be.
I can look at an example, BUT I don't think coding to an example (which may not be correct) is the correct thing to do.
"meta" : {
"lastUpdated" : "2019-12-12T09:14:11+00:00",
"profile" : [
"http://hl7.org/fhir/us/carin-bb/StructureDefinition/C4BB-ExplanationOfBenefit-Inpatient-Institutional"
]
},
Is that the value that conformance requires? If so where is it stated in the IG (non-example)?
Saul Kravitz (Dec 02 2020 at 18:29):
Good point! Not sure whether this is best specified with an invariant (one of the elements of meta.profile must refer to the appropriate profile) or through a hard coded constraint.
Saul Kravitz (Dec 03 2020 at 14:08):
See discussion here: https://chat.fhir.org/#narrow/stream/215610-shorthand/topic/meta.2Eprofile.20requirement
Josh Lamb (Dec 03 2020 at 18:02):
I think the heart of this issue is that the profile should not require meta.profile for validation since the data within the model can change and the validity of the profile will always need verified. Also, the client posting the data may not be aware of every profile the resource conforms to. By keeping this as optional (will not fail during profile validation) we can validate first, and include the profile in meta.profile when appropriate. There are some cases, such as Inpatient vs Outpatient where a single resource could be valid according to two profiles. In this case it may be beneficial to assert the desired profile beforehand.
Paul Knapp (Dec 03 2020 at 18:41):
It is beneficial to declare the profile to which an instance is intended to conform as you often cannot determine instance accuracy from the instance alone. That an instance conforms to multiple profiles is often not useful, and certainly it is not efficient to take each instance received and then check it's conformance to all known profiles to derive an assumption of what was intended.
For example, profile A has element x as optional, profile B has element x as required. If an instance received does not include element x is it a valid instance of profile A and therefore may be accepted or an invalid instance of profile B and therefore should be rejected?
Josh Lamb (Dec 03 2020 at 19:48):
Good points Paul. I agree this does not sound efficient. Both approaches are supported though by leaving meta.profile as optional.
Saul Kravitz (Dec 03 2020 at 21:49):
This was debated, and the decision was made to require the profile be declared. The implementation of that decision by yours. truly in the IG was incorrect. Now I know how to do it correctly.
Last updated: Apr 12 2022 at 19:14 UTC
