Implicit base not picked up in FHIR Reference search

[prb112]

Implicit base not picked up in fhir-search... When executing the Search -> extractParameterValues with resolve(), the fhir-search module and persistence layer extracts only Patient/.

For example... consider "code" : "patient", the extractParameterValues processes a JSON:

"subject": {
        "reference": "Patient/1-2-3-4"
    },

and stores the value Patient/1-2-3-4.

The specification says the following are valid search query parameters:

[parameter]=[id] the logical [id] of a resource using a local reference (i.e. a relative reference)
[parameter]=[type]/[id] the logical [id] of a resource of a specified type using a local reference (i.e. a relative reference), for when the reference can point to different types of resources (e.g. Observation.subject)
[parameter]=[url] where the [url] is an absolute URL - a reference to a resource by its absolute location, or by it's canonical URL

Upon executing the request to
https://<SERVER>:443/<ROOT>/api/v4/MedicationRequest?patient=1-2-3-4
The request should return the resource body, however, we only support the specification #2.

The first behavior must be implemented, and the third behavior must be confirmed.

Note, the request with subject:Patient resource type works:
GET https://:443//api/v4/MedicationRequest?subject:Patient=1-2-3-4

URL: https://hl7.org/fhir/R4/search.html
In some cases, search parameters are defined with an implicitly limited scope. For example, Observation has an element subject, which is a reference to one of a number of types. This has a matching search parameter subject, which refers to any of the possible types. In addition to this, there is another search parameter patient, which also refers to Observation.subject, but is limited to only include references of type Patient. When using the patient search parameter, there is no need to specify ":Patient" as a modifier, or "Patient/" in the search value, as this must always be true.

[lmsurpre]

Be sure to uncomment corresponding tests in AbstractSearchReferenceTest

        // TODO does this work if you define the extension in a StructureDefinition 
        // and declare the allowed types? 
//        assertSearchReturnsSavedResource("Reference-id", "Patient/123");

[prb112]

We hit this again in the Connectathon 25. It'd be nice to nail this one.

[kmbarton423]

Inferno tests are not returning expected resources:
{{base}}{{contextRoot}}AllergyIntolerance?patient=1748dd8e606-de9c1bdf-3ecc-4e2f-b496-f2232ea77e1d

[lmsurpre]

We found the following text from https://www.hl7.org/fhir/search.html#reference

Some references may point to more than one type of resource; e.g. subject: Reference(Patient|Group|Device|..). In these cases, multiple resources may have the same logical identifier. Servers SHOULD reject a search where the logical id refers to more than one matching resource across different types.

This means that we should try to infer the resource type even in cases where the search parameter refers to multiple different types. Based on this text, it seems that omitting the resource type while searching a reference is really only an error if the target identifier exists in one or more of the target resource types that is being searched.

For this issue (#300) lets just focus on adding the implicit types at the fhir-search layer. We'll handle "is there more than one matching resource type with this id" in #1553