Accept URI-style terminology ids.


Current spec does not allow URI-style terminology ids; various solutions appear possible:

Additionally create a mapping table for openEHR of all terminology namespace names like 'SNOMED-CT', 'loinc'.


Erik Sundvall
November 6, 2018, 9:46 PM

Having a mapping table and short clear terminology id's may actually lead to more readable AQL-queries etc than full URIs (in addition to being backwards compatible). Inspired by Seref's notion of namespaces, I think we can take it a bit further if we use "URI-templates" instead that can include/map more patterns and more than on varaible, for example, TERMINOLOGY_ID.version (and for some cases even provide a way to include/extract CODE_PHRASE.code_string within URIs)

Several libraries:

Bjørn Næss
September 21, 2020, 10:49 AM

In general - do we need any constraints on terminology id? Can’t we just accept any string?

Ian McNicoll
September 21, 2020, 11:38 AM

In reality there are no enforced rules - or good sources for formal ‘namespaces’ other than those defined by FHIR and SNOMED.

I think we should strip ‘our version’ e.g SNOMED-CT, LOINC etc right back to a minimum, in line with e FHIR equivalent and allow both. I agree that the short names are more readable but I suspect this will be a losing battle as the URI equivalents become the def-facto industry standard approach

Pieter Bos
September 21, 2020, 12:05 PM

the term constraint operational binding in ADL 2 syntax is:

Although I do not think anyone supports that syntax yet, I think it will be something that is needed.
I’m not sure if it’s possible to replace terminologyId with a URI there. That has the potential to introduce quite a lot of ambiguities in the grammar, leading to even more lexer hacks, and we may need to introduce a different syntax there if we allow URIs there, even if it’s just surrounding the URI with something like “-characters.


Thomas Beale

Raised By

Thomas Beale


Affects versions