See https://chat.fhir.org/#narrow/stream/179166-implementers/topic/.22distinct.22.20search/near/176041645

The motivaing use cases are:

1) Returning a distinct list of Codings in currently existing Observations in the server, and filtered by some paritial string (e.g. "we" for matching codes with "weight" in the display string).

2) Returning a distinct list of Observation.category Codings (again, for value currently in existing Observations)

3) Returning a distinct list of Observation.meta.tag Codings.

The solution proposed by Grahame is to add a new value, "existing", for the contextMode parameter (which seems to be now called "contextDirection") to the ValueSet $expand operation, so that

http://test.fhir.org/r4/ValueSet/$expand?context=Observation.code&contextDirection=existing&count=5&filter=we

would return up to 5 distinct Observation.code Codings actually used by exsiting Observations whose display text matches "we" (per the usual meaning of "filter"-- I am not proposing a change on that point here).

Note that this differs from the "outgoing" option of contextDirection, which would refer to a list of potential Codings, not necessarily used by existing Observations.