Terminology_id name list

Specifications
41

The problem I’m facing is that, on one hand, HL7 lists externally managed terminologies here: External Code Systems - HL7 Terminology (THO) v6.2.0.

However, when looking at the HL7 Terminology artifacts, we see many other resources—for example, this one: https://terminology.hl7.org/CodeSystem-HPO.html—which also appears to be externally managed, but isn’t listed as such. As I understand it, not everyone is familiar with what CodeSystems are, so HL7 sometimes maintains them internally as duplicates or proxies.

The core issue is that the CodeSystems are internal components of HL7 Terminology.
For example, we have http://terminology.hl7.org/CodeSystem/v2 as a general V2 terminology umbrella, but then also http://terminology.hl7.org/CodeSystem/v2-0211 as a separate CodeSystem.

In general there are 4 terminologies in HL7, http://terminology.hl7.org/CodeSystem/v2, http://terminology.hl7.org/CodeSystem/. http://terminology.hl7.org/CodeSystem/v3, Index - FHIR v5.0.0 which are now all part of the terminology table.

We need to manage these distinctions properly. The options I considered

  • Adding something like 0211::CODE to the defining_code

  • Formatting the namespace: HL7V2-0211 or HL7V2::0211

  • Introducing a new subterminology or metadata property to distinguish terminology subgroups in TERMINOLOGY_ID.

I personally think all of which are valid, except for the defining_code cause it interferes with the code. Namespaces may end up ppl doing mistakes + you need to be aware of it, but is much better to be standardized. I prefer that one using ::, since we control these namespace. We could also add a list of them additionally to the terminology json, for ppl to use. Mostly these terminologies are administrative in nature, like status. Therefore, i think this shouldnt stop us in moving forward.

Adding them as different terminologies maybe an option, laborious but we would cover all. Adding another RM field feels too intrusive (just to cover the CodeSystems). We could use the version also to store the CodeSystem if we wanted.

Given this fact and the amount of terminologies already covered in the CodeSystem website just using HL7 ones maybe also an option, but problematic with legacy data + the reasons we discussed above (which anyhow is badly standardized, can we count on SNOMED-CT being used ?!).

Update of the table now on github using the :: for the namespace as a suggestion

42

A list of well known names “ICD10”, “SNOMED-CT”, etc that needs to be maintained somewhere for reference is really no different to a list of URIs (NOT URLs) other than generally being shorter and more human friendly. They are each just unique identifiers for a corresponding terminology.

I’ll also note that “namespaces” in the XML (and FSH) sense are JUST syntactic shorthands (like macros) for an associated URI – you should never be comparing FOO:1234 from one context with FOO:1234 from another context since each (XML/FSH) context defines a mapping from “FOO” to a URI and these may be different. Even though, by convention, they are not defined differently, inevitably it happens.

I won’t pretend to know what “namespace” means in an openEHR context.

43

In general i have given that a lot of thought lately, i think i would prefer actually adapting what FHIR does, since they also have an standardized process around it e.g. submiting termonologies to HL7. This would safe us work and time.
The problem is that namespaces for LOINC SNOMED-CT etc are already defacto standardized by their use.
So im not sure how feasible this is, in the end this would lead to two terminology names being used (or an update script touching existing data), which may still be managable, but comes with problems.

44

I’m with you on this @SevKohler

The existing ‘terms’ came from a very old list maintained by a US organisation, so they are really coded terms, not namespaces as such and I would be pretty sure that none of these terms are used apart from SNOMED-CT, SNOMED, ICD-x and LOINC. In the current environment where FHIR uri’s dominate , these are IMO best regarded as Fixed Aliases

There will of course, be issues for systems that are already using ‘LOINC’ inside modelling artefacts and CDRs rather than the FHIR uri but given the very small number of codesystems for which this is an actual problem, I would have thought that implementers could decide how best to transition (or not) based on a lookup table from legacy system ‘code’ to URI.

This issue also affects AD / CKM/ LE tooling but I think the same can apply there. We have small number of in-use ‘alias’ codes that are easily mapped to FHIR uris going forward.

2 Likes
45

As discussed in the SEC meeting in Barcelona:

    1. need to add more background info and details on the table

    2. suggest to add it to the TERM component specifications

   3.  @Erik Sundvall template uris

    4. ADL2 requires URLs in term_bindings - that’s not aligned with this specs; suggestion is to change ADL2, @Jelte Zeilstra @Severin Kohler will make proposal for that
  1. done
  2. This needs to be added to the spec
  3. @erik.sundvall what did you mean with that again ?
  4. @joostholslag @Jelte any suggestions on the corse of action?

Please find the updated version in the github repo:

46

I’m not aware that is true.

47

Well that would be true (and it is true) for terminologies that have a defined URI, and never change it. But it’s only true for a handful of terminologies; a lot have no defined URI, and some publishers who don’t quite know what they are doing in this area will change the URI (without realising that doing so is evil).

Namespaces avoid all of this. They’re just a map to URIs, or in some cases, nothing, if no URI has been defined. In openEHR, namespaces are universal, i.e. same names across all tools, APIs, contexts, with a single definitive map to URIs.

Human readability should not be undervalued. I’m a big believer in URIs, but in string data they really make it hard to find the terminology id/name, which is all you care about.

I’d have to say that if FOO:1234 doesn’t always mean the same thing, then it means that ‘FOO’ does not refer to a properly defined thing.

2 Likes
48

@yampeku

Should we introduce a LOCAL namespace for openEHR?
I mean we have it anyways internally but for conceptMaps or so it can be useful.
But arent these internal codings not really unique ?

49

‘local’ means local to the archetype, it’s an alternative to a terminology name. It does act like a namespace I guess (the proper name of the name space is the id of the ownig archetype). I don’t know if it helps adding it to that list though. Unless there is some concrete computational use for adding it, I would not do it.

2 Likes
50

One reason for adding it could be to specify it as reserved for use in the archetype, so terminologies added in the template or at run-time can’t use it?

2 Likes
51

My rationale was that if ‘local’ (and even ‘openehr’) can end up in the namespace of a code, we should at least have a place where people can get information of the semantics of this ‘terminology’

1 Like
52

Seems unlikely, but technically possible! If others agree with that reason, I guess it could be added, but it should be made pretty clear that it is like a reserved namespace, even though it doesn’t actually identify an external terminology.

2 Likes
53 
ARCHETYPE_TERMINOLOGY Class

term_bindings: Hash <String, Hash<String, Uri>> 
Directory of bindings to external terminology codes and value sets, as a two-level table. The outer hash keys are terminology ids, e.g. "SNOMED_CT", and the inner hash keys are constraint codes, e.g. "at4", "ac13" or paths. The indexed Uri objects represent references to externally defined resources, either terms, ontology concepts, or terminology subsets / ref-sets

So yes, ADL2 does require term_bindings (like SNOMED coding of element names) as URI.

1 Like