FHIR Chat · USCDR-13 - DocumentReference.content.attachment

Stream: inferno

Topic: USCDR-13 - DocumentReference.content.attachment

Cooper Thompson (Aug 30 2021 at 20:23):

Prior art:

Inferno Github Issue #316
Inferno Github Issue #261
Prior topic in this chat.fhir stream DocumentReference.content.attachment

Spec References:

Topic:
I want to bring up the DocumentReference.content.attachment must-support / us-core-6 invariant topic again, this time in light of the CCG clarification about choice elements:

"A Health IT Module must support at least one Choice or Reference for
US Core IG “must support” elements with multiple Choices or References, respectively. "

DocumentReference.content.attachment is labeled as must-support in 3.1.1. Right now, Inferno USCDR-13 is requiring that a server demonstrate support for both attachment.data and attachment.url. However, in light of the CCG clarification, it seems reasonable for Inferno to only require support for one or the other. I make this claim for a few reasons:

The CCG clarification uses the term "Choice", and the obvious interpretation of that is the choice[x] structure in FHIR, but attachment.data and attachment.url is functionally a "choice".
US Core 3.1.1 indicates that if a responder doesn't have the data, and doesn't know why, then it SHALL not return it. (Relevant note: US Core 3.1.1 indicates that if a responder doesn't have the data, but does know why, it should DAR it.)

#2 above is a little tricky, because DAR has an option of unsupported, but you have to figure out which entity is the responder. If the responder is the API server, then if it doesn't support something (i.e. it is unintentionally unsupported), then it doesn't know enough to DAR it. However if it is the developer of the API server, then they it might be intentionally unsupported, in which case a DAR would be fine.

Summary
Anyway - this all boils down to whether a server who only supports either attachment.data or attachment.url should pass Inferno's 3.1.1 g10 checks. The prior art above shows this is contentious, so I wanted to get consensus here before I throw another github issue at Inferno.

Michele Mottini (Aug 30 2021 at 20:27):

I think supporting one of the two should be enough. Clients won't mind (they have to support both in any case)

Yunwei Wang (Aug 30 2021 at 20:31):

@Michele Mottini That is an update in US Core 4.0.0.
The question is if there is wiggle room under US Core 3.1.1 which is required by (g)(10) test procedure.

Cooper Thompson (Aug 30 2021 at 20:51):

I think there are two different reasons why this could be fine in 3.1.1:

I think the CCG clarification should/could apply here. There is a conceptual "Choice" even though there isn't a "value[x]". This might be stretching the specific intent of the CCG update, but I think it is in line with the general intent of the CCG update
I think because of how 3.1.1 defines must-support, a non-DAR'ed "don't return anything" option is allowed for stuff the server just doesn't support.

Yunwei Wang (Aug 30 2021 at 20:54):

@Cooper Thompson
#1 they are not choices. Invariant us-core-6 state that both elements could be populated at the same time

us-core-6: DocumentReference.content.attachment.url or DocumentReference.content.attachment.data or both SHALL be present.

#2 The testing of MustSuppor is that a server has to demonstrate that it support all MustSupport elements. If a server never provide data with a specific MustSupprt element, then there is no evidence that the sever support such element.

Michele Mottini (Aug 30 2021 at 21:00):

??
requiring to support both does not really make sense: one of the two is enough - and the same data can be rendered in either really

Cooper Thompson (Aug 30 2021 at 21:04):

The us-core-6 invariant isn't what Inferno is using to justify checking both, right? There isn't any compliance language that I know about that requires a server to support all permutations of an invariant. And since that one is an "or", meeting only one of the expressions is sufficient.

Yunwei Wang (Aug 31 2021 at 13:31):

@Michele Mottini
It is not "required" to support both but MAY support both. While choice means SHALL NOT support both.
@Cooper Thompson
I agree that one is sufficient to pass resource validation. I used to indicate that these two are different than value[x] choice type because there is no chance that two choice values be provided in the same resource but it is possible to have both url and data in DocumentReference.

For each individual resource validation (USCDR-01 - USCDR-12), Inferno use us-core-6 to check that either url or data or both are provided in each USCDR resources.

For the MustSupport check (USCDR-13), Inferno looks through all USCDR resources received from previous tests (USCDR-01 to USCDR-11). The evidence that server supports these two MustSupport elements is that if there is at least one USCDR resource having url and at least one USCDR resource having data (it does not matter if they are the same resource or not).

Michele Mottini (Aug 31 2021 at 13:37):

The evidence that server supports these two MustSupport elements is that if there is at least one USCDR resource having url and at least one USCDR resource having data

Yes, my point is that checking ^ does not make any sense. Having just one or the other should be fine, because they are functionally interchangeable

Cooper Thompson (Aug 31 2021 at 13:41):

And my point is that checking that there are resources that support both url and data could be covered by that CCG clarification, if you consider url and data to be "Choices".

Cooper Thompson (Aug 31 2021 at 13:42):

Which means a server would only have to support one option in the list of choices, so only supporting one option across all resources would be ok.

Yunwei Wang (Aug 31 2021 at 13:57):

@Cooper Thompson CCG does say that

A Health IT Module must support at least one Choice or Reference for US Core IG “must support” elements with multiple Choices or References, respectively.

I think question here is that if Choice here is the FHIR choice type value[x] only or sub elements which could be considered as having or/xor relationship.