Updating DocumentReferences using XDS-on-FHIR

[unixoid]

Section Number Identify the most specific section number the issue occurs (e.g. 4.1.2)

3:4.5.1.2

Issue Describe your issue. Don't write a book, but do include enough to indicate what you see as a problem.

Imagine that both the Document Recipient and the Document Responder support the option "XDS on FHIR". A client (Document Source/Document Consumer) retrieves metadata of a document using ITI-67, and then wants to modify it using ITI-65 UpdateDocumentRefs. The Document Recipient will have to convert this request into an ITI-57 one. In the ITI-57 request, the attributes logicalID, repositoryUniqueID, version, and documentAvailability are required. The problem is that these XDS attributes are not mapped to any elements of the MHD ComprehensiveDocumentReference — therefore, the client could neither obtain them in the ITI-67 response nor provide them in the ITI-65 request.

Proposed Change Propose a resolution to your issue (e.g., suggested new wording or description of a way to address the issue). The committee might simply accept your suggested text. Even if they don't, it gives a good sense of what you are looking for. Leaving this blank means you can't imagine how to resolve the issue, which makes it easier for the committee to admit they can't imagine how to resolve it either and leave it unresolved.

In #234, a corresponding mapping is proposed. The attribute logicalID is mapped to a slice of DocumentReference.identifier, all other mentioned XDS attributes — to extensions.

Priority:

• High: Important issue where there is major issue to be resolved. Requires discussion and debate.
• Medium: Significant issue or clarification. Requires discussion, but should not lead to long debate.
• Low: Typo or other minor classification that an editor can manage. Requires no group discussion.

Medium

[JohnMoehrke]

This is not a practical use-case. Where as the application given is able to use Metadata Update, which uses eb-Registry technology; but is not able to use the XDS transactions to retrieve the data. I am not convinced that this is a useful reason to make MHD more difficult to use. This use-case is satisfied with XDS and MU.

[unixoid]

The application (Document Source/Consumer) can only FHIR and uses ITI-67/ITI-65.
The server (Document Recipient/Responder) is an MHD adapter to an XDS backend.

[JohnMoehrke]

MHD provides for no way to update an entry. MHD is only a search/retrieve API. So there is no applicability.