Stream: argonaut
Topic: Filters in valuesets
Caitlin Voegele (Feb 04 2022 at 17:57):
We have a customer that is trying to load and validate patients against US Core that have race defined by this valueset: http://hl7.org/fhir/us/core/ValueSet-detailed-race.json.html
Currently, the FHIR server we are using does not support filters in valuesets so a few questions:
- By not supporting this valueset, does that mean we do not support US Core?
- Has anyone found a good workaround for not supporting filters besides adding the support :)?
Thanks so much!
Josh Mandel (Feb 04 2022 at 18:01):
"Support US Core" means being able to perform all of the functions of either a client or a server, per http://hl7.org/fhir/us/core/capability-statements.html
Josh Mandel (Feb 04 2022 at 18:03):
- Basically for a server this means storing and serving data conforming to US Core profiles. Technically you don't need to be able to validate resources to meet this bar... but in practice, if you're providing the infrastructure for an org, it's very helpful if the infrastructure can answer questions like "does this resource that the org created actually meet the profile expectations" so that'd be a very important feature IMHO.
Josh Mandel (Feb 04 2022 at 18:03):
- It's not clear what a "workaround" means here; you could always hard-code support for a specific (hand-curated) expansion of this valueset definition without ever reading/processing the computable definiton. You don't need to do any automated processing of the formal ValueSet definitions in order to use them.
Yunwei Wang (Feb 04 2022 at 20:19):
- When you say "supporting filters", what do you mean?
- When you say "not supporting this valueset", do you mean you don't have any date saved using any values from this valueset?
Paul Church (Feb 04 2022 at 20:26):
This might be kind of philosophical but I think there's an interesting disconnect in what "supporting an IG" means to different people.
From the EHR or facade perspective, I think it means mapping your internal data model into the model defined by the IG, and then putting an API in front of it that meets the capability statement. There's no need for full runtime validation of resources, because the mapping that creates them is designed to make them conformant.
From the general-purpose FHIR server perspective...we support every field and extension, and we have an implementation of basically all of the REST API surface. So given a few customizable extras like custom search parameters, I guess we support every IG that could ever exist? (Okay, bespoke extended operations are a problem.) But this doesn't seem like enough without profile validation when writing resources to the server - or else the server is just serving up anything, conformant or not. So that's what is increasingly being implemented, in various servers.
In the EHR pattern, the valuesets don't really need to be actual fhir ValueSet resources loaded in the server. Some data analyst can just look at a human-readable description while doing mapping, and that's enough. Having all of them available as fhir artifacts to use for runtime validation is a new expectation that runs into some problems - e.g. CARIN BB has several licensed valuesets that they're unable to publish, so assembling the artifacts the implementer needs for runtime profile validation is not trivial. There is also a big functional difference between these little enum types that have half a dozen values, vs. "all of SNOMED". The Google implementation is able to validate small or medium-ish sized valuesets, but validating against huge terminologies is not really supported.
Last updated: Apr 12 2022 at 19:14 UTC
