@pacharanero
Sounds great — thanks for sharing the repository. I am happy to check it out and help get things started. 
Please do have a read and help me figure out the way everything will work. At this stage I’m still deciding things like the identifier format. At the present moment the front-running idea is to use Crockford base32, which means that reading out an ID (eg over the phone) will be fairly unambiguous (no need to differentiate between upper and lower case letters) and error-resistant (similar-looking letters and numbers are removed)
Sorry for the silly question, but are you considering using the SNOMED API or building everything — including the datasets — completely from scratch? @pacharanero
1 Like
Everything from scratch. We cannot use or even mention SNOMED in relation to this project. There has to be an intellectual firewall separating this project from any copyrighted works.
It is a clean-room, new build, open source terminology, built in a different way to take advantage of the 2-3 decades of improvements in technical collaboration tools and practices that have happened since existing terminologies were created.
1 Like
That’s kind of a groundbreaking idea.
Hi Marcus,
I have come to the conclusion that the next generation of openEHR and any ecosystem to which it contributes needs its own new terminology. I concur on many of your points. Notes on a few details…
It is, but to be fair, they have been searching for a business model that allows them to survive, similar to other standards orgs. I think they’d be better doing what we do at openEHR - solicit financial sponsorship in various categories (rather than just country-level), and make the result free for everyone.
What I’m most interested in is a terminology that works (better). SNOMED is still (10y after I represented the UK on IHTSDO standing committees) full of precoordinated codes and questionable hierarchy relationships. On the other hand, it has a decent meta-model, constraint language and expression language (the thing you use to create a post-coordinated concept expression).
So it’s a mixed bag. I have however come to the conclusion that we would be better off creating a new terminology that is:
- smaller - it doesn’t need to be as big as Snomed
- ontologically coherent, e.g. children of any node are all mutually consistent, not overlapping etc
- extensible - easily
- doesn’t end up with ‘national extensions’ hiding major sub-terminologies.
This is a consequence of ontological ambiguities, and could be fixed.
I have also come to the same conclusion a few years ago. I would (probably) still not allow codes to have spaces, and I would prefer shorter codes, because they get bound into larger syntactic elements (e.g. paths). We could consider multi-axial approach as well. E.g. can you guess these codes? ’sysbp-pt-tgt’(systolic BP, point in time, target);’hr-4h_avg-hist’(heart rate, 4h average, historical measurement); ’myo_infarct-hist’(historical MI event); ’myo-infarct-risk’etc. There would be more to learn here, but a simple bit of UI could generate such codes easily for the user. Multi-axial (= post-coordinated) codes provide a lot more computability, and also that the terminology is a lot smaller. These are early thoughts!
That probably doesn’t happen too much even with SNOMED - they do have discipline these days on not changing meanings of codes. It won’t be possible to make queries completely resilient to change. E.g. remember when the classifications of Hepatitis were A, B and non-A-non-B. Now we have 8 (or whatever it is) varieties. Older queries containing ‘non-A-non-B’ might need to be re-engineered.
We definitely want hierarchy (IS-A relationships) - that’s the basis of inferencing with terminology. It also enables browsing a subset within an app, for the purpose of code selection. Just think for example of trying to choose blood type for blood bank purposes.
Hierarchy can be completely hidden from any user context where it doesn’t help.
Whether we need the exact expression language SNOMED has is a question, but it’s quite well designed. It’s just never used in real life (that I’ve ever seen). But we will need something that enables post-coordination.
This is just a technical detail, and easy to achieve. Currently SNOMED can be obtained in OWL-RDF form (as well as DB tables), and that is a widely accepted formalism. Generating a JSON format form of any terminology is easy.
Apparently not, I just did it 
Yes but we would need a browser tool as well to be able to search, look at hierarchies etc.
One of the main (maybe the main) question for this group is whether you want a better reference terminology, or an interface terminology, with mappings to existing terminologies. I am personally interested in a better reference terminology where the codes are human comprehensible, that is maybe 100k terms, and reliably computable.
Would a client-side web browser interface (front-end) that clinicians use to search for term codes be considered for OCT? Any idea?
1 Like
100% this has to be part of the oct project. I would like it to be a self-hostable local web server with web UI, and we would also run an instance of the UI for public web use.
If we could make the design of the web server as simple as possible then we might even be able to make it a static site, requiring no server resource, or at least something that might be able to run in a very low-resource runtime (container apps, function apps sort of thing).
Thanks for creating the Issue describing some initial spec for this feature, I would propose that we continue the elaboration of the UI feature over there.
1 Like
Hi everyone,
Although this continues an earlier discussion, I’m interested in contributing to the built-in web browser component and would greatly appreciate any input or insights from the community regarding the UI design. 
At the moment, the NHS SNOMED CT browser is one of the primary reference points. Do you think a similar design approach would be suitable for universal next-generation clinical terminology tools, or are there alternative UI concepts we should consider exploring?
Your feedback would be sincerely appreciated.
I’ve always found Ontoserver / Shrimp helpful to show people what the Ontology means and how (where it’s been modelled properly) things fit together well…
1 Like
@mike.bainbridge Thanks. I think this provides a solid starting point from a UI design perspective. 
I’ve submitted a pull request for the minimal UI, titled Universal OCTOPUS Viewer. Please take a look when you get a chance. I’d welcome any feedback from anyone.
I’ll be enhancing it further as I work toward finalizing the MVP.
1 Like
Thanks @tommyyama2020 - will review this week. Should be able to make some progress on oct.
1 Like
- Thanks @tommyyama2020 Forgive the question but I’m still coming up to speed here. We need to be careful with the intended audience - It’s important that the browser addresses all areas of the ontology such as inheritence and context but for a real end user, this needs to be [almost] completely invisible. This goes for things like concept and term_ids too where they are unlikely to have mean outside of unique identification of the concept. So what I can see is great for the developer community but needs careful ‘veneer’ for the end user. Diabetes Melitus in the screen shot can be:
- A diagnosis
- A family history
- A differential diagnosis
- A worry the patient has expressed
- etc. etc.
- Also the second term Diabetes - is this a relative of the first term? Does it take in ALL Diabetes concepts (like Diabetes insipidus) whch may have nothing to do physiologically with Diabetes Mellitus?
- Is the term I am looking at, the preferred or a synonym..
Happy to jump on a call to discuss,
1 Like
I think those terms are ones tommy has put in for demo purposes. They aren’t oct terms, which are 6-digit Crockford Base32 strings (unless someone can convince me to do something else)
1 Like
@mike.bainbridge
Yes, it is As @pacharanero pointed out, the terms aren’t clinically validated—they’re just there for demo purposes.
If displaying the attributions you mentioned in the UI is more clinically appropriate, I’ll make the necessary changes at my convenience.
Just found out that CTV3 is on the Open Government License, which is very permissive. Looks like we can very likely pull the entirety of CTV3 into oct, which is a great advantage, even if some of CTV3 is out of date. Medicine doesn’t actually move that fast.
Clinical Terms Version 3 (CTV3, a successor of the Read Codes) was made available on an Open Government License (OGL3). It hasn’t been updated since 2018, but it contains a huge amount of what went on to be merged into SNOMED-RT to become SNOMED-CT. This means we can simply take all that CTV3 content and use it in oct’s namespace and graphs (this is what I’m proposing to call our hierarchies/ontologies). This accelerates us significantly.
That should give us a decent start on terms.
Before I start haggling with the TRUD people to give me an old copy or set up FTP access, does anyone have a copy of CTV3 from 2018?
Also, just in case anyone fancies supporting the project financially, so that we can start to build some momentum around it, I have set up a GitHub Sponsors account, initially under Baw Medical Ltd which is my own company. For now this is a business entity that already exists and has a bank account.
https://github.com/sponsors/bawmedical
Over time if we can build the project into a serious terminology, then I would like there to be an independent ‘foundation’ or other non-profit behind oct, to ensure its open future. At that point donations can go direct to that organisation instead.
1 Like
Hello,
I’ve temporarily deployed the mock UI to the GitHub Pages link below and would greatly appreciate any feedback you may have:
I’m currently focusing on refining the user experience and adding new features, so please feel free to share any suggestions or impressions. For now, regulatory and policy compliance can be set aside—any general or UI-focused feedback is welcome.
Design-wise, you may notice that the overall impression is quite different from the existing NHS browser. With that in mind, I would really appreciate your thoughts on whether this direction feels appropriate or if there are aspects I should reconsider.