# \`oct\` - a new open clinical terminology

**URL:** <https://discourse.openehr.org/t/oct-a-new-open-clinical-terminology/11556>\
**Category:** General Discussion\
**Created:** [27 October 2025 21:27 UTC](https://discourse.openehr.org/t/oct-a-new-open-clinical-terminology/11556 "2025-10-27T21:27:33Z")\
**Posts on this page:** 8\
**Page:** 2

<div class="post-metadata">

**Author:** ![marcusbaw](https://discourse.openehr.org/user_avatar/discourse.openehr.org/marcusbaw/32/4792_2.png) [@marcusbaw](https://discourse.openehr.org/u/marcusbaw)\
**Post date:** [30 October 2025 09:00 UTC](https://discourse.openehr.org/t/oct-a-new-open-clinical-terminology/11556/21 "2025-10-30T09:00:12Z")

</div>

> [@mjlawley](#):
>
> What do you do when the code name has to change. For example bronze\_diabetes → haemochromatosis or renaming away from Nazi associations (Asperger syndrome, …)

I am proposing that nothing is ever deleted from the Namespace.  
New codes will be added to represent the new way to describe that concept.  
A term which is no longer appropriate to use will be made inactive.  
We will support ways to **only** discover active concepts (eg an index of active concepts)

> [@mjlawley](#):
>
> words change in meaning over time.

This is true, but more of a problem for those extracting data from the system than thos inputting it at they time the input it (which is generally ‘now’, historically). The correct solutions will vary for how to extract meaningful data over a long period of time (eg a retrospective longitudinal study) according to the type of project, the question being asked, the clinical situation.

---

<div class="post-metadata">

**Author:** ![grahamegrieve](https://discourse.openehr.org/user_avatar/discourse.openehr.org/grahamegrieve/32/3602_2.png) [@grahamegrieve](https://discourse.openehr.org/u/grahamegrieve)\
**Post date:** [30 October 2025 11:12 UTC](https://discourse.openehr.org/t/oct-a-new-open-clinical-terminology/11556/22 "2025-10-30T11:12:03Z")

</div>

> [@marcusbaw](#):
>
> Wouldn’t this get cumbersome for very long Descriptions?

well, it forces you to be very clear on what is the differentiating parts of the descriptions and what is clarifying. But yes, as the set of codes gets longer, and the granularity gets finer, the codes get longer, and harder to manage. Unique numbers per SCT don’t have this problem, but they have obvious disadvantages.

One chooses one’s poison ☹

---

<div class="post-metadata">

**Author:** ![erik.sundvall](https://discourse.openehr.org/user_avatar/discourse.openehr.org/erik.sundvall/32/1961_2.png) [@erik.sundvall](https://discourse.openehr.org/u/erik.sundvall)\
**Post date:** [30 October 2025 16:44 UTC](https://discourse.openehr.org/t/oct-a-new-open-clinical-terminology/11556/23 "2025-10-30T16:44:47Z")

</div>

Seems people here don’t like RDF, does that mean you don’t like OWL (in any form/dialect) either? Whatever you pick, it would be good to be able to run a [_reasoner_](https://en.wikipedia.org/wiki/Semantic_reasoner) (see [also this](https://arxiv.org/pdf/2309.06888)) to find inconsistencies etc. otherwise things will be hard to maintain. Reasoner capabilities come for free with OWL and some other formalisms with a sufficiently strong logical foundation.

If not using OWL, at least going for some graph that can be queried via [GQL](https://en.wikipedia.org/wiki/Graph_Query_Language) would be good. Having the terminology system and the EHR in the same GQL-queryable database would be nice.

Also of course starting a new Snomed CT competitor would be madness yesterday, maybe today too, or maybe not with clever use of AI for information gathering and structuring.

[Same madness level goes for starting a new Wikipedia, [right Elon](https://grokipedia.com/)? (But Grokipedia does not necessarily contribute to more openess in the world…)]

P.S. Also have a chat with @Daniel_Karlsson

---

<div class="post-metadata">

**Author:** ![erik.sundvall](https://discourse.openehr.org/user_avatar/discourse.openehr.org/erik.sundvall/32/1961_2.png) [@erik.sundvall](https://discourse.openehr.org/u/erik.sundvall)\
**Post date:** [30 October 2025 16:53 UTC](https://discourse.openehr.org/t/oct-a-new-open-clinical-terminology/11556/24 "2025-10-30T16:53:45Z")

</div>

Regarding unique identifiers I would go for non-semantic short (alpahnumeric) ones, but also allow an optional canonical (unique) alias (likely in English) for those that prefer to maintain and use that for some common codes. And make sure APIs etc can accept both and cross-translate.

---

<div class="post-metadata">

**Author:** ![linforest](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/l/ac8455/32.png) [@linforest](https://discourse.openehr.org/u/linforest)\
**Post date:** [31 October 2025 01:21 UTC](https://discourse.openehr.org/t/oct-a-new-open-clinical-terminology/11556/25 "2025-10-31T01:21:29Z")

</div>

> [@erik.sundvall](#):
>
> Seems people here don’t like RDF, does that mean you don’t like OWL (in any form/dialect) either? …

OWL and OBO are my favorite. And also SPARQL.

---

<div class="post-metadata">

**Author:** ![marcusbaw](https://discourse.openehr.org/user_avatar/discourse.openehr.org/marcusbaw/32/4792_2.png) [@marcusbaw](https://discourse.openehr.org/u/marcusbaw)\
**Post date:** [31 October 2025 14:09 UTC](https://discourse.openehr.org/t/oct-a-new-open-clinical-terminology/11556/26 "2025-10-31T14:09:36Z")

</div>

> [@erik.sundvall](#):
>
> also allow an optional canonical (unique) alias

I like this idea. Kind of gives us the best of both worlds.

If we have a vast, immutable namespace, the ‘graphs’ built on top of that can be anything we want. They can add hierarchies, groupings/refsets, or convenience alternative naming layers.

At the moment I am leaning towards using [Crockford base32](https://www.crockford.com/base32.html) for the identifier, which gets us 5 bits per character of ID length, while being URL-safe and case-insensitive-filesystem-safe.

A base32 ID 7 chars long would give us 35 billion terms, is this enough for the time being?  
SNOMED has a 109 = 1 billion namespace size, of which it is currently using ~360k.

Alternatively, a truncated hash of the Description (ie a UUIDv5) might work, this would look a little bit like a Git commit hash. Yes we won’t be able to change the Description without changing the ID. But since we would have an insanely large namespace this wouldn’t matter. We’d just keep track of the changes in the graphs.

---

<div class="post-metadata">

**Author:** ![erik.sundvall](https://discourse.openehr.org/user_avatar/discourse.openehr.org/erik.sundvall/32/1961_2.png) [@erik.sundvall](https://discourse.openehr.org/u/erik.sundvall)\
**Post date:** [2 October 2026 09:22 UTC](https://discourse.openehr.org/t/oct-a-new-open-clinical-terminology/11556/27 "2026-10-02T09:22:34Z")

</div>

I still find this intersting but have no time to push it. Is there any master- or PhD-student (+supervisor) or posisibly a frontier AI-lab that we could get interested in picking up the thougts from this thread and make a feasability study / PoC to start with . Perhaps picking 2-3-clinical sub-areas or something corredsonding to a main hierarchy branch in Snomed CT?

And don’t forget to have a chat with Alan Rector and others that were involved in the GALEN project if you do. @Daniel_Karlsson might have some names.

---

<div class="post-metadata">

**Author:** ![marcusbaw](https://discourse.openehr.org/user_avatar/discourse.openehr.org/marcusbaw/32/4792_2.png) [@marcusbaw](https://discourse.openehr.org/u/marcusbaw)\
**Post date:** [12 October 2026 10:25 UTC](https://discourse.openehr.org/t/oct-a-new-open-clinical-terminology/11556/28 "2026-10-12T10:25:46Z")

</div>

> [@erik.sundvall](#):
>
> don’t forget to have a chat with Alan Rector

I tried once to find a point of contact with him but couldn’t find a way at the time. A long time ago I originally proposed an open clinical terminology and @ShinjiKobayashi I think mentioned [openGALEN](https://en.wikipedia.org/wiki/OpenGALEN). But the website [https://opengalen.org/](https://opengalen.org/) has been either hijacked or abandoned and resold. I can’t find anything concrete on the web about GRAIL (openGALEN’s formalism) or anything else. Academia seems to do this a lot - write the paper then forget to publish any usable code or build a reusable tool around the idea. I am trying to avoid that fate.

It would be great to speak to those key people from openGALEN though.

### SNOMED-CT developments in 2026

An interesting thing happened this year - SNOMED-CT added massively to what at first glance appears to be the crippled ‘[Global Patient Set](https://www.snomed.org/gps)’ - but now it includes the **entire SNOMED namespace** in Int’l English, but **no hierarchy** - the motivation is (I think) SNOMED are becoming aware that the license model is restricting their ability to be the ‘official lexicon’ of various truly global healthcare record standardisation initiatives. It’s been released as CC-BY-ND though, so can’t function as a basis for an `oct`, without breaking those license terms.

I also had a chat with someone senior and internal at SNOMED and he did indicate in a subtly coded way that there are definitely moves afoot within SNOMED to try to make the terminology more openly available. It is just a matter of reassuring certain stakeholders that there is a way to keep the revenue flowing if you don’t have a hard ransom on access to the terminology.

[Previous page](https://discourse.openehr.org/t/oct-a-new-open-clinical-terminology/11556.md?page=1)