Current spec does not allow URI-style terminology ids; various solutions appear possible:
add extra field to CODE_PHRASE (probably not a good solution)
relax TERMINOLOGY_ID regex to allow URIs (at least ':', ... more chars?)
The current regex described in https://openehr.org/releases/BASE/latest/docs/base_types/base_types.html#_syntaxes is...
terminology_id = name-str, [ '(', name-str, ')' ] ;
name-str = letter, { letter | digit | '_' | '-' | '/' | '+' } ;
...and thus does not allow URIs
Additionally create a mapping table for openEHR of all terminology namespace names like 'SNOMED-CT', 'loinc'.
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.name, TERMINOLOGY_ID.version (and for some cases even provide a way to include/extract CODE_PHRASE.code_string within URIs)
URI-templates: https://tools.ietf.org/html/rfc6570
Several libraries: https://github.com/uri-templates/uritemplate-spec/wiki/Implementations
In general - do we need any constraints on terminology id? Can’t we just accept any string?
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
the term constraint operational binding in ADL 2 syntax is:
[acx@terminologyId]
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.