Reference.identifier is not encoded

[chgl]

Describe the bug We create resources that set both Reference.reference and Reference.identifier for references to Patient and Encounter resources.

For example:

{
  "resourceType": "Condition",
  "id": "123",
  "subject": {
    "reference": "Patient/456",
    "identifier": {
      "type": {
        "coding": [
          {
            "system": "http://terminology.hl7.org/CodeSystem/v2-0203",
            "code": "MR"
          }
        ]
      },
      "system": "https://fhir.example.com/identifiers/mrn",
      "value": "123456789"
    }
  }
}

However, while Condition.subject.reference is encoded correctly, the Condition.subject.identifier is ignored. The following SQL:

SELECT subject
FROM delta.`s3a://pathling-warehouse/default/Condition.parquet`

returns only:

{"reference":"Patient/456","display":null,"_fid":447035444}

The FHIR spec https://hl7.org/fhir/R4B/references.html#logical states:

When both logical and literal references are provided, the literal reference is preferred. Applications processing the resource are allowed - but not required - to check that the identifier matches the literal reference, if they understand how to resolve the logical reference.

So this does make sense, but it would still be nice to have it preserved.

To Reproduce

1. Create a resource referencing a different resource with both (or just setting the Reference.identifer might do the trick), like in the example above
2. POST it to the Pathling Server to have it encoded
3. Observe that the encoded resource no longer contains the Reference.identifier

Expected behavior

Both the Reference.reference and Reference.identifier should be preserved when encoding.

This is definitely nothing critical, it's just a helpful extra-information we include in resources to make identification easier.

[chgl]

Might be a duplicate for or related to https://github.com/aehrc/pathling/issues/217 - in my case at least being able to join/resolve via logical references isn't necessary.

[johngrimes]

Thanks for sending this through @chgl!

I don't think this is a duplicate, as this merely refers to the preservation of the data through the encoding process.

This is certainly our goal, so we will treat this as a defect and will work on a fix for the next release.