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 <thomas.be...@openehr.org>:

> 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
>    <http://snomed.info/ecl/%3c404684003:%3c%3c47429007=%3c%3c79654002>
>    ://snomed.info/ecl/%
>    <http://snomed.info/ecl/%3c404684003:%3c%3c47429007=%3c%3c79654002>
>    3C404684003%3A%3C%3C47429007%3D%3C%3C79654002
>    <http://snomed.info/ecl/%3c404684003:%3c%3c47429007=%3c%3c79654002>
>
>
> that is seriously unreadable. In a different universe, we would have hoped
> for something like:
>
> http://snomed.info/ecl/<404684003:<47429007=<79654002
>
> but of course that is illegal in URI syntax.
>
> In terms of what we put in archetype bindings, I start to wonder. Could it
> make sense to allow:
>
>    - proper URIs for single terms, value set refs, module refs etc (all
>    the URIs that only include a single SCT code)
>    - post-coordinated expressions in their syntax form
>    - constraint expressions in their syntax form
>
> where the latter two would be understood as standing for their equivalent
> URIs? That's an awful hack though.
>
> A more consistent argument would be to revert to not using URIs in
> bindings, and use just codes and expressions.
>
> The problem with doing that is that the ID concept URIs include useful
> things like /id, /module, /field, etc.
>
> If we just go with the kind of URIs like the above, archetype bindings
> will cease to be self-documenting. I am starting to think we need an
> expression syntax that covers all of:
>
>    - single term references, including to SNOMED codes, modules,
>    versions, ....
>    - SNOMED post-coordinated expressions
>    - SNOMED constraint expressions
>    - and... the equivalent for non-SNOMED codes, e.g. LOINC, ICDx, ICF,
>    etc etc
>
> We still don't have a universal terminology referencing mechanism, but
> it's what I think we need. It could in theory be achieved with the use of a
> new 'terminology' scheme space, thus:
>
>    <  19829001 |Disorder of lung| <http://snomed.info/id/19829001>  and <
>  301867009 |Edema of trunk| <http://snomed.info/id/301867009>
>
> becomes
>
> terminology:/snomed-ct/ecf/value="<  19829001 |Disorder of lung|
> <http://snomed.info/id/19829001>  and <  301867009 |Edema of trunk|"
> <http://snomed.info/id/301867009>
>
> (I won't try to work out the nicest syntax, let's just say we agree that
> we could find one)
>
> This would allow URIs of the form
>
> terminology:/loinc/xyz/something-loinc-ish
>
> and so on.
>
> The sole purpose of a terminology scheme space might just be to establish
> a universal id space whose ids are readable, structured strings, that can
> be machine-converted to real URIs for SNOMED, but also LOINC, ICDx, HL7,
> and all the other terminologies.
>
> - thomas
>
> On 03/05/2017 12:09, Daniel Karlsson wrote:
>
> 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 <bert.verh...@rosa.nl>
> <bert.verh...@rosa.nl> wrote:
>
> 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
> <https://confluence.ihtsdotools.org/display/DOCSCG> and Expression
> Constraint Language <https://confluence.ihtsdotools.org/display/DOCECL>
> specs, is how to create a URI (which is the type of a term binding in ADL2
> <http://www.openehr.org/releases/AM/latest/docs/AOM2/AOM2.html#_terminology_package>)
> 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.
>
>
> The URI spec is here
> <https://confluence.ihtsdotools.org/display/SLPG/SNOMED+CT+URI+Standard>,
> but it doesn't address URIs for expressions either.
>
> (All the SNOMED language specs appear to be here
> <https://confluence.ihtsdotools.org/display/SLPG/SNOMED+CT+Computable+Languages>
> these days - nice and convenient, and also nicely published. We probably
> should go back to linking to them somewhere on the openEHR site).
>
>
> 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
>
>
>
>
> _______________________________________________
> openEHR-technical mailing 
> listopenEHR-technical@lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
>
> --
> Thomas Beale
> Principal, Ars Semantica <http://www.arssemantica.com>
> Consultant, ABD Team, Intermountain Healthcare
> <https://intermountainhealthcare.org/>
> Management Board, Specifications Program Lead, openEHR Foundation
> <http://www.openehr.org>
> Chartered IT Professional Fellow, BCS, British Computer Society
> <http://www.bcs.org/category/6044>
> Health IT blog <http://wolandscat.net/> | Culture blog
> <http://wolandsothercat.net/>
>
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>



-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/000001C268PZ>

[image: Twitter]  <https://htmlsig.com/t/000001C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/000001C4DPJG> [image: Maps]
<https://htmlsig.com/t/000001BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 961071863 <+34%20961%2007%2018%2063> / +34 627015023
<+34%20627%2001%2050%2023>
www.veratech.es

Su dirección de correo electrónico junto a sus datos personales forman
parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley
Orgánica 15/1999, usted puede ejercitar sus derechos de acceso,
rectificación, cancelación y, en su caso oposición, enviando una solicitud
por escrito a verat...@veratech.es.
_______________________________________________
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Reply via email to