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 <[email protected]>: > 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 <[email protected]> > <[email protected]> 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 > [email protected]http://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 > [email protected] > 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 [email protected] [email protected] 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 [email protected].
_______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
