# Terminology_id name list **Category:** [Specifications](https://discourse.openehr.org/c/specifications/6) **Created:** 2025-03-12 16:15 UTC **Views:** 401 **Replies:** 52 **URL:** https://discourse.openehr.org/t/terminology-id-name-list/6546 --- ## Post #1 by @SevKohler As previously discussed, there is currently no standardized way to write terminology_id [names](https://specifications.openehr.org/releases/BASE/latest/base_types.html#_terminology_id_class), as the field is an unconstrained string. The idea is to provide a list of terminology names as standards. For example, if you are using LOINC, you should write "LOINC" as the `terminology_id`. Currently, some instances use "LOINC," while others use the URL of LOINC, similar to how it's done in FHIR. The field will continue to be a string, but people are advised to use standardized terminology names from the list. Tools should also support this standard. This approach streamlines the `terminology_id` field while still allowing users to input internal terminologies when needed. I have extracted the codings from OMOP as a first draft. Please add any terminologies you think are missing. The goal is to allow this list to be extended over time. The list is now maintained here: https://github.com/SevKohler/Terminologies --- ## Post #2 by @thomas.beale The openEHR specs historically used [the UMLS-derived list maintained at NLM](https://www.nlm.nih.gov/research/umls/sourcereleasedocs/). I don't know how reliable / complete that is these days. The problem for us isn't obtaining a list of terminologies today, it is maintaining it over time (obviously ;) What are our thoughts on that? As per [this other thread](https://discourse.openehr.org/t/terminology-namespace-to-uris-map-csv/5885), we started maintaining a short list of terminology ids and meta-data, which will be publicly visible within days. Since it is all generic information, it seems like a nice idea to have one such resource for the world ... (doesn't have to be ours, we just need something working for now - but we can easily copy from something upstream maintained at openEHR.org). --- ## Post #3 by @SevKohler Can you extend it with the ones i above linked, they are from OHDSI ? We want to add this to the 1.3.0 release soon, since its infringes AQL interoperability etc. --- ## Post #4 by @thomas.beale You might want to look at that other thread - @damoca was pointing to the HL7 list, which as far as I can see is way too incomplete to be useful. We could augment our list for sure, but I don't think everyone agrees on its contents yet. One thing it doesn't do is handle synonyms for namespace names, i.e. local forms of a terminology name. In openEHR, SNOMED is represented (in archetype bindings for example) as more than one kind of string, such as "SNOMED-CT", "snomed-ct" and I think some other variants. In S2 we are just using 'snomed'. So there would need to be some further form of local aliasing. I don't think the file would solve that, although we could have columns with a preferred namespace for certain standardising orgs, e.g. an 'openehr' column with 'SNOMED-CT"; a HL7 column with the URI and so on. I think @ian.mcnicoll , @erik.sundvall , @pablo etc might want to have another look at this question. --- ## Post #5 by @SevKohler I think the best is here to follow up what OHDSI does (following up on https://discourse.openehr.org/t/terminology-namespace-to-uris-map-csv/5885/7?u=sevkohler comment ), since they are heavily invested in terminologies and also actively mapping those + not coming up with our own list. Only thing i would do is actually add new ones if we forgot smt (or delete nonsense). In regrads of the string, i would just use whats in column 1, so the list is solving that. Otherways use a url as FHIR does, but there are often no urls for most of these and FHIR is adding it via /fhir/icd-10 e.g. So actually only valid thing is introducing own at codes which is meh, or just using the name. I renamed snomed to SNOMED-CT to be compatbile with legacy stuff. I added s2. --- ## Post #6 by @thomas.beale [quote="SevKohler, post:5, topic:6546"] think the best is here to follow up what OHDSI does [/quote] I'm not 100% clear on what the idea is - is there a computable form of the OHDSI list online - is the idea to regularly integrate new versions of that in an openEHR list that would include more meta-data (URIs for example)? --- ## Post #7 by @SevKohler Well i took it from [Athena](https://athena.ohdsi.org/search-terms/start), the moment you generate an OMOP CDM you will have all those terminologies in your database. Apart from that there is an uncomplete list here: https://www.ohdsi.org/web/wiki/doku.php?id=documentation:cdm:vocabulary I would say yes we extend it regularly. URIs you mean as "identifiers" or what would you use them for ? Problem is, we should use the names, since e.g. SNOMED-CT is already in use. --- ## Post #8 by @thomas.beale [quote="SevKohler, post:7, topic:6546"] URIs you mean as “identifiers” or what would you use them for ? [/quote] Some people (HL7, Snomed) love URIs as terminology identifiers. I am much more in favour of a standardised set of namespace names, i.e what you are proposing. Since many/most terminologies have no defined URI at all, such a list of normative names is very useful indeed. I'll have a look at extending our list with the current copy you supplied. --- ## Post #9 by @linforest Maintain this list as a termset on the CKM repo? And/Or as a part of the collaboration btw openEHR and FHIR, utilize a recognized FHIR Terminology Server to address this terminological requirement and others? --- ## Post #10 by @yampeku This is actually a great idea so it can be easily referenced even from outside openEHR space --- ## Post #11 by @vanessap Hi! I think this is a good idea @SevKohler and using the OMOP list can be a good start. But I think we need to control it internally and set some rules and explanations on how to register this information. I find it interesting that in the ICD cases, OMOP has "ICD10" and then "ICD-11". Just looking at it and the way the specifications define the terminology class in openEHR, out of curiosity (and hoping not to open a can of worms in between), this means we would make it as: terminology_id: ICD version_id: 10 OR terminology_id: ICD10? And for ICD10CM? terminology_id: ICD version_id: 10-CM OR terminology_id: ICD10CM? What about ICD-O-3? Although OMOP mentions it as ICDO3. terminology_id: ICD-O version_id: 3 OR terminology_id: ICD-O-3 ? Aren't WHO ATC/DDD and ATC the same? The codes for each substance are the same in both, the only difference is that one provides an extra set of values for defined daily doses for each substance. I would guess that the version here is the year of release. For LOINC, I would imagine this would fit as: terminology_id: LOINC version_id: 2.74 which is pretty straightforward. What about SNOMED? We register the release date and the instance used as the version_id? --- ## Post #12 by @SevKohler Some of them i edited, i added now - since ICD does this. ICD has internal releases for the major releases too ICD-03.1 ICD-03.2 ICD-03.3 ``` name: ICD-O3 version: 1 ``` I think its the best to adapt what the given terminology is doing, e.g. ICD makes a hard split between its versions so we adapt them as different terminologies. Other terminologies like LOINC have a more soft versioning and people dont adress e.g. LOINC as LOINC v12321.1. In regards of ICD-10 extensions, for AQL it would be good to have them in the version id, since these are 1-to-1 adaptation + extra codes for the country. If we split it, this will make queries between institutions more complex. ICD-10-GM 2023 -> ``` name: ICD-10 version: GM 2023 ``` Semantically one could argue that these are another version, since they differ from the ICD-10 by adding new codes. To be more correct we may add a terminology field to the table extension, for future versions of openEHR, but i see this only true for ICD so far ? Changed WHO ATC/DDD to ATC. I updated the table now to contain modifications. For the generic list, we could list the modifications as own terminologies. In regards of openEHR i think adding them to the version is good, or extending the temrinology with modification field. --- ## Post #13 by @thomas.beale [quote="vanessap, post:11, topic:6546"] I think this is a good idea @SevKohler and using the OMOP list can be a good start. But I think we need to control it internally and set some rules and explanations on how to register this information. [/quote] You are right there are some inconsistencies that would need to be fixed (or maybe not, if we really just want to follow OHDSI...) With respect ICDx, normally ICDn and ICDn+1 are understood as different terminologies rather than backwardly compatible versions of some notional 'ICD' terminology. I am not even sure if ICD9CM could be considered a clean superset of ICD9 (due to forking and subsequent divergent updates); similarly ICD10AM / ICD10. We should however treat LOINC and Snomed however as being properly versioned. --- ## Post #14 by @yampeku For what it's worth, everyone seems to consider each extension of ICD as their own separate thing. Even national editions are not compatible amongst them --- ## Post #15 by @SevKohler Really, okay i wasnt aware of that, i thought they are a subset of e.g. ICD-10 with additional codes. So fever code in ICD-10 and ICD-10GM could be different ? If this is not the case we probably should list them seperatly, but as said this makes cross border queries harder. Which could be escaped by * anyhow. --- ## Post #16 by @yampeku No, most of the codes on base are, but probably would assume that subcodes may collide with close enough meanings. An example for athena (modifications for china, korea, german, french, and clinical which can be specialized per country again) ![imagen|690x103](upload://ssvbPypZ2n49hDBe4RXHJsjcBdQ.png) For example in Spain we call it CIE-10-ES --- ## Post #17 by @SevKohler Wtf, these need to be their own terminologies. What a mess. --- ## Post #18 by @thomas.beale [quote="SevKohler, post:15, topic:6546"] So fever code in ICD-10 and ICD-10GM could be different ? [/quote] The problem is that the derivative form, e.g. ICD10AM (Australian modifications) could add new codes to the ICD10 core for new core concepts. Most likely they are supposed to always update the ICD10 core when that changes - but what do they do if they need a code for e.g. "trauma due to kangaroo through windshield" (a real thing in Australia)? We'd have to ask the maintainers, but I imagine they may create a new code they need, and maybe (we hope) give it to WHO to add to the ICD10 core. A fair bit of this has human processing involved, and is likely to sometimes fail. So maybe one day ICD10 does get a code for (roughly) the same meaning, but it is a different code made in the US, created to record injuries seen at the Texas Western Plains Aussie Kangaroo Park. So then you're into _mapping_ just to handle differences between variant forms of ICD10 :person_facepalming: We live the same difficulties with archetypes of course, so it's easy to criticise, but hard to get right... If only there was an idea of definitive computational ontologies ... oh wait... --- ## Post #19 by @SevKohler What about ATC and/or DDD are these own terminology or we just label it both under ATC DDD. @thomas.beale @yampeku @vanessap --- ## Post #20 by @yampeku seems to be an extension that you would want to point explicitly --- ## Post #21 by @SevKohler So that would then be the only case for a modification that works. Should we list this as version or as own terminology ? If we list it as own terminology people have to be aware of using * --- ## Post #22 by @yampeku I think for all those cases (even different ICD flavours) should be fine to consider them their own thing --- ## Post #23 by @bna Hi How you define the terminology and code for HGNC codes? They typically define the code as `HGNC:1100`. Would you then do: `HGNC::HGNC:1100|BGCA1|` ? --- ## Post #24 by @ian.mcnicoll I would follow FHIR advice https://www.hl7.org/fhir/uv/genomics-reporting/ValueSet-hgnc-vs.html > This value set includes all HGNC Codes, which includes multiple code systems. In this guide, Gene IDs from HGNC are used as CodeableConcepts, **which must be sent with the HGNC gene ID including the prefix ‘HGNC:’ as the code and the HGNC ‘gene symbol’ as display**. CAUTION: HGNC also indexes gene groups by numeric ID (without a prefix), and older systems may send HGNC gene IDs without the prefix, so care must be taken to confirm alignment. We have separately included the genegroup code system to draw attention to this ambiguity and potential error. --- ## Post #25 by @SevKohler Well fhir uses urls, we will be using namespaces. But they do it excalty like that: "HGNC:2621" So it would end up as bjorn said i guess ? I dont know about HGNC if it can have different prefixes or so --- ## Post #26 by @thomas.beale [quote="SevKohler, post:25, topic:6546"] So it would end up as bjorn said i guess ? [/quote] If that's how they represent their codes, i.e. with 'HGNC:' prefixed, then that's how we do it. However, are we sure that the 'terminology' in this case is also just 'HGNC'? It probably is, but we should check. If it really is, then @bna is right. Looks a bit funny, but otherwise no problem. --- ## Post #27 by @yampeku Should be HGNC as per UMLS https://www.nlm.nih.gov/research/umls/sourcereleasedocs/current/HGNC --- ## Post #28 by @linforest Same as [W3C OWL representation for namespaces](https://www.w3.org/TR/2004/REC-owl-guide-20040210/#Namespaces) --- ## Post #29 by @SevKohler Are we on one level here with the list, i would then suggest we make a first attempt to make it more accessible/public and see how it goes ? Anymore comments, corrections please note them. @thomas.beale @yampeku @linforest @ian.mcnicoll --- ## Post #30 by @ian.mcnicoll I'll be honest and declare that I have doubts about the value of doing this against the FHIR approach. At the very least our list should contain the equivalent FHIR uris, as whether we like it or not these regoing to dominate in the wider market. I would currently advise clients to use FHIR codesystems uris (many are doing that already) , and not e.g 'SNOMED-CT', as that just complicates migration/ integration. --- ## Post #31 by @SevKohler People already use namespaces, and you can't expect everyone to switch to URLs in openEHR, especially with legacy data (even thou they are not enforced). Namespaces are also easier to maintain than requiring existing URLs. For example, some older ICD versions don’t have official URLs, so people just make something up (hl7/...) — and those URLs aren’t resolvable, which defeats the purpose of using a URL in the first place. I don’t see any real value in using URLs, though I don’t have strong personal feelings about it. Adding fhir urls to them is anyhow a good idea (as a mapping). --- ## Post #32 by @ian.mcnicoll I largely agree that namespaces are better but it might be interesting to get a feel for what the wider community is actually doing, esp for SNOMED, given the preponderance of FHIR-based Terminology services. Interestingly FHIR Shorthand does allow the use of namespaces for Codesystems though these are locally defined. There probably is value in trying to keep this closely aligned with , or even jointly managed with FHIR. Adding FHR uri to the table would be a good start. --- ## Post #33 by @SevKohler Maybe something for june then, is there an agenda or smt ?! We can add that along talking about Dosage and timing standardization for example. --- ## Post #34 by @thomas.beale [quote="SevKohler, post:31, topic:6546"] Namespaces are also easier to maintain than requiring existing URLs. For example, some older ICD versions don’t have official URLs, so people just make something up (hl7/…) — and those URLs aren’t resolvable, which defeats the purpose of using a URL in the first place. [/quote] It's mainly ideology (like HL7's earlier obsession with ISO Oids, thankfully that didn't stick). Namespaces make for more resilient data and software. We actually do use the URLs in code binding values, but not anywhere else in the ecosystem. The reality is that the FHIR URL approach is not fully worked out, and as soon as you go outside a small number of well known terminologies, there are no defined URLs. But there are namespaces that we can use from NLM and similar places. [quote="ian.mcnicoll, post:32, topic:6546"] I largely agree that namespaces are better but it might be interesting to get a feel for what the wider community is actually doing, esp for SNOMED, given the preponderance of FHIR-based Terminology services. [/quote] Transformation on the fly in and out of e.g. FHIR data is no problem. That's why the table we are talking about here is useful. I agree having the FHIR URL column would be useful. I'll put that in our version and reshare it. --- ## Post #35 by @SevKohler https://github.com/SevKohler/Terminologies Please PR if you find anything or want to add anything @thomas.beale @ian.mcnicoll @yampeku @linforest @bna to the terminologies.json. Currently, it contains 51 terminologies (some of those not included in HL7 or OMOP so quite a hollistic list, surely there is still stuff missing). I also added a OMOP mapping column, i didnt add omop as a terminology, cause its very unlikely we use them to e.g. integrate data into openEHR (@yampeku what do you think) @sebastian.iancu maybe we can move that over to openEHR, i dont have the rights sadly. For now i kept the - / and spaces and just did capital letters. We may change that if we want. I would have deleted the - etc as OMOP does, but we already use that for SNOMED-CT. --- ## Post #36 by @yampeku Good question... they DO have custom codes, but seems unlikely we will end up finding omop codes in an openehr system (but knowing people, they probably will someday so...) --- ## Post #37 by @thomas.beale Here is our file, with an added FHIR mapping column. [code_systems.doc|attachment](upload://1CN2HpCahbJv1PXeI4Ya4DjCbYf.doc) (2.0 KB) Rename this to .csv. Note that the namespace is the second column, not the first. Each ISO code-set is treated as if it is a distinct terminology, same for IANA. We take a different line than HL7 for terminology URIs: the URIs we use reflect the primary maintaining org, not HL7. Thus, ISO, IANA etc have URIs pointing to them, not HL7. However, it appears that HL7 is the primary maintainer of CVX and NDC, so they are the HL7 URIs. Your current list doesn't have any of the ISO or IANA entries. Our list doesn't have most of your rows yet ;) --- ## Post #38 by @linforest @SevKohler [Human Phenotype Ontology (HPO)](https://terminology.hl7.org/NamingSystem-HPO.html) --- ## Post #39 by @thomas.beale Severin, was just looking at your list - are you thinking to use the name column as the technical namespace name? Notice that some entries have spaces in them, and that's going to be a problem for parsing situations, e.g. if names like 'ICD-10 CM' are used in openEHR style stringified codes like 'ICD-10 CM:O44', depending on what kind of lexing is being used, the space could mess things up. Also, I am not sure namespace names used in various frameworks (XML schema, etc) can have spaces. Personally I stay away from spaces in such things if they are meant to be parsed. We could create a transform that generates a form of the 'name' with e.g. spaces replaced with underscores. Also we are currently using lower-case for everything, but if we agreed that the names are case-insensitive, that won't matter. --- ## Post #40 by @SevKohler Yeah i first wanted to collect, thinking about the format once we got to see what other did. i think spaces need to be deleted out of the reasons you named. I think its maybe easier to just delte them instead of underscoring (as OHDSI e.g. does it). I will adapt some of your column also they make sense. Just didnt had the time yet. --- ## Post #41 by @SevKohler The problem I'm facing is that, on one hand, HL7 lists externally managed terminologies here: https://terminology.hl7.org/external_terminologies.html. 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, http://hl7.org/fhir/ 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](https://github.com/SevKohler/Terminologies) using the :: for the namespace as a suggestion --- ## Post #42 by @mjlawley 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. --- ## Post #43 by @SevKohler 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. --- ## Post #44 by @ian.mcnicoll 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. --- ## Post #45 by @SevKohler As discussed in the [SEC meeting](https://openehr.atlassian.net/wiki/spaces/spec/pages/3148251137/2025-10-14+SEC+Face2face+Meeting+Barcelona) 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: https://github.com/SevKohler/Terminologies --- ## Post #46 by @ian.mcnicoll [quote="SevKohler, post:45, topic:6546"] `ADL2 requires URLs in term_bindings` [/quote] I’m not aware that is true. --- ## Post #47 by @thomas.beale [quote="mjlawley, post:42, topic:6546"] 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. [/quote] 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. --- ## Post #48 by @SevKohler @yampeku https://github.com/SevKohler/Terminologies/issues/5#issuecomment-3518716777 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 ? --- ## Post #49 by @thomas.beale '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. --- ## Post #50 by @siljelb 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? --- ## Post #51 by @yampeku 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’ --- ## Post #52 by @thomas.beale [quote="siljelb, post:50, topic:6546"] 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? [/quote] 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. --- ## Post #53 by @joostholslag [quote="SevKohler, post:45, topic:6546"] 1. @joostholslag @Jelte any suggestions on the corse of action? [/quote] ``` ARCHETYPE_TERMINOLOGY Class term_bindings: Hash > 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 ``` https://specifications.openehr.org/releases/AM/Release-2.3.0/AOM2.html#_archetype_terminology_class So yes, ADL2 does require term_bindings (like SNOMED coding of element names) as URI. --- **Canonical:** https://discourse.openehr.org/t/terminology-id-name-list/6546 **Original content:** https://discourse.openehr.org/t/terminology-id-name-list/6546