ConceptMap/$translate: match.originMap is emitted based on translation direction, not on whether the map was named explicitly

[jmandel]

Summary

On $translate, match.originMap (the provenance pointer to the contributing ConceptMap) is emitted for forward translations even when the caller named the map explicitly via url, and is never emitted for reverse translations — i.e. it is keyed to direction rather than to whether the map was explicitly supplied.

Internal-consistency/provenance issue (the mapping result itself is correct). The server's own code intends to suppress originMap for explicitly-named maps (if (!explicit)), but a parameter mix-up defeats that. originMap is not a normatively-specified output, so this is quality rather than strict conformance.

Relation to the withdrawn #218

#218 ("reverse translate … should not include an unrelated originMap") was withdrawn as non-reproducing — but it tested the reverse direction, where this bug never emits originMap. The defect actually shows on the forward direction (below), which is why #218 looked clean. This issue is that other half + the root cause.

Repro (live) — forward translate, explicit url, still emits originMap

curl -sS -X POST 'https://tx.fhir.org/r4/ConceptMap/$translate' \
  -H 'Content-Type: application/fhir+json' -d '{
  "resourceType":"Parameters","parameter":[
    {"name":"url","valueUri":"http://hl7.org/fhir/ConceptMap/cm-administrative-gender-v2"},
    {"name":"system","valueUri":"http://hl7.org/fhir/administrative-gender"},
    {"name":"code","valueCode":"male"}]}' | grep -o '"originMap"'
# => "originMap"  (present, despite the map being named explicitly)

Likely cause

doTranslate calls translateUsingGroupsForwards/Reverse(…, result, reverse, explicit) (8 args) but those functions declare 7 params ending in explicit; the 8th arg is dropped and reverse lands in the explicit slot. originMap is gated by if (!explicit), so forward (reverse falsy) always emits it and reverse (reverse truthy) never does — independent of the real explicit flag (set true when the caller supplies url).

Expected

originMap should track explicitness, not direction: suppressed when the map was named explicitly, present for an auto-discovered map — in either direction.

---

Confirmed live against https://tx.fhir.org on 2026-06-06 (software FHIRsmith 0.9.6). Source line refs are from the published main branch.

[grahamegrieve]

on reflection, and after consideration of both this case and discussion around other responses, I'm going to include origin Map always.