In FHIR, there’s a neat feature called implicit ValueSets. These don’t need to be defined or published anywhere. They exist because the server knows how to interpret the request. You ask for an expansion, and the server builds the ValueSet on the fly. No authoring. No versioning. No fuss.
This capability is mostly tailored for SNOMED CT, and it’s described in the FHIR spec. There are five different implicit ValueSet URL patterns you can use, but in practice I only ever use one.
?fhir_vs=ecl/[ecl]
{{TerminologyServer}}/ValueSet/$expand?url=http://snomed.info/sct?fhir_vs=ecl/(^852631000168103)
This ECL variant is the only one I bother with. Why? Because it can do everything the others can, and more.
- Want all concept IDs in the edition? Write the ECL for it.
- Want all subtypes of a concept? Write the ECL for it.
- Want the members of a published reference set? Write the ECL for it.
- Want to combine all of these, filter by terms, include descendants, exclude subhierarchies, or mix multiple criteria? ECL handles it.
I live by the Keep It Simple maxim. Arguably, some of the other options look simpler, but why deal with a whole toolbox when there’s a multitool available?
So if you’re working with SNOMED CT in FHIR, you probably only need one implicit ValueSet URL pattern: the ECL one. It’s flexible, expressive, and saves you from having to manage published ValueSets unless you truly need to.