FHIR Chat · Reference search parameter and resource versions · fhir/infrastructure-wg

Stream: fhir/infrastructure-wg

Topic: Reference search parameter and resource versions

Vassil Peytchev (Jun 11 2021 at 17:47):

In a discussion in #implementers , we got to a use case where there is a reference that is likely to point to a specific version of a resource (in the particular case Provenance.target). If I want to find all instances of a resource that references any version of the referenced resource, how do we search for it?

It seems that the following is the most straight-forward (assuming that target is the reference parameter):

1. Obtain the un-versioned referenced resource. The latest version is available in the ETag.
2. Use a parameter search: GET [base]/MainResource?target:below=[base]/ReferencedResource/[id]/_history/[latest version]

The problem is that the :below modifier is explicitly described working with versions for canonical references. Would it apply to regular references?

Alternatively, what is the result if a search is using a non-versioned reference - is it supposed to match versioned and un-versioned references, or only un-versioned ones?

@Paul Church @Elliot Silver (who were part of the previous discussion) @John Moehrke (because this seems to be something Provenance.target really needs).

Elliot Silver (Jun 11 2021 at 17:57):

Aah, canonical... you had to throw that extra wrench in there -- do you want to search against the business version or the resource history version? Perhaps overloading :below for both isn't the best approach.

Paul Church (Jun 11 2021 at 18:06):

Our interpretation was that an un-versioned search only matches un-versioned references, and :below doesn't apply here.

This does sound like a useful search, especially for Provenance.target (find all provenances applying to any version of the resource). I can't think of any way to construct that search using my current interpretations.

I think there's some ambiguity if we made un-versioned search match versioned references....the un-versioned name of a resource is the identity of the current version, so matching references to past versions might not be what the client wants.

Adding :below is a possibility but with it already applying to canonical and URI, will there be cases that don't make sense?

John Moehrke (Jun 14 2021 at 18:13):

I don't know. I think I heard that if you requested a historic version, you would be given the current, unless you did something special to force retriavl of that specific historic version....

John Moehrke (Jun 14 2021 at 18:13):

@Grahame Grieve ? @Lloyd McKenzie ?

Grahame Grieve (Jun 14 2021 at 18:16):

I don't knbow

Alexander Zautke (Apr 05 2022 at 12:58):

Paul Church said:

Our interpretation was that an un-versioned search only matches un-versioned references, and :below doesn't apply here. [...]

Is this the interpretation that most other implementations follow? Our server behaves exactly like this. We just received a customer request questioning that behaviour, exactly for the same use case outlined above.

Alexander Zautke (Apr 05 2022 at 17:36):

Would there be sufficient support from others to clarify that unversioned references should only match unversioned references in the instance?

Lloyd McKenzie (Apr 05 2022 at 20:24):

Not sure what you mean. References match instances, not other references...

Alexander Zautke (Apr 06 2022 at 05:58):

I meant that it’s clarified that if you have a unversioned reference as the search parameter value, this search only matches if there is an unversioned reference in the instance. If the instance has a versioned reference in it, there should be no match.

John Moehrke (Apr 06 2022 at 12:49):

maybe you need to provide an example. I am confused on what you are describing as "unversioned reference as the search parameter value". I am not confused by each word, but by the string of words you use. -- a search on an unversioned reference will get you the latest, indeed it is hard to get anything but the latest, as the default for a versioned reference is to give you the latest.

Alexander Zautke (Apr 06 2022 at 13:00):

Say you have a Provenance instance with a versioned reference as the target:

{
  "resourceType": "Provenance",
  "target": [{
     "reference": "Patient/example/_history/1234"
   }]
}

Now you are executing a search on that target:

[base]/Provenance?target=Patient/example

Should this match the instance or not?

Alexander Zautke (Apr 06 2022 at 13:00):

In the thread above it was indicated that it should not match. However, as far as I can see, the spec is silent about it.

John Moehrke (Apr 06 2022 at 13:13):

Your example

[base]/Provenance?target=Patient/example
is just a normal search. You should get the latest instance of that Patient resource... regardless of how many versions are available.

Note your search example has nothing to do with the Provenance instance you give. Or, I am not understanding the relationship you are seeing.

Where do you see in the FHIR specification statements different than that?

Alexander Zautke (Apr 06 2022 at 13:24):

This was the first question raised by Vassil Peytchev said:

Alternatively, what is the result if a search is using a non-versioned reference - is it supposed to match versioned and un-versioned references, or only un-versioned ones?

Alexander Zautke (Apr 06 2022 at 13:26):

My question was if everyone follows the interpretation of Paul Church said:

Our interpretation was that an un-versioned search only matches un-versioned references, and :below doesn't apply here.

Alexander Zautke (Apr 06 2022 at 13:27):

There is nothing in the spec indicate if it should match or not

Alexander Zautke (Apr 06 2022 at 13:36):

I would expect that the Provenance instance is returned if I search using

[base]/Provenance?target=Patient/example/_history/1234

Should the instance also be returned if I use the latest / unversioned reference

Alexander Zautke (Apr 06 2022 at 13:41):

Also note that the first paragraph of section "3.1.1.4.12 reference" does not say that you are allowed to have history part in the search parameter value.

Alexander Zautke (Apr 06 2022 at 13:45):

Does this clarify the question or am I missing something essential here?

Josh Mandel (Apr 06 2022 at 14:07):

I think the question is clear. I'll say from a client perspective, if I'm trying to find all (current) Observations referencing Patient 123, it'd be confusing (and beyond my control) if some Observations weren't returned simply because they were referencing Patient 123 in a more specific way. (Note of course that even a version specific reference to Patient 123 might currently be pointing to the latest version, which surely every client searching by reference would want to find).

John Moehrke (Apr 06 2022 at 14:08):

I guess that is why i was confused on the question... because I agree with @Josh Mandel that there is no possible way for this to be anyother way.

Alexander Zautke (Apr 06 2022 at 15:59):

A quick test against different test servers result in different behaviour here. So I think it would be good to clarify this.

Alexander Zautke (Apr 06 2022 at 15:59):

https://jira.hl7.org/browse/FHIR-36716

Alexander Zautke (Apr 06 2022 at 15:59):

https://jira.hl7.org/browse/FHIR-36715

Gino Canessa (Apr 06 2022 at 16:20):

I feel like there is a pitfall here, but I am not quite sure how to express it... apologies and thanks as I work through this in stream =).

I guess I am trying to figure out why/when resources are pinned to a specific version, and if it is safe to assume version resolution.

For example, if you are resolving the target of an AuditEvent, it is likely important that it resolves only the exact version referenced (returning the current version would be wrong and could cause legal trouble). So if I want to know exactly who accessed Patient/example/_history/1234, I do not want the records for version 1233, nor do I want logs for version 1235.

In Josh's example, why would someone pin an Observation to a specific version of a patient? If a system/app/user does that, is it safe for us to assume any other version is okay?

John Moehrke (Apr 06 2022 at 16:28):

This is not a question about when a version specific reference is a query parameter, I understood it as a question when a non-version specific reference is a query parameter, which is also different than a GET of a URL that is version or non-version specific (not search, read/vread).

John Moehrke (Apr 06 2022 at 16:29):

if a version specific reference is in a query parameter, surely one should just return resources with that version specific reference (like the Provenance example). right?

Lloyd McKenzie (Apr 06 2022 at 16:30):

If you search for prescriptions for Patient 123, you should get all MedicationRequests with a subject of Patient 123 - regardless of whether the references are version-specific or not.

John Moehrke (Apr 06 2022 at 16:30):

agree

John Moehrke (Apr 06 2022 at 16:31):

and I think that is the first example Alex provides.

John Moehrke (Apr 06 2022 at 16:32):

the second perspective, that Gino is focused on, is where search parameter includes a version specific value... that seems should only return for THAT version matching, not all. so what you specify in the search matters.

John Moehrke (Apr 06 2022 at 16:34):

so

[base]/Provenance?target=Patient/example/_history/1234

should return only Provenance instances where .target has specifically version 1234 in it... not others.

but

[base]/Provenance?target=Patient/example

should return ALL Provenance with any version of Patient/example

John Moehrke (Apr 06 2022 at 16:35):

Alexander Zautke said:

My question was if everyone follows the interpretation of Paul Church said:

Our interpretation was that an un-versioned search only matches un-versioned references, and :below doesn't apply here.

so this seems wrong

Gino Canessa (Apr 06 2022 at 16:55):

Thanks!

Regarding the below modifier, we just 'audited' the modifier <-> type mappings (FHIR-36684), and reference does not have a definition for them. Note that it doesn't mean it is not implementable (e.g., server-specific behavior), just that behavior is undefined according to the spec.

I think the behavior of version searching needs to be clarified before the modifiers can be discussed though. For example, if target=Patient/example implicitly includes references of Patient/example/_history/x, then the type already includes behavior equivalent to the uri definition of below.

Josh Mandel (Apr 06 2022 at 17:53):

Re: uri search behavior vs reference search behalf... While canonical resources have an explicit notion of resource.version, this is different than resource.meta.versionId -- I'm not sure we want to conflate these

Gino Canessa (Apr 06 2022 at 18:16):

Yes, I was referring to how above and below are already defined on uri. Namely that [Resource]/[id] is hierarchically defined to exist above [Resource]/[id]/_history/[version] per a pathing mechanic on the uri.

Gino Canessa (Apr 06 2022 at 18:16):

It does not do anything about actual version references (e.g., you cannot ask for versions above/below '3')

John Moehrke (Apr 06 2022 at 18:30):

is that needed? I understand an academic argument that it is possible, but struggle with real use-case.

Gino Canessa (Apr 06 2022 at 18:40):

:shrug: No idea on need/use, just noting that it is there and normative.

Last updated: Apr 12 2022 at 19:14 UTC