On 03/05/2017 14:04, michael.law...@csiro.au wrote:
I think this thread has gone a little off the rails.
There are predefined (by FHIR) URIs for value sets that are defined
just as descendants of a single concept, or members of a reference set.
For an enumeration of concepts and/or a snomed ECL expression, then
you can use a Fhir ValueSet and give it a URI. ValueSets also
generalise beyond just SNOMED (LOINC for example).
Furthermore, there are existing tools to expand them to the set of
member concepts, you can include metadata, manage versions etc. This
is much more than you get just by encoding ECL in a URI.
right - but this is the argument that the definition of structured value
sets (i.e. intensional ref-sets) should live in terminology services
somewhere, and not in archetypes or other source model locations (a view
I espoused for many years, and not very popular...). The
counter-argument is that while this is fine for subsets like 'blood
phenotype' or whatever, no-one wants to pollute terminology services
with thousands of ECL expressions that are purely local to an
information artefact (i.e. some very specific permutation, also very
I am starting to think that we need a new artefact which is a kind of
local terminology expression 'library' - probably just a file - that is
associated with any collection of archetypes of similar information
The specific problem we are trying to solve here is 'terminology
binding', not just terminology expressions, which I think are pretty
well defined. Where bindings live is not a simple question, because the
answer depends on what the binding is to.
Aside: the ontoserver tool is very nice, people should have a look if
they have not already.
In case anyone wants to play with ECL expressions and their evaluation
you can go here for an interactive page:
Also, some brief documentation and click-through examples here
openEHR-technical mailing list