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 



From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Koray Atalag
Sent: Tuesday, 2 May 2017 11:47 p.m.
To: For openEHR technical discussions
Subject: [FORGED] RE: SNOMEDCT - correct representation

Yup - that's the right URI format.



From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Thomas Beale
Sent: Thursday, 27 April 2017 1:01 a.m.
Subject: Re: SNOMEDCT - correct representation

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 

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"] = 
            ["id5"] = 
            ["id6"] = 
            ["id14"] = 
        ["openehr"] = <
            ["at1055"] = <http://openehr.org/id/125><http://openehr.org/id/125>
            ["at1056"] = <http://openehr.org/id/497><http://openehr.org/id/497>
            ["at1057"] = <http://openehr.org/id/146><http://openehr.org/id/146>
- thomas
On 25/04/2017 07:03, Ian McNicoll wrote:
SNOMED-CT is the official designator, based on the archetype editor terminology 
On Tue, 25 Apr 2017 at 06:36, Pablo Pazos 
<pablo.pa...@cabolabs.com<mailto:pablo.pa...@cabolabs.com>> wrote:
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: 
Tested on the Ocean's archetype editor and they use:

constraint_bindings = <
        ["SNOMED-CT"] = <
            items = <
                ["ac0001"] = <terminology:SNOMED-CT/release?subset=cabolabs>

On Mon, Apr 24, 2017 at 7:33 PM, Bjørn Næss <b...@dips.no<mailto:b...@dips.no>> 
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?

 <value xsi:type="DV_CODED_TEXT">
                    <value>Høyre øye</value>

Vennlig hilsen
Bjørn Næss

Mobil +47 93 43 29 10<tel:+47%2093%2043%2029%2010>

openEHR-implementers mailing list

Ing. Pablo Pazos Gutiérrez
Cel:(00598) 99 043 145
Skype: cabolabs

Subscribe to our newsletter<http://eepurl.com/b_w_tj>

openEHR-technical mailing list
Ian McNicoll


openEHR-technical mailing list




Thomas Beale
Management Board, Specifications Program Lead, openEHR 
Chartered IT Professional Fellow, BCS, British Computer 
Health IT blog<http://wolandscat.net/> | Culture 

openEHR-technical mailing list

Reply via email to