Relative References with the Same Logical Identifier should throw an error

[prb112]

Describe the bug
Relative References with the Same Logical Identifier should throw an error on Search

For searches on subject=1 that use a SearchParameter like the following:

    {
      "fullUrl": "http://hl7.org/fhir/SearchParameter/Account-subject",
      "resource": {
        "resourceType": "SearchParameter",
        "id": "Account-subject",
          "description": "The entity that caused the expenses",
        "code": "subject",
        "base": [
          "Account"
        ],
        "type": "reference",
        "expression": "Account.subject",
        "target": [
          "Practitioner",
          "Organization",
          "Device",
          "Patient",
          "HealthcareService",
          "PractitionerRole",
          "Location"
        ]
      }
    }

abbreviated to highlight the problem

The target is extracted and matrixed with the input identifier to generate a logical reference, such as:

• Practitioner/1
• Organization/1
• et cetra

In the specific case where there are TWO relative references with the same Logical Identifier should throw an error, as stated in 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.

To Reproduce
Steps to reproduce the behavior:

1. Create a Practitioner Resource with ID 1
2. Create a Organization Resource with ID 1
3. Search with subject=1

Expected behavior
Throw an error in the case of the reference ID being duplicate.

Additional context
n/a

[michaelwschroeder]

After discussion with the team, the following was agreed upon with respect to references that only contain a logical ID:

1. A logical ID-only reference is not valid to be stored in a resource’s reference field, but since we currently allow it, we need to make it a configuration option as to whether or not an error is generated at create/update time in order not to break existing resources.
2. If configured to accept logical ID-only, we should index as an absolute reference at create/update time.
3. Logical ID-only references should be treated as absolute references, but to resources that don't exist on the server.
4. Logical ID-only values are valid as reference search parameter values, and should match on any resources of valid target type with that logical ID. If resources with multiple target types are returned, we will fail the search (per this issue).
5. Logical ID-only references used in chain or include or compartment type searches should not return any matches (based on Update the server.xml to reflect the OpenSource pacakage name in the trace specification. #3 above).

Given this set of rules, the search scenarios identified for this issue will be handled as follows:

1. Standard search where reference parameter value is a logical ID
   Example: Observation?subject=123

   Solution: Execute search, return error if the references that the returned resources matched on contain multiple resource types for the same logical ID.

2. Chain/ReverseChain search where final search parameter is type reference and value is a logical ID
   Examples:
   Condition?encounter.subject=123
Patient?_has:Observation:patient:performer=123

   This is just a variation of scenario Update docs/Conformance.md for R4 #1.

   Solution: Return error before executing search if there's a possibility of matching on multiple resource types, based on the reference search parameter having multiple target types.

3. Chain/ReverseChain search where chaining parameter value is a logical ID

   Examples (where ‘subject’ value is a logical ID):
   Observation?subject:Patient.name=Joe
Patient?_has:Observation:subject:code=xyz

   Solution: No matches returned for the chaining parameter (based on rule Update the server.xml to reflect the OpenSource pacakage name in the trace specification. #3 above). Since this is our current behavior, no change is required for this scenario.

4. Include/Revinclude search where inclusion parameter value is a logical ID

   Example (where ‘subject’ value is a logical ID):
   Observation?_include=Observation:subject
Patient?_revinclude=Observation:subject

   Solution: No matches returned for the inclusion parameter (based on rule Update the server.xml to reflect the OpenSource pacakage name in the trace specification. #3 above). Since this is our current behavior, no change is required for this scenario.

5. Compartment search where inclusion criteria parameter value is a logical ID

   Example (where ‘Observation.subject’ value is a logical ID):
   Patient/123/Observation

   Solution: No matches returned for the inclusion criteria parameter (based on rule Update the server.xml to reflect the OpenSource pacakage name in the trace specification. #3 above). Since this is our current behavior, no change is required for this scenario.

[d0roppe]

verified message issued when needed.