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 common).

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 artefacts.

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.

- thomas

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

Reply via email to