MHD_067: Consider alignment with $docref operation in IPA

[slagesse-epic]

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

2:3.67

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

ITI-67 is currently based on the FHIR DocumentReference.search operation. Other interoperability standards, such as International Patient Access and US-Core, have proposed a $docref operation (IPA, IPS, US-Core to accomplish this goal.

$docref has the following advantages over DocumentReference.serach:

• It has a parameter for on-demand status, which is missing from DocumentRefernece.search
• It is easier to implement as a standalone API when not a part of a full FHIR server. For example, a server that wants to be compliant with DocumentReference.search would need to support the _id search parameter, where this is not necessary to claim $docref support.

The latter point might be of particular interest to MHD, given that an API layer in front of an XDS community might not have the ability to reasonably allow searching on Resource IDs.

The downside of $docref is that it has far fewer parameters than DocumentReference.search, which might be a problem for clients that wish to do a fairly granular search.

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.

Consider whether $docref fulfils a purpose in ITI-67 or if a new transaction that would be an alternate to ITI-67 would make sense to support MHD use cases.

Priority:

• High: Important issue where there is major issue to be resolved. Requires discussion and debate.

[slagesse-epic]

Some interesting prior discussion:

https://chat.fhir.org/#narrow/stream/179175-argonaut/topic/US.20Core.20GF.2320066.20re.20the.20Fetch.20DocRef.20operation

https://chat.fhir.org/#narrow/stream/261969-IPA/topic/docref

[JohnMoehrke]

It is also only defined in US-Core, so not clear how we can use it in an international specification
https://hl7.org/fhir/us/core/OperationDefinition-docref.html

Further, the documentation is poor quality. It says that there is only 3 parameters, but there are actually 5 parameters.

The documentation tries to define the distinction from RESTful search. It puts forth weak statements, then contradicts those statements.

The best aspect of $docref is that it does indicate a way for a client to express that the client is ONLY interested in on-demand. Well, it then says that this can distinguish on-demand, stable (and something about delayed assembly) but the Input parameter is a boolean, so not clear how one gets a tristate out of a boolean.

In MHD this is not possible, one would have to filter the resulting search locally to find those entries in the search bundle that are on-demand vs stable.

One could imagine a well defined operation that is used to get "the one and only latest medical summary". Not all of the previous stable snapshots. Just ONE. Thus making it easier on the client. However this too is somewhat difficult in a multi-depth federation where multiple authoring sites might be able to provide THEIR latest summary.

[slagesse-epic]

$docRef is defined in IPA which is an international specification. See https://build.fhir.org/ig/HL7/fhir-ipa/OperationDefinition-docref.html

The $summary operation sounds like your last suggestion, but I agree that $summary probably won't work well in federated environments.

[JohnMoehrke]

Having $docRef defined in IPA is not helpful. How can MHD have a specification requirement only for $docRef without pulling in all of IPA? This is not a very modular friendly approach.

I am still convinced that $docRef is useful, but not really MHD relevant. It seems an alternative that would not be forbidden, but does not seem useful to bring into MHD.

[JohnMoehrke]

on call decided to defer this to future. Create an Open-Issue. And send a notification email to ITITECH to see if anyone wants to come forward with persuasive arguments to continue developing it.

The operation is not yet defined in a released IG, soon IPA. There is concern with needing to dependon all of IPA at that time. We could define similar but different operation, but that seems to not be useful.

[JohnMoehrke]

now identified as Open-Issue MHD_067 and linked here to capture any comments the community offers.