Re: SNOMEDCT - correct representation

We should not understand the namespace "snomed-ct" in this way; instead it should resolve to whatever SNOMED there is in the local termology service, which might be some Norway national thing, or Spanish regional server etc. So the expected national extensions and translations would be

Re: SNOMEDCT - correct representation

I totally agree with that, my argument was more about considering *only* syntax improvements without considering tooling and modeler's issues / challenges. As a techie also I like simple and clear formalisms, but we can also read "machine code", so we might need a "simple enough" solution for

Re: SNOMEDCT - correct representation

Hi Pablo, for clinical modellers I completely agree. It is mostly technical people - tool writers who work with the syntax form of things. But at the end of the day, it is them who build the systems and who must understand every last subtlety of the semantics of any of the languages we use -

Re: SNOMEDCT - correct representation

I really believe we should be teaching using tools not reading syntax, specially for clinical modelers. If we are doing that right now is because tools lack usability, features and maturity. For techies, we like to look at the syntax because we need to parse and process it. I'm not against

SNOMEDCT - correct representation

Hi, First this, because of some technical issue at my provider, all my emails of yesterday are gone, I am now replying from the mail-archive of OpenEHR. So I can not reply inline. --- I favour the idea of having an explaining-comment-feature for the terminology

Re: SNOMEDCT - correct representation

Bert there is no resistance, in fact I at least agree with your general idea - see my other post. Just a question of getting the analysis right, implementing it and releasing a specification update. Then retroatively fitting it to ADL 1.4 (now we need ADL 1.5 ;) - thomas On 16/05/2017

Re: SNOMEDCT - correct representation

not at all - a lot of people work with ADL, ODIN, BMM, JSON etc in plain text for teaching, development of test archetypes, test data, looking at data, making small systems etc. - thomas On 16/05/2017 13:22, Pablo Pazos wrote: it would be good to ask them why they do that, maybe is for

Re: SNOMEDCT - correct representation

If anyone knows an editor that does ADL2 and supports enough options to make editing by hand no longer needed, we're interested. Regards, Pieter Bos Op 16 mei 2017 om 18:23 heeft Pablo Pazos > het volgende geschreven: it would be

Re: SNOMEDCT - correct representation

Sorry, I cannot reply now, I reply tomorrow Bert On 16-05-17 18:25, Thomas Beale wrote: I think this idea is probably right, in some form. You can see the current formal definitions for the terminology structures here (ADL2

Re: SNOMEDCT - correct representation

I think this idea is probably right, in some form. You can see the current formal definitions for the terminology structures here (ADL2 , AOM2

Re: SNOMEDCT - correct representation

On 16-05-17 18:14, Thomas Beale wrote: sure. But there are a lot that do, just not the ones you know ;) We have to make things work for everyone. So what about my suggestion a few weeks ago, to add a comment-section to a terminology-binding url to explain what the url does. Most people

Re: SNOMEDCT - correct representation

it would be good to ask them why they do that, maybe is for limitations on the modeling tools, or maybe they are cyborgs in disguise. On Tue, May 16, 2017 at 1:14 PM, Thomas Beale wrote: > > sure. But there are a lot that do, just not the ones you know ;) We have > to

Re: SNOMEDCT - correct representation

sure. But there are a lot that do, just not the ones you know ;) We have to make things work for everyone. - thomas On 16/05/2017 13:08, Bert Verhees wrote: Most creators or users of archetypes I know, completely depend on tooling. They are never capable to read an ADL text, nor do they

Re: SNOMEDCT - correct representation

Most creators or users of archetypes I know, completely depend on tooling. They are never capable to read an ADL text, nor do they ever want to read it. And as I suggested, with smart text-editors http-url encoding can be easily translated/showed into readable url's On 16-05-17 16:06,

Re: SNOMEDCT - correct representation

Mentioned that in general, don't see the point of arguing about readability of things that are meant to be generated and processed by machines. not read or processed by a person. If modeling tools work as expected, no clinical modeler or terminologist should deal with "source code". But I get

Re: SNOMEDCT - correct representation

Hi Pablo, if you were talking XML or other such unreadable stuff I agree. But the whole point of context free grammars like programming languages, ADL, OWL, and also these SNOMED mini-languages is to be formal and human readable. It is via languages that humans learn the semantics of the

Re: SNOMEDCT - correct representation

Not sure why readability is a requirement here. Shouldn't those expressions be generated and consumed by systems? We should create simple to use GUIs not simple to read code :) On Wed, May 3, 2017 at 9:31 AM, Diego Boscá wrote: > Or just use the "Long syntax" as described in

Re: SNOMEDCT - correct representation

s.openehr.org> on behalf of Koray Atalag <k.ata...@auckland.ac.nz> Sent: Saturday, 6 May 2017 11:25 PM To: For openEHR technical discussions Subject: RE: SNOMEDCT - correct representation Hi Michael, You can only define and manage so many ECL valuesets and assign URIs – which is fine. Troub

RE: SNOMEDCT - correct representation

Of michael.law...@csiro.au Sent: Thursday, 4 May 2017 1:05 a.m. To: openehr-technical@lists.openehr.org Subject: [FORGED] Re: SNOMEDCT - correct representation I think this thread has gone a little off the rails. There are predefined (by FHIR) URIs for value sets that are defined just

Re: SNOMEDCT - correct representation

well, nothing stops you for not encoding the query in definition time, most services are ok with that e.g. http://diebosto2.pc.upv.es:/SnomedQuery/ws/JSONQuery?query= <404684003:363698007=39057004 2017-05-03 16:31 GMT+02:00 Thomas Beale : > > On 03/05/2017 13:31,

Re: SNOMEDCT - correct representation

On 03/05/2017 14:04, michael.law...@csiro.au wrote: I think this thread has gone a little off the rails. There are predefined (by FHIR) URIs for value sets that are defined just as descendants of a single concept, or members of a reference set. For an enumeration of concepts and/or a

Re: SNOMEDCT - correct representation

On 03/05/2017 13:31, Diego Boscá wrote: Or just use the "Long syntax" as described in point 5.2 from Expression Constraint Language, which keeps things readable enough http://snomed.info/ecl/descendantOrSelfOf 73211009 |Diabetes mellitus| at the very least, a %20 is needed for the spaces,

Re: SNOMEDCT - correct representation

I think this thread has gone a little off the rails. There are predefined (by FHIR) URIs for value sets that are defined just as descendants of a single concept, or members of a reference set. For an enumeration of concepts and/or a snomed ECL expression, then you can use a Fhir ValueSet and

Re: SNOMEDCT - correct representation

On 03-05-17 14:20, Thomas Beale wrote: that is seriously unreadable. I don't think that is a problem, all programming languages have libraries to en/decode that kind of strings, so archetype-tooling can do that without much programming effort, and also this can be done when copy and pasting

Re: SNOMEDCT - correct representation

Or just use the "Long syntax" as described in point 5.2 from Expression Constraint Language, which keeps things readable enough http://snomed.info/ecl/descendantOrSelfOf 73211009 |Diabetes mellitus| 2017-05-03 14:20 GMT+02:00 Thomas Beale : > Daniel, > > my fault -

Re: SNOMEDCT - correct representation

Daniel, my fault - didn't read the front page properly - the things we need are mooted for next release. But now I agree with Diego... The expression constraint "< 404684003|Clinical finding|: < 47429007|Associated with| = < 79654002 |Edema|" * http

Re: SNOMEDCT - correct representation

2017-05-03 13:09 GMT+02:00 Daniel Karlsson >: See this page: https://confluence.ihtsdotools.org/display/SLPG/SNOMED+CT+URI+Standard Please

Re: SNOMEDCT - correct representation

For the expression constraint language seems strange to encode the characters when there is already an official expression constraint language alternative that avoids these kinds of characters 2017-05-03 13:09 GMT+02:00 Daniel Karlsson : > See this page: >

Re: SNOMEDCT - correct representation

See this page: https://confluence.ihtsdotools.org/display/SLPG/SNOMED+CT+URI+Standard Please consider the language used when posting. /Daniel On May 3, 2017 13:03, Bert Verhees wrote: On 03-05-17 12:53, Thomas Beale wrote: On 03/05/2017 11:40, Bert Verhees wrote: On

Re: SNOMEDCT - correct representation

Seems like the only way right now is creating refsets and referencing them with standard URIs... 2017-05-03 13:02 GMT+02:00 Bert Verhees : > On 03-05-17 12:53, Thomas Beale wrote: > > On 03/05/2017 11:40, Bert Verhees wrote: > > On 03-05-17 12:36, Thomas Beale wrote: > >

Re: SNOMEDCT - correct representation

On 03-05-17 12:53, Thomas Beale wrote: On 03/05/2017 11:40, Bert Verhees wrote: On 03-05-17 12:36, Thomas Beale wrote: The only missing part, now that I look at the SNOMED Compositional Grammar and Expression Constraint Language

Re: SNOMEDCT - correct representation

On 03/05/2017 11:40, Bert Verhees wrote: On 03-05-17 12:36, Thomas Beale wrote: The only missing part, now that I look at the SNOMED Compositional Grammar and Expression Constraint Language

Re: SNOMEDCT - correct representation

On 03-05-17 12:36, Thomas Beale wrote: 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

Re: SNOMEDCT - correct representation

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

Re: SNOMEDCT - correct representation

Hi Koray, On 03/05/2017 10:41, Koray Atalag wrote: 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

Re: SNOMEDCT - correct representation

;mailto:openehr-technical@lists.openehr.org> 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 name

RE: SNOMEDCT - correct representation

...@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. Cheers, -koray From: openEHR-technical [mailto:openehr-technical-boun

Re: SNOMEDCT - correct representation

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 On ons, 2017-04-26 at

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

RE: SNOMEDCT - correct representation

l 2017 08.03 To: For openEHR technical discussions <openehr-technical@lists.openehr.org>; For openEHR implementation discussions <openehr-implement...@lists.openehr.org> Subject: Re: SNOMEDCT - correct representation SNOMED-CT is the official designator, based on the archetype editor

Re: SNOMEDCT - correct representation

But you probably need to define national extensions in constraint binding in templates. Templates are archetypes in the end 2017-04-25 11:47 GMT+02:00 Bert Verhees : > On 25-04-17 09:50, Diego Boscá wrote: > >> I think having this in a hardcoded terminology list is probably

Re: SNOMEDCT - correct representation

This should be used as the name at least then 2017-04-25 10:08 GMT+02:00 : > > There is a spec that tells you how to identify different editions and > versions of SNOMED CT - see http://snomed.org/uri > > In short, http://snomed.info/sct is the identifier for any version

Re: SNOMEDCT - correct representation

There is a spec that tells you how to identify different editions and versions of SNOMED CT - see http://snomed.org/uri In short, http://snomed.info/sct is the identifier for any version of SNOMED CT. for the Norway extension you need to know which module it is in (this is what will be used

Re: SNOMEDCT - correct representation

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?) 2017-04-25 8:03 GMT+02:00 Ian McNicoll : > SNOMED-CT is the

Re: SNOMEDCT - correct representation

SNOMED-CT is the official designator, based on the archetype editor terminology list. On Tue, 25 Apr 2017 at 06:36, Pablo Pazos wrote: > Congratulations about the new adoption! > > The IHTSDO recommends to use exactly "SNOMED CT" as the *name*, in our > specs we are

Re: SNOMEDCT - correct representation

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

SNOMEDCT - correct representation

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