ITI-68: incompatibility with the FHIR Binary read operation

[qligier]

Section Number 2:3.68.4.1.2 Message Semantics

Issue At the European Connectathon, we have seen multiple vendors using a regular FHIR Binary read URL as ITI-68 endpoint (e.g. DocumentReference.content.attachment.url = http://example.com/fhir/Binary/a54ef236-7e13-48be-951c-1ab7a6a2611f).

This seems to be non-compliant with the ITI-68 specifications in some edge cases:

• If the stored document is anything but a FHIR resource, and the ITI-68 request contains Accept: application/fhir+xml (or JSON) MHD should fail with a 406 Not Acceptable, or convert the document into a FHIR resource (document Bundle) FHIR should return the FHIR Binary.
• If the stored document is a FHIR resource, and the ITI-68 request contains Accept: application/fhir+xml (or JSON) MHD should return the document content (a FHIR resource). FHIR should return the FHIR Binary.

One might argue that transforming the stored document into a FHIR Binary is allowed by 2:3.68.4.1.2, so the first example is compliant. But the second one definitively isn't.

Is that incompatibility between both specifications already known?

Proposed Change If it is a deliberate choice, could an explicit warning be added to the ITI-68 specification to inform vendors the FHIR Binary read is not suitable as ITI-68 endpoint? If it is not a deliberate choice, should we discuss whether ITI-68 specifications should be updated to match the FHIR Binary read operation? The main argument in favour that I can think of is the simplicity of implementation (and unification of specifications).

Priority: Medium

@oliveregger FYI

[JohnMoehrke]

The Document Responder is completely empowered to use whatever URL format they want. The Document Consumer must not expect any specific URL format, they must just do a GET. The Document Responder can use a URL format that appears to look like a Binary endpoint, it is their choice. The Document Responder can invent their own URL encoding, including using url parameters.

Note in MHDS, where the Document Registry is persisting the documents, these URLs will be Binary endpoints.

see https://profiles.ihe.net/ITI/MHD/ITI-67.html#236742211-document-location

This does setup the situation you describe, and that situation is fully expected. If the Document Consumer really does put FHIR in the accept header higher up than the mime-type of the document, then they ARE ASKING for a FHIR encoding as higher priority, and thus getting a FHIR Binary should be expected.

This is explained - https://profiles.ihe.net/ITI/MHD/ITI-68.html#2368412-message-semantics

Meaning that the Document Consumer must understand what they have placed into the http accept header, as it could change the mime-type of the content returned.

I speak to the benefits of using http negotiate on the ITI-68 in my tutorials.