Norway just became a SNOMED country.
One simple question – what is the correct terminologyId to use for SNOMED-CT.
Currently we use ‘SNOMEDCT’ like below. Is this correct?
Høyre øye SNOMEDCT 18944008Vennlig hilsen
Bjørn Næss
Produktansvarlig
DIPS ASA
Mobil +47 93 43 29 10
Congratulations about the new adoption!
The IHTSDO recommends to use exactly “SNOMED CT” as the name, in our specs we are using SNOMED-CT as the name (it should be corrected to the name preferred by the IHTSDO). On an event they explicitly asked to avoid the SNOMED-CT with the hyphen when referencing the standard.
As for the term id, I’ve seen [snomed-ct::35917007 on the specs, or SNOMED-CT on sample archetypes: https://github.com/openEHR/specifications-ITS/search?utf8=%E2%9C%93&q=snomed&type=
Tested on the Ocean’s archetype editor and they use:
constraint_bindings = <
[“SNOMED-CT”] = <
items = <
[“ac0001”] = terminology:SNOMED-CT/release?subset=cabolabs
SNOMED-CT is the official designator, based on the archetype editor terminology list.
I think having this in a hardcoded terminology list is probably far from ideal (e.g. how do you put “snomed ct+norway national extension”? do we need an exhaustive listing of all possible extensions/versions?)
There is a spec that tells you how to identify different editions and versions of SNOMED CT - see http://snomed.org/uri
This should be used as the name at least then
When you use SNOMED in termbindings, you don't need to mention extensions, the code will do. But we need post coordinated expressions for the things which are not coded but still required to express in a SNOMED. At this moment, the ADL standard is not ready for that. I already made a JIRA entry
When you need SNOMED in a terminology constraint, and you want to constrain to a subset, then it should be sufficient to use the code to that subset. The terminology service should be able to find out if it is a code to an entry, an hierarchy or a subset, and response appropriate.
I am not sure about national extensions
Bert
But you probably need to define national extensions in constraint binding in templates. Templates are archetypes in the end
Thanks Ian
You are right. The correct ID is “SNOMED-CT” . Then the example will be as follows:
Høyre øye SNOMED-CT 18944008I don’t think any subsets should be used on this context. What we need is a way to say that the code_string “18944008” is defined by the terminology defined by terminology_id/value = “SNOMED-CT”. This must be done the same way by all openEHR systems to enable a true open platform based on openEHR archetypes.
Thanks for the feedback from all of you!
Vennlig hilsen
Bjørn Næss
Product owner
DIPS ASA
Mobil +47 93 43 29 10
In the new world of URIs representing SNOMED codes, this “SNOMED-CT” value for the terminology_id is understood as an openEHR-local (and maybe more widely agreed) namespace alias for the SNOMED CT namespace whose URI is http://snomed.info/sct (see http://doc.ihtsdo.org/download/doc_UriStandard_Current-en-US_INT_20140527.pdf).
Practically speaking this means that if other variants exist, e.g. ‘snomed_ct’, ‘SNOMED_CT’ and so on, they can all be defined as aliases for SNOMED CT, in different contexts such as archetype tools, AQL queries and so on.
BTW, the ARchetype editor should generate URIs of this form for terminologies (from the ADL2 converted form of the CKM BP archetype):
term_bindings = <
[“SNOMED-CT”] = <
[“id1”] = http://snomed.info/id/163020007
[“id5”] = http://snomed.info/id/163030003
[“id6”] = http://snomed.info/id/163031004
[“id14”] = http://snomed.info/id/246153002
[“openehr”] = <
[“at1055”] = http://openehr.org/id/125
[“at1056”] = http://openehr.org/id/497
[“at1057”] = http://openehr.org/id/146
Hi All,
please use this link to refer to the SNOMED CT URI Standard: https://confluence.ihtsdotools.org/display/DOCURI
This page contains more info about SNOMED CT languages:
https://confluence.ihtsdotools.org/display/SLPG/SNOMED+CT+Languages+Project+Group
Thanks,
Daniel
Yup – that’s the right URI format.
Hi again,
I’ve been snowed under for a while and just now catching up with this…I reckon there was a suggestion that we do not include SNOMED codes within archetypes, or more specifically post-coordinated expressions, if I understand correctly but to define these somewhere else and then include the external URI instead. While this would be a good solution for well-defined expressions, subsets etc. I think if you think about the vast amount of potential expressions with almost endless permutations of terms it quickly becomes too complex and unmanageable. Therefore there will always need for including specific expressions within archetypes and templates.
I’ve been doing a lot of terminology bindings using various ontologies and terminology lately and I think we need urgently a consistent way to make these bindings and get the tools support it. For example when term bindings (for the purpose of defining real-world meaning of a node) are done at archetype level you end up with local at codes that refer to each binding and then it is possible to link one or more terms from same or different terminology systems. For the purpose of providing a valueset to a DV_CODED_TEXT at archetype level we don’t have a very clear way – we keep on saying we’ll put a terminology query but it is not really usable or useful. Tooling support is also not satisfactory. But when you do that at template level (e.g. define a valueset for a DV_TEXT by further constraining it to DV_CODED_TEXT or an existing DV_CODED_TEXT) it is just a list of terms, code and terminology system with version/release. It is not clear how we can refer to an external list defined by a terminology query or refset – at least I couldn’t figure out. There’s quite an inconsistency between archetype vs template defined valuesets within .opt – whereas they should be defined in the same way and share same semantics.
I don’t know how to fix it – my guess is that this is not a commonly used feature so it was never a high priority for SEC group. I think it is time to bring loose ends together as more and more countries adopt SNOMED and there is clear pressure to do this. FHIR terminology service is quite good and I think we should just start using it. If we need further bells and whistles it can be extended.
Hi Koray, as I started to read your message I was thinking “why not re-use the terminology infrastructure already defined by FHIR”, and then you proposed exactly that!
Hi Koray,
I’m unclear on the problem exactly. We can bind to a URI that points to a SNOMED CT subset. If we upgrade the binding syntax in ADL 1.4 as per this , then we can include SNOMED constraint expressions. Let’s assume we do this, and the tools follow suit. What else is needed? (I agree that we need to address all this ASAP by the way. It is already addressed in ADL2, but the user-base is moving much more slowly than I expected towards it). I’m not sure how using the FHIR terminology service solves the above problems. As far as I can see, the question of FHIR or CTS2 or xyz terminology service is orthogonal to the question of representing bindings to post-coordinated expressions. - thomas
The only missing part, now that I look at the SNOMED Compositional Grammar and Expression Constraint Language specs, is how to create a URI (which is the type of a term binding in ADL2) from a post-coordinated expression or constraint expression. This should be trivial, but I don’t see where SNOMED has specified it.
True, I was looking for that also, a few days ago. I don’t have time to read much now, but there is a document on the SNOMED site on URI’s, maybe it is in there? I can take a look later or look in my documentation, I have course materials. I come back to this tomorrow if not someone else already has. Bert
The , but it doesn’t address URIs for expressions either. (All the SNOMED language specs appear to be these days - nice and convenient, and also nicely published. We probably should go back to linking to them somewhere on the openEHR site). - thomas
I checked my course materials from last year, lucky I found it quickly, there is not any mentioning of URI’s for expressions, so I guess it does not yet exist. Stupid. Bert
Seems like the only way right now is creating refsets and referencing them with standard URIs…