SNOMED CT URIs in openEHR

Specifications Terminology
1

I believe I and others may sometimes have used the wrong URI-based prefix for SNOMED CT.

When looking closer at 3.2 URI Use-Cases - URI Standard - SNOMED Confluence I believe the prefix pattern for SNOMED IDs used in actual (openEHR) data instances (EHR content) should be http://snomed.info/id/{sctid} (pointing to an actual SCTID code) not http://snomed.info/sct/{sctid} (pointing to an entire SNOMED CT Edition).

What I am asking about is what e.g. goes into the “Terminology” field when listing “External coded”+“Local terms” in Archetype designer;
image

(I assume the nicer terminology-server-query way to bind already returns codes with /id rather than ´/sct´. Right?)

Thus the examples in this post is likely correct:

…and the examples in these posts are likely wrong:

And these ones I do not know if they are right or wrong, since they seem to point to the SNOMED CT as a system:

Perhaps @mikael or some other SNOMED CT wizard could verify/clarify?

2 Likes
2

I think your supposition is correct. The ADL Workbench has just http://snomed.info/id/$code_string as the correct URI leaders. My guess is that I and possibly others have unwittingly copy-pasted a wrong URI a few times. If that is what is in Archetype Designer etc, then, possibly problematic…

3

I agree.

Well, formally http://snomed.info/sct/{sctid} is pointing to a module and not an edition and an edition usually consist of more than one module. However, it is usually possible to infer the edition from the module if the module is well chosen, so the modules are used as proxies for editions.

It seems like this thread is no longer existing.

I agree.

This grammar seems strange to me. If you are dealing with SNOMED CT, why not just use SNOMED CT Expression Constraint Language?

It seems like this thread is no longer existing.

/The annoying guy in SNOMED CT Terminology Release Advisory Group

1 Like