As previously discussed, there is currently no standardized way to write terminology_id names, 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.
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, 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).
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.
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 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’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)?
Well i took it from Athena, 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:
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.
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.
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?
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?
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.
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.
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
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.
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)
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
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…
