All

With the introduction of using alternate identifiers directly in ECL there is concern that the user may not be clear about what substrate is being used and what semantics that substrate has.

• Semantics of LOINC and its use in ECL:
  • DK- The LOINC domain is fairly flat.
    
    • Subtypes may come in when one concept may have a method specified and another code is very similar but does not have method specified.
    • Loinc parts may also have subsumption

We added the following warning in the ECL guide in the alternate identifiers section:

• ECL is always evaluated against SNOMED CT concepts. When you run a query using alternate identifiers from another code system only concepts that are in the SNOMED CT representation of that other code system will be returned. For example the descendants of a concept in the SNOMED CT version of a code system is likely to be different from the code system of the alternate identifier.

• Kai Kewley Send SLPG proposition to LOINC extension group. We suggest that a Map should be included in the LOINC extension, in addition to alt identifiers. This will enable terminology servers to translate back and forth between LOINC and SNOMED CT codes in the existing standard way. We are updating ECL to allow SNOMED CT concepts to be referenced using alternate identifiers. However if there is a requirement to translate ECL results back to LOINC codes then a map refset is the obvious way.

All

Discussion:

How to make it easier to add an ECL capability to more tooling?

• SI already has open source implementations
• The specification is now very large. An ECL Lite profile would reduce the months of effort required to implement the whole specification when starting fresh.

ECL Lite - MVP Scope:

• *, <, <<, >, >>, <!, !>, ^, AND, OR, MINUS, (), {{ +HISTORY-(MIN,MOD,MAX) }}
• Maybe? {{ C active }}