Want to support filters in valuesets

[CaitlinV39]

User story
As a implementer of US core, I want the ability to support filters in valuesets so that I can use https://hl7.org/fhir/us/core/ValueSet-detailed-race.json.html with my patients.

Acceptance criteria

1. When I do $validate against customers with race in https://hl7.org/fhir/us/core/ValueSet-detailed-race.json.html I am able to.

This is related to this fire.ly issue: FirelyTeam/firely-net-sdk#1956

We could wait until fire.ly supports it or take their recommendations.

[CaitlinV39]

https://www.hl7.org/fhir/us/core/ValueSet-detailed-ethnicity.json.html
https://www.hl7.org/fhir/us/core/ValueSet-detailed-race.json.html
https://www.hl7.org/fhir/us/core/ValueSet-simple-language.json.html
https://www.hl7.org/fhir/us/core/ValueSet-us-core-condition-code.json.html
https://www.hl7.org/fhir/us/core/ValueSet-us-core-diagnosticreport-lab-codes.json.html
https://www.hl7.org/fhir/us/core/ValueSet-us-core-documentreference-type.json.html
https://www.hl7.org/fhir/us/core/ValueSet-us-core-encounter-type.json.html
https://www.hl7.org/fhir/us/core/ValueSet-us-core-procedure-code.json.html

[brianpos]

This would require use of more detailed terminology services - and wouldn't expect to find this to be acceptably performant in the SDK.
For performance reasons I would recommend that the MS server implement a basic level of terminology services (including this level) which would give far better performance, and use less memory/processing in the server.
That race & ethnicity set is a 3 level system with 964 codes in it that would need to be loaded into memory, then filtered in memory, which is a role better served for some form of query (leveraging indexing) rather than the brute forcing that would be here - or in mem indexing created for it, and thus using up more memory space.

[CraigP68]

AB#89463