custodian should not be forbidden
Closed this issue · 4 comments
Given that there are use-cases where custodian is different than the Registry, and some may want to populate it. Should the .custodian element be allowed?
allow on Search results, but is this already allowed by the Postel's Law indicating non-conformant results may be returned?
on ITI-65, with XDS, might need to yet forbid it? Or is there someplace in XDS DocumentEntry for this kind of thing? Or do we allow XDS to drop the element? Document Recipient grouped with XDS should drop the .custodian value.
ITI-65 already has a statement that allows flexibility.
Some FHIR elements do not translate to XDS concepts; the handling of these elements is left to the implementer of the Document Recipient. "
ITI-66 and ITI-67 already had statements about Document Consumers being robust
The Document Consumer shall process the results according to application-defined rules. The Document Consumer should be robust as the response may contain DocumentReference Resources that match the query parameters but are not compliant with the DocumentReference constraints defined here.
But ITI-66 and ITI-67 indicate too strongly that the Document Responder will fill the response bundle with compliant resources. Using the non-normative word "will". Changed to "may"
The DocumentReference Resources returned may be compliant with the MHD metadata for the IHE restrictions on DocumentReference Resource and with the mapping to DocumentEntry from IHE Document Sharing profiles (e.g., XDS) to FHIR.
custodian was forbidden, now is allowed but with no defined XDS map.
@JohnMoehrke - change may to should on search results.